[PATCH 0/2] DRA72/DRA74: Add 2 lane support

2016-01-06 Thread Kishon Vijay Abraham I
Add driver modifications in pci-dra7xx to get x2 mode working in
DRA72 and DRA74. Certain modifications is needed in PHY driver also
which will be sent as a separate series.

Certain board modifications has to be done in order to test
x2 mode in dra72-evm.

These patches were created on pci next.

Changes from RFC:
*) .b1co_mode_sel_mask is now set with the correct value.
*) cleanup the patch

Kishon Vijay Abraham I (2):
  pci: host: pci-dra7xx: use "num-lanes" property to find phy count
  pci: host: pci-dra7xx: Enable x2 mode support

 Documentation/devicetree/bindings/pci/ti-pci.txt |8 +-
 drivers/pci/host/pci-dra7xx.c|  104 +++---
 2 files changed, 97 insertions(+), 15 deletions(-)

-- 
1.7.9.5

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


[PATCH 1/2] phy: ti-pipe3: get tx and rx MEM resource

2016-01-06 Thread Kishon Vijay Abraham I
get tx and rx MEM resource since this has to be used to configure
for DRA72x to work in X2 mode.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Signed-off-by: Sekhar Nori <nsek...@ti.com>
---
 drivers/phy/phy-ti-pipe3.c |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 0a477d2..7d83d2b 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -91,6 +91,8 @@ struct pipe3_dpll_map {
 
 struct ti_pipe3 {
void __iomem*pll_ctrl_base;
+   void __iomem*phy_rx;
+   void __iomem*phy_tx;
struct device   *dev;
struct device   *control_dev;
struct clk  *wkupclk;
@@ -536,6 +538,27 @@ static int ti_pipe3_get_pll_base(struct ti_pipe3 *phy)
return 0;
 }
 
+static int ti_pipe3_get_rx_tx_base(struct ti_pipe3 *phy)
+{
+   struct resource *res;
+   struct device *dev = phy->dev;
+   struct platform_device *pdev = to_platform_device(dev);
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "phy_rx");
+   phy->phy_rx = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(phy->phy_rx))
+   return PTR_ERR(phy->phy_rx);
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "phy_tx");
+   phy->phy_tx = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(phy->phy_tx))
+   return PTR_ERR(phy->phy_tx);
+
+   return 0;
+}
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
struct ti_pipe3 *phy;
@@ -555,6 +578,10 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ret = ti_pipe3_get_rx_tx_base(phy);
+   if (ret)
+   return ret;
+
ret = ti_pipe3_get_sysctrl(phy);
if (ret)
return ret;
-- 
1.7.9.5

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


[PATCH 2/2] pci: host: pci-dra7xx: Enable x2 mode support

2016-01-06 Thread Kishon Vijay Abraham I
Perform syscon configurations to get x2 mode to working in DRA74x and
DRA72x. Also add a new compatible string to dfferentiate
DRA72x and DRA74x, since b1c0 mask is different for both these platforms.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 Documentation/devicetree/bindings/pci/ti-pci.txt |8 ++-
 drivers/pci/host/pci-dra7xx.c|   81 +-
 2 files changed, 86 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e2516..0b10e84 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,7 +1,9 @@
 TI PCI Controllers
 
 PCIe Designware Controller
- - compatible: Should be "ti,dra7-pcie""
+ - compatible: "ti,dra7-pcie" is deprecated
+  Should be "ti,dra746-pcie" for DRA74x
+  Should be "ti,dra726-pcie" for DRA72x
  - reg : Two register ranges as listed in the reg-names property
  - reg-names : The first entry must be "ti-conf" for the TI specific registers
   The second entry must be "rc-dbics" for the designware pcie
@@ -14,6 +16,10 @@ PCIe Designware Controller
   where  is the instance number of the pcie from the HW spec.
  - interrupts : Two interrupt entries must be specified. The first one is for
main interrupt line and the second for MSI interrupt line.
+ - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
module and the
+   register offset to specify 1 lane or 2 lane.
+ - syscon-lane-sel : phandle/offset pair. Phandle to the system control module 
and the
+   register offset to specify lane selection.
  - #address-cells,
#size-cells,
#interrupt-cells,
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 05bbeee..dac216f 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -22,9 +22,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #include 
 
@@ -67,14 +69,22 @@
 #defineLINK_UP BIT(16)
 #defineDRA7XX_CPU_TO_BUS_ADDR  0x0FFF
 
+#define PCIE_1LANE_2LANE_SELECTION BIT(13)
+#define PCIE_B1C0_MODE_SEL BIT(2)
+
 struct dra7xx_pcie {
void __iomem*base;
+   u32 *b1c0_mask;
struct phy  **phy;
int lanes;
struct device   *dev;
struct pcie_portpp;
 };
 
+struct dra7xx_pcie_data {
+   u32 b1co_mode_sel_mask;
+};
+
 #define to_dra7xx_pcie(x)  container_of((x), struct dra7xx_pcie, pp)
 
 static inline u32 dra7xx_pcie_readl(struct dra7xx_pcie *pcie, u32 offset)
@@ -358,6 +368,57 @@ static int dra7xx_pcie_reset(struct platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id of_dra7xx_pcie_match[];
+
+static int dra7xx_pcie_configure_two_lane(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct regmap *pcie_syscon;
+   unsigned int pcie_reg;
+   struct dra7xx_pcie_data *data;
+   const struct of_device_id *match;
+
+   match = of_match_device(of_dra7xx_pcie_match, dev);
+   if (!match)
+   return -EINVAL;
+
+   data = (struct dra7xx_pcie_data *)match->data;
+   if (!data) {
+   dev_err(dev, "no b1c0 mask data\n");
+   return -EINVAL;
+   }
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-conf");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-conf\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-conf", 1, _reg)) {
+   dev_err(dev, "couldn't get lane configuration reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, PCIE_1LANE_2LANE_SELECTION,
+  PCIE_1LANE_2LANE_SELECTION);
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-sel");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-sel\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-sel", 1, _reg)) {
+   dev_err(dev, "couldn't get lane selection reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, data->b1co_mode_sel_mask,
+  PCIE_B1C0_MODE_SEL);
+
+   return 0;
+}
+
 static int __init dra7xx_pcie_probe(struct platform_device *pdev)
 {
u3

[PATCH 1/2] pci: host: pci-dra7xx: use "num-lanes" property to find phy count

2016-01-06 Thread Kishon Vijay Abraham I
use "num-lanes" property to find phy count instead of the number
phy-names property.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Signed-off-by: Sekhar Nori <nsek...@ti.com>
---
 drivers/pci/host/pci-dra7xx.c |   23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 5963adc..05bbeee 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -70,7 +70,7 @@
 struct dra7xx_pcie {
void __iomem*base;
struct phy  **phy;
-   int phy_count;
+   int lanes;
struct device   *dev;
struct pcie_portpp;
 };
@@ -364,7 +364,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
int ret;
int irq;
int i;
-   int phy_count;
+   u32 lanes;
struct phy **phy;
void __iomem *base;
struct resource *res;
@@ -402,17 +402,16 @@ static int __init dra7xx_pcie_probe(struct 
platform_device *pdev)
if (!base)
return -ENOMEM;
 
-   phy_count = of_property_count_strings(np, "phy-names");
-   if (phy_count < 0) {
-   dev_err(dev, "unable to find the strings\n");
-   return phy_count;
+   if (of_property_read_u32(np, "num-lanes", )) {
+   dev_err(dev, "Failed to parse the number of lanes\n");
+   return -EINVAL;
}
 
-   phy = devm_kzalloc(dev, sizeof(*phy) * phy_count, GFP_KERNEL);
+   phy = devm_kzalloc(dev, sizeof(*phy) * lanes, GFP_KERNEL);
if (!phy)
return -ENOMEM;
 
-   for (i = 0; i < phy_count; i++) {
+   for (i = 0; i < lanes; i++) {
snprintf(name, sizeof(name), "pcie-phy%d", i);
phy[i] = devm_phy_get(dev, name);
if (IS_ERR(phy[i]))
@@ -432,7 +431,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
dra7xx->base = base;
dra7xx->phy = phy;
dra7xx->dev = dev;
-   dra7xx->phy_count = phy_count;
+   dra7xx->lanes = lanes;
 
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
@@ -489,7 +488,7 @@ static int __exit dra7xx_pcie_remove(struct platform_device 
*pdev)
struct dra7xx_pcie *dra7xx = platform_get_drvdata(pdev);
struct pcie_port *pp = >pp;
struct device *dev = >dev;
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
if (pp->irq_domain)
irq_domain_remove(pp->irq_domain);
@@ -535,7 +534,7 @@ static int dra7xx_pcie_resume(struct device *dev)
 static int dra7xx_pcie_suspend_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
while (count--) {
phy_power_off(dra7xx->phy[count]);
@@ -548,7 +547,7 @@ static int dra7xx_pcie_suspend_noirq(struct device *dev)
 static int dra7xx_pcie_resume_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int phy_count = dra7xx->phy_count;
+   int phy_count = dra7xx->lanes;
int ret;
int i;
 
-- 
1.7.9.5

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


[PATCH 0/2] dra72: add support for PCIE 2 lane mode

2016-01-06 Thread Kishon Vijay Abraham I
dra72 reuse the USB PHY for the PCIe 2n lane. So in order for PCIe x2 mode
to work in dra72, certain special configuration has to be made in
USB PHY. This patch series adds those configurations.

In order to enable PCIe x2 mode in DRA72, USB should be disabled.

Certain board modifications has to be done in order to test
x2 mode in dra72-evm.

Patch series is rebased on top of linux-phy next

Kishon Vijay Abraham I (2):
  phy: ti-pipe3: get tx and rx MEM resource
  phy: ti-pipe3: configure usb3 phy to be used as pcie phy

 Documentation/devicetree/bindings/phy/ti-phy.txt |2 +
 drivers/phy/phy-ti-pipe3.c   |   57 +-
 2 files changed, 58 insertions(+), 1 deletion(-)

-- 
1.7.9.5

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


[PATCH 2/2] phy: ti-pipe3: configure usb3 phy to be used as pcie phy

2016-01-06 Thread Kishon Vijay Abraham I
DRA72 uses USB3 PHY for the 2nd lane of PCIE. The configuration
required to make USB3 PHY used for the 2nd lane of PCIe is done
here.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
 drivers/phy/phy-ti-pipe3.c   |   30 +-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index a3b3945..6a7de94 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -91,6 +91,8 @@ Optional properties:
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
  - syscon-pcs : phandle/offset pair. Phandle to the system control module and 
the
register offset to write the PCS delay value.
+ - "ti,configure-as-pcie" : property to indicate if the PHY should be
+   configured as PCIE PHY.
 
 Deprecated properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 7d83d2b..793185e 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -56,6 +56,12 @@
 
 #define SATA_PLL_SOFT_RESETBIT(18)
 
+#define PHY_RX_ANA_PRGRAMMABILITY_REG  0xC
+#define MEM_EN_PLLBYP  BIT(7)
+
+#define PHY_TX_TEST_CONFIG 0x2C
+#define MEM_ENTESTCLK  BIT(31)
+
 #define PIPE3_PHY_PWRCTL_CLK_CMD_MASK  0x003FC000
 #define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
 
@@ -68,6 +74,10 @@
 #define PCIE_PCS_MASK  0xFF
 #define PCIE_PCS_DELAY_COUNT_SHIFT 0x10
 
+#define PIPE3_PHY_DISABLE_SYNC_POWER   BIT(4)
+
+#define CONFIGURE_AS_PCIE  BIT(0)
+
 /*
  * This is an Empirical value that works, need to confirm the actual
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -90,6 +100,7 @@ struct pipe3_dpll_map {
 };
 
 struct ti_pipe3 {
+   u32 flags;
void __iomem*pll_ctrl_base;
void __iomem*phy_rx;
void __iomem*phy_tx;
@@ -270,6 +281,19 @@ static int ti_pipe3_init(struct phy *x)
int ret = 0;
 
ti_pipe3_enable_clocks(phy);
+
+   if (phy->flags & CONFIGURE_AS_PCIE) {
+   val = ti_pipe3_readl(phy->phy_rx,
+PHY_RX_ANA_PRGRAMMABILITY_REG);
+   val |= MEM_EN_PLLBYP;
+   ti_pipe3_writel(phy->phy_rx, PHY_RX_ANA_PRGRAMMABILITY_REG,
+   val);
+   val = ti_pipe3_readl(phy->phy_tx, PHY_TX_TEST_CONFIG);
+   val |= MEM_ENTESTCLK;
+   ti_pipe3_writel(phy->phy_tx, PHY_TX_TEST_CONFIG, val);
+   return 0;
+   }
+
/*
 * Set pcie_pcs register to 0x96 for proper functioning of phy
 * as recommended in AM572x TRM SPRUHZ6, section 18.5.2.2, table
@@ -318,7 +342,8 @@ static int ti_pipe3_exit(struct phy *x)
return 0;
 
/* PCIe doesn't have internal DPLL */
-   if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
+   if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie") &&
+   !(phy->flags & CONFIGURE_AS_PCIE)) {
/* Put DPLL in IDLE mode */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
val |= PLL_IDLE;
@@ -590,6 +615,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   if (of_property_read_bool(node, "ti,configure-as-pcie"))
+   phy->flags |= CONFIGURE_AS_PCIE;
+
platform_set_drvdata(pdev, phy);
pm_runtime_enable(dev);
 
-- 
1.7.9.5

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


Re: Nokia N900: u-SD card in v4.2+

2016-01-06 Thread Kishon Vijay Abraham I
Hi,

On Thursday 07 January 2016 02:16 AM, Pavel Machek wrote:
> Hi!
> 
> In v4.1, both internal MMC and u-SD cards work ok.
> 
> In v4.2, only the internal MMC is detected. In v4.3, not even internal
> MMC works. In v4.4, only the internal MMC is detected.
> 
> Does it work for you? Any patches?

I don't have Nokia N900 to check this, but can you share your config and kernel
logs? Check if CONFIG_REGULATOR_PBIAS is present in your config.
CONFIG_REGULATOR_PBIAS is now mandatory for all omap3+ SoCs to work.

Thanks
Kishon

> 
> (I do have hack in the dts to disable back cover detection...)
> 
>   Pavel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] pci: host: pci-dra7xx: Enable x2 mode support

2016-01-06 Thread Kishon Vijay Abraham I
Hi,

On Wednesday 06 January 2016 07:43 PM, Rob Herring wrote:
> On Wed, Jan 06, 2016 at 04:19:53PM +0530, Kishon Vijay Abraham I wrote:
>> Perform syscon configurations to get x2 mode to working in DRA74x and
>> DRA72x. Also add a new compatible string to dfferentiate
>> DRA72x and DRA74x, since b1c0 mask is different for both these platforms.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>> ---
>>  Documentation/devicetree/bindings/pci/ti-pci.txt |8 ++-
>>  drivers/pci/host/pci-dra7xx.c|   81 
>> +-
>>  2 files changed, 86 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
>> b/Documentation/devicetree/bindings/pci/ti-pci.txt
>> index 60e2516..0b10e84 100644
>> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
>> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
>> @@ -1,7 +1,9 @@
>>  TI PCI Controllers
>>  
>>  PCIe Designware Controller
>> - - compatible: Should be "ti,dra7-pcie""
>> + - compatible: "ti,dra7-pcie" is deprecated
>> +   Should be "ti,dra746-pcie" for DRA74x
>> +   Should be "ti,dra726-pcie" for DRA72x
>>   - reg : Two register ranges as listed in the reg-names property
>>   - reg-names : The first entry must be "ti-conf" for the TI specific 
>> registers
>> The second entry must be "rc-dbics" for the designware pcie
>> @@ -14,6 +16,10 @@ PCIe Designware Controller
>> where  is the instance number of the pcie from the HW spec.
>>   - interrupts : Two interrupt entries must be specified. The first one is 
>> for
>>  main interrupt line and the second for MSI interrupt line.
>> + - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
>> module and the
>> +   register offset to specify 1 lane or 2 lane.
>> + - syscon-lane-sel : phandle/offset pair. Phandle to the system control 
>> module and the
>> +   register offset to specify lane selection.
> 
> These should have a ti prefix.

Okay. Will fix that and post a new version.

Thanks
Kishon
> 
>>   - #address-cells,
>> #size-cells,
>> #interrupt-cells,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 6/9] phy: ti-pipe3: use *syscon* framework API to power on/off the PHY

2015-12-21 Thread Kishon Vijay Abraham I
Hi

On Sunday 20 December 2015 09:08 AM, Rob Herring wrote:
> On Tue, Dec 15, 2015 at 02:46:05PM +0530, Kishon Vijay Abraham I wrote:
>> Deprecate using phy-omap-control driver to power on/off the PHY and
>> use *syscon* framework to do the same.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>> ---
>>  Documentation/devicetree/bindings/phy/ti-phy.txt |   10 ++-
>>  drivers/phy/phy-ti-pipe3.c   |   90 
>> ++
>>  2 files changed, 85 insertions(+), 15 deletions(-)
> 
> For the binding:
> 
> Acked-by: Rob Herring <r...@kernel.org>
> 
> One comment on the driver though.
> 
> [...]
> 
>> --- a/drivers/phy/phy-ti-pipe3.c
>> +++ b/drivers/phy/phy-ti-pipe3.c
> 
> [...]
> 
>> @@ -144,18 +155,53 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3 
>> *phy);
>>  
>>  static int ti_pipe3_power_off(struct phy *x)
>>  {
>> +u32 val;
>> +int ret;
>>  struct ti_pipe3 *phy = phy_get_drvdata(x);
>>  
>> -omap_control_phy_power(phy->control_dev, 0);
>> +if (phy->phy_power_syscon) {
> 
> Writing this as:
> 
> if (!phy->phy_power_syscon) {
>   ...
>   return 0;
> }
> 
> //regmap code
> 
> 
> will make it simpler to remove the deprecated code later.

hmm.. I will make this change in all the applicable patches.

Thanks
Kishon
> 
> 
>> +val = PIPE3_PHY_TX_RX_POWEROFF <<
>> +PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
>> +
>> +ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
>> + PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
>> +if (ret < 0)
>> +return ret;
>> +} else {
>> +omap_control_phy_power(phy->control_dev, 0);
>> +}
>>  
>>  return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

2015-12-21 Thread Kishon Vijay Abraham I
Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..9ab7b6a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+   scm_conf_pcie: scm_conf@1c24 {
+   compatible = "syscon";
+   reg = <0x1c24 0x0024>;
+   };
};
 
cm_core_aon: cm_core_aon@5000 {
-- 
1.7.9.5

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


[PATCH v4 3/4] ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2 PHY2

2015-12-21 Thread Kishon Vijay Abraham I
The USB2 PHY2 has a different register map compared to USB2 PHY1
to power on/off the PHY. In order to handle it, use the new compatible
string "ti,dra7x-usb2-phy2" for the second instance of USB2 PHY.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 41a3d35..7d35b94 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1299,7 +1299,8 @@
};
 
usb2_phy2: phy@4a085000 {
-   compatible = "ti,omap-usb2";
+   compatible = "ti,dra7x-usb2-phy2",
+"ti,omap-usb2";
reg = <0x4a085000 0x400>;
ctrl-module = <_control_usb2phy2>;
clocks = <_phy2_always_on_clk32k>,
-- 
1.7.9.5

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


[PATCH v4 2/4] ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY node

2015-12-21 Thread Kishon Vijay Abraham I
Add "syscon-phy-power" property and "syscon-pcs" property which can
be used to perform the control module initializations and remove
the deprecated "ctrl-module" property from PCIe PHY dt nodes.

Phandle to "sysclk" clock node is also added to the PCIe PHY node
since some of the syscon initializations is based on system clock
frequency.

Since "omap_control_pcie1phy" and "omap_control_pcie2phy" devicetree
nodes are no longer used, remove it.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |   33 ++---
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9ab7b6a..41a3d35 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1204,16 +1204,18 @@
reg = <0x4a094000 0x80>, /* phy_rx */
  <0x4a094400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie1phy>;
+   syscon-phy-power = <_conf_pcie 0x1c>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy1_32khz>,
 <_pciephy1_clk>,
 <_pciephy1_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
};
 
@@ -1222,16 +1224,18 @@
reg = <0x4a095000 0x80>, /* phy_rx */
  <0x4a095400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie2phy>;
+   syscon-phy-power = <_conf_pcie 0x20>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy2_32khz>,
 <_pciephy2_clk>,
 <_pciephy2_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
status = "disabled";
};
@@ -1247,23 +1251,6 @@
ti,hwmods = "sata";
};
 
-   omap_control_pcie1phy: control-phy@0x4a003c40 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c40 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
-   omap_control_pcie2phy: control-pcie@0x4a003c44 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c44 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   status = "disabled";
-   };
-
rtc: rtc@48838000 {
compatible = "ti,am3352-rtc";
reg = <0x48838000 0x100>;
-- 
1.7.9.5

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


[PATCH v4 4/4] ARM: dts: : Use "syscon-phy-power" instead of "ctrl-module"

2015-12-21 Thread Kishon Vijay Abraham I
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from SATA and USB PHY node. Also remove the unused control
module dt nodes.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/am4372.dtsi |   16 ++--
 arch/arm/boot/dts/dra7.dtsi   |   34 --
 arch/arm/boot/dts/omap5.dtsi  |   26 +++---
 3 files changed, 9 insertions(+), 67 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..f42d4a4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -853,18 +853,6 @@
status = "disabled";
};
 
-   am43xx_control_usb2phy1: control-phy@44e10620 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10620 0x4>;
-   reg-names = "power";
-   };
-
-   am43xx_control_usb2phy2: control-phy@0x44e10628 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10628 0x4>;
-   reg-names = "power";
-   };
-
ocp2scp0: ocp2scp@483a8000 {
compatible = "ti,am437x-ocp2scp", "ti,omap-ocp2scp";
#address-cells = <1>;
@@ -875,7 +863,7 @@
usb2_phy1: phy@483a8000 {
compatible = "ti,am437x-usb2";
reg = <0x483a8000 0x8000>;
-   ctrl-module = <_control_usb2phy1>;
+   syscon-phy-power = <_conf 0x620>;
clocks = <_phy0_always_on_clk32k>,
 <_otg_ss0_refclk960m>;
clock-names = "wkupclk", "refclk";
@@ -894,7 +882,7 @@
usb2_phy2: phy@483e8000 {
compatible = "ti,am437x-usb2";
reg = <0x483e8000 0x8000>;
-   ctrl-module = <_control_usb2phy2>;
+   syscon-phy-power = <_conf 0x628>;
clocks = <_phy1_always_on_clk32k>,
 <_otg_ss1_refclk960m>;
clock-names = "wkupclk", "refclk";
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 7d35b94..8a1c0c4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1170,14 +1170,6 @@
status = "disabled";
};
 
-   omap_control_sata: control-phy@4a002374 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002374 0x4>;
-   reg-names = "power";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp";
@@ -1192,7 +1184,7 @@
  <0x4A096400 0x64>, /* phy_tx */
  <0x4A096800 0x40>; /* pll_ctrl */
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
-   ctrl-module = <_control_sata>;
+   syscon-phy-power = <_conf 0x374>;
clocks = <_clkin1>, <_ref_clk>;
clock-names = "sysclk", "refclk";
syscon-pllreset = <_conf 0x3fc>;
@@ -1260,24 +1252,6 @@
clocks = <_32k_ck>;
};
 
-   omap_control_usb2phy1: control-phy@4a002300 {
-   compatible = "ti,control-phy-usb2";
-   reg = <0x4a002300 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb3phy1: control-phy@4a002370 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002370 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb2phy2: control-phy@0x4a002e74 {
-   compatible = "ti,control-phy-usb2-dra7";
-   reg = <0x4a002e74 0x4>;
-   reg-names = "power";
-   };
-

[PATCH v4 4/4] ARM: dts: : Use "syscon-phy-power" instead of "ctrl-module"

2015-12-21 Thread Kishon Vijay Abraham I
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from SATA and USB PHY node. Also remove the unused control
module dt nodes.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/am4372.dtsi |   16 ++--
 arch/arm/boot/dts/dra7.dtsi   |   34 --
 arch/arm/boot/dts/omap5.dtsi  |   26 +++---
 3 files changed, 9 insertions(+), 67 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..f42d4a4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -853,18 +853,6 @@
status = "disabled";
};
 
-   am43xx_control_usb2phy1: control-phy@44e10620 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10620 0x4>;
-   reg-names = "power";
-   };
-
-   am43xx_control_usb2phy2: control-phy@0x44e10628 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10628 0x4>;
-   reg-names = "power";
-   };
-
ocp2scp0: ocp2scp@483a8000 {
compatible = "ti,am437x-ocp2scp", "ti,omap-ocp2scp";
#address-cells = <1>;
@@ -875,7 +863,7 @@
usb2_phy1: phy@483a8000 {
compatible = "ti,am437x-usb2";
reg = <0x483a8000 0x8000>;
-   ctrl-module = <_control_usb2phy1>;
+   syscon-phy-power = <_conf 0x620>;
clocks = <_phy0_always_on_clk32k>,
 <_otg_ss0_refclk960m>;
clock-names = "wkupclk", "refclk";
@@ -894,7 +882,7 @@
usb2_phy2: phy@483e8000 {
compatible = "ti,am437x-usb2";
reg = <0x483e8000 0x8000>;
-   ctrl-module = <_control_usb2phy2>;
+   syscon-phy-power = <_conf 0x628>;
clocks = <_phy1_always_on_clk32k>,
 <_otg_ss1_refclk960m>;
clock-names = "wkupclk", "refclk";
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 7d35b94..8a1c0c4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1170,14 +1170,6 @@
status = "disabled";
};
 
-   omap_control_sata: control-phy@4a002374 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002374 0x4>;
-   reg-names = "power";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp";
@@ -1192,7 +1184,7 @@
  <0x4A096400 0x64>, /* phy_tx */
  <0x4A096800 0x40>; /* pll_ctrl */
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
-   ctrl-module = <_control_sata>;
+   syscon-phy-power = <_conf 0x374>;
clocks = <_clkin1>, <_ref_clk>;
clock-names = "sysclk", "refclk";
syscon-pllreset = <_conf 0x3fc>;
@@ -1260,24 +1252,6 @@
clocks = <_32k_ck>;
};
 
-   omap_control_usb2phy1: control-phy@4a002300 {
-   compatible = "ti,control-phy-usb2";
-   reg = <0x4a002300 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb3phy1: control-phy@4a002370 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002370 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb2phy2: control-phy@0x4a002e74 {
-   compatible = "ti,control-phy-usb2-dra7";
-   reg = <0x4a002e74 0x4>;
-   reg-names = "power";
-   };
-

[PATCH v4 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

2015-12-21 Thread Kishon Vijay Abraham I
Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..9ab7b6a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+   scm_conf_pcie: scm_conf@1c24 {
+   compatible = "syscon";
+   reg = <0x1c24 0x0024>;
+   };
};
 
cm_core_aon: cm_core_aon@5000 {
-- 
1.7.9.5

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


[PATCH v4 3/4] ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2 PHY2

2015-12-21 Thread Kishon Vijay Abraham I
The USB2 PHY2 has a different register map compared to USB2 PHY1
to power on/off the PHY. In order to handle it, use the new compatible
string "ti,dra7x-usb2-phy2" for the second instance of USB2 PHY.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 41a3d35..7d35b94 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1299,7 +1299,8 @@
};
 
usb2_phy2: phy@4a085000 {
-   compatible = "ti,omap-usb2";
+   compatible = "ti,dra7x-usb2-phy2",
+"ti,omap-usb2";
reg = <0x4a085000 0x400>;
ctrl-module = <_control_usb2phy2>;
clocks = <_phy2_always_on_clk32k>,
-- 
1.7.9.5

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


[PATCH v4 0/4] ARM: dts: use syscon property instead of ctrl-module

2015-12-21 Thread Kishon Vijay Abraham I
This series is basically to deprecate using ctrl-module property and use
corresponding syscon properties to program the control module registers.

Changes from v3:
*) Renamed 'tisyscon@1c24' node to 'scm_conf@1c24'

Changes from v2:
No changes.

Changes from v1:
*) Squashed the patches that replaces "ctrl-module" with
   "syscon-phy-power"
*) Added "syscon-phy-power" for SATA dt node in OMAP5 which was missed
   earlier
*) removed _ARM: dts: omap4: Use "syscon-otghs" instead of "ctrl-module"
   in USB node_. It will be done later.

Changes from [1] in PHY patches include
*) cleanup ti_pipe3_probe
*) have mask, power_on and power_off values in usb_phy_data for
   omap-usb2 phy

This series should be merged only after [2]
Kishon Vijay Abraham I (4):
  ARM: dts: dra7: Add dt node for the sycon pcie
  ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY
node
  ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2
PHY2
  ARM: dts: : Use "syscon-phy-power" instead of
"ctrl-module"

 arch/arm/boot/dts/am4372.dtsi |   16 ++---
 arch/arm/boot/dts/dra7.dtsi   |   75 -
 arch/arm/boot/dts/omap5.dtsi  |   26 ++
 3 files changed, 26 insertions(+), 91 deletions(-)

-- 
1.7.9.5

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


[RESEND PATCH v4 0/4] ARM: dts: use syscon property instead of ctrl-module

2015-12-21 Thread Kishon Vijay Abraham I
This series is basically to deprecate using ctrl-module property and use
corresponding syscon properties to program the control module registers.

Changes from v3:
*) Renamed 'tisyscon@1c24' node to 'scm_conf@1c24'

Changes from v2:
No changes.

Changes from v1:
*) Squashed the patches that replaces "ctrl-module" with
   "syscon-phy-power"
*) Added "syscon-phy-power" for SATA dt node in OMAP5 which was missed
   earlier
*) removed _ARM: dts: omap4: Use "syscon-otghs" instead of "ctrl-module"
   in USB node_. It will be done later.

Changes from [1] in PHY patches include
*) cleanup ti_pipe3_probe
*) have mask, power_on and power_off values in usb_phy_data for
   omap-usb2 phy

This series should be merged only after [2]
Kishon Vijay Abraham I (4):
  ARM: dts: dra7: Add dt node for the sycon pcie
  ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY
node
  ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2
PHY2
  ARM: dts: : Use "syscon-phy-power" instead of
"ctrl-module"

 arch/arm/boot/dts/am4372.dtsi |   16 ++---
 arch/arm/boot/dts/dra7.dtsi   |   75 -
 arch/arm/boot/dts/omap5.dtsi  |   26 ++
 3 files changed, 26 insertions(+), 91 deletions(-)

-- 
1.7.9.5

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


[PATCH v4 2/4] ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY node

2015-12-21 Thread Kishon Vijay Abraham I
Add "syscon-phy-power" property and "syscon-pcs" property which can
be used to perform the control module initializations and remove
the deprecated "ctrl-module" property from PCIe PHY dt nodes.

Phandle to "sysclk" clock node is also added to the PCIe PHY node
since some of the syscon initializations is based on system clock
frequency.

Since "omap_control_pcie1phy" and "omap_control_pcie2phy" devicetree
nodes are no longer used, remove it.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |   33 ++---
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9ab7b6a..41a3d35 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1204,16 +1204,18 @@
reg = <0x4a094000 0x80>, /* phy_rx */
  <0x4a094400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie1phy>;
+   syscon-phy-power = <_conf_pcie 0x1c>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy1_32khz>,
 <_pciephy1_clk>,
 <_pciephy1_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
};
 
@@ -1222,16 +1224,18 @@
reg = <0x4a095000 0x80>, /* phy_rx */
  <0x4a095400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie2phy>;
+   syscon-phy-power = <_conf_pcie 0x20>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy2_32khz>,
 <_pciephy2_clk>,
 <_pciephy2_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
status = "disabled";
};
@@ -1247,23 +1251,6 @@
ti,hwmods = "sata";
};
 
-   omap_control_pcie1phy: control-phy@0x4a003c40 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c40 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
-   omap_control_pcie2phy: control-pcie@0x4a003c44 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c44 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   status = "disabled";
-   };
-
rtc: rtc@48838000 {
compatible = "ti,am3352-rtc";
reg = <0x48838000 0x100>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY

2015-12-20 Thread Kishon Vijay Abraham I
Hi Rob,

On Sunday 20 December 2015 09:09 AM, Rob Herring wrote:
> On Tue, Dec 15, 2015 at 02:46:08PM +0530, Kishon Vijay Abraham I wrote:
>> Deprecate using phy-omap-control driver to power on/off the PHY,
>> and use *syscon* framework to do the same. This handles
>> powering on/off the PHY for the USB2 PHYs used in various TI SoCs.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>> ---
>>  Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
>>  drivers/phy/phy-omap-usb2.c  |   94 
>> ++
>>  include/linux/phy/omap_usb.h |   23 ++
>>  3 files changed, 107 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
>> b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> index 49e5b0c..a3b3945 100644
>> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> @@ -31,6 +31,8 @@ OMAP USB2 PHY
>>  
>>  Required properties:
>>   - compatible: Should be "ti,omap-usb2"
>> +   Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
>> +   in DRA7x
> 
> The 2nd instance is different somehow?

yeah, the bit fields are slightly different.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/9] phy: use syscon framework APIs to set ctrl mod reg

2015-12-18 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 15 December 2015 08:56 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kis...@ti.com> [151215 04:47]:
>> On Tuesday 15 December 2015 05:25 PM, Arnd Bergmann wrote:
>>>>>
>>>>> Can you explain here what the conversion is good for? Why do you
>>>>> prefer the syscon mapping over a high-level driver in this case?
>>>>
>>>> phy-omap-control driver was added when there was no proper
>>>> infrastructure for doing control module initializations. The
>>>> phy-omap-control driver is not an 'actual' PHY driver and it
>>>> was just a hack to do PHY related control module initializations.
>>>> phy-omap-control is also getting unmanageable with the number of
>>>> platforms each having number of modules (like USB, SATA, PCIe),
>>>> using the same driver for control module initializations.
>>>>
>>>> Now with SYSCON framework being added to the kernel, phy-omap-control
>>>> shouldn't be needed and it also provides a uniform API across all the
>>>> modules to program the control module.
>>>
>>> Ok, so the "phy-control" devices were really just a few registers of
>>> a system controller device that does a lot of other things as well, right?
>>
>> right.
>>>
>>> Can you put your description above into the cover-letter for the series,
>>> and the merge commit?
> 
> Just to confirm.. Seems like this series keeps USB working and the dts
> changes can be done later after the driver changes have been merged?

that's right Tony. Will merge this series by tomorrow if I don't get any review
comments.

Thanks
Kishon
> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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 linux-omap" 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/4] ARM: dts: dra7: Add dt node for the sycon pcie

2015-12-18 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 15 December 2015 06:52 PM, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/15/2015 12:39 PM, Kishon Vijay Abraham I wrote:
> 
>> Add new device tree node for the control module register space where
>> PCIe registers are present.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>> ---
>>   arch/arm/boot/dts/dra7.dtsi |5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index fe99231..e38f63f 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -155,6 +155,11 @@
>>   compatible = "syscon";
>>   reg = <0x1c04 0x0020>;
>>   };
>> +
>> +scm_conf_pcie: tisyscon@1c24 {
> 
>Please use the generic node names as the ePAPR standard says.

something like  scm_conf_pcie: syscon@1c24??

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


[PATCH v3 5/9] phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during probe

2015-12-15 Thread Kishon Vijay Abraham I
No functional change. Previously omap_control_phy_power() was used to power
off the PHY during probe. But once PIPE3 driver is adapted to use syscon,
omap_control_phy_power() cannot be used. Hence used ti_pipe3_power_off
to power off the PHY.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Roger Quadros <rog...@ti.com>
---
 drivers/phy/phy-ti-pipe3.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 1991efd..0ce4194 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -475,8 +475,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   omap_control_phy_power(phy->control_dev, 0);
-
platform_set_drvdata(pdev, phy);
pm_runtime_enable(dev);
 
@@ -495,6 +493,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
return PTR_ERR(generic_phy);
 
phy_set_drvdata(generic_phy, phy);
+
+   ti_pipe3_power_off(generic_phy);
+
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
if (IS_ERR(phy_provider))
return PTR_ERR(phy_provider);
-- 
1.7.9.5

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


[PATCH v3 2/9] phy: ti-pipe3: move clk initialization to a separate function

2015-12-15 Thread Kishon Vijay Abraham I
No functional change. Moved clock initialization done in probe to a
separate function as part of cleaning up ti_pipe3_probe.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 drivers/phy/phy-ti-pipe3.c |  127 +---
 1 file changed, 72 insertions(+), 55 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index c511105..3379a4d 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -308,48 +308,11 @@ static const struct phy_ops ops = {
 
 static const struct of_device_id ti_pipe3_id_table[];
 
-static int ti_pipe3_probe(struct platform_device *pdev)
+static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
 {
-   struct ti_pipe3 *phy;
-   struct phy *generic_phy;
-   struct phy_provider *phy_provider;
-   struct resource *res;
-   struct device_node *node = pdev->dev.of_node;
-   struct device_node *control_node;
-   struct platform_device *control_pdev;
-   const struct of_device_id *match;
struct clk *clk;
-   struct device *dev = >dev;
-
-   phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
-   if (!phy)
-   return -ENOMEM;
-
-   phy->dev= dev;
-
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-   match = of_match_device(ti_pipe3_id_table, dev);
-   if (!match)
-   return -EINVAL;
-
-   phy->dpll_map = (struct pipe3_dpll_map *)match->data;
-   if (!phy->dpll_map) {
-   dev_err(dev, "no DPLL data\n");
-   return -EINVAL;
-   }
-
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "pll_ctrl");
-   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(phy->pll_ctrl_base))
-   return PTR_ERR(phy->pll_ctrl_base);
-
-   phy->sys_clk = devm_clk_get(dev, "sysclk");
-   if (IS_ERR(phy->sys_clk)) {
-   dev_err(dev, "unable to get sysclk\n");
-   return -EINVAL;
-   }
-   }
+   struct device *dev = phy->dev;
+   struct device_node *node = dev->of_node;
 
phy->refclk = devm_clk_get(dev, "refclk");
if (IS_ERR(phy->refclk)) {
@@ -369,25 +332,17 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
} else {
phy->wkupclk = ERR_PTR(-ENODEV);
-   phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
-   "syscon-pllreset");
-   if (IS_ERR(phy->dpll_reset_syscon)) {
-   dev_info(dev,
-"can't get syscon-pllreset, sata dpll won't 
idle\n");
-   phy->dpll_reset_syscon = NULL;
-   } else {
-   if (of_property_read_u32_index(node,
-  "syscon-pllreset", 1,
-  >dpll_reset_reg)) {
-   dev_err(dev,
-   "couldn't get pllreset reg. offset\n");
-   return -EINVAL;
-   }
+   }
+
+   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   phy->sys_clk = devm_clk_get(dev, "sysclk");
+   if (IS_ERR(phy->sys_clk)) {
+   dev_err(dev, "unable to get sysclk\n");
+   return -EINVAL;
}
}
 
if (of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-
clk = devm_clk_get(dev, "dpll_ref");
if (IS_ERR(clk)) {
dev_err(dev, "unable to get dpll ref clk\n");
@@ -418,6 +373,68 @@ static int ti_pipe3_probe(struct platform_device *pdev)
phy->div_clk = ERR_PTR(-ENODEV);
}
 
+   return 0;
+}
+
+static int ti_pipe3_probe(struct platform_device *pdev)
+{
+   struct ti_pipe3 *phy;
+   struct phy *generic_phy;
+   struct phy_provider *phy_provider;
+   struct resource *res;
+   struct device_node *node = pdev->dev.of_node;
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
+   const struct of_device_id *match;
+   struct device *dev = >dev;
+   int ret;
+
+   phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+   if (!phy)
+   return -ENOMEM;
+
+   phy->dev= dev;
+
+   if (!of_device_is_compatible(node, "ti,phy-pipe3-

[PATCH v3 4/9] phy: ti-pipe3: move mem resource initialization to a separate function

2015-12-15 Thread Kishon Vijay Abraham I
No functional change. Moved mem resource initialization done in
probe to a separate function as part of cleaning up
ti_pipe3_probe.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 drivers/phy/phy-ti-pipe3.c |   52 
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 3154da0..1991efd 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -418,14 +418,42 @@ static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
return 0;
 }
 
+static int ti_pipe3_get_pll_base(struct ti_pipe3 *phy)
+{
+   struct resource *res;
+   const struct of_device_id *match;
+   struct device *dev = phy->dev;
+   struct device_node *node = dev->of_node;
+   struct platform_device *pdev = to_platform_device(dev);
+
+   if (of_device_is_compatible(node, "ti,phy-pipe3-pcie"))
+   return 0;
+
+   match = of_match_device(ti_pipe3_id_table, dev);
+   if (!match)
+   return -EINVAL;
+
+   phy->dpll_map = (struct pipe3_dpll_map *)match->data;
+   if (!phy->dpll_map) {
+   dev_err(dev, "no DPLL data\n");
+   return -EINVAL;
+   }
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "pll_ctrl");
+   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(phy->pll_ctrl_base))
+   return PTR_ERR(phy->pll_ctrl_base);
+
+   return 0;
+}
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
struct ti_pipe3 *phy;
struct phy *generic_phy;
struct phy_provider *phy_provider;
-   struct resource *res;
struct device_node *node = pdev->dev.of_node;
-   const struct of_device_id *match;
struct device *dev = >dev;
int ret;
 
@@ -435,23 +463,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 
phy->dev= dev;
 
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-   match = of_match_device(ti_pipe3_id_table, dev);
-   if (!match)
-   return -EINVAL;
-
-   phy->dpll_map = (struct pipe3_dpll_map *)match->data;
-   if (!phy->dpll_map) {
-   dev_err(dev, "no DPLL data\n");
-   return -EINVAL;
-   }
-
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "pll_ctrl");
-   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(phy->pll_ctrl_base))
-   return PTR_ERR(phy->pll_ctrl_base);
-   }
+   ret = ti_pipe3_get_pll_base(phy);
+   if (ret)
+   return ret;
 
ret = ti_pipe3_get_sysctrl(phy);
if (ret)
-- 
1.7.9.5

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


[PATCH v3 2/4] ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY node

2015-12-15 Thread Kishon Vijay Abraham I
Add "syscon-phy-power" property and "syscon-pcs" property which can
be used to perform the control module initializations and remove
the deprecated "ctrl-module" property from PCIe PHY dt nodes.

Phandle to "sysclk" clock node is also added to the PCIe PHY node
since some of the syscon initializations is based on system clock
frequency.

Since "omap_control_pcie1phy" and "omap_control_pcie2phy" devicetree
nodes are no longer used, remove it.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |   33 ++---
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e38f63f..156d735 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1204,16 +1204,18 @@
reg = <0x4a094000 0x80>, /* phy_rx */
  <0x4a094400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie1phy>;
+   syscon-phy-power = <_conf_pcie 0x1c>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy1_32khz>,
 <_pciephy1_clk>,
 <_pciephy1_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
};
 
@@ -1222,16 +1224,18 @@
reg = <0x4a095000 0x80>, /* phy_rx */
  <0x4a095400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie2phy>;
+   syscon-phy-power = <_conf_pcie 0x20>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy2_32khz>,
 <_pciephy2_clk>,
 <_pciephy2_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
status = "disabled";
};
@@ -1247,23 +1251,6 @@
ti,hwmods = "sata";
};
 
-   omap_control_pcie1phy: control-phy@0x4a003c40 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c40 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
-   omap_control_pcie2phy: control-pcie@0x4a003c44 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c44 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   status = "disabled";
-   };
-
rtc: rtc@48838000 {
compatible = "ti,am3352-rtc";
reg = <0x48838000 0x100>;
-- 
1.7.9.5

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


[PATCH v3 0/4] ARM: dts: use syscon property instead of ctrl-module

2015-12-15 Thread Kishon Vijay Abraham I
This series is basically to deprecate using ctrl-module property and use
corresponding syscon properties to program the control module registers.

Changes from v2:
No changes.

Changes from v1:
*) Squashed the patches that replaces "ctrl-module" with
   "syscon-phy-power"
*) Added "syscon-phy-power" for SATA dt node in OMAP5 which was missed
   earlier
*) removed _ARM: dts: omap4: Use "syscon-otghs" instead of "ctrl-module"
   in USB node_. It will be done later.

Changes from [1] in PHY patches include
*) cleanup ti_pipe3_probe
*) have mask, power_on and power_off values in usb_phy_data for
   omap-usb2 phy

This series should be merged only after [2]

[2] -> http://www.spinics.net/lists/kernel/msg2144510.html

Logs with SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025205/
DRA7 EVM  : http://pastebin.ubuntu.com/14025212/
AM43XX EVM: http://pastebin.ubuntu.com/14025222/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025228/

Logs without SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025233/
DRA7 EVM  : http://pastebin.ubuntu.com/14025238/
AM43XX EVM: http://pastebin.ubuntu.com/14025329/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025248/

The config I used: http://pastebin.ubuntu.com/14025336/

Kishon Vijay Abraham I (4):
  ARM: dts: dra7: Add dt node for the sycon pcie
  ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY
node
  ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2
PHY2
  ARM: dts: : Use "syscon-phy-power" instead of
"ctrl-module"

 arch/arm/boot/dts/am4372.dtsi |   16 ++---
 arch/arm/boot/dts/dra7.dtsi   |   75 -
 arch/arm/boot/dts/omap5.dtsi  |   26 ++
 3 files changed, 26 insertions(+), 91 deletions(-)

-- 
1.7.9.5

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


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

2015-12-15 Thread Kishon Vijay Abraham I
Deprecate using phy-omap-control driver to power on/off the PHY,
and use *syscon* framework to do the same. This handles
powering on/off the PHY for the USB2 PHYs used in various TI SoCs.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
 drivers/phy/phy-omap-usb2.c  |   94 ++
 include/linux/phy/omap_usb.h |   23 ++
 3 files changed, 107 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 49e5b0c..a3b3945 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -31,6 +31,8 @@ OMAP USB2 PHY
 
 Required properties:
  - compatible: Should be "ti,omap-usb2"
+  Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
+  in DRA7x
  - reg : Address and length of the register set for the device.
  - #phy-cells: determine the number of cells that should be given in the
phandle while referencing this phy.
@@ -40,10 +42,14 @@ Required properties:
* "wkupclk" - wakeup clock.
* "refclk" - reference clock (optional).
 
-Optional properties:
+Deprecated properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
the PHY.
 
+Recommended properies:
+- syscon-phy-power : phandle/offset pair. Phandle to the system control
+  module and the register offset to power on/off the PHY.
+
 This is usually a subnode of ocp2scp to which it is connected.
 
 usb2phy@4a0ad080 {
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index c79633e..c9c04ff 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #define USB2PHY_DISCON_BYP_LATCH (1 << 31)
@@ -97,22 +99,40 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
 }
 
-static int omap_usb_power_off(struct phy *x)
+static int omap_usb_phy_power(struct omap_usb *phy, int on)
 {
-   struct omap_usb *phy = phy_get_drvdata(x);
+   u32 val;
+   int ret;
 
-   omap_control_phy_power(phy->control_dev, 0);
+   if (phy->syscon_phy_power) {
+   if (on)
+   val = phy->power_on;
+   else
+   val = phy->power_off;
+
+   ret = regmap_update_bits(phy->syscon_phy_power, phy->power_reg,
+phy->mask, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_phy_power(phy->control_dev, on);
+   }
 
return 0;
 }
 
-static int omap_usb_power_on(struct phy *x)
+static int omap_usb_power_off(struct phy *x)
 {
struct omap_usb *phy = phy_get_drvdata(x);
 
-   omap_control_phy_power(phy->control_dev, 1);
+   return omap_usb_phy_power(phy, false);
+}
 
-   return 0;
+static int omap_usb_power_on(struct phy *x)
+{
+   struct omap_usb *phy = phy_get_drvdata(x);
+
+   return omap_usb_phy_power(phy, true);
 }
 
 static int omap_usb_init(struct phy *x)
@@ -147,21 +167,38 @@ static const struct phy_ops ops = {
 static const struct usb_phy_data omap_usb2_data = {
.label = "omap_usb2",
.flags = OMAP_USB2_HAS_START_SRP | OMAP_USB2_HAS_SET_VBUS,
+   .mask = OMAP_DEV_PHY_PD,
+   .power_off = OMAP_DEV_PHY_PD,
 };
 
 static const struct usb_phy_data omap5_usb2_data = {
.label = "omap5_usb2",
.flags = 0,
+   .mask = OMAP_DEV_PHY_PD,
+   .power_off = OMAP_DEV_PHY_PD,
 };
 
 static const struct usb_phy_data dra7x_usb2_data = {
.label = "dra7x_usb2",
.flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+   .mask = OMAP_DEV_PHY_PD,
+   .power_off = OMAP_DEV_PHY_PD,
+};
+
+static const struct usb_phy_data dra7x_usb2_phy2_data = {
+   .label = "dra7x_usb2_phy2",
+   .flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+   .mask = OMAP_USB2_PHY_PD,
+   .power_off = OMAP_USB2_PHY_PD,
 };
 
 static const struct usb_phy_data am437x_usb2_data = {
.label = "am437x_usb2",
.flags =  0,
+   .mask = AM437X_USB2_PHY_PD | AM437X_USB2_OTG_PD |
+   AM437X_USB2_OTGVDET_EN | AM437X_USB2_OTGSESSEND_EN,
+   .power_on = AM437X_USB2_OTGVDET_EN | AM437X_USB2_OTGSESSEND_EN,
+   .power_off = AM437X_USB2_PHY_PD | AM437X_USB2_OTG_PD,
 };
 
 static const struct of_device_id omap_usb2_id_table[] = {
@@ -178,6 +215,10 @@ static const struct of_device_id omap_usb2_id_table[] = {
.data = _usb2_data,
},
{
+   .compatible = "ti,dra7x-usb2-phy2",
+   .data = _usb2_phy2_data,
+   },
+   {
  

[PATCH v3 8/9] phy: omap-usb2: use omap_usb_power_off to power off the PHY during probe

2015-12-15 Thread Kishon Vijay Abraham I
No functional change. Previously omap_control_phy_power() was used to power
off the PHY during probe. But once phy-omap-usb2 driver is adapted to
use syscon, omap_control_phy_power() cannot be used. Hence used
omap_usb_power_off to power off the PHY.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Roger Quadros <rog...@ti.com>
---
 drivers/phy/phy-omap-usb2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 0fe8058..c79633e 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -241,7 +241,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
 
phy->control_dev = _pdev->dev;
-   omap_control_phy_power(phy->control_dev, 0);
 
otg->set_host   = omap_usb_set_host;
otg->set_peripheral = omap_usb_set_peripheral;
@@ -261,6 +260,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
 
phy_set_drvdata(generic_phy, phy);
+   omap_usb_power_off(generic_phy);
 
phy_provider = devm_of_phy_provider_register(phy->dev,
of_phy_simple_xlate);
-- 
1.7.9.5

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


[PATCH v3 1/9] phy: ti-pipe3: introduce local struct device* in probe

2015-12-15 Thread Kishon Vijay Abraham I
No functional change. Introduce local struct device pointer in
probe and replace using >dev/phy->dev with the local
device pointer. This is in preparation to split ti_pipe3_probe
and add separate functions for getting mem resource, getting
sysctrl and getting clocks.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 drivers/phy/phy-ti-pipe3.c |   54 ++--
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 93bc112..c511105 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -319,40 +319,41 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct platform_device *control_pdev;
const struct of_device_id *match;
struct clk *clk;
+   struct device *dev = >dev;
 
-   phy = devm_kzalloc(>dev, sizeof(*phy), GFP_KERNEL);
+   phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
if (!phy)
return -ENOMEM;
 
-   phy->dev= >dev;
+   phy->dev= dev;
 
if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-   match = of_match_device(ti_pipe3_id_table, >dev);
+   match = of_match_device(ti_pipe3_id_table, dev);
if (!match)
return -EINVAL;
 
phy->dpll_map = (struct pipe3_dpll_map *)match->data;
if (!phy->dpll_map) {
-   dev_err(>dev, "no DPLL data\n");
+   dev_err(dev, "no DPLL data\n");
return -EINVAL;
}
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
   "pll_ctrl");
-   phy->pll_ctrl_base = devm_ioremap_resource(>dev, res);
+   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
if (IS_ERR(phy->pll_ctrl_base))
return PTR_ERR(phy->pll_ctrl_base);
 
-   phy->sys_clk = devm_clk_get(phy->dev, "sysclk");
+   phy->sys_clk = devm_clk_get(dev, "sysclk");
if (IS_ERR(phy->sys_clk)) {
-   dev_err(>dev, "unable to get sysclk\n");
+   dev_err(dev, "unable to get sysclk\n");
return -EINVAL;
}
}
 
-   phy->refclk = devm_clk_get(phy->dev, "refclk");
+   phy->refclk = devm_clk_get(dev, "refclk");
if (IS_ERR(phy->refclk)) {
-   dev_err(>dev, "unable to get refclk\n");
+   dev_err(dev, "unable to get refclk\n");
/* older DTBs have missing refclk in SATA PHY
 * so don't bail out in case of SATA PHY.
 */
@@ -361,9 +362,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
 
if (!of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
-   phy->wkupclk = devm_clk_get(phy->dev, "wkupclk");
+   phy->wkupclk = devm_clk_get(dev, "wkupclk");
if (IS_ERR(phy->wkupclk)) {
-   dev_err(>dev, "unable to get wkupclk\n");
+   dev_err(dev, "unable to get wkupclk\n");
return PTR_ERR(phy->wkupclk);
}
} else {
@@ -371,14 +372,14 @@ static int ti_pipe3_probe(struct platform_device *pdev)
phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
"syscon-pllreset");
if (IS_ERR(phy->dpll_reset_syscon)) {
-   dev_info(>dev,
+   dev_info(dev,
 "can't get syscon-pllreset, sata dpll won't 
idle\n");
phy->dpll_reset_syscon = NULL;
} else {
if (of_property_read_u32_index(node,
   "syscon-pllreset", 1,
   >dpll_reset_reg)) {
-   dev_err(>dev,
+   dev_err(dev,
"couldn't get pllreset reg. offset\n");
return -EINVAL;
}
@@ -387,30 +388,30 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 
if (of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
 
-   clk = devm_clk_get(phy->dev, "dpll_ref");
+   clk = devm_clk_get(dev, "dpll_ref");
if (I

[PATCH v3 3/4] ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2 PHY2

2015-12-15 Thread Kishon Vijay Abraham I
The USB2 PHY2 has a different register map compared to USB2 PHY1
to power on/off the PHY. In order to handle it, use the new compatible
string "ti,dra7x-usb2-phy2" for the second instance of USB2 PHY.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 156d735..41545f9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1299,7 +1299,8 @@
};
 
usb2_phy2: phy@4a085000 {
-   compatible = "ti,omap-usb2";
+   compatible = "ti,dra7x-usb2-phy2",
+"ti,omap-usb2";
reg = <0x4a085000 0x400>;
ctrl-module = <_control_usb2phy2>;
clocks = <_phy2_always_on_clk32k>,
-- 
1.7.9.5

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


[PATCH v3 4/4] ARM: dts: : Use "syscon-phy-power" instead of "ctrl-module"

2015-12-15 Thread Kishon Vijay Abraham I
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from SATA and USB PHY node. Also remove the unused control
module dt nodes.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/am4372.dtsi |   16 ++--
 arch/arm/boot/dts/dra7.dtsi   |   34 --
 arch/arm/boot/dts/omap5.dtsi  |   26 +++---
 3 files changed, 9 insertions(+), 67 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..f42d4a4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -853,18 +853,6 @@
status = "disabled";
};
 
-   am43xx_control_usb2phy1: control-phy@44e10620 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10620 0x4>;
-   reg-names = "power";
-   };
-
-   am43xx_control_usb2phy2: control-phy@0x44e10628 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10628 0x4>;
-   reg-names = "power";
-   };
-
ocp2scp0: ocp2scp@483a8000 {
compatible = "ti,am437x-ocp2scp", "ti,omap-ocp2scp";
#address-cells = <1>;
@@ -875,7 +863,7 @@
usb2_phy1: phy@483a8000 {
compatible = "ti,am437x-usb2";
reg = <0x483a8000 0x8000>;
-   ctrl-module = <_control_usb2phy1>;
+   syscon-phy-power = <_conf 0x620>;
clocks = <_phy0_always_on_clk32k>,
 <_otg_ss0_refclk960m>;
clock-names = "wkupclk", "refclk";
@@ -894,7 +882,7 @@
usb2_phy2: phy@483e8000 {
compatible = "ti,am437x-usb2";
reg = <0x483e8000 0x8000>;
-   ctrl-module = <_control_usb2phy2>;
+   syscon-phy-power = <_conf 0x628>;
clocks = <_phy1_always_on_clk32k>,
 <_otg_ss1_refclk960m>;
clock-names = "wkupclk", "refclk";
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 41545f9..8ce37e4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1170,14 +1170,6 @@
status = "disabled";
};
 
-   omap_control_sata: control-phy@4a002374 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002374 0x4>;
-   reg-names = "power";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp";
@@ -1192,7 +1184,7 @@
  <0x4A096400 0x64>, /* phy_tx */
  <0x4A096800 0x40>; /* pll_ctrl */
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
-   ctrl-module = <_control_sata>;
+   syscon-phy-power = <_conf 0x374>;
clocks = <_clkin1>, <_ref_clk>;
clock-names = "sysclk", "refclk";
syscon-pllreset = <_conf 0x3fc>;
@@ -1260,24 +1252,6 @@
clocks = <_32k_ck>;
};
 
-   omap_control_usb2phy1: control-phy@4a002300 {
-   compatible = "ti,control-phy-usb2";
-   reg = <0x4a002300 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb3phy1: control-phy@4a002370 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002370 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb2phy2: control-phy@0x4a002e74 {
-   compatible = "ti,control-phy-usb2-dra7";
-   reg = <0x4a002e74 0x4>;
-   reg-names = "power";
-   };
-

[PATCH v3 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

2015-12-15 Thread Kishon Vijay Abraham I
Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..e38f63f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+   scm_conf_pcie: tisyscon@1c24 {
+   compatible = "syscon";
+   reg = <0x1c24 0x0024>;
+   };
};
 
cm_core_aon: cm_core_aon@5000 {
-- 
1.7.9.5

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


[PATCH v3 6/9] phy: ti-pipe3: use *syscon* framework API to power on/off the PHY

2015-12-15 Thread Kishon Vijay Abraham I
Deprecate using phy-omap-control driver to power on/off the PHY and
use *syscon* framework to do the same.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |   10 ++-
 drivers/phy/phy-ti-pipe3.c   |   90 ++
 2 files changed, 85 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 9cf9446..e06f980 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -77,8 +77,6 @@ Required properties:
* "div-clk" - apll clock
 
 Optional properties:
- - ctrl-module : phandle of the control module used by PHY driver to power on
-   the PHY.
  - id: If there are multiple instance of the same type, in order to
differentiate between each instance "id" can be used (e.g., multi-lane PCIe
PHY). If "id" is not provided, it is set to default value of '1'.
@@ -86,6 +84,14 @@ Optional properties:
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
 
+Deprecated properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+   the PHY.
+
+Recommended properies:
+ - syscon-phy-power : phandle/offset pair. Phandle to the system control
+   module and the register offset to power on/off the PHY.
+
 This is usually a subnode of ocp2scp to which it is connected.
 
 usb3phy@4a084400 {
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 0ce4194..bc03625 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -56,6 +56,15 @@
 
 #define SATA_PLL_SOFT_RESETBIT(18)
 
+#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK  0x003FC000
+#define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
+
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_MASK 0xFFC0
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT22
+
+#define PIPE3_PHY_TX_RX_POWERON0x3
+#define PIPE3_PHY_TX_RX_POWEROFF   0x0
+
 /*
  * This is an Empirical value that works, need to confirm the actual
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -86,8 +95,10 @@ struct ti_pipe3 {
struct clk  *refclk;
struct clk  *div_clk;
struct pipe3_dpll_map   *dpll_map;
+   struct regmap   *phy_power_syscon; /* ctrl. reg. acces */
struct regmap   *dpll_reset_syscon; /* ctrl. reg. acces */
unsigned intdpll_reset_reg; /* reg. index within syscon */
+   unsigned intpower_reg; /* power reg. index within syscon */
boolsata_refclk_enabled;
 };
 
@@ -144,18 +155,53 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3 *phy);
 
 static int ti_pipe3_power_off(struct phy *x)
 {
+   u32 val;
+   int ret;
struct ti_pipe3 *phy = phy_get_drvdata(x);
 
-   omap_control_phy_power(phy->control_dev, 0);
+   if (phy->phy_power_syscon) {
+   val = PIPE3_PHY_TX_RX_POWEROFF <<
+   PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+
+   ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_phy_power(phy->control_dev, 0);
+   }
 
return 0;
 }
 
 static int ti_pipe3_power_on(struct phy *x)
 {
+   u32 val;
+   u32 mask;
+   int ret;
+   unsigned long rate;
struct ti_pipe3 *phy = phy_get_drvdata(x);
 
-   omap_control_phy_power(phy->control_dev, 1);
+   if (phy->phy_power_syscon) {
+   rate = clk_get_rate(phy->sys_clk);
+   if (!rate) {
+   dev_err(phy->dev, "Invalid clock rate\n");
+   return -EINVAL;
+   }
+   rate = rate / 100;
+   mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
+ OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK;
+   val = PIPE3_PHY_TX_RX_POWERON <<
+   PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+   val |= rate << OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
+
+   ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+mask, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_phy_power(phy->control_dev, 1);
+   }
 
return 0;
 }
@@ -334,7 +380,8 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
phy->wkupclk = ERR_PTR(-ENODEV);
}
 
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   

[PATCH v3 7/9] phy: ti-pipe3: use *syscon* framework API to set PCS value of the PHY

2015-12-15 Thread Kishon Vijay Abraham I
Deprecate using phy-omap-control driver to set PCS value of the PHY
and start using *syscon* API to do the same.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Roger Quadros <rog...@ti.com>
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
 drivers/phy/phy-ti-pipe3.c   |   34 +-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index e06f980..49e5b0c 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -83,6 +83,8 @@ Optional properties:
  - syscon-pllreset: Handle to system control region that contains the
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
+ - syscon-pcs : phandle/offset pair. Phandle to the system control module and 
the
+   register offset to write the PCS delay value.
 
 Deprecated properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index bc03625..684d467 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -65,6 +65,9 @@
 #define PIPE3_PHY_TX_RX_POWERON0x3
 #define PIPE3_PHY_TX_RX_POWEROFF   0x0
 
+#define PCIE_PCS_MASK  0xFF
+#define PCIE_PCS_DELAY_COUNT_SHIFT 0x10
+
 /*
  * This is an Empirical value that works, need to confirm the actual
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -96,9 +99,11 @@ struct ti_pipe3 {
struct clk  *div_clk;
struct pipe3_dpll_map   *dpll_map;
struct regmap   *phy_power_syscon; /* ctrl. reg. acces */
+   struct regmap   *pcs_syscon; /* ctrl. reg. acces */
struct regmap   *dpll_reset_syscon; /* ctrl. reg. acces */
unsigned intdpll_reset_reg; /* reg. index within syscon */
unsigned intpower_reg; /* power reg. index within syscon */
+   unsigned intpcie_pcs_reg; /* pcs reg. index in syscon */
boolsata_refclk_enabled;
 };
 
@@ -275,7 +280,16 @@ static int ti_pipe3_init(struct phy *x)
 * 18-1804.
 */
if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
-   omap_control_pcie_pcs(phy->control_dev, 0x96);
+   if (phy->pcs_syscon) {
+   val = 0x96 << OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT;
+   ret = regmap_update_bits(phy->pcs_syscon,
+phy->pcie_pcs_reg,
+PCIE_PCS_MASK, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_pcie_pcs(phy->control_dev, 0x96);
+   }
return 0;
}
 
@@ -461,6 +475,24 @@ static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
phy->control_dev = _pdev->dev;
}
 
+   if (of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   phy->pcs_syscon = syscon_regmap_lookup_by_phandle(node,
+ "syscon-pcs");
+   if (IS_ERR(phy->pcs_syscon)) {
+   dev_dbg(dev,
+   "can't get syscon-pcs, using omap control\n");
+   phy->pcs_syscon = NULL;
+   } else {
+   if (of_property_read_u32_index(node,
+  "syscon-pcs", 1,
+  >pcie_pcs_reg)) {
+   dev_err(dev,
+   "couldn't get pcie pcs reg. offset\n");
+   return -EINVAL;
+   }
+   }
+   }
+
if (of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
"syscon-pllreset");
-- 
1.7.9.5

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


[PATCH v3 3/9] phy: ti-pipe3: move sysctrl initialization to a separate function

2015-12-15 Thread Kishon Vijay Abraham I
No functional change. Moved sysctrl initialization done in probe to a
separate function as part of cleaning up ti_pipe3_probe.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 drivers/phy/phy-ti-pipe3.c |   78 +---
 1 file changed, 45 insertions(+), 33 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 3379a4d..3154da0 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -376,6 +376,48 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
return 0;
 }
 
+static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
+{
+   struct device *dev = phy->dev;
+   struct device_node *node = dev->of_node;
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
+
+   control_node = of_parse_phandle(node, "ctrl-module", 0);
+   if (!control_node) {
+   dev_err(dev, "Failed to get control device phandle\n");
+   return -EINVAL;
+   }
+
+   control_pdev = of_find_device_by_node(control_node);
+   if (!control_pdev) {
+   dev_err(dev, "Failed to get control device\n");
+   return -EINVAL;
+   }
+
+   phy->control_dev = _pdev->dev;
+
+   if (of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
+   phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
+   "syscon-pllreset");
+   if (IS_ERR(phy->dpll_reset_syscon)) {
+   dev_info(dev,
+"can't get syscon-pllreset, sata dpll won't 
idle\n");
+   phy->dpll_reset_syscon = NULL;
+   } else {
+   if (of_property_read_u32_index(node,
+  "syscon-pllreset", 1,
+  >dpll_reset_reg)) {
+   dev_err(dev,
+   "couldn't get pllreset reg. offset\n");
+   return -EINVAL;
+   }
+   }
+   }
+
+   return 0;
+}
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
struct ti_pipe3 *phy;
@@ -383,8 +425,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct phy_provider *phy_provider;
struct resource *res;
struct device_node *node = pdev->dev.of_node;
-   struct device_node *control_node;
-   struct platform_device *control_pdev;
const struct of_device_id *match;
struct device *dev = >dev;
int ret;
@@ -413,42 +453,14 @@ static int ti_pipe3_probe(struct platform_device *pdev)
return PTR_ERR(phy->pll_ctrl_base);
}
 
-   if (of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
-   phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
-   "syscon-pllreset");
-   if (IS_ERR(phy->dpll_reset_syscon)) {
-   dev_info(dev,
-"can't get syscon-pllreset, sata dpll won't 
idle\n");
-   phy->dpll_reset_syscon = NULL;
-   } else {
-   if (of_property_read_u32_index(node,
-  "syscon-pllreset", 1,
-  >dpll_reset_reg)) {
-   dev_err(dev,
-   "couldn't get pllreset reg. offset\n");
-   return -EINVAL;
-   }
-   }
-   }
+   ret = ti_pipe3_get_sysctrl(phy);
+   if (ret)
+   return ret;
 
ret = ti_pipe3_get_clk(phy);
if (ret)
return ret;
 
-   control_node = of_parse_phandle(node, "ctrl-module", 0);
-   if (!control_node) {
-   dev_err(dev, "Failed to get control device phandle\n");
-   return -EINVAL;
-   }
-
-   control_pdev = of_find_device_by_node(control_node);
-   if (!control_pdev) {
-   dev_err(dev, "Failed to get control device\n");
-   return -EINVAL;
-   }
-
-   phy->control_dev = _pdev->dev;
-
omap_control_phy_power(phy->control_dev, 0);
 
platform_set_drvdata(pdev, phy);
-- 
1.7.9.5

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


[PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

2015-12-15 Thread Kishon Vijay Abraham I
This series is basically to deprecate using phy-omap-control and use
syscon APIs to program the control module registers.

Changes from v2:
No changes.

Changes from v1:
*) cleanup ti_pipe3_probe in multiple steps
*) other minor cleanups

Changes from [1] in PHY patches include
*) cleanup ti_pipe3_probe
*) have mask, power_on and power_off values in usb_phy_data for
   omap-usb2 phy

The patches have been pushed to
git://git.ti.com/linux-phy/linux-phy.git syscon

[1] -> https://lkml.org/lkml/2015/6/23/189

All the testing was done both before applying the dt patches and after
applying the dt patches (dt patches will be posted shortly).

Logs with SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025205/
DRA7 EVM  : http://pastebin.ubuntu.com/14025212/
AM43XX EVM: http://pastebin.ubuntu.com/14025222/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025228/

Logs without SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025233/
DRA7 EVM  : http://pastebin.ubuntu.com/14025238/
AM43XX EVM: http://pastebin.ubuntu.com/14025329/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025248/

The config I used: http://pastebin.ubuntu.com/14025336/

Kishon Vijay Abraham I (9):
  phy: ti-pipe3: introduce local struct device* in probe
  phy: ti-pipe3: move clk initialization to a separate function
  phy: ti-pipe3: move sysctrl initialization to a separate function
  phy: ti-pipe3: move mem resource initialization to a separate
function
  phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during
probe
  phy: ti-pipe3: use *syscon* framework API to power on/off the PHY
  phy: ti-pipe3: use *syscon* framework API to set PCS value of the PHY
  phy: omap-usb2: use omap_usb_power_off to power off the PHY during
probe
  phy: omap-usb2: use *syscon* framework API to power on/off the PHY

 Documentation/devicetree/bindings/phy/ti-phy.txt |   20 +-
 drivers/phy/phy-omap-usb2.c  |   96 +--
 drivers/phy/phy-ti-pipe3.c   |  304 --
 include/linux/phy/omap_usb.h |   23 ++
 4 files changed, 340 insertions(+), 103 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/9] phy: use syscon framework APIs to set ctrl mod reg

2015-12-15 Thread Kishon Vijay Abraham I
Hi Arnd,

On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
> On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
>> This series is basically to deprecate using phy-omap-control and use
>> syscon APIs to program the control module registers.
>>
>> Changes from v2:
>> No changes.
>>
>> Changes from v1:
>> *) cleanup ti_pipe3_probe in multiple steps
>> *) other minor cleanups
>>
>> Changes from [1] in PHY patches include
>> *) cleanup ti_pipe3_probe
>> *) have mask, power_on and power_off values in usb_phy_data for
>>omap-usb2 phy
>>
>> The patches have been pushed to
>> git://git.ti.com/linux-phy/linux-phy.git syscon
>>
>> [1] -> https://lkml.org/lkml/2015/6/23/189
>>
>> All the testing was done both before applying the dt patches and after
>> applying the dt patches (dt patches will be posted shortly).
>>
> 
> Can you explain here what the conversion is good for? Why do you
> prefer the syscon mapping over a high-level driver in this case?

phy-omap-control driver was added when there was no proper
infrastructure for doing control module initializations. The
phy-omap-control driver is not an 'actual' PHY driver and it
was just a hack to do PHY related control module initializations.
phy-omap-control is also getting unmanageable with the number of
platforms each having number of modules (like USB, SATA, PCIe),
using the same driver for control module initializations.

Now with SYSCON framework being added to the kernel, phy-omap-control
shouldn't be needed and it also provides a uniform API across all the
modules to program the control module.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/9] phy: use syscon framework APIs to set ctrl mod reg

2015-12-15 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 15 December 2015 05:25 PM, Arnd Bergmann wrote:
> On Tuesday 15 December 2015 16:44:41 Kishon Vijay Abraham I wrote:
>> Hi Arnd,
>>
>> On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
>>> On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
>>>> This series is basically to deprecate using phy-omap-control and use
>>>> syscon APIs to program the control module registers.
>>>>
>>>> Changes from v2:
>>>> No changes.
>>>>
>>>> Changes from v1:
>>>> *) cleanup ti_pipe3_probe in multiple steps
>>>> *) other minor cleanups
>>>>
>>>> Changes from [1] in PHY patches include
>>>> *) cleanup ti_pipe3_probe
>>>> *) have mask, power_on and power_off values in usb_phy_data for
>>>>omap-usb2 phy
>>>>
>>>> The patches have been pushed to
>>>> git://git.ti.com/linux-phy/linux-phy.git syscon
>>>>
>>>> [1] -> https://lkml.org/lkml/2015/6/23/189
>>>>
>>>> All the testing was done both before applying the dt patches and after
>>>> applying the dt patches (dt patches will be posted shortly).
>>>>
>>>
>>> Can you explain here what the conversion is good for? Why do you
>>> prefer the syscon mapping over a high-level driver in this case?
>>
>> phy-omap-control driver was added when there was no proper
>> infrastructure for doing control module initializations. The
>> phy-omap-control driver is not an 'actual' PHY driver and it
>> was just a hack to do PHY related control module initializations.
>> phy-omap-control is also getting unmanageable with the number of
>> platforms each having number of modules (like USB, SATA, PCIe),
>> using the same driver for control module initializations.
>>
>> Now with SYSCON framework being added to the kernel, phy-omap-control
>> shouldn't be needed and it also provides a uniform API across all the
>> modules to program the control module.
> 
> Ok, so the "phy-control" devices were really just a few registers of
> a system controller device that does a lot of other things as well, right?

right.
> 
> Can you put your description above into the cover-letter for the series,
> and the merge commit?

Sure.

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


Re: [PATCH 1/2] usb: musb: core: Fix handling of the phy notifications

2015-12-06 Thread Kishon Vijay Abraham I
On Tuesday 01 December 2015 11:07 AM, Tony Lindgren wrote:
> We currently can't unload omap2430 MUSB platform glue driver module and
> this cause issues for fixing the MUSB code further. The reason we can't
> remove omap2430 is because it uses the PHY functions and also exports the
> omap_musb_mailbox function that some PHY drivers are using.
> 
> Let's fix the issue by exporting a more generic musb_mailbox function
> from the MUSB core and allow platform glue layers to register phy_callback
> function as needed.
> 
> And now we can now also get rid of the include/linux/musb-omap.h.
> 
> Cc: Bin Liu <b-...@ti.com>
> Cc: Felipe Balbi <ba...@ti.com>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: NeilBrown <n...@brown.name>
> Signed-off-by: Tony Lindgren <t...@atomide.com>

Reviewed-by: Kishon Vijay Abraham I <kis...@ti.com>
> 
> ---
> 
> Probably best that Felipe merges this patch via the USB tree after
> comments if that works for Kishon? I have another two fixes for the

That should be okay.

Thanks
Kishon
> phy-twl4030-usb.c coming after this series but they can be merged
> separately and won't conflict with this patch.
> 
> ---
>  drivers/phy/phy-twl4030-usb.c | 32 
>  drivers/usb/musb/musb_core.c  | 21 +
>  drivers/usb/musb/musb_core.h  |  2 ++
>  drivers/usb/musb/omap2430.c   | 27 ++-
>  drivers/usb/phy/phy-twl6030-usb.c | 30 +++---
>  include/linux/usb/musb-omap.h | 30 --
>  include/linux/usb/musb.h  | 15 +++
>  7 files changed, 83 insertions(+), 74 deletions(-)
>  delete mode 100644 include/linux/usb/musb-omap.h
> 
> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
> index 3a707dd..4a3fc6e 100644
> --- a/drivers/phy/phy-twl4030-usb.c
> +++ b/drivers/phy/phy-twl4030-usb.c
> @@ -34,7 +34,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -148,10 +148,10 @@
>   * If VBUS is valid or ID is ground, then we know a
>   * cable is present and we need to be runtime-enabled
>   */
> -static inline bool cable_present(enum omap_musb_vbus_id_status stat)
> +static inline bool cable_present(enum musb_vbus_id_status stat)
>  {
> - return stat == OMAP_MUSB_VBUS_VALID ||
> - stat == OMAP_MUSB_ID_GROUND;
> + return stat == MUSB_VBUS_VALID ||
> + stat == MUSB_ID_GROUND;
>  }
>  
>  struct twl4030_usb {
> @@ -170,7 +170,7 @@ struct twl4030_usb {
>   enum twl4030_usb_mode   usb_mode;
>  
>   int irq;
> - enum omap_musb_vbus_id_status linkstat;
> + enum musb_vbus_id_status linkstat;
>   boolvbus_supplied;
>  
>   struct delayed_work id_workaround_work;
> @@ -276,11 +276,11 @@ static bool twl4030_is_driving_vbus(struct twl4030_usb 
> *twl)
>   return (ret & (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
>  }
>  
> -static enum omap_musb_vbus_id_status
> +static enum musb_vbus_id_status
>   twl4030_usb_linkstat(struct twl4030_usb *twl)
>  {
>   int status;
> - enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
> + enum musb_vbus_id_status linkstat = MUSB_UNKNOWN;
>  
>   twl->vbus_supplied = false;
>  
> @@ -306,14 +306,14 @@ static enum omap_musb_vbus_id_status
>   }
>  
>   if (status & BIT(2))
> - linkstat = OMAP_MUSB_ID_GROUND;
> + linkstat = MUSB_ID_GROUND;
>   else if (status & BIT(7))
> - linkstat = OMAP_MUSB_VBUS_VALID;
> + linkstat = MUSB_VBUS_VALID;
>   else
> - linkstat = OMAP_MUSB_VBUS_OFF;
> + linkstat = MUSB_VBUS_OFF;
>   } else {
> - if (twl->linkstat != OMAP_MUSB_UNKNOWN)
> - linkstat = OMAP_MUSB_VBUS_OFF;
> + if (twl->linkstat != MUSB_UNKNOWN)
> + linkstat = MUSB_VBUS_OFF;
>   }
>  
>   dev_dbg(twl->dev, "HW_CONDITIONS 0x%02x/%d; link %d\n",
> @@ -535,7 +535,7 @@ static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, 
> NULL);
>  static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
>  {
>   struct twl4030_usb *twl = _twl;
> - enum omap_musb_vbus_id_status status;
> + enum musb_vbus_id_status status;
>   bool status_changed = false;
>  
>   status = twl4030_usb_linkstat(twl);
> @@ -567,11 +567,11 @@ static irqreturn_t twl4030_usb

Re: [PATCH 2/2] usb: musb: Fix unbalanced pm_runtime_enable

2015-12-06 Thread Kishon Vijay Abraham I


On Tuesday 01 December 2015 11:07 AM, Tony Lindgren wrote:
> When reloading omap2430 kernel module we get a warning about
> unbalanced pm_runtime_enable. Let's fix this. Note that we
> need to do this after the child musb-core platform_device is
> removed because of pm_runtime_irq_safe being set at the child.
> 
> Cc: Bin Liu <b-...@ti.com>
> Cc: Felipe Balbi <ba...@ti.com>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: NeilBrown <n...@brown.name>
> Signed-off-by: Tony Lindgren <t...@atomide.com>

Reviewed-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
>  drivers/usb/musb/omap2430.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index bf05f80..c84e0322 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -664,8 +664,11 @@ static int omap2430_remove(struct platform_device *pdev)
>  {
>   struct omap2430_glue*glue = platform_get_drvdata(pdev);
>  
> + pm_runtime_get_sync(glue->dev);
>   cancel_work_sync(>omap_musb_mailbox_work);
>   platform_device_unregister(glue->musb);
> + pm_runtime_put_sync(glue->dev);
> + pm_runtime_disable(glue->dev);
>  
>   return 0;
>  }
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PCIe regression with DRA7xx in 4.4-rc1

2015-11-24 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 24 November 2015 05:38 PM, Gabriele Paoloni wrote:
> Hi Kishon
> 
>> -Original Message-----
>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
>> Sent: 24 November 2015 12:01
>> To: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
>> o...@vger.kernel.org; james.mo...@arm.com; gabriel.fernan...@st.com;
>> minghuan.l...@freescale.com; Wangzhou (B); Gabriele Paoloni; a...@arndb.de;
>> bhelg...@google.com; pratyush.an...@gmail.com; Nori, Sekhar;
>> jingooh...@gmail.com; linux-arm-ker...@lists.infradead.org
>> Subject: PCIe regression with DRA7xx in 4.4-rc1
>>
>> Hi,
>>
>> I'm seeing a regression with ("PCI:
>> designware: Make driver arch-agnostic").
>>
>> Logs using a SATA PCIe card [1]. The PCIe card enumerates fine but after that
>> I
>> observe "ata3.00: qc timeout (cmd 0xec), ata3.00: failed to IDENTIFY (I/O
>> error, err_mask=0x4)"
>>
> 
> May this be related to the bug flagged in:
> 
> [PATCH] PCI: designware: remove wrong io_base assignment
> 
> [...]
> diff --git a/drivers/pci/host/pcie-designware.c 
> b/drivers/pci/host/pcie-designware.c
> index 540f077c37ea..02a7452bdf23 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -440,7 +440,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
>ret, pp->io);
>   continue;
>   }
> - pp->io_base = pp->io->start;
>   break;
>   case IORESOURCE_MEM:
>   pp->mem = win->res;
> 


yes, this indeed solved the bug.

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


PCIe regression with DRA7xx in 4.4-rc1

2015-11-24 Thread Kishon Vijay Abraham I
Hi,

I'm seeing a regression with ("PCI:
designware: Make driver arch-agnostic").

Logs using a SATA PCIe card [1]. The PCIe card enumerates fine but after that I
observe "ata3.00: qc timeout (cmd 0xec), ata3.00: failed to IDENTIFY (I/O
error, err_mask=0x4)"

Logs using a Ethenet PCIe card [2]. Again here the PCIe card enumerates fine
but when I give ifconfig up, it fails.

If I just revert commit , the PCIe
cards starts to work fine again

Logs using a SATA PCIe card [3]. Here the KINGSTON SSD gets detected fine.
Logs using a Ethernet PCIe card [4]. I'm able to do ping tests now.

Actually I'm not able to find any obvious problems with the patch and the irq
number and the memory resource also looks fine. Any idea what could be the 
problem?

[1] -> http://pastebin.ubuntu.com/13491456/
[2] -> http://pastebin.ubuntu.com/13491526/

[3] -> http://pastebin.ubuntu.com/13491658/
[4] -> http://pastebin.ubuntu.com/13491593/

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


Re: PCIe regression with DRA7xx in 4.4-rc1

2015-11-24 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 24 November 2015 05:44 PM, Jisheng Zhang wrote:
> 
> 
> On Tue, 24 Nov 2015 17:31:07 +0530
> Kishon Vijay Abraham I wrote:
> 
>> Hi,
>>
>> I'm seeing a regression with ("PCI:
>> designware: Make driver arch-agnostic").
>>
>> Logs using a SATA PCIe card [1]. The PCIe card enumerates fine but after 
>> that I
>> observe "ata3.00: qc timeout (cmd 0xec), ata3.00: failed to IDENTIFY (I/O
>> error, err_mask=0x4)"
>>
>> Logs using a Ethenet PCIe card [2]. Again here the PCIe card enumerates fine
>> but when I give ifconfig up, it fails.
>>
>> If I just revert commit , the PCIe
>> cards starts to work fine again
> 
> FYI, maybe the patch can fix the regression.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/387362.html

yes, it fixed.

Thanks
Kishon

> 
>>
>> Logs using a SATA PCIe card [3]. Here the KINGSTON SSD gets detected fine.
>> Logs using a Ethernet PCIe card [4]. I'm able to do ping tests now.
>>
>> Actually I'm not able to find any obvious problems with the patch and the irq
>> number and the memory resource also looks fine. Any idea what could be the 
>> problem?
>>
>> [1] -> http://pastebin.ubuntu.com/13491456/
>> [2] -> http://pastebin.ubuntu.com/13491526/
>>
>> [3] -> http://pastebin.ubuntu.com/13491658/
>> [4] -> http://pastebin.ubuntu.com/13491593/
>>
>> Thanks
>> Kishon
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

2015-10-12 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 13 October 2015 03:42 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kis...@ti.com> [151012 15:09]:
>> Hi,
>>
>> On Tuesday 13 October 2015 03:33 AM, Tony Lindgren wrote:
>>> * Kishon Vijay Abraham I <kis...@ti.com> [151012 14:50]:
>>>> Hi Tony,
>>>>
>>>> On Tuesday 13 October 2015 02:51 AM, Tony Lindgren wrote:
>>>>> * Kishon Vijay Abraham I <kis...@ti.com> [150915 06:37]:
>>>>>> Add new device tree node for the control module register space where
>>>>>> PCIe registers are present.
>>>>>>
>>>>>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/dra7.dtsi |5 +
>>>>>>  1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>>>>>> index 5d65db9..0769b5d 100644
>>>>>> --- a/arch/arm/boot/dts/dra7.dtsi
>>>>>> +++ b/arch/arm/boot/dts/dra7.dtsi
>>>>>> @@ -154,6 +154,11 @@
>>>>>>  compatible = "syscon";
>>>>>>  reg = <0x1c04 0x0020>;
>>>>>>  };
>>>>>> +
>>>>>> +scm_conf_pcie: tisyscon@1c24 {
>>>>>> +compatible = "syscon";
>>>>>> +reg = <0x1c24 0x0024>;
>>>>>> +};
>>>>>>  };
>>>>>>  
>>>>>>  cm_core_aon: cm_core_aon@5000 {
>>>>>
>>>>>
>>>>> Why don't you just extend the existing scm_conf1 area? This is not all 
>>>>> pcie
>>>>> specific for scm_conf_pcie, at least for PLLEN_CONTROL, RMII_CLK_SETTING
>>>>> and MUXSEL_32K_CLKIN.
>>>>
>>>> scm_conf_pcie has only PCIe registers (it starts at 0x4A003C24).
>>>> PLLEN_CONTROL and others are at 0x4A003C14 as per
>>>> DRA75x_DRA74x_SR1.1_NDA_TRM_vW.
>>>
>>> Oh sorry I guess I was looking at a wrong address then.
>>>
>>>> Since PCIe itself has a bunch of registers for itself, thought of
>>>> creating a separate dt node. But I can extend scm_conf1 area.
>>>
>>> Why not just ioremap them then? Do these need to be shared with
>>> some other driver?
>>
>> yeah, some are used by PCIe controller driver and some are used by PCIe
>> PHY driver.
> 
> OK makes sense to me then.

Cool.

Btw the driver modifications has not yet been merged, so don't merge
these yet. I'll repost these once the driver is merged.

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


Re: [PATCH v2 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

2015-10-12 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 13 October 2015 03:33 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kis...@ti.com> [151012 14:50]:
>> Hi Tony,
>>
>> On Tuesday 13 October 2015 02:51 AM, Tony Lindgren wrote:
>>> * Kishon Vijay Abraham I <kis...@ti.com> [150915 06:37]:
>>>> Add new device tree node for the control module register space where
>>>> PCIe registers are present.
>>>>
>>>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>>>> ---
>>>>  arch/arm/boot/dts/dra7.dtsi |5 +
>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>>>> index 5d65db9..0769b5d 100644
>>>> --- a/arch/arm/boot/dts/dra7.dtsi
>>>> +++ b/arch/arm/boot/dts/dra7.dtsi
>>>> @@ -154,6 +154,11 @@
>>>>compatible = "syscon";
>>>>reg = <0x1c04 0x0020>;
>>>>};
>>>> +
>>>> +  scm_conf_pcie: tisyscon@1c24 {
>>>> +  compatible = "syscon";
>>>> +  reg = <0x1c24 0x0024>;
>>>> +  };
>>>>};
>>>>  
>>>>cm_core_aon: cm_core_aon@5000 {
>>>
>>>
>>> Why don't you just extend the existing scm_conf1 area? This is not all pcie
>>> specific for scm_conf_pcie, at least for PLLEN_CONTROL, RMII_CLK_SETTING
>>> and MUXSEL_32K_CLKIN.
>>
>> scm_conf_pcie has only PCIe registers (it starts at 0x4A003C24).
>> PLLEN_CONTROL and others are at 0x4A003C14 as per
>> DRA75x_DRA74x_SR1.1_NDA_TRM_vW.
> 
> Oh sorry I guess I was looking at a wrong address then.
> 
>> Since PCIe itself has a bunch of registers for itself, thought of
>> creating a separate dt node. But I can extend scm_conf1 area.
> 
> Why not just ioremap them then? Do these need to be shared with
> some other driver?

yeah, some are used by PCIe controller driver and some are used by PCIe
PHY driver.

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


Re: [PATCH v2 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

2015-10-12 Thread Kishon Vijay Abraham I
Hi Tony,

On Tuesday 13 October 2015 02:51 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kis...@ti.com> [150915 06:37]:
>> Add new device tree node for the control module register space where
>> PCIe registers are present.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>> ---
>>  arch/arm/boot/dts/dra7.dtsi |5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 5d65db9..0769b5d 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -154,6 +154,11 @@
>>  compatible = "syscon";
>>  reg = <0x1c04 0x0020>;
>>  };
>> +
>> +scm_conf_pcie: tisyscon@1c24 {
>> +compatible = "syscon";
>> +reg = <0x1c24 0x0024>;
>> +};
>>  };
>>  
>>  cm_core_aon: cm_core_aon@5000 {
> 
> 
> Why don't you just extend the existing scm_conf1 area? This is not all pcie
> specific for scm_conf_pcie, at least for PLLEN_CONTROL, RMII_CLK_SETTING
> and MUXSEL_32K_CLKIN.

scm_conf_pcie has only PCIe registers (it starts at 0x4A003C24).
PLLEN_CONTROL and others are at 0x4A003C14 as per
DRA75x_DRA74x_SR1.1_NDA_TRM_vW.

Since PCIe itself has a bunch of registers for itself, thought of
creating a separate dt node. But I can extend scm_conf1 area.

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


Re: [RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

2015-10-09 Thread Kishon Vijay Abraham I
Hi Bjorn,

On Saturday 10 October 2015 04:20 AM, Bjorn Helgaas wrote:
> [+cc Arnd, Rob]
> 
> On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
>> Add driver modifications in pci-dra7xx to get x2 mode working in
>> DRA72 and DRA74. Certain modifications is needed in PHY driver also
>> which I'll send as a separate series.
>>
>> Kishon Vijay Abraham I (2):
>>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
>>   pci: host: pci-dra7xx: Enable x2 mode support
> 
> Applied to pci/host-dra7xx for v4.4, thanks!
> 
> I adjusted the subject line capitalization & format to match the history.
> 
> Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
> strings in "phy-names" changes?

I sent it as RFC since I didn't have the board to test 2 lane mode with
$patch. And just now I got a board to test x2 and I found a problem with
the 2nd patch.

.b1co_mode_sel_mask = GENMASK(2, 3), in the patch should be replaced with
.b1co_mode_sel_mask = GENMASK(3, 2).

I'll resend the patch fixing the above.

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


Re: [RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

2015-10-09 Thread Kishon Vijay Abraham I
Hi,

On Saturday 10 October 2015 04:46 AM, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> On Saturday 10 October 2015 04:20 AM, Bjorn Helgaas wrote:
>> [+cc Arnd, Rob]
>>
>> On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
>>> Add driver modifications in pci-dra7xx to get x2 mode working in
>>> DRA72 and DRA74. Certain modifications is needed in PHY driver also
>>> which I'll send as a separate series.
>>>
>>> Kishon Vijay Abraham I (2):
>>>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
>>>   pci: host: pci-dra7xx: Enable x2 mode support
>>
>> Applied to pci/host-dra7xx for v4.4, thanks!
>>
>> I adjusted the subject line capitalization & format to match the history.
>>
>> Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
>> strings in "phy-names" changes?
> 
> I sent it as RFC since I didn't have the board to test 2 lane mode with
> $patch. And just now I got a board to test x2 and I found a problem with
> the 2nd patch.
> 
> .b1co_mode_sel_mask = GENMASK(2, 3), in the patch should be replaced with
> .b1co_mode_sel_mask = GENMASK(3, 2).
> 
> I'll resend the patch fixing the above.

I'll resend after a couple of days to fix any comments from Arnd or Rob.

Thanks
Kishon

> 
> Thanks
> Kishon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: All OMAP platforms: MMC is broken

2015-10-07 Thread Kishon Vijay Abraham I
Hi,

On Thursday 08 October 2015 01:10 AM, Ulf Hansson wrote:
> On 7 October 2015 at 17:52, Tony Lindgren  wrote:
>> * Ulf Hansson  [151007 06:46]:
>>> On 7 October 2015 at 15:26, Tony Lindgren  wrote:
>> Good idea, how about something like the following? AFAIK that's the
>> only .config option needed as MFD_SYSCON is selected by Kconfig
>> already.
>>>
>>> Similar to MFD_SYSCON, why don't we have REGULATOR_PBIAS to be
>>> selected when omap_hsmmc is being used?
>>>
>>> It seems like that should also be a patch for the rc, right!?
>>
>> Well selecting CONFIG_REGULATOR is still optional and force selecting
>> drivers usually leads into randconfig build issues sooner or later.
>> And we'd like to make everything into loadable modules eventually.
> 
> I am not sure I get your point. Perhaps I was too vague in what I suggested.
> 
> Unless we express the dependencies via Kconfig files (or perhaps via
> updated defconfigs), how do you expect build/boot automated tools to
> handle this?

Both omap2plus_defconfig and multi_v7_defconfig has
CONFIG_PBIAS_REGULATOR enabled [1].

I think by using *depends on* in Kconfig, we'll end up in the same issue
faced by Russell (since even with that CONFIG_PBIAS_REGULATOR won't be
enabled) and using *select* can lead to randconfig errors.

[1] -> https://lkml.org/lkml/2015/9/3/119

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


Re: All OMAP platforms: MMC is broken

2015-10-07 Thread Kishon Vijay Abraham I
Hi,

On Wednesday 07 October 2015 01:27 AM, Russell King - ARM Linux wrote:
> On Wed, Oct 07, 2015 at 12:59:29AM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 06 October 2015 08:37 PM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 06, 2015 at 04:06:09PM +0530, Kishon Vijay Abraham I wrote:
>>>> Hi,
>>>>
>>>> On Tuesday 06 October 2015 03:41 PM, Ulf Hansson wrote:
>>>>> On 6 October 2015 at 11:44, Tony Lindgren <t...@atomide.com> wrote:
>>>>>> * Russell King - ARM Linux <li...@arm.linux.org.uk> [151006 02:04]:
>>>>>>> On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux 
>>>>>>> wrote:
>>>>>>>> On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
>>>>>>>>> * Tony Lindgren <t...@atomide.com> [151005 07:57]:
>>>>>>>>>> * Tony Lindgren <t...@atomide.com> [151005 07:44]:
>>>>>>>>>>> * Tony Lindgren <t...@atomide.com> [151005 04:28]:
>>>>>>>>>>>
>>>>>>>>>>> Based on some tests it seems that the duovero unpaired regulator 
>>>>>>>>>>> usage
>>>>>>>>>>> is fixed by reverting:
>>>>>>>>>>>
>>>>>>>>>>> c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
>>>>>>>>>>> find pbias status")
>>>>>>>>>>
>>>>>>>>>> With commit c55d7a055364 my guess is that the PBIAS regulator is
>>>>>>>>>> already on from an earlier MMC probe and getting re-enabled when
>>>>>>>>>> a deferred probe happens?
>>>>>>>>>
>>>>>>>>> Unless somebody has a better fix in mind for the above, I suggest
>>>>>>>>> we revert it for the -rc kernel.
>>>>>>>>
>>>>>>>> Let me try reverting that in my build tree, and...
>>>>>>>>
>>>>>>>>>>> And it seems that omap3 legacy MMC is broken earlier in the
>>>>>>>>>>> series with:
>>>>>>>>>>>
>>>>>>>>>>> 7d607f917008 ("mmc: host: omap_hsmmc: use
>>>>>>>>>>> devm_regulator_get_optional() for vmmc")
>>>>>>>>>>>
>>>>>>>>>>> This one does not cleanly revert so have not yet tried reverting
>>>>>>>>>>> it.
>>>>>>>>>>
>>>>>>>>>> And with commit 7d607f917008 I'm guessing we can't return anHi,
>>>>>>>>>> error if the PBIAS regulator does not exist as that's not there
>>>>>>>>>> for the legacy booting.
>>>>>>>>>
>>>>>>>>> For omap3 legacy booting, we keep getting -EPROBE_DEFER for
>>>>>>>>> all the optional regulators.
>>>>>>>>>
>>>>>>>>> Something like the following might be the minimal fix for the -rc
>>>>>>>>> cycle?
>>>>>>>>
>>>>>>>> applying this patch.  If that gets things going again, then we
>>>>>>>> _definitely_ should get both of these to Linus ASAP.  The breakage
>>>>>>>> has been around far too long already.
>>>>>>>
>>>>>>> Last night's build shows that this fixes the non-DT LDP3430 booting, but
>>>>>>> DT-based LDP3430 and SDP4430 both remain broken for the same reason -
>>>>>>> neither can find their SD cards.
>>>>>>
>>>>>> Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot 
>>>>>> [1].
>>>>>> Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
>>>>>> working for you with DT-based booting because you don't seem to have
>>>>>> CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
>>>>>> for both your omap3 and omap4 seed config files?
>>>>>>
>>>>>>> We're at -rc4.  That means we're could be only three weeks away from 4.3
>>>>>>> being released, and DT OMAP has yet to boot _once_ here.
>>>>>>>
&g

Re: All OMAP platforms: MMC is broken

2015-10-06 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 06 October 2015 08:37 PM, Russell King - ARM Linux wrote:
> On Tue, Oct 06, 2015 at 04:06:09PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 06 October 2015 03:41 PM, Ulf Hansson wrote:
>>> On 6 October 2015 at 11:44, Tony Lindgren <t...@atomide.com> wrote:
>>>> * Russell King - ARM Linux <li...@arm.linux.org.uk> [151006 02:04]:
>>>>> On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
>>>>>> On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
>>>>>>> * Tony Lindgren <t...@atomide.com> [151005 07:57]:
>>>>>>>> * Tony Lindgren <t...@atomide.com> [151005 07:44]:
>>>>>>>>> * Tony Lindgren <t...@atomide.com> [151005 04:28]:
>>>>>>>>>
>>>>>>>>> Based on some tests it seems that the duovero unpaired regulator usage
>>>>>>>>> is fixed by reverting:
>>>>>>>>>
>>>>>>>>> c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
>>>>>>>>> find pbias status")
>>>>>>>>
>>>>>>>> With commit c55d7a055364 my guess is that the PBIAS regulator is
>>>>>>>> already on from an earlier MMC probe and getting re-enabled when
>>>>>>>> a deferred probe happens?
>>>>>>>
>>>>>>> Unless somebody has a better fix in mind for the above, I suggest
>>>>>>> we revert it for the -rc kernel.
>>>>>>
>>>>>> Let me try reverting that in my build tree, and...
>>>>>>
>>>>>>>>> And it seems that omap3 legacy MMC is broken earlier in the
>>>>>>>>> series with:
>>>>>>>>>
>>>>>>>>> 7d607f917008 ("mmc: host: omap_hsmmc: use
>>>>>>>>> devm_regulator_get_optional() for vmmc")
>>>>>>>>>
>>>>>>>>> This one does not cleanly revert so have not yet tried reverting
>>>>>>>>> it.
>>>>>>>>
>>>>>>>> And with commit 7d607f917008 I'm guessing we can't return anHi,
>>>>>>>> error if the PBIAS regulator does not exist as that's not there
>>>>>>>> for the legacy booting.
>>>>>>>
>>>>>>> For omap3 legacy booting, we keep getting -EPROBE_DEFER for
>>>>>>> all the optional regulators.
>>>>>>>
>>>>>>> Something like the following might be the minimal fix for the -rc
>>>>>>> cycle?
>>>>>>
>>>>>> applying this patch.  If that gets things going again, then we
>>>>>> _definitely_ should get both of these to Linus ASAP.  The breakage
>>>>>> has been around far too long already.
>>>>>
>>>>> Last night's build shows that this fixes the non-DT LDP3430 booting, but
>>>>> DT-based LDP3430 and SDP4430 both remain broken for the same reason -
>>>>> neither can find their SD cards.
>>>>
>>>> Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
>>>> Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
>>>> working for you with DT-based booting because you don't seem to have
>>>> CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
>>>> for both your omap3 and omap4 seed config files?
>>>>
>>>>> We're at -rc4.  That means we're could be only three weeks away from 4.3
>>>>> being released, and DT OMAP has yet to boot _once_ here.
>>>>>
>>>>> What I find *totally* unacceptable is the lack of reaction from the MMC
>>>>> and TI people: it's just like "we'll break your crap, and we'll ignore
>>>>> reports of regressions."  That is *not* acceptable in any shape or form,
>>>>> and people who do this _should_ have their future patches ignored until
>>>>> they demonstrate that they understand the need to not break stuff.
>>>>>
>>>>> I'm at the point of suggesting that there should be a moritorium on all
>>>>> OMAP related development for 4.4: delay all development to 4.5, and have
>>>>> 4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
>>&g

Re: All OMAP platforms: MMC is broken

2015-10-06 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 06 October 2015 03:41 PM, Ulf Hansson wrote:
> On 6 October 2015 at 11:44, Tony Lindgren  wrote:
>> * Russell King - ARM Linux  [151006 02:04]:
>>> On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
 On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
> * Tony Lindgren  [151005 07:57]:
>> * Tony Lindgren  [151005 07:44]:
>>> * Tony Lindgren  [151005 04:28]:
>>>
>>> Based on some tests it seems that the duovero unpaired regulator usage
>>> is fixed by reverting:
>>>
>>> c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
>>> find pbias status")
>>
>> With commit c55d7a055364 my guess is that the PBIAS regulator is
>> already on from an earlier MMC probe and getting re-enabled when
>> a deferred probe happens?
>
> Unless somebody has a better fix in mind for the above, I suggest
> we revert it for the -rc kernel.

 Let me try reverting that in my build tree, and...

>>> And it seems that omap3 legacy MMC is broken earlier in the
>>> series with:
>>>
>>> 7d607f917008 ("mmc: host: omap_hsmmc: use
>>> devm_regulator_get_optional() for vmmc")
>>>
>>> This one does not cleanly revert so have not yet tried reverting
>>> it.
>>
>> And with commit 7d607f917008 I'm guessing we can't return anHi,
>> error if the PBIAS regulator does not exist as that's not there
>> for the legacy booting.
>
> For omap3 legacy booting, we keep getting -EPROBE_DEFER for
> all the optional regulators.
>
> Something like the following might be the minimal fix for the -rc
> cycle?

 applying this patch.  If that gets things going again, then we
 _definitely_ should get both of these to Linus ASAP.  The breakage
 has been around far too long already.
>>>
>>> Last night's build shows that this fixes the non-DT LDP3430 booting, but
>>> DT-based LDP3430 and SDP4430 both remain broken for the same reason -
>>> neither can find their SD cards.
>>
>> Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
>> Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
>> working for you with DT-based booting because you don't seem to have
>> CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
>> for both your omap3 and omap4 seed config files?
>>
>>> We're at -rc4.  That means we're could be only three weeks away from 4.3
>>> being released, and DT OMAP has yet to boot _once_ here.
>>>
>>> What I find *totally* unacceptable is the lack of reaction from the MMC
>>> and TI people: it's just like "we'll break your crap, and we'll ignore
>>> reports of regressions."  That is *not* acceptable in any shape or form,
>>> and people who do this _should_ have their future patches ignored until
>>> they demonstrate that they understand the need to not break stuff.
>>>
>>> I'm at the point of suggesting that there should be a moritorium on all
>>> OMAP related development for 4.4: delay all development to 4.5, and have
>>> 4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
>>> OMAP is still broken, then I don't think there's an option on that.
>>>
>>> Maybe the idea that development work won't hit mainline for another 4
>>> months will help focus the minds on not breaking stuff and then ignoring
>>> regression reports.
>>
>> I'm thinking along the same lines. In general, I do not and will not
>> apply any patches that are not fixes until all critical regressions are
>> out of the way. So not applying anything new for v4.4 until these MMC
>> regressions are fixed for v4.3.
>>
> 
> Tony, Russell - just wanted to say thanks for putting a big effort in
> fixing this. I was expecting support from Kishon, but I guess he's
> busy.
> 
> Unfortunate, I don't have any of the hardware that fails, otherwise I
> would of course be helping out more. The only thing I can think of is
> to revert the entire patchset I picked up for 4.3 from Kishon for the
> omap_hsmmc driver, but then I am not sure if that would cause other
> issues...

Please don't do that as that will just mask lot of bugs in the
devicetree and might get MMC working. Indeed I was busy but I'll try to
get this resolved asap. The 2 pending issues as far as I know

1) warn dump while enabling pbias regulator in duovero. As I mentioned
in some other thread it might be because the PBIAS regulator in 4430 is
not setting the status bit properly because of which we can't use the
regulator_is_enabled API to enable/disable the regulator. I don't think
there is any other way to fix this other than reverting c55d7a055364.

2) legacy booting is not working with OMAP3.
I'm not sure what is causing this. I'm right now in ELCE and will be
able to look at this on Friday when I'll be able to get hold of LDP3430.

I really didn't 

[RFC PATCH 1/2] pci: host: pci-dra7xx: use "num-lanes" property to find phy count

2015-09-28 Thread Kishon Vijay Abraham I
use "num-lanes" property to find phy count instead of the number
phy-names property.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 drivers/pci/host/pci-dra7xx.c |   23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 199e29a..e15b2e2 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -66,7 +66,7 @@
 struct dra7xx_pcie {
void __iomem*base;
struct phy  **phy;
-   int phy_count;
+   int lanes;
struct device   *dev;
struct pcie_portpp;
 };
@@ -328,7 +328,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
int ret;
int irq;
int i;
-   int phy_count;
+   u32 lanes;
struct phy **phy;
void __iomem *base;
struct resource *res;
@@ -362,17 +362,16 @@ static int __init dra7xx_pcie_probe(struct 
platform_device *pdev)
if (!base)
return -ENOMEM;
 
-   phy_count = of_property_count_strings(np, "phy-names");
-   if (phy_count < 0) {
-   dev_err(dev, "unable to find the strings\n");
-   return phy_count;
+   if (of_property_read_u32(np, "num-lanes", )) {
+   dev_err(dev, "Failed to parse the number of lanes\n");
+   return -EINVAL;
}
 
-   phy = devm_kzalloc(dev, sizeof(*phy) * phy_count, GFP_KERNEL);
+   phy = devm_kzalloc(dev, sizeof(*phy) * lanes, GFP_KERNEL);
if (!phy)
return -ENOMEM;
 
-   for (i = 0; i < phy_count; i++) {
+   for (i = 0; i < lanes; i++) {
snprintf(name, sizeof(name), "pcie-phy%d", i);
phy[i] = devm_phy_get(dev, name);
if (IS_ERR(phy[i]))
@@ -392,7 +391,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
dra7xx->base = base;
dra7xx->phy = phy;
dra7xx->dev = dev;
-   dra7xx->phy_count = phy_count;
+   dra7xx->lanes = lanes;
 
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
@@ -449,7 +448,7 @@ static int __exit dra7xx_pcie_remove(struct platform_device 
*pdev)
struct dra7xx_pcie *dra7xx = platform_get_drvdata(pdev);
struct pcie_port *pp = >pp;
struct device *dev = >dev;
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
if (pp->irq_domain)
irq_domain_remove(pp->irq_domain);
@@ -495,7 +494,7 @@ static int dra7xx_pcie_resume(struct device *dev)
 static int dra7xx_pcie_suspend_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
while (count--) {
phy_power_off(dra7xx->phy[count]);
@@ -508,7 +507,7 @@ static int dra7xx_pcie_suspend_noirq(struct device *dev)
 static int dra7xx_pcie_resume_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int phy_count = dra7xx->phy_count;
+   int phy_count = dra7xx->lanes;
int ret;
int i;
 
-- 
1.7.9.5

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


[RFC PATCH 2/2] pci: host: pci-dra7xx: Enable x2 mode support

2015-09-28 Thread Kishon Vijay Abraham I
Perform syscon configurations to get x2 mode to working in DRA74x and
DRA72x. Also add a new compatible string to dfferentiate
DRA72x and DRA74x, since b1c0 mask is different for both these platforms.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 Documentation/devicetree/bindings/pci/ti-pci.txt |7 +-
 drivers/pci/host/pci-dra7xx.c|   81 +-
 2 files changed, 86 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e2516..1ae1705 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,7 +1,8 @@
 TI PCI Controllers
 
 PCIe Designware Controller
- - compatible: Should be "ti,dra7-pcie""
+ - compatible: Should be "ti,dra7-pcie" for DRA74x
+  Should be "ti,dra72-pcie" for DRA72x
  - reg : Two register ranges as listed in the reg-names property
  - reg-names : The first entry must be "ti-conf" for the TI specific registers
   The second entry must be "rc-dbics" for the designware pcie
@@ -14,6 +15,10 @@ PCIe Designware Controller
   where  is the instance number of the pcie from the HW spec.
  - interrupts : Two interrupt entries must be specified. The first one is for
main interrupt line and the second for MSI interrupt line.
+ - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
module and the
+   register offset to specify 1 lane or 2 lane.
+ - syscon-lane-sel : phandle/offset pair. Phandle to the system control module 
and the
+   register offset to specify lane selection.
  - #address-cells,
#size-cells,
#interrupt-cells,
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index e15b2e2..fb23a58 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -22,8 +22,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
 
 #include "pcie-designware.h"
 
@@ -63,14 +66,22 @@
 #definePCIECTRL_DRA7XX_CONF_PHY_CS 0x010C
 #defineLINK_UP BIT(16)
 
+#define PCIE_1LANE_2LANE_SELECTION BIT(13)
+#define PCIE_B1C0_MODE_SEL BIT(2)
+
 struct dra7xx_pcie {
void __iomem*base;
+   u32 *b1c0_mask;
struct phy  **phy;
int lanes;
struct device   *dev;
struct pcie_portpp;
 };
 
+struct dra7xx_pcie_data {
+   u32 b1co_mode_sel_mask;
+};
+
 #define to_dra7xx_pcie(x)  container_of((x), struct dra7xx_pcie, pp)
 
 static inline u32 dra7xx_pcie_readl(struct dra7xx_pcie *pcie, u32 offset)
@@ -322,6 +333,57 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie 
*dra7xx,
return 0;
 }
 
+static const struct of_device_id of_dra7xx_pcie_match[];
+
+static int dra7xx_pcie_configure_two_lane(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct regmap *pcie_syscon;
+   unsigned int pcie_reg;
+   struct dra7xx_pcie_data *data;
+   const struct of_device_id *match;
+
+   match = of_match_device(of_dra7xx_pcie_match, dev);
+   if (!match)
+   return -EINVAL;
+
+   data = (struct dra7xx_pcie_data *)match->data;
+   if (!data) {
+   dev_err(dev, "no b1c0 mask data\n");
+   return -EINVAL;
+   }
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-conf");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-conf\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-conf", 1, _reg)) {
+   dev_err(dev, "couldn't get lane configuration reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, PCIE_1LANE_2LANE_SELECTION,
+  PCIE_1LANE_2LANE_SELECTION);
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-sel");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-sel\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-sel", 1, _reg)) {
+   dev_err(dev, "couldn't get lane selection reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, data->b1co_mode_sel_mask,
+  PCIE_B1C0_MODE_SEL);
+
+   return 0;
+}
+
 static int __init dra7xx_pcie_probe(struct platform_device *pdev)
 {
u32 reg;
@@ -386,6 +448,14 @@ static int __init dra7x

[RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

2015-09-28 Thread Kishon Vijay Abraham I
Add driver modifications in pci-dra7xx to get x2 mode working in
DRA72 and DRA74. Certain modifications is needed in PHY driver also
which I'll send as a separate series.

Kishon Vijay Abraham I (2):
  pci: host: pci-dra7xx: use "num-lanes" property to find phy count
  pci: host: pci-dra7xx: Enable x2 mode support

 Documentation/devicetree/bindings/pci/ti-pci.txt |7 +-
 drivers/pci/host/pci-dra7xx.c|  104 +++---
 2 files changed, 97 insertions(+), 14 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/4] ARM: dts: dra7: Add dt node for the sycon pcie

2015-09-15 Thread Kishon Vijay Abraham I
Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5d65db9..0769b5d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -154,6 +154,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+   scm_conf_pcie: tisyscon@1c24 {
+   compatible = "syscon";
+   reg = <0x1c24 0x0024>;
+   };
};
 
cm_core_aon: cm_core_aon@5000 {
-- 
1.7.9.5

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


[PATCH v2 4/4] ARM: dts: : Use "syscon-phy-power" instead of "ctrl-module"

2015-09-15 Thread Kishon Vijay Abraham I
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from SATA and USB PHY node. Also remove the unused control
module dt nodes.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/am4372.dtsi |   16 ++--
 arch/arm/boot/dts/dra7.dtsi   |   34 --
 arch/arm/boot/dts/omap5.dtsi  |   26 +++---
 3 files changed, 9 insertions(+), 67 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 0447c04a..fd162d8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -852,18 +852,6 @@
status = "disabled";
};
 
-   am43xx_control_usb2phy1: control-phy@44e10620 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10620 0x4>;
-   reg-names = "power";
-   };
-
-   am43xx_control_usb2phy2: control-phy@0x44e10628 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10628 0x4>;
-   reg-names = "power";
-   };
-
ocp2scp0: ocp2scp@483a8000 {
compatible = "ti,am437x-ocp2scp", "ti,omap-ocp2scp";
#address-cells = <1>;
@@ -874,7 +862,7 @@
usb2_phy1: phy@483a8000 {
compatible = "ti,am437x-usb2";
reg = <0x483a8000 0x8000>;
-   ctrl-module = <_control_usb2phy1>;
+   syscon-phy-power = <_conf 0x620>;
clocks = <_phy0_always_on_clk32k>,
 <_otg_ss0_refclk960m>;
clock-names = "wkupclk", "refclk";
@@ -893,7 +881,7 @@
usb2_phy2: phy@483e8000 {
compatible = "ti,am437x-usb2";
reg = <0x483e8000 0x8000>;
-   ctrl-module = <_control_usb2phy2>;
+   syscon-phy-power = <_conf 0x628>;
clocks = <_phy1_always_on_clk32k>,
 <_otg_ss1_refclk960m>;
clock-names = "wkupclk", "refclk";
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 65eecb3..ad1bb2d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1124,14 +1124,6 @@
status = "disabled";
};
 
-   omap_control_sata: control-phy@4a002374 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002374 0x4>;
-   reg-names = "power";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp";
@@ -1146,7 +1138,7 @@
  <0x4A096400 0x64>, /* phy_tx */
  <0x4A096800 0x40>; /* pll_ctrl */
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
-   ctrl-module = <_control_sata>;
+   syscon-phy-power = <_conf 0x374>;
clocks = <_clkin1>, <_ref_clk>;
clock-names = "sysclk", "refclk";
syscon-pllreset = <_conf 0x3fc>;
@@ -1213,24 +1205,6 @@
clocks = <_32k_ck>;
};
 
-   omap_control_usb2phy1: control-phy@4a002300 {
-   compatible = "ti,control-phy-usb2";
-   reg = <0x4a002300 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb3phy1: control-phy@4a002370 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002370 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb2phy2: control-phy@0x4a002e74 {
-   compatible = "ti,control-phy-usb2-dra7";
-   reg = <0x4a002e74 0x4>;
-   reg-names = "power";
-   };
-

[PATCH v2 3/4] ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2 PHY2

2015-09-15 Thread Kishon Vijay Abraham I
The USB2 PHY2 has a different register map compared to USB2 PHY1
to power on/off the PHY. In order to handle it, use the new compatible
string "ti,dra7x-usb2-phy2" for the second instance of USB2 PHY.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe28215..65eecb3 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1252,7 +1252,7 @@
};
 
usb2_phy2: phy@4a085000 {
-   compatible = "ti,omap-usb2";
+   compatible = "ti,dra7x-usb2-phy2", 
"ti,omap-usb2";
reg = <0x4a085000 0x400>;
ctrl-module = <_control_usb2phy2>;
clocks = <_phy2_always_on_clk32k>,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/4] ARM: dts: use syscon property instead of ctrl-module

2015-09-15 Thread Kishon Vijay Abraham I
This series is basically to deprecate using ctrl-module property and use
corresponding syscon properties to program the control module registers.

Changes from v1:
*) Squashed the patches that replaces "ctrl-module" with
   "syscon-phy-power"
*) Added "syscon-phy-power" for SATA dt node in OMAP5 which was missed
   earlier
*) removed _ARM: dts: omap4: Use "syscon-otghs" instead of "ctrl-module"
   in USB node_. It will be done later.

Changes from [1] in PHY patches include
*) cleanup ti_pipe3_probe
*) have mask, power_on and power_off values in usb_phy_data for
   omap-usb2 phy

This series should be merged only after [2]

Did basic enumeration testing to make sure the patch series doesn't
cause any regressions.

[1] -> https://lkml.org/lkml/2015/6/23/189
[2] -> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg973939.html

Kishon Vijay Abraham I (4):
  ARM: dts: dra7: Add dt node for the sycon pcie
  ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY
node
  ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2
PHY2
  ARM: dts: : Use "syscon-phy-power" instead of
"ctrl-module"

 arch/arm/boot/dts/am4372.dtsi |   16 ++
 arch/arm/boot/dts/dra7.dtsi   |   69 ++---
 arch/arm/boot/dts/omap5.dtsi  |   26 ++--
 3 files changed, 22 insertions(+), 89 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/4] ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY node

2015-09-15 Thread Kishon Vijay Abraham I
Add "syscon-phy-power" property and "syscon-pcs" property which can
be used to perform the control module initializations and remove
the deprecated "ctrl-module" property from PCIe PHY dt nodes.

Phandle to "sysclk" clock node is also added to the PCIe PHY node
since some of the syscon initializations is based on system clock
frequency.

Since "omap_control_pcie1phy" and "omap_control_pcie2phy" devicetree
nodes are no longer used, remove it.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |   28 +++-
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 0769b5d..fe28215 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1158,16 +1158,18 @@
reg = <0x4a094000 0x80>, /* phy_rx */
  <0x4a094400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie1phy>;
+   syscon-phy-power = <_conf_pcie 0x1c>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy1_32khz>,
 <_pciephy1_clk>,
 <_pciephy1_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
};
 
@@ -1176,7 +1178,8 @@
reg = <0x4a095000 0x80>, /* phy_rx */
  <0x4a095400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie2phy>;
+   syscon-phy-power = <_conf_pcie 0x20>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy2_32khz>,
@@ -1201,23 +1204,6 @@
ti,hwmods = "sata";
};
 
-   omap_control_pcie1phy: control-phy@0x4a003c40 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c40 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
-   omap_control_pcie2phy: control-pcie@0x4a003c44 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c44 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   status = "disabled";
-   };
-
rtc: rtc@48838000 {
compatible = "ti,am3352-rtc";
reg = <0x48838000 0x100>;
-- 
1.7.9.5

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


Re: [PATCH v3 0/2] regulator: Fix pbias regulator enable

2015-09-14 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 15 September 2015 01:52 AM, Tony Lindgren wrote:
> Hi,
> 
> * Ulf Hansson  [150904 05:48]:
>>
>> Okay, just to be clear on the way forward. I spoked with Mark Brown
>> offlist, and he will/has picked up the regulator patch and will send
>> it as fix for the 4.3 rc[n].
>>
>> Regarding the ARM patch here, I guess Tony might as well handle it and
>> send through arm-soc, especially since the regression won't be fixed
>> within my mmc tree anyway.
>>
>> So, I am going to leave my next branch as is - and thus relying on
>> teet the regression for OMAP will be fixed in some the 4.3 rc[n].
> 
> I'm picking up the .dts changes from this series into
> omap-for-v4.3/fixes as those are safe to apply while waiting
> for the pbias-regulator.c fix to hit mainline.
> 
> I'm not yet applying the related dts change "fix address translation
> for pbias" as that depends on the pbias-regulator.c change.
> 
> Howver, when testing all the patches applied, I'm still getting
> the following splat at least on duovero (with MMC working):
> 
> WARNING: CPU: 0 PID: 6 at drivers/regulator/core.c:2105 
> _regulator_disable+0x13c/0x1d4()
> unbalanced disables for pbias_mmc_omap4
> Modules linked in:
> CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.3.0-rc1-00015-gf5c4173-dirty 
> #1295
> Hardware name: Generic OMAP4 (Flattened Device Tree)
> Workqueue: deferwq deferred_probe_work_func
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0x9c)
> [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4)
> [] (warn_slowpath_common) from [] 
> (warn_slowpath_fmt+0x30/0x40)
> [] (warn_slowpath_fmt) from [] 
> (_regulator_disable+0x13c/0x1d4)
> [] (_regulator_disable) from [] 
> (regulator_disable+0x30/0x6c)
> [] (regulator_disable) from [] 
> (omap_hsmmc_set_power+0x158/0x1e8)
> [] (omap_hsmmc_set_power) from [] 
> (omap_hsmmc_set_ios+0x198/0x318)
> [] (omap_hsmmc_set_ios) from [] 
> (mmc_power_up.part.10+0x30/0xf8)
> [] (mmc_power_up.part.10) from [] 
> (mmc_start_host+0x40/0x7c)
> [] (mmc_start_host) from [] (mmc_add_host+0x5c/0x84)
> [] (mmc_add_host) from [] (omap_hsmmc_probe+0x5b0/0x9f0)
> [] (omap_hsmmc_probe) from [] 
> (platform_drv_probe+0x44/0xac)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x1f4/0x2f0)
> [] (driver_probe_device) from [] 
> (bus_for_each_drv+0x64/0x98)
> [] (bus_for_each_drv) from [] (__device_attach+0xb0/0x118)
> [] (__device_attach) from [] (bus_probe_device+0x88/0x90)
> [] (bus_probe_device) from [] 
> (deferred_probe_work_func+0x60/0x90)
> [] (deferred_probe_work_func) from [] 
> (process_one_work+0x1a4/0x558)
> [] (process_one_work) from [] (worker_thread+0x3c/0x514)
> [] (worker_thread) from [] (kthread+0xd4/0xf0)
> [] (kthread) from [] (ret_from_fork+0x14/0x24)
> 
> Kishon, can you please take a look?

really weird, since I didn't see any issues with my OMAP4 PANDA. Most
likely it's because the PBIAS register is not showing the correct state
of PBIAS. So we might have to remove using regulator_is_enabled and use
our own bookkeeping pbias_enabled variable. Anyway I'll check this.

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


Re: [PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

2015-09-09 Thread Kishon Vijay Abraham I
hi,

On Wednesday 09 September 2015 09:33 AM, Guenter Roeck wrote:
> On Sun, Sep 06, 2015 at 04:41:10PM -0700, Guenter Roeck wrote:
>> On Thu, Sep 03, 2015 at 03:25:11PM +0530, Kishon Vijay Abraham I wrote:
>>> PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
>>> OMAP5 and DRA7 SoCs. Enable it here.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>>
>> Tested-by: Guenter Roeck <li...@roeck-us.net>
>>
> This problem is now causing various runtime failures in mainline.
> I see the following qemu test failures:
> 
> arm:beagle:multi_v7_defconfig:omap3-beagle
> arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
> arm:overo:multi_v7_defconfig:omap3-overo-tobi
> 
> I would expect all omap2/3/4/5 runtime tests with multi_v7_defconfig to fail.
> 
> Also, FWIW,
> 
> Fixes: 6a9b2ff07d04 ("mmc: host: omap_hsmmc: return on fatal errors from 
> omap_hsmmc_reg_get")

I've resend the patch to a...@kernel.org and it bounced back from Nicolas
Pitre. However others like Arnd, Thomas, Olof would have received and I
think they'll be applying this soonish.

Thanks
Kishon

> 
> Guenter
> 
>>> ---
>>>  arch/arm/configs/multi_v7_defconfig |1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/configs/multi_v7_defconfig 
>>> b/arch/arm/configs/multi_v7_defconfig
>>> index 5fd8df6..f497c96 100644
>>> --- a/arch/arm/configs/multi_v7_defconfig
>>> +++ b/arch/arm/configs/multi_v7_defconfig
>>> @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
>>>  CONFIG_REGULATOR_MAX77686=y
>>>  CONFIG_REGULATOR_MAX77693=m
>>>  CONFIG_REGULATOR_PALMAS=y
>>> +CONFIG_REGULATOR_PBIAS=y
>>>  CONFIG_REGULATOR_S2MPS11=y
>>>  CONFIG_REGULATOR_S5M8767=y
>>>  CONFIG_REGULATOR_TPS51632=y
>>> -- 
>>> 1.7.9.5
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: omap2plus_defconfig: make PCF857x built-in

2015-09-08 Thread Kishon Vijay Abraham I
Hello,

On Wednesday 05 August 2015 07:13 PM, Kishon Vijay Abraham I wrote:
> One of the lines from PCF857x is connected to the vdd line of MMC1
> in DRA74x and DRA72x EVMs and is modelled as a regulator. If PCF857x
> is not made as built-in, the regulator_get in omap_hsmmc fails making
> it difficult to use MMC1 as rootfs.
> 
> Make PCF857x built-in.

Can this be picked for 4.3?

Thanks
Kishon

> 
> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
> Signed-off-by: Sekhar Nori <nsek...@ti.com>
> ---
>  arch/arm/configs/omap2plus_defconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig 
> b/arch/arm/configs/omap2plus_defconfig
> index ac521e7..7cedfe9 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -236,7 +236,7 @@ CONFIG_SSI_PROTOCOL=m
>  CONFIG_PINCTRL_SINGLE=y
>  CONFIG_DEBUG_GPIO=y
>  CONFIG_GPIO_SYSFS=y
> -CONFIG_GPIO_PCF857X=m
> +CONFIG_GPIO_PCF857X=y
>  CONFIG_GPIO_TWL4030=y
>  CONFIG_GPIO_PALMAS=y
>  CONFIG_W1=m
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 0/2] regulator: Fix pbias regulator enable

2015-09-04 Thread Kishon Vijay Abraham I
vsel_reg and enable_reg of the pbias regulator descriptor should actually
have the offset from syscon.

However after
"ARM: dts: : add minimal l4 bus layout with control module
support"
vsel_reg and enable_reg started to have the absolute address because
of address translation that happens due to pbias node made as the
child node of syscon. This breaks the pbias regulator enable.

This series adds the 'offset' to be populated in vsel_reg and enable_reg
in the pbias driver itself.

Changes from v2:
*) Squashed all the dt patches into a single patch

Changes from v1:
*) Fixed Tony's review comments on adding a 'comment' for adding offset in
   the driver and adding a warning for using platform_get_resource.
*) Added Tony's Acked-by.

Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
dra72 and omap5 uevm

Kishon Vijay Abraham I (2):
  regulator: pbias: program pbias register offset in pbias driver
  ARM: dts: : use "ti,pbias-" compatible
string for pbias

 .../bindings/regulator/pbias-regulator.txt |7 ++-
 arch/arm/boot/dts/dra7.dtsi|2 +-
 arch/arm/boot/dts/omap2430.dtsi|2 +-
 arch/arm/boot/dts/omap3.dtsi   |2 +-
 arch/arm/boot/dts/omap4.dtsi   |2 +-
 arch/arm/boot/dts/omap5.dtsi   |2 +-
 drivers/regulator/pbias-regulator.c|   56 +---
 7 files changed, 61 insertions(+), 12 deletions(-)

-- 
1.7.9.5

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


[RESEND PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

2015-09-04 Thread Kishon Vijay Abraham I
PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
OMAP5 and DRA7 SoCs. Enable it here.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/configs/multi_v7_defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 5fd8df6..f497c96 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
 CONFIG_REGULATOR_MAX77686=y
 CONFIG_REGULATOR_MAX77693=m
 CONFIG_REGULATOR_PALMAS=y
+CONFIG_REGULATOR_PBIAS=y
 CONFIG_REGULATOR_S2MPS11=y
 CONFIG_REGULATOR_S5M8767=y
 CONFIG_REGULATOR_TPS51632=y
-- 
1.7.9.5

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


[PATCH v3 1/2] regulator: pbias: program pbias register offset in pbias driver

2015-09-04 Thread Kishon Vijay Abraham I
Add separate compatible strings for every platform and populate the
pbias register offset in the driver data.
This helps avoid depending on the dt for pbias register offset.

Also update the dt binding documentation with the new compatible
strings.

Suggested-by: Tony Lindgren <t...@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Tony Lindgren <t...@atomide.com>
---
 .../bindings/regulator/pbias-regulator.txt |7 ++-
 drivers/regulator/pbias-regulator.c|   56 +---
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
index 32aa26f..acbcb45 100644
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
@@ -2,7 +2,12 @@ PBIAS internal regulator for SD card dual voltage i/o pads on 
OMAP SoCs.
 
 Required properties:
 - compatible:
-  - "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7.
+  - should be "ti,pbias-dra7" for DRA7
+  - should be "ti,pbias-omap2" for OMAP2
+  - should be "ti,pbias-omap3" for OMAP3
+  - should be "ti,pbias-omap4" for OMAP4
+  - should be "ti,pbias-omap5" for OMAP5
+  - "ti,pbias-omap" is deprecated
 - reg: pbias register offset from syscon base and size of pbias register.
 - syscon : phandle of the system control module
 - regulator-name : should be
diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index bd2b75c..c21cedb 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -44,6 +44,10 @@ struct pbias_regulator_data {
int voltage;
 };
 
+struct pbias_of_data {
+   unsigned int offset;
+};
+
 static const unsigned int pbias_volt_table[] = {
180,
300
@@ -98,8 +102,35 @@ static struct of_regulator_match pbias_matches[] = {
 };
 #define PBIAS_NUM_REGS ARRAY_SIZE(pbias_matches)
 
+/* Offset from SCM general area (and syscon) base */
+
+static const struct pbias_of_data pbias_of_data_omap2 = {
+   .offset = 0x230,
+};
+
+static const struct pbias_of_data pbias_of_data_omap3 = {
+   .offset = 0x2b0,
+};
+
+static const struct pbias_of_data pbias_of_data_omap4 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_omap5 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_dra7 = {
+   .offset = 0xe00,
+};
+
 static const struct of_device_id pbias_of_match[] = {
{ .compatible = "ti,pbias-omap", },
+   { .compatible = "ti,pbias-omap2", .data = _of_data_omap2, },
+   { .compatible = "ti,pbias-omap3", .data = _of_data_omap3, },
+   { .compatible = "ti,pbias-omap4", .data = _of_data_omap4, },
+   { .compatible = "ti,pbias-omap5", .data = _of_data_omap5, },
+   { .compatible = "ti,pbias-dra7", .data = _of_data_dra7, },
{},
 };
 MODULE_DEVICE_TABLE(of, pbias_of_match);
@@ -114,6 +145,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
const struct pbias_reg_info *info;
int ret = 0;
int count, idx, data_idx = 0;
+   const struct of_device_id *match;
+   const struct pbias_of_data *data;
+   unsigned int offset;
 
count = of_regulator_match(>dev, np, pbias_matches,
PBIAS_NUM_REGS);
@@ -129,6 +163,20 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (IS_ERR(syscon))
return PTR_ERR(syscon);
 
+   match = of_match_device(of_match_ptr(pbias_of_match), >dev);
+   if (match && match->data) {
+   data = match->data;
+   offset = data->offset;
+   } else {
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res)
+   return -EINVAL;
+
+   offset = res->start;
+   dev_WARN(>dev,
+"using legacy dt data for pbias offset\n");
+   }
+
cfg.regmap = syscon;
cfg.dev = >dev;
 
@@ -141,10 +189,6 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (!info)
return -ENODEV;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -EINVAL;
-
drvdata[data_idx].syscon = syscon;
drvdata[data_idx].info = info;
drvdata[data_idx].desc.name = info->name;
@@ -154,9 +198,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
drvdata[data_idx].desc.volt_table = pbias_volt_table;
drvdata[data

[PATCH v3 2/2] ARM: dts: : use "ti,pbias-" compatible string for pbias

2015-09-04 Thread Kishon Vijay Abraham I
Use platform specific compatible strings instead of the common
"ti,pbias-omap" compatible string.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/dra7.dtsi |2 +-
 arch/arm/boot/dts/omap2430.dtsi |2 +-
 arch/arm/boot/dts/omap3.dtsi|2 +-
 arch/arm/boot/dts/omap4.dtsi|2 +-
 arch/arm/boot/dts/omap5.dtsi|2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1e29ccf..d6bc6db 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -122,7 +122,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
reg = <0xe00 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap5 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 2390f38..3961a6f 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -63,7 +63,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap2", 
"ti,pbias-omap";
reg = <0x230 0x4>;
syscon = <_conf>;
pbias_mmc_reg: 
pbias_mmc_omap2430 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..9af9ae1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -203,7 +203,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap3", "ti,pbias-omap";
reg = <0x2b0 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap2430 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index abc4473..5aad7f3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -198,7 +198,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap4", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap4 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b1a1263..76ef595 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -187,7 +187,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap5", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap5 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] omap: Fix broken address translation for pbias

2015-09-04 Thread Kishon Vijay Abraham I
Hi Tony,

On Thursday 03 September 2015 08:40 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kis...@ti.com> [150903 04:31]:
>> pbias device stopped having memory resource after
>> "ARM: dts: : add minimal l4 bus layout with control module
>> support" got merged. This results in platform_get_resource returning
>> -EINVAL in pbias driver. This is because address translation fails
>> while trying to convert the address to resource which happens
>> during the device creation process during boot up.
>>
>> Even though after [1], reg property in pbias dt node is un-used,
>> it might be an issue if we plan to use it at a later point of time.
>>
>> Patch series is created on top of [1].
>>
>> [1] -> https://lkml.org/lkml/2015/9/3/51
>>
>> Verified the address in omap4 panda, omap5 uevm and dra72 boards.
> 
> Your other series is obviously needed for v4.3.. But seems these
> are also needed for stable? If so, which versions, v4.2+?

Both the series are needed from v4.1+. However since the 'reg' property
is not going to be used, I'm not sure if this series has to be marked
for stable.
> 
> Can you please just do a single patch with multiple Fixes tags
> as they fix regression for multiple commits? Doing tons of one
> liner patches for the same thing just creates commit log noise..

Sure.
> 
> Remember to not Cc stable when posting, I'll add that tag when
> committing if needed.

Sure.

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


[PATCH v2] ARM: dts: >: fix address translation for pbias

2015-09-04 Thread Kishon Vijay Abraham I
"ARM: dts: : add minimal l4 bus
layout with control module support" moved pbias_regulator dt node
from being a child node of ocp to be the child node of
'syscon'. Since 'syscon' doesn't have the 'ranges' property,
address translation fails while trying to convert the address
to resource. Fix it here by populating 'ranges' property in
syscon dt node.

Fixes: 72b10ac00eb1 ("ARM: dts: omap24xx: add minimal l4 bus
layout with control module support")

Fixes: 7415b0b4c645 ("ARM: dts: omap4: add minimal l4 bus layout
with control module support")

Fixes: ed8509edddeb ("ARM: dts: omap5: add minimal l4 bus
layout with control module support")

Fixes: d919501feffa ("ARM: dts: dra7: add minimal l4 bus
layout with control module support")

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
Changes from v1:
*) squashed [1] to a single patch
[1] -> https://lkml.org/lkml/2015/9/3/166

 arch/arm/boot/dts/dra7.dtsi |1 +
 arch/arm/boot/dts/omap2430.dtsi |1 +
 arch/arm/boot/dts/omap4.dtsi|1 +
 arch/arm/boot/dts/omap5.dtsi|1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d6bc6db..5896896 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -120,6 +120,7 @@
reg = <0x0 0x1400>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x0 0x1400>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 3961a6f..798dda0 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -56,6 +56,7 @@
reg = <0x270 0x240>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x270 0x240>;
 
scm_clocks: clocks {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5aad7f3..5a206c1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,7 @@
reg = <0x5a0 0x170>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x5a0 0x170>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap4", 
"ti,pbias-omap";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 76ef595..dd7a0e8 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -185,6 +185,7 @@
reg = <0x5a0 0xec>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x5a0 0xec>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap5", 
"ti,pbias-omap";
-- 
1.7.9.5

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


Re: [PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

2015-09-04 Thread Kishon Vijay Abraham I
Hi,

On Thursday 03 September 2015 08:53 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kis...@ti.com> [150903 02:58]:
>> PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
>> OMAP5 and DRA7 SoCs. Enable it here.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
> 
> For the multi_v7_defconfig changes you need to resend this
> to a...@kernel.org. This is to avoid conflicts with other
> patches.

for some reason mail to a...@kernel.org bounced :-( Should I subscribe to
it before sending patches?

Thanks
Kishon

> 
> Regards,
> 
> Tony
> 
>>  arch/arm/configs/multi_v7_defconfig |1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig 
>> b/arch/arm/configs/multi_v7_defconfig
>> index 5fd8df6..f497c96 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
>>  CONFIG_REGULATOR_MAX77686=y
>>  CONFIG_REGULATOR_MAX77693=m
>>  CONFIG_REGULATOR_PALMAS=y
>> +CONFIG_REGULATOR_PBIAS=y
>>  CONFIG_REGULATOR_S2MPS11=y
>>  CONFIG_REGULATOR_S5M8767=y
>>  CONFIG_REGULATOR_TPS51632=y
>> -- 
>> 1.7.9.5
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/6] regulator: pbias: program pbias register offset in pbias driver

2015-09-03 Thread Kishon Vijay Abraham I
Add separate compatible strings for every platform and populate the
pbias register offset in the driver data.
This helps avoid depending on the dt for pbias register offset.

Also update the dt binding documentation for the new compatible
strings.

Suggested-by: Tony Lindgren <t...@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Tony Lindgren <t...@atomide.com>
---
 .../bindings/regulator/pbias-regulator.txt |7 ++-
 drivers/regulator/pbias-regulator.c|   56 +---
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
index 32aa26f..acbcb45 100644
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
@@ -2,7 +2,12 @@ PBIAS internal regulator for SD card dual voltage i/o pads on 
OMAP SoCs.
 
 Required properties:
 - compatible:
-  - "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7.
+  - should be "ti,pbias-dra7" for DRA7
+  - should be "ti,pbias-omap2" for OMAP2
+  - should be "ti,pbias-omap3" for OMAP3
+  - should be "ti,pbias-omap4" for OMAP4
+  - should be "ti,pbias-omap5" for OMAP5
+  - "ti,pbias-omap" is deprecated
 - reg: pbias register offset from syscon base and size of pbias register.
 - syscon : phandle of the system control module
 - regulator-name : should be
diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index bd2b75c..c21cedb 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -44,6 +44,10 @@ struct pbias_regulator_data {
int voltage;
 };
 
+struct pbias_of_data {
+   unsigned int offset;
+};
+
 static const unsigned int pbias_volt_table[] = {
180,
300
@@ -98,8 +102,35 @@ static struct of_regulator_match pbias_matches[] = {
 };
 #define PBIAS_NUM_REGS ARRAY_SIZE(pbias_matches)
 
+/* Offset from SCM general area (and syscon) base */
+
+static const struct pbias_of_data pbias_of_data_omap2 = {
+   .offset = 0x230,
+};
+
+static const struct pbias_of_data pbias_of_data_omap3 = {
+   .offset = 0x2b0,
+};
+
+static const struct pbias_of_data pbias_of_data_omap4 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_omap5 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_dra7 = {
+   .offset = 0xe00,
+};
+
 static const struct of_device_id pbias_of_match[] = {
{ .compatible = "ti,pbias-omap", },
+   { .compatible = "ti,pbias-omap2", .data = _of_data_omap2, },
+   { .compatible = "ti,pbias-omap3", .data = _of_data_omap3, },
+   { .compatible = "ti,pbias-omap4", .data = _of_data_omap4, },
+   { .compatible = "ti,pbias-omap5", .data = _of_data_omap5, },
+   { .compatible = "ti,pbias-dra7", .data = _of_data_dra7, },
{},
 };
 MODULE_DEVICE_TABLE(of, pbias_of_match);
@@ -114,6 +145,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
const struct pbias_reg_info *info;
int ret = 0;
int count, idx, data_idx = 0;
+   const struct of_device_id *match;
+   const struct pbias_of_data *data;
+   unsigned int offset;
 
count = of_regulator_match(>dev, np, pbias_matches,
PBIAS_NUM_REGS);
@@ -129,6 +163,20 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (IS_ERR(syscon))
return PTR_ERR(syscon);
 
+   match = of_match_device(of_match_ptr(pbias_of_match), >dev);
+   if (match && match->data) {
+   data = match->data;
+   offset = data->offset;
+   } else {
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res)
+   return -EINVAL;
+
+   offset = res->start;
+   dev_WARN(>dev,
+"using legacy dt data for pbias offset\n");
+   }
+
cfg.regmap = syscon;
cfg.dev = >dev;
 
@@ -141,10 +189,6 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (!info)
return -ENODEV;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -EINVAL;
-
drvdata[data_idx].syscon = syscon;
drvdata[data_idx].info = info;
drvdata[data_idx].desc.name = info->name;
@@ -154,9 +198,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
drvdata[data_idx].desc.volt_table = pbias_volt_table;
drvdata[data

[PATCH v2 0/6] regulator: Fix pbias regulator enable

2015-09-03 Thread Kishon Vijay Abraham I
vsel_reg and enable_reg of the pbias regulator descriptor should actually
have the offset from syscon.

However after
"ARM: dts: : add minimal l4 bus layout with control module
support"
vsel_reg and enable_reg started to have the absolute address because
of address translation that happens due to pbias node made as the
child node of syscon. This breaks the pbias regulator enable.

This series adds the 'offset' to be populated in vsel_reg and enable_reg
in the pbias driver itself.

Changes from v1:
*) Fixed Tony's review comments on adding a 'comment' for adding offset in
   the driver and adding a warning for using platform_get_resource.
*) Added Tony's Acked-by.

Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
dra72 and omap5 uevm

Kishon Vijay Abraham I (6):
  regulator: pbias: program pbias register offset in pbias driver
  ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias
  ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias
  ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias
  ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias
  ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias

 .../bindings/regulator/pbias-regulator.txt |7 ++-
 arch/arm/boot/dts/dra7.dtsi|2 +-
 arch/arm/boot/dts/omap2430.dtsi|2 +-
 arch/arm/boot/dts/omap3.dtsi   |2 +-
 arch/arm/boot/dts/omap4.dtsi   |2 +-
 arch/arm/boot/dts/omap5.dtsi   |2 +-
 drivers/regulator/pbias-regulator.c|   56 +---
 7 files changed, 61 insertions(+), 12 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/6] ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias

2015-09-03 Thread Kishon Vijay Abraham I
Use "ti,pbias-dra7" compatible string which is specifically added
for DRA7 SoCs.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/dra7.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1e29ccf..d6bc6db 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -122,7 +122,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
reg = <0xe00 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap5 {
-- 
1.7.9.5

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


[PATCH v2 4/6] ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias

2015-09-03 Thread Kishon Vijay Abraham I
Use "ti,pbias-omap3" compatible string which is specifically added
for OMAP3.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/omap3.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..9af9ae1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -203,7 +203,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap3", "ti,pbias-omap";
reg = <0x2b0 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap2430 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/6] ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias

2015-09-03 Thread Kishon Vijay Abraham I
Use "ti,pbias-omap2" compatible string which is specifically added
for OMAP2.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/omap2430.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 2390f38..3961a6f 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -63,7 +63,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap2", 
"ti,pbias-omap";
reg = <0x230 0x4>;
syscon = <_conf>;
pbias_mmc_reg: 
pbias_mmc_omap2430 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/6] regulator: Fix pbias regulator enable

2015-09-03 Thread Kishon Vijay Abraham I
Hi,

On Thursday 03 September 2015 01:09 PM, Ulf Hansson wrote:
> +Olof
> 
> On 3 September 2015 at 08:50, Kishon Vijay Abraham I <kis...@ti.com> wrote:
>> vsel_reg and enable_reg of the pbias regulator descriptor should actually
>> have the offset from syscon.
>>
>> However after
>> "ARM: dts: : add minimal l4 bus layout with control module
>> support"
>> vsel_reg and enable_reg started to have the absolute address because
>> of address translation that happens due to pbias node made as the
>> child node of syscon. This breaks the pbias regulator enable.
>>
>> This series adds the 'offset' to be populated in vsel_reg and enable_reg
>> in the pbias driver itself.
>>
>> Changes from v1:
>> *) Fixed Tony's review comments on adding a 'comment' for adding offset in
>>the driver and adding a warning for using platform_get_resource.
>> *) Added Tony's Acked-by.
>>
>> Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
>> dra72 and omap5 uevm
>>
>> Kishon Vijay Abraham I (6):
>>   regulator: pbias: program pbias register offset in pbias driver
>>   ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias
>>   ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias
>>   ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias
>>   ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias
>>   ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias
>>
>>  .../bindings/regulator/pbias-regulator.txt |7 ++-
>>  arch/arm/boot/dts/dra7.dtsi|2 +-
>>  arch/arm/boot/dts/omap2430.dtsi|2 +-
>>  arch/arm/boot/dts/omap3.dtsi   |2 +-
>>  arch/arm/boot/dts/omap4.dtsi   |2 +-
>>  arch/arm/boot/dts/omap5.dtsi   |2 +-
>>  drivers/regulator/pbias-regulator.c|   56 
>> +---
>>  7 files changed, 61 insertions(+), 12 deletions(-)
>>
>> --
>> 1.7.9.5
>>
> 
> I have recently queued another patchset [1] for the mmc omap driver
> for 4.3 through my mmc tree for which Olof Johansson reported a
> regression [2] for Panda ES with multi_v7_defconfig.

I generally perform my tests with omap2plus_defconfig and without this
series MMC doesn't work with omap2plus_defconfig.
> 
> Kishon, could you please clarify if $subject patchset solves that
> regression reported by Olof? Or perhaps Olof can run a test?

Just checked multi_v7_defconfig and this series is definitely required
to get MMC working. But we also have to enable 'CONFIG_REGULATOR_PBIAS'
which is not enabled by default in multi_v7_defconfig.

So we should have a patch to enable 'CONFIG_REGULATOR_PBIAS' in
multi_v7_defconfig to completely solve the problem reported by Olof.
I'll prepare a patch for multi_v7_defconfig and post it asap.

Thanks
Kishon

> 
> Finally, perhaps it's better if we queue this through my mmc tree
> since we would then be able to avoid the regression - if I put
> $subject patchset before [1], right? Then I need an ack from Mark for
> the regulator patch.
> Please tell me if you guys prefer another way.
> 
> Kind regards
> Uffe
> 
> [1]
> http://permalink.gmane.org/gmane.linux.kernel/2027789
> 
> [2]
> http://www.spinics.net/lists/linux-mmc/msg33146.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 6/6] ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias

2015-09-03 Thread Kishon Vijay Abraham I
Use "ti,pbias-omap5" compatible string which is specifically added
for OMAP5.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/omap5.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b1a1263..76ef595 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -187,7 +187,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap5", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap5 {
-- 
1.7.9.5

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


[PATCH v2 5/6] ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias

2015-09-03 Thread Kishon Vijay Abraham I
Use "ti,pbias-omap4" compatible string which is specifically added
for OMAP4.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
Acked-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/omap4.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index abc4473..5aad7f3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -198,7 +198,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap4", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap4 {
-- 
1.7.9.5

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


[PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

2015-09-03 Thread Kishon Vijay Abraham I
PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
OMAP5 and DRA7 SoCs. Enable it here.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/configs/multi_v7_defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 5fd8df6..f497c96 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
 CONFIG_REGULATOR_MAX77686=y
 CONFIG_REGULATOR_MAX77693=m
 CONFIG_REGULATOR_PALMAS=y
+CONFIG_REGULATOR_PBIAS=y
 CONFIG_REGULATOR_S2MPS11=y
 CONFIG_REGULATOR_S5M8767=y
 CONFIG_REGULATOR_TPS51632=y
-- 
1.7.9.5

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


[PATCH 1/4] ARM: dts: omap24xx: fix address translation for pbias

2015-09-03 Thread Kishon Vijay Abraham I
commit <72b10ac00eb1> ("ARM: dts: omap24xx: add minimal l4 bus
layout with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
scm_conf. Since scm_conf doesn't have the 'ranges' property,
address translation fails while trying to convert the address
to resource. Fix it here.

Fixes: 72b10ac00eb1 ("ARM: dts: omap24xx: add minimal l4 bus
layout with control module support")

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/omap2430.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 3961a6f..798dda0 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -56,6 +56,7 @@
reg = <0x270 0x240>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x270 0x240>;
 
scm_clocks: clocks {
#address-cells = <1>;
-- 
1.7.9.5

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


[PATCH 4/4] ARM: dts: dra7: fix address translation for pbias

2015-09-03 Thread Kishon Vijay Abraham I
commit  ("ARM: dts: dra7: add minimal l4 bus
layout with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
scm_conf. Since scm_conf doesn't have the 'ranges'
property, address translation fails while trying to convert the
address to resource. Fix it here.

Fixes: d919501feffa ("ARM: dts: dra7: add minimal l4 bus
layout with control module support")

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d6bc6db..5896896 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -120,6 +120,7 @@
reg = <0x0 0x1400>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x0 0x1400>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
-- 
1.7.9.5

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


[PATCH 0/4] omap: Fix broken address translation for pbias

2015-09-03 Thread Kishon Vijay Abraham I
pbias device stopped having memory resource after
"ARM: dts: : add minimal l4 bus layout with control module
support" got merged. This results in platform_get_resource returning
-EINVAL in pbias driver. This is because address translation fails
while trying to convert the address to resource which happens
during the device creation process during boot up.

Even though after [1], reg property in pbias dt node is un-used,
it might be an issue if we plan to use it at a later point of time.

Patch series is created on top of [1].

[1] -> https://lkml.org/lkml/2015/9/3/51

Verified the address in omap4 panda, omap5 uevm and dra72 boards.

Kishon Vijay Abraham I (4):
  ARM: dts: omap24xx: fix address translation for pbias
  ARM: dts: omap4: fix address translation for pbias
  ARM: dts: omap5: fix address translation for pbias
  ARM: dts: dra7: fix address translation for pbias

 arch/arm/boot/dts/dra7.dtsi |1 +
 arch/arm/boot/dts/omap2430.dtsi |1 +
 arch/arm/boot/dts/omap4.dtsi|1 +
 arch/arm/boot/dts/omap5.dtsi|1 +
 4 files changed, 4 insertions(+)

-- 
1.7.9.5

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


[PATCH 3/4] ARM: dts: omap5: fix address translation for pbias

2015-09-03 Thread Kishon Vijay Abraham I
commit  ("ARM: dts: omap5: add minimal l4 bus
layout with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
omap5_padconf_global. Since omap5_padconf_global doesn't have the
'ranges' property, address translation fails while trying to convert
the address to resource. Fix it here.

Fixes: ed8509edddeb ("ARM: dts: omap5: add minimal l4 bus
layout with control module support")

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/omap5.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 76ef595..dd7a0e8 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -185,6 +185,7 @@
reg = <0x5a0 0xec>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x5a0 0xec>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap5", 
"ti,pbias-omap";
-- 
1.7.9.5

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


[PATCH 2/4] ARM: dts: omap4: fix address translation for pbias

2015-09-03 Thread Kishon Vijay Abraham I
commit <7415b0b4c645> ("ARM: dts: omap4: add minimal l4 bus layout
with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
omap4_padconf_global. Since omap4_padconf_global doesn't have the
'ranges' property, address translation fails while trying to convert
the address to resource. Fix it here.

Fixes: 7415b0b4c645 ("ARM: dts: omap4: add minimal l4 bus layout
with control module support")

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/omap4.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5aad7f3..5a206c1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,7 @@
reg = <0x5a0 0x170>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x5a0 0x170>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap4", 
"ti,pbias-omap";
-- 
1.7.9.5

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


[PATCH 5/6] ARM: dts: OMAP4: use "ti,pbias-omap4" compatible string for pbias

2015-09-02 Thread Kishon Vijay Abraham I
Use "ti,pbias-omap4" compatible string which is specifically added
for OMAP4.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/omap4.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index abc4473..5aad7f3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -198,7 +198,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap4", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap4 {
-- 
1.7.9.5

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


[PATCH 4/6] ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias

2015-09-02 Thread Kishon Vijay Abraham I
Use "ti,pbias-omap3" compatible string which is specifically added
for OMAP3.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/omap3.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..9af9ae1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -203,7 +203,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap3", "ti,pbias-omap";
reg = <0x2b0 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap2430 {
-- 
1.7.9.5

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


[PATCH 0/6] Fix pbias regulator enable

2015-09-02 Thread Kishon Vijay Abraham I
vsel_reg and enable_reg of the pbias regulator descriptor should actually
have the offset from syscon.

However after
"ARM: dts: : add minimal l4 bus layout with control module
support"
vsel_reg and enable_reg started to have the absolute address because
of address translation that happens due to pbias node made as the
child node of syscon. This breaks the pbias regulator enable.

This series adds the 'offset' to be populated in vsel_reg and enable_reg
in the pbias driver itself.

Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
dra72 and omap5 uevm

Kishon Vijay Abraham I (6):
  regulator: pbias: program pbias register offset in pbias driver
  ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias
  ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias
  ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias
  ARM: dts: OMAP4: use "ti,pbias-omap4" compatible string for pbias
  ARM: dts: OMAP5: use "ti,pbias-omap5" compatible string for pbias

 .../bindings/regulator/pbias-regulator.txt |7 ++-
 arch/arm/boot/dts/dra7.dtsi|2 +-
 arch/arm/boot/dts/omap2430.dtsi|2 +-
 arch/arm/boot/dts/omap3.dtsi   |2 +-
 arch/arm/boot/dts/omap4.dtsi   |2 +-
 arch/arm/boot/dts/omap5.dtsi   |2 +-
 drivers/regulator/pbias-regulator.c|   52 +---
 7 files changed, 57 insertions(+), 12 deletions(-)

-- 
1.7.9.5

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


[PATCH 1/6] regulator: pbias: program pbias register offset in pbias driver

2015-09-02 Thread Kishon Vijay Abraham I
Add separate compatible strings for every platform and populate the
pbias register offset in the driver data.
This helps avoid depending on the dt for pbias register offset.

Also update the dt binding documentation with the new compatible
strings.

Suggested-by: Tony Lindgren <t...@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 .../bindings/regulator/pbias-regulator.txt |7 ++-
 drivers/regulator/pbias-regulator.c|   52 +---
 2 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
index 32aa26f..acbcb45 100644
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
@@ -2,7 +2,12 @@ PBIAS internal regulator for SD card dual voltage i/o pads on 
OMAP SoCs.
 
 Required properties:
 - compatible:
-  - "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7.
+  - should be "ti,pbias-dra7" for DRA7
+  - should be "ti,pbias-omap2" for OMAP2
+  - should be "ti,pbias-omap3" for OMAP3
+  - should be "ti,pbias-omap4" for OMAP4
+  - should be "ti,pbias-omap5" for OMAP5
+  - "ti,pbias-omap" is deprecated
 - reg: pbias register offset from syscon base and size of pbias register.
 - syscon : phandle of the system control module
 - regulator-name : should be
diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index bd2b75c..afe5056 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -44,6 +44,10 @@ struct pbias_regulator_data {
int voltage;
 };
 
+struct pbias_of_data {
+   unsigned int offset;
+};
+
 static const unsigned int pbias_volt_table[] = {
180,
300
@@ -98,8 +102,33 @@ static struct of_regulator_match pbias_matches[] = {
 };
 #define PBIAS_NUM_REGS ARRAY_SIZE(pbias_matches)
 
+static const struct pbias_of_data pbias_of_data_omap2 = {
+   .offset = 0x230,
+};
+
+static const struct pbias_of_data pbias_of_data_omap3 = {
+   .offset = 0x2b0,
+};
+
+static const struct pbias_of_data pbias_of_data_omap4 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_omap5 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_dra7 = {
+   .offset = 0xe00,
+};
+
 static const struct of_device_id pbias_of_match[] = {
{ .compatible = "ti,pbias-omap", },
+   { .compatible = "ti,pbias-omap2", .data = _of_data_omap2, },
+   { .compatible = "ti,pbias-omap3", .data = _of_data_omap3, },
+   { .compatible = "ti,pbias-omap4", .data = _of_data_omap4, },
+   { .compatible = "ti,pbias-omap5", .data = _of_data_omap5, },
+   { .compatible = "ti,pbias-dra7", .data = _of_data_dra7, },
{},
 };
 MODULE_DEVICE_TABLE(of, pbias_of_match);
@@ -114,6 +143,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
const struct pbias_reg_info *info;
int ret = 0;
int count, idx, data_idx = 0;
+   const struct of_device_id *match;
+   const struct pbias_of_data *data;
+   unsigned int offset;
 
count = of_regulator_match(>dev, np, pbias_matches,
PBIAS_NUM_REGS);
@@ -129,6 +161,18 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (IS_ERR(syscon))
return PTR_ERR(syscon);
 
+   match = of_match_device(of_match_ptr(pbias_of_match), >dev);
+   if (match && match->data) {
+   data = match->data;
+   offset = data->offset;
+   } else {
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res)
+   return -EINVAL;
+
+   offset = res->start;
+   }
+
cfg.regmap = syscon;
cfg.dev = >dev;
 
@@ -141,10 +185,6 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (!info)
return -ENODEV;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -EINVAL;
-
drvdata[data_idx].syscon = syscon;
drvdata[data_idx].info = info;
drvdata[data_idx].desc.name = info->name;
@@ -154,9 +194,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
drvdata[data_idx].desc.volt_table = pbias_volt_table;
drvdata[data_idx].desc.n_voltages = 2;
drvdata[data_idx].desc.enable_time = info->enable_time;
-   drvdata[data_idx].desc.vsel_reg = res->start;
+   drvdata[data_idx].desc.vsel_reg = offse

[PATCH 2/6] ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias

2015-09-02 Thread Kishon Vijay Abraham I
Use "ti,pbias-dra7" compatible string which is specifically added
for DRA7 SoCs.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1e29ccf..d6bc6db 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -122,7 +122,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
reg = <0xe00 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap5 {
-- 
1.7.9.5

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


[PATCH 6/6] ARM: dts: OMAP5: use "ti,pbias-omap5" compatible string for pbias

2015-09-02 Thread Kishon Vijay Abraham I
Use "ti,pbias-omap5" compatible string which is specifically added
for OMAP5.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/omap5.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b1a1263..76ef595 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -187,7 +187,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap5", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap5 {
-- 
1.7.9.5

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


[PATCH 3/6] ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias

2015-09-02 Thread Kishon Vijay Abraham I
Use "ti,pbias-omap2" compatible string which is specifically added
for OMAP2.

Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
---
 arch/arm/boot/dts/omap2430.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 2390f38..3961a6f 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -63,7 +63,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap2", 
"ti,pbias-omap";
reg = <0x230 0x4>;
syscon = <_conf>;
pbias_mmc_reg: 
pbias_mmc_omap2430 {
-- 
1.7.9.5

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


Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

2015-09-01 Thread Kishon Vijay Abraham I
Hi Mark,

On Monday 31 August 2015 08:22 PM, Mark Brown wrote:
> On Mon, Aug 31, 2015 at 04:14:07PM +0530, Kishon Vijay Abraham I wrote:
>> On Tuesday 25 August 2015 07:20 PM, Mark Brown wrote:
>>> On Tue, Aug 25, 2015 at 01:03:04PM +0300, Grygorii Strashko wrote:
>>>> On 08/19/2015 09:11 PM, Mark Brown wrote:
> 
>>>>> So substract this address from the start of the resource to get the
>>>>> offset?  Or provide a wrapper function in the resource code which does
>>>>> that.  
>>>
>>>> I'd be very appreciated if you have and can share any thought on
>>>> How can we get this absolute base address to substract?
>>>
>>> Ask the syscon device for its resource?  Or have it provide an absolute
>>
>> Even if we get the absolute address of syscon, we have to do the
>> subtraction only for the newer dtbs (previous dtbs already have only the
>> offset). Do you recommend adding a new property to differentiate between
>> older dtbs and newer dtbs? Any other suggestions here?
> 
> Hang on.  This is the first I've heard of any DTs not just having
> absolute addresses.  How does any of this work - has it ever worked, and
> is the situation completely understood?  My original concern with this

Before commit d919501feffa8715147582c3ffce96fad0c7016f ARM: dts: dra7:
add minimal l4 bus layout with control module support, the dt was like

ocp {
dra7_ctrl_general: tisyscon@4a002e00 {
compatible = "syscon";
reg = <0x4a002e00 0x7c>;
};

pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap";
reg = <0 0x4>;
syscon = <_ctrl_general>;
};
};

Here platform_get_resource in pbias driver returns '0' which is
populated in vsel_reg and enable_reg. And regulator_enable_regmap uses
the base address from tisyscon@4a002e00 which is '0x4a002e00' and offset
from enable_reg which is '0' inorder to write to the pbias register.

But after commit d919501fef, the dt became like this (after a couple of
fixes)

ocp {
l4_cfg: l4@4a00 {
compatible = "ti,dra7-l4-cfg", "simple-bus";
ranges = <0 0x4a00 0x22c000>;

scm: scm@2000 {
compatible = "ti,dra7-scm-core", "simple-bus";
reg = <0x2000 0x2000>;
ranges = <0 0x2000 0x2000>;

scm_conf: scm_conf@0 {
compatible = "syscon", "simple-bus";
reg = <0x0 0x1400>;
ranges = <0 0x0 0x1400>;

pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap";
reg = <0xe00 0x4>;
syscon = <_conf>;
};
};
};
};
};

Here platform_get_resource in pbias driver returns '4a002e00' which is
populated in vsel_reg and enable_reg. And regulator_enable_regmap uses
the base address from scm_conf@0 which is '0x4a002000' and offset from
enable_reg which is '4a002e00' inorder to write to the pbias register
and it results in a abort.

> was that I coudn't understand the commit log and your original response
> seemed to indicate that we always have the absolute address :(  Perhaps

We started having the absolute address only after the dt change (commit
d919501fef and a couple of more dt fixes).

> this is something to do with the brief mention of having moved the DT
> node for some reason?
> 
> We at least need some sort of coherent explanation of the problem and a
> comprehensible fix to go with it.  Right now it seems like things are
> just being moved about to hide problems without either of these things
> which seems like it makes the code less clear and more fragile.

hmm.. IMO the actual problem was modelling the 'offset' as a resource
(by populating the offset in 'reg' property) which was added when the
initial pbias dt node was created. And now since the pbias dt node is
being moved around, it's causing inadvertent address translation
breaking the pbias driver. IMHO the value in 'reg' property of pbias dt
node should be treated as 'offset' instead of address 'resource' and
that's what my patch tried to do.
> 
>>> address based interface for that matter?
> 
>> Syscon doesn't directly expose any API's to write to it's register.
>> Rather it uses regmap APIs to read/write to it's register. I'm not sure
>> if it's possible to add regmap APIs to write to a registe

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

2015-09-01 Thread Kishon Vijay Abraham I
Now fixed Lee Jones mail address!

On Tuesday 01 September 2015 03:10 PM, Kishon Vijay Abraham I wrote:
> Hi Mark,
> 
> On Monday 31 August 2015 08:22 PM, Mark Brown wrote:
>> On Mon, Aug 31, 2015 at 04:14:07PM +0530, Kishon Vijay Abraham I wrote:
>>> On Tuesday 25 August 2015 07:20 PM, Mark Brown wrote:
>>>> On Tue, Aug 25, 2015 at 01:03:04PM +0300, Grygorii Strashko wrote:
>>>>> On 08/19/2015 09:11 PM, Mark Brown wrote:
>>
>>>>>> So substract this address from the start of the resource to get the
>>>>>> offset?  Or provide a wrapper function in the resource code which does
>>>>>> that.  
>>>>
>>>>> I'd be very appreciated if you have and can share any thought on
>>>>> How can we get this absolute base address to substract?
>>>>
>>>> Ask the syscon device for its resource?  Or have it provide an absolute
>>>
>>> Even if we get the absolute address of syscon, we have to do the
>>> subtraction only for the newer dtbs (previous dtbs already have only the
>>> offset). Do you recommend adding a new property to differentiate between
>>> older dtbs and newer dtbs? Any other suggestions here?
>>
>> Hang on.  This is the first I've heard of any DTs not just having
>> absolute addresses.  How does any of this work - has it ever worked, and
>> is the situation completely understood?  My original concern with this
> 
> Before commit d919501feffa8715147582c3ffce96fad0c7016f ARM: dts: dra7:
> add minimal l4 bus layout with control module support, the dt was like
> 
> ocp {
>   dra7_ctrl_general: tisyscon@4a002e00 {
>   compatible = "syscon";
>   reg = <0x4a002e00 0x7c>;
>   };
> 
>   pbias_regulator: pbias_regulator {
>   compatible = "ti,pbias-omap";
>   reg = <0 0x4>;
>   syscon = <_ctrl_general>;
>   };
> };
> 
> Here platform_get_resource in pbias driver returns '0' which is
> populated in vsel_reg and enable_reg. And regulator_enable_regmap uses
> the base address from tisyscon@4a002e00 which is '0x4a002e00' and offset
> from enable_reg which is '0' inorder to write to the pbias register.
> 
> But after commit d919501fef, the dt became like this (after a couple of
> fixes)
> 
> ocp {
>   l4_cfg: l4@4a00 {
>   compatible = "ti,dra7-l4-cfg", "simple-bus";
>   ranges = <0 0x4a00 0x22c000>;
> 
>   scm: scm@2000 {
>   compatible = "ti,dra7-scm-core", "simple-bus";
>   reg = <0x2000 0x2000>;
>   ranges = <0 0x2000 0x2000>;
> 
>   scm_conf: scm_conf@0 {
>   compatible = "syscon", "simple-bus";
>   reg = <0x0 0x1400>;
>   ranges = <0 0x0 0x1400>;
> 
>   pbias_regulator: pbias_regulator {
>   compatible = "ti,pbias-omap";
>   reg = <0xe00 0x4>;
>   syscon = <_conf>;
> };
>   };
>   };
>   };
> };
> 
> Here platform_get_resource in pbias driver returns '4a002e00' which is
> populated in vsel_reg and enable_reg. And regulator_enable_regmap uses
> the base address from scm_conf@0 which is '0x4a002000' and offset from
> enable_reg which is '4a002e00' inorder to write to the pbias register
> and it results in a abort.
> 
>> was that I coudn't understand the commit log and your original response
>> seemed to indicate that we always have the absolute address :(  Perhaps
> 
> We started having the absolute address only after the dt change (commit
> d919501fef and a couple of more dt fixes).
> 
>> this is something to do with the brief mention of having moved the DT
>> node for some reason?
>>
>> We at least need some sort of coherent explanation of the problem and a
>> comprehensible fix to go with it.  Right now it seems like things are
>> just being moved about to hide problems without either of these things
>> which seems like it makes the code less clear and more fragile.
> 
> hmm.. IMO the actual problem was modelling the 'offset' as a resource
> (by populating the offset in 'reg' property) which was added when the
> initial pbias dt node was created. And now since the pbias dt node is
> being moved arou

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

2015-08-31 Thread Kishon Vijay Abraham I
Hi Mark,

On Tuesday 25 August 2015 07:20 PM, Mark Brown wrote:
> On Tue, Aug 25, 2015 at 01:03:04PM +0300, Grygorii Strashko wrote:
>> On 08/19/2015 09:11 PM, Mark Brown wrote:
> 
>>> So substract this address from the start of the resource to get the
>>> offset?  Or provide a wrapper function in the resource code which does
>>> that.  
> 
>> I'd be very appreciated if you have and can share any thought on
>> How can we get this absolute base address to substract?
> 
> Ask the syscon device for its resource?  Or have it provide an absolute

Even if we get the absolute address of syscon, we have to do the
subtraction only for the newer dtbs (previous dtbs already have only the
offset). Do you recommend adding a new property to differentiate between
older dtbs and newer dtbs? Any other suggestions here?

> address based interface for that matter?

Syscon doesn't directly expose any API's to write to it's register.
Rather it uses regmap APIs to read/write to it's register. I'm not sure
if it's possible to add regmap APIs to write to a register with absolute
address. Any hints?

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get

2015-08-30 Thread Kishon Vijay Abraham I
Hi,

On Saturday 29 August 2015 12:33 AM, Tony Lindgren wrote:
 * Olof Johansson o...@lixom.net [150828 11:11]:
 Hi,

 On Thu, Aug 27, 2015 at 2:13 AM, Kishon Vijay Abraham I kis...@ti.com 
 wrote:
 Now return error only if the return value of
 devm_regulator_get_optional() is not the same as -ENODEV, since with
 -EPROBE_DEFER, the regulator can be obtained later and all other
 errors are fatal.

 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 Tested-by: Tony Lindgren t...@atomide.com

 I bisected boot failures on Panda ES with multi_v7_defconfig down to
 this commit on last night's -next build:

 http://arm-soc.lixom.net/bootlogs/next/next-20150828/pandaes-arm-multi_v7_defconfig.html
 
 MMC is working for me at least on Duovero. Interesting that you also
 have all kind of errors there, I guess this is some older revision
 of the board.
 
 Anyways, Kishon, care to look into what might be causing this?

I think this might be because my pbias fix [1] patch wasn't merged yet.
I'll try to get that resolved asap.

Thanks
Kishon

[1] - http://lkml.iu.edu/hypermail/linux/kernel/1507.3/01594.html
 
 Regards,
 
 Tony
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 13/15] mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status

2015-08-27 Thread Kishon Vijay Abraham I
Hi Uffe,

On Thursday 27 August 2015 06:12 PM, Ulf Hansson wrote:
 On 27 August 2015 at 14:41, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 27 August 2015 at 11:14, Kishon Vijay Abraham I kis...@ti.com wrote:
 Use regulator_is_enabled of pbias regulator to find pbias regulator
 status instead of maintaining a custom bookkeeping
 pbias_enabled variable.

 Doesn't this cause a problem for the scenario when the initial state
 of the regulator is enabled?

Patch 11 of this series mmc: host: omap_hsmmc: don't use -set_power to
set initial regulator state disables the pbias regulator if the initial
state of the regulator is enabled.

Thanks
Kishon

 Both in the sense that you will increase the enable count for it
 
 /s/will/won't
 
 (potentially it may then become disabled when you need it enabled) but
 also from a enable/disable imbalance point of view.

 Kind regards
 Uffe


 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 Tested-by: Tony Lindgren t...@atomide.com
 ---
  drivers/mmc/host/omap_hsmmc.c |8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 5a5946a..4cd7a58 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -182,7 +182,6 @@ struct omap_hsmmc_host {
 struct  clk *fclk;
 struct  clk *dbclk;
 struct  regulator   *pbias;
 -   boolpbias_enabled;
 void__iomem *base;
 int vqmmc_enabled;
 resource_size_t mapbase;
 @@ -330,22 +329,20 @@ static int omap_hsmmc_set_pbias(struct 
 omap_hsmmc_host *host, bool power_on,
 return ret;
 }

 -   if (host-pbias_enabled == 0) {
 +   if (!regulator_is_enabled(host-pbias)) {
 ret = regulator_enable(host-pbias);
 if (ret) {
 dev_err(host-dev, pbias reg enable 
 fail\n);
 return ret;
 }
 -   host-pbias_enabled = 1;
 }
 } else {
 -   if (host-pbias_enabled == 1) {
 +   if (regulator_is_enabled(host-pbias)) {
 ret = regulator_disable(host-pbias);
 if (ret) {
 dev_err(host-dev, pbias reg disable 
 fail\n);
 return ret;
 }
 -   host-pbias_enabled = 0;
 }
 }

 @@ -2081,7 +2078,6 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 host-base  = base + pdata-reg_offset;
 host-power_mode = MMC_POWER_OFF;
 host-next_data.cookie = 1;
 -   host-pbias_enabled = 0;
 host-vqmmc_enabled = 0;

 ret = omap_hsmmc_gpio_init(mmc, host, pdata);
 --
 1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/15] omap_hsmmc: regulator usage cleanup and fixes

2015-08-27 Thread Kishon Vijay Abraham I


On Thursday 27 August 2015 06:39 PM, Ulf Hansson wrote:
 On 27 August 2015 at 11:13, Kishon Vijay Abraham I kis...@ti.com wrote:
 This patch series does the following
 *) Uses devm_regulator_get_optional() for vmmc and then removes the
CONFIG_REGULATOR check altogether.
 *) return on -EPROBE_DEFER and any other fatal errors
 *) enable/disable vmmc_aux regulator based on prior state

 Changes from v2:
 *) rebased to mmc -next branch
 *) dropped using mmc_of_parse_voltage to get ocr_avail patch.

 Changes from v1:
 *) return on -EPROBE_DEFER and other fatal errors. (Don't return only
if the return value is -ENODEV)
 *) Remove the beagle x15 dts patch. It can be part of a different
series.
 *) Avoid using regulator_is_enabled for vqmmc since if the regulator
is shared and the other users are not using regulator_is_enabled
then there can be unbalanced regulator_enable/regulator_disable

 I've pushed this patch series to
 git://git.ti.com/linux-phy/linux-phy.git mmc_for-next

 Please note the branch also has the pbias fixes [1].
 [1] - https://lkml.org/lkml/2015/7/27/358

 This series is in preparation for implementing the voltage switch
 sequence so that UHS cards can be supported.

 Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM,
 Beaglebone black, OMAP5 uEVM, OMAP4 PANDA and OMAP3gle xm.

 Kishon Vijay Abraham I (15):
   mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc
   mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get
   mmc: host: omap_hsmmc: cleanup omap_hsmmc_reg_get()
   mmc: host: omap_hsmmc: use the ocrmask provided by the vmmc regulator
   mmc: host: omap_hsmmc: use mmc_host's vmmc and vqmmc
   mmc: host: omap_hsmmc: remove unnecessary pbias set_voltage
   mmc: host: omap_hsmmc: return error if any of the regulator APIs fail
   mmc: host: omap_hsmmc: add separate functions for enable/disable
 supply
   mmc: host: omap_hsmmc: add separate function to set pbias
   mmc: host: omap_hsmmc: avoid pbias regulator enable on power off
   mmc: host: omap_hsmmc: don't use -set_power to set initial regulator
 state
   mmc: host: omap_hsmmc: enable/disable vmmc_aux regulator based on
 previous state
   mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status
   mmc: host: omap_hsmmc: use ios-vdd for setting vmmc voltage
   mmc: host: omap_hsmmc: remove CONFIG_REGULATOR check

  drivers/mmc/host/omap_hsmmc.c |  326 
 +++--
  1 file changed, 212 insertions(+), 114 deletions(-)

 --
 1.7.9.5

 
 Thanks, applied for next!

Thank you.

-Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/15] mmc: host: omap_hsmmc: avoid pbias regulator enable on power off

2015-08-27 Thread Kishon Vijay Abraham I
Fix omap_hsmmc_set_power so that pbias regulator is not enabled
during power off.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Tested-by: Tony Lindgren t...@atomide.com
---
 drivers/mmc/host/omap_hsmmc.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 810d612..eec6975 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -388,16 +388,16 @@ static int omap_hsmmc_set_power(struct device *dev, int 
power_on, int vdd)
ret = omap_hsmmc_enable_supply(mmc, vdd);
if (ret)
return ret;
+
+   ret = omap_hsmmc_set_pbias(host, true, vdd);
+   if (ret)
+   goto err_set_voltage;
} else {
ret = omap_hsmmc_disable_supply(mmc);
if (ret)
return ret;
}
 
-   ret = omap_hsmmc_set_pbias(host, true, vdd);
-   if (ret)
-   goto err_set_voltage;
-
if (mmc_pdata(host)-after_set_reg)
mmc_pdata(host)-after_set_reg(dev, power_on, vdd);
 
-- 
1.7.9.5

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


[PATCH v3 11/15] mmc: host: omap_hsmmc: don't use -set_power to set initial regulator state

2015-08-27 Thread Kishon Vijay Abraham I
If the regulator is enabled on boot (checked using regulator_is_enabled),
invoke regulator_enable() so that the usecount reflects the correct
state of the regulator and then disable the regulator so that the
initial state of the regulator is disabled. Avoid using -set_power,
since set_power also takes care of setting the voltages which is not
needed at this point.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Tested-by: Tony Lindgren t...@atomide.com
---
 drivers/mmc/host/omap_hsmmc.c |   66 ++---
 1 file changed, 56 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index eec6975..cd4bd6d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -409,6 +409,59 @@ err_set_voltage:
return ret;
 }
 
+static int omap_hsmmc_disable_boot_regulator(struct regulator *reg)
+{
+   int ret;
+
+   if (!reg)
+   return 0;
+
+   if (regulator_is_enabled(reg)) {
+   ret = regulator_enable(reg);
+   if (ret)
+   return ret;
+
+   ret = regulator_disable(reg);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int omap_hsmmc_disable_boot_regulators(struct omap_hsmmc_host *host)
+{
+   struct mmc_host *mmc = host-mmc;
+   int ret;
+
+   /*
+* disable regulators enabled during boot and get the usecount
+* right so that regulators can be enabled/disabled by checking
+* the return value of regulator_is_enabled
+*/
+   ret = omap_hsmmc_disable_boot_regulator(mmc-supply.vmmc);
+   if (ret) {
+   dev_err(host-dev, fail to disable boot enabled vmmc reg\n);
+   return ret;
+   }
+
+   ret = omap_hsmmc_disable_boot_regulator(mmc-supply.vqmmc);
+   if (ret) {
+   dev_err(host-dev,
+   fail to disable boot enabled vmmc_aux reg\n);
+   return ret;
+   }
+
+   ret = omap_hsmmc_disable_boot_regulator(host-pbias);
+   if (ret) {
+   dev_err(host-dev,
+   failed to disable boot enabled pbias reg\n);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
 {
int ocr_value = 0;
@@ -456,17 +509,10 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
*host)
/* For eMMC do not power off when not in sleep state */
if (mmc_pdata(host)-no_regulator_off_init)
return 0;
-   /*
-* To disable boot_on regulator, enable regulator
-* to increase usecount and then disable it.
-*/
-   if ((mmc-supply.vmmc  regulator_is_enabled(mmc-supply.vmmc)  0) ||
-   (mmc-supply.vqmmc  regulator_is_enabled(mmc-supply.vqmmc))) {
-   int vdd = ffs(mmc_pdata(host)-ocr_mask) - 1;
 
-   omap_hsmmc_set_power(host-dev, 1, vdd);
-   omap_hsmmc_set_power(host-dev, 0, 0);
-   }
+   ret = omap_hsmmc_disable_boot_regulators(host);
+   if (ret)
+   return ret;
 
return 0;
 }
-- 
1.7.9.5

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


  1   2   3   4   5   6   7   8   9   10   >