[PATCH 1/2] ARM: dts: use ti,fixed-factor-clock for dpll4_m5x2_mul_ck

2014-04-21 Thread Laurent Pinchart
We need to use set-rate-parent for dpll4_m5 clock path, so use the
ti,fixed-factor-clock version which supports set-rate-parent property.

The set-rate-parent flag itself is set in the following patch, this one
just changes the clock driver to ti,fixed-factor-clock without any other
changes.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +-
 arch/arm/boot/dts/omap3xxx-clocks.dtsi | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi 
b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 6b5280d..200ae3a 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -83,7 +83,7 @@
 };
 
 dpll4_m5x2_mul_ck {
-   clock-mult = 1;
+   ti,clock-mult = 1;
 };
 
 dpll4_m6x2_mul_ck {
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi 
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index 12be2b3..351f58b 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -453,10 +453,10 @@
 
dpll4_m5x2_mul_ck: dpll4_m5x2_mul_ck {
#clock-cells = 0;
-   compatible = fixed-factor-clock;
+   compatible = ti,fixed-factor-clock;
clocks = dpll4_m5_ck;
-   clock-mult = 2;
-   clock-div = 1;
+   ti,clock-mult = 2;
+   ti,clock-div = 1;
};
 
dpll4_m5x2_ck: dpll4_m5x2_ck {
-- 
1.8.3.2

--
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] ARM: dts: Fix OMAP3 ISP functional clock configuration

2014-04-21 Thread Laurent Pinchart
Hello,

This patch set enables rate propagation from the OMAP3 ISP functional clock to
the DPLL4 M5 clock. It copies Tomi Valkeinen's similar patch set for the OMAP
DSS functional clock from the OMAP: OMAP3 DSS related clock patches patch
series.

Laurent Pinchart (2):
  ARM: dts: use ti,fixed-factor-clock for dpll4_m5x2_mul_ck
  ARM: dts: set 'ti,set-rate-parent' for dpll4_m5 path

 arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +-
 arch/arm/boot/dts/omap3xxx-clocks.dtsi | 7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

-- 
Regards,

Laurent Pinchart

--
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] ARM: dts: set 'ti,set-rate-parent' for dpll4_m5 path

2014-04-21 Thread Laurent Pinchart
Set 'ti,set-rate-parent' property for the dpll4_m5x2_mul_ck clock, which
is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
clock rate configuration, which needs the rate to be propagated properly
to the divider node (dpll4_m5_ck).

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi 
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index 351f58b..e47ff69 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -457,6 +457,7 @@
clocks = dpll4_m5_ck;
ti,clock-mult = 2;
ti,clock-div = 1;
+   ti,set-rate-parent;
};
 
dpll4_m5x2_ck: dpll4_m5x2_ck {
-- 
1.8.3.2

--
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/3] usb: ohci-exynos: Make provision for vdd regulators

2014-04-21 Thread Vivek Gautam
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.

With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,

certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---

Based on 'usb-next' branch of Greg's usb tree.

 drivers/usb/host/ohci-exynos.c |   47 
 1 file changed, 47 insertions(+)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
 #include linux/module.h
 #include linux/of.h
 #include linux/platform_device.h
+#include linux/regulator/consumer.h
 #include linux/usb/phy.h
 #include linux/usb/samsung_usb_phy.h
 #include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+   struct regulator *vdd33;
+   struct regulator *vdd10;
 };
 
 static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device *pdev)
exynos_ohci-otg = phy-otg;
}
 
+   exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+   if (IS_ERR(exynos_ohci-vdd33)) {
+   err = PTR_ERR(exynos_ohci-vdd33);
+   goto fail_regulator1;
+   }
+   err = regulator_enable(exynos_ohci-vdd33);
+   if (err) {
+   dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+   goto fail_regulator1;
+   }
+
+   exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+   if (IS_ERR(exynos_ohci-vdd10)) {
+   err = PTR_ERR(exynos_ohci-vdd10);
+   goto fail_regulator2;
+   }
+   err = regulator_enable(exynos_ohci-vdd10);
+   if (err) {
+   dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+   goto fail_regulator2;
+   }
+
 skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
 
@@ -154,6 +179,10 @@ fail_add_hcd:
 fail_io:
clk_disable_unprepare(exynos_ohci-clk);
 fail_clk:
+   regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+   regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
 }
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct platform_device *pdev)
 
clk_disable_unprepare(exynos_ohci-clk);
 
+   regulator_disable(exynos_ohci-vdd10);
+   regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
 
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
 
clk_disable_unprepare(exynos_ohci-clk);
 
+   regulator_disable(exynos_ohci-vdd10);
+   regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
 
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+   int ret;
+
+   ret = regulator_enable(exynos_ohci-vdd33);
+   if (ret) {
+   dev_err(dev, Failed to enable VDD33 supply\n);
+   return ret;
+   }
+   ret = regulator_enable(exynos_ohci-vdd10);
+   if (ret) {
+   dev_err(dev, Failed to enable VDD10 supply\n);
+   return ret;
+   }
 
clk_prepare_enable(exynos_ohci-clk);
 
-- 
1.7.10.4

--
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/3] usb: dwc3-exynos: Make provision for vdd regulators

2014-04-21 Thread Vivek Gautam
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.

With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,

certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---

Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.

 drivers/usb/dwc3/dwc3-exynos.c |   51 ++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
 #include linux/usb/usb_phy_gen_xceiv.h
 #include linux/of.h
 #include linux/of_platform.h
+#include linux/regulator/consumer.h
 
 struct dwc3_exynos {
struct platform_device  *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device   *dev;
 
struct clk  *clk;
+   struct regulator*vdd33;
+   struct regulator*vdd10;
 };
 
 static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
 
clk_prepare_enable(exynos-clk);
 
+   exynos-vdd33 = devm_regulator_get(dev, vdd33);
+   if (IS_ERR(exynos-vdd33)) {
+   ret = PTR_ERR(exynos-vdd33);
+   goto err2;
+   }
+   ret = regulator_enable(exynos-vdd33);
+   if (ret) {
+   dev_err(dev, Failed to enable VDD33 supply\n);
+   goto err2;
+   }
+
+   exynos-vdd10 = devm_regulator_get(dev, vdd10);
+   if (IS_ERR(exynos-vdd10)) {
+   ret = PTR_ERR(exynos-vdd10);
+   goto err3;
+   }
+   ret = regulator_enable(exynos-vdd10);
+   if (ret) {
+   dev_err(dev, Failed to enable VDD10 supply\n);
+   goto err3;
+   }
+
if (node) {
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(dev, failed to add dwc3 core\n);
-   goto err2;
+   goto err4;
}
} else {
dev_err(dev, no device node, failed to add dwc3 core\n);
ret = -ENODEV;
-   goto err2;
+   goto err4;
}
 
return 0;
 
+err4:
+   regulator_disable(exynos-vdd10);
+err3:
+   regulator_disable(exynos-vdd33);
 err2:
clk_disable_unprepare(clk);
 err1:
@@ -174,6 +203,9 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
 
clk_disable_unprepare(exynos-clk);
 
+   regulator_disable(exynos-vdd33);
+   regulator_disable(exynos-vdd10);
+
return 0;
 }
 
@@ -192,12 +224,27 @@ static int dwc3_exynos_suspend(struct device *dev)
 
clk_disable(exynos-clk);
 
+   regulator_disable(exynos-vdd33);
+   regulator_disable(exynos-vdd10);
+
return 0;
 }
 
 static int dwc3_exynos_resume(struct device *dev)
 {
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+   int ret;
+
+   ret = regulator_enable(exynos-vdd33);
+   if (ret) {
+   dev_err(dev, Failed to enable VDD33 supply\n);
+   return ret;
+   }
+   ret = regulator_enable(exynos-vdd10);
+   if (ret) {
+   dev_err(dev, Failed to enable VDD10 supply\n);
+   return ret;
+   }
 
clk_enable(exynos-clk);
 
-- 
1.7.10.4

--
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/3] usb: ehci-exynos: Make provision for vdd regulators

2014-04-21 Thread Vivek Gautam
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.

With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,

certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---

Based on 'usb-next' branch of Greg's usb tree.

 drivers/usb/host/ehci-exynos.c |   47 
 1 file changed, 47 insertions(+)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index d1d8c47..a3ca8cc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -20,6 +20,7 @@
 #include linux/of.h
 #include linux/of_gpio.h
 #include linux/platform_device.h
+#include linux/regulator/consumer.h
 #include linux/usb/phy.h
 #include linux/usb/samsung_usb_phy.h
 #include linux/usb.h
@@ -46,6 +47,8 @@ struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+   struct regulator *vdd33;
+   struct regulator *vdd10;
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
@@ -112,6 +115,28 @@ static int exynos_ehci_probe(struct platform_device *pdev)
exynos_ehci-otg = phy-otg;
}
 
+   exynos_ehci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+   if (IS_ERR(exynos_ehci-vdd33)) {
+   err = PTR_ERR(exynos_ehci-vdd33);
+   goto fail_regulator1;
+   }
+   err = regulator_enable(exynos_ehci-vdd33);
+   if (err) {
+   dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+   goto fail_regulator1;
+   }
+
+   exynos_ehci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+   if (IS_ERR(exynos_ehci-vdd10)) {
+   err = PTR_ERR(exynos_ehci-vdd10);
+   goto fail_regulator2;
+   }
+   err = regulator_enable(exynos_ehci-vdd10);
+   if (err) {
+   dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+   goto fail_regulator2;
+   }
+
 skip_phy:
 
exynos_ehci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -178,6 +203,10 @@ fail_add_hcd:
 fail_io:
clk_disable_unprepare(exynos_ehci-clk);
 fail_clk:
+   regulator_disable(exynos_ehci-vdd10);
+fail_regulator2:
+   regulator_disable(exynos_ehci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
 }
@@ -197,6 +226,9 @@ static int exynos_ehci_remove(struct platform_device *pdev)
 
clk_disable_unprepare(exynos_ehci-clk);
 
+   regulator_disable(exynos_ehci-vdd10);
+   regulator_disable(exynos_ehci-vdd33);
+
usb_put_hcd(hcd);
 
return 0;
@@ -221,6 +253,9 @@ static int exynos_ehci_suspend(struct device *dev)
 
clk_disable_unprepare(exynos_ehci-clk);
 
+   regulator_disable(exynos_ehci-vdd10);
+   regulator_disable(exynos_ehci-vdd33);
+
return rc;
 }
 
@@ -228,6 +263,18 @@ static int exynos_ehci_resume(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
+   int ret;
+
+   ret = regulator_enable(exynos_ehci-vdd33);
+   if (ret) {
+   dev_err(dev, Failed to enable VDD33 supply\n);
+   return ret;
+   }
+   ret = regulator_enable(exynos_ehci-vdd10);
+   if (ret) {
+   dev_err(dev, Failed to enable VDD10 supply\n);
+   return ret;
+   }
 
clk_prepare_enable(exynos_ehci-clk);
 
-- 
1.7.10.4

--
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: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5 on all OMAP3 platforms

2014-04-21 Thread Laurent Pinchart
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com

Commit 7b2e1277598e4187c9be3e61fd9b0f0423f97986 (ARM: OMAP3: clock:
Back-propagate rate change from cam_mclk to dpll4_m5) enabled clock
rate back-propagation from cam_mclk do dpll4_m5 on OMAP3630 only.
Perform back-propagation on other OMAP3 platforms as well.

Reported-by: Jean-Philippe François jp.franc...@cynove.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 arch/arm/mach-omap2/cclock3xxx_data.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c 
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 8f5121b..eb8c75e 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -456,7 +456,8 @@ static struct clk_hw_omap dpll4_m5x2_ck_hw = {
.clkdm_name = dpll4_clkdm,
 };
 
-DEFINE_STRUCT_CLK(dpll4_m5x2_ck, dpll4_m5x2_ck_parent_names, 
dpll4_m5x2_ck_ops);
+DEFINE_STRUCT_CLK_FLAGS(dpll4_m5x2_ck, dpll4_m5x2_ck_parent_names,
+   dpll4_m5x2_ck_ops, CLK_SET_RATE_PARENT);
 
 static struct clk dpll4_m5x2_ck_3630 = {
.name   = dpll4_m5x2_ck,
-- 
Regards,

Laurent Pinchart

--
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 06/19] bus: omap_l3_noc: un-obfuscate l3_targ address computation

2014-04-21 Thread Nishanth Menon
On 04/17/2014 05:00 PM, Felipe Balbi wrote:
 On Thu, Apr 17, 2014 at 03:49:22PM -0500, Nishanth Menon wrote:
 just simplify derefencing that is equivalent.

 Signed-off-by: Nishanth Menon n...@ti.com
 ---
 V2: just ordering change
 V1: https://patchwork.kernel.org/patch/3984201/
  drivers/bus/omap_l3_noc.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
 index c8facb0..f7d3bf4 100644
 --- a/drivers/bus/omap_l3_noc.c
 +++ b/drivers/bus/omap_l3_noc.c
 @@ -76,7 +76,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
  err_src = __ffs(err_reg);
  
  /* Read the stderrlog_main_source from clk domain */
 -l3_targ_base = base + *(l3_targ[i] + err_src);
 +l3_targ_base = base + l3_targ[i][err_src];
 
 hmmm, wasn't it so that pointer arithmetic was slightly faster than
 array indexing ? In that case would it be best to:
 
 l3_targ_base = base + *(l3_targ + i + err_src);
 
Yes, if this was a hot path (example: interrupt handler that gets
invoked very often), I would probably have preferred optimization at
this point.

However, the patch is just a step away from patches that converts the
target information into a structure under flagmux structure allowing
us to get rid of multiple array operations.

This patch just makes the further changes a bit readable.

-- 
Regards,
Nishanth Menon
--
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 05/19] bus: omap_l3_noc: switch over to relaxed variants of readl/writel

2014-04-21 Thread Nishanth Menon
On 04/17/2014 05:03 PM, Felipe Balbi wrote:
 On Thu, Apr 17, 2014 at 05:56:15PM -0400, Santosh Shilimkar wrote:
 On Thursday 17 April 2014 05:52 PM, Felipe Balbi wrote:
 Hi,

 On Thu, Apr 17, 2014 at 03:49:21PM -0500, Nishanth Menon wrote:
 Currently we use __raw_readl and writel in this driver, however, there

 __raw_* and *_relaxed variants are the same, just have a look asm/io.h

 Except the relaxed version can take care of endian conversion if
 needed. :-)
 
 right, but according to commit log, this commit is more concerned about
 the memory barriers which writel()/readl() add, not endianness. Just a
 matter of fixing up commit log.
 

yep, this patch does replace writel with writel_relaxed there is no
strong need for barriers in the operations that we perform here.

I agree that the commit message should probably be a little more
detailed at this point.


How about:
Currently we use __raw_readl and writel in this driver. Considering
there is no specific need for a memory barrier, replacing writel with
endian-neutral writel_relaxed and replacing __raw_readls with the
corresponding endian-neutral readl_relaxed allows us to have a
standard set of register operations for the driver.

While at it, simplify address computation using variables for register.


-- 
Regards,
Nishanth Menon
--
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 2/4] ARM: dts: Add ctrl-core DT node for DRA7

2014-04-21 Thread Tony Lindgren
* Archit Taneja arc...@ti.com [140420 22:16]:
 Hi,
 
 On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
 * Archit Taneja arc...@ti.com [140416 06:20]:
 Add DT node for the ctrl-core sub module of the DRA7 control module. We map 
 the
 CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains 
 register
 fields which configure clocks. The remainder of the registers are related to
 pad configurations or cross-bar configurations, and therefore aren't mapped.
 
 Can you please check if this can just use the existing
 regmap syscon mapping:
 
 syscon = dra7_ctrl_general;
 
 See how the drivers/regulator/pbias-regulator.c is using the
 syscon to initialize a regulator and then omap_hsmmc.c just does
 the standard regulator calls.
 
 The thing is that this bit needs to be set before the the DSS hwmods are
 reset, and that happens very early. If we don't do this, DSS won't reset
 properly, and not get back to an idle state.
 
 I am not sure where I can configure the syscon register early enough that it
 happens before the hwmods are reset. With a syscon mapping, I guess we would
 access the register when the DSS driver is probed. But that's too late for
 us.
 
 Ideally, it would be much better to have a syscon mapping. Do you have any
 suggestions how this can be achieved very early in boot?

It's best to move the reset and initialization of DSS happen later. I believe
we already are resetting only some of the hwmods early on.

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 V2 05/19] bus: omap_l3_noc: switch over to relaxed variants of readl/writel

2014-04-21 Thread Felipe Balbi
On Mon, Apr 21, 2014 at 08:16:28AM -0500, Nishanth Menon wrote:
 On 04/17/2014 05:03 PM, Felipe Balbi wrote:
  On Thu, Apr 17, 2014 at 05:56:15PM -0400, Santosh Shilimkar wrote:
  On Thursday 17 April 2014 05:52 PM, Felipe Balbi wrote:
  Hi,
 
  On Thu, Apr 17, 2014 at 03:49:21PM -0500, Nishanth Menon wrote:
  Currently we use __raw_readl and writel in this driver, however, there
 
  __raw_* and *_relaxed variants are the same, just have a look asm/io.h
 
  Except the relaxed version can take care of endian conversion if
  needed. :-)
  
  right, but according to commit log, this commit is more concerned about
  the memory barriers which writel()/readl() add, not endianness. Just a
  matter of fixing up commit log.
  
 
 yep, this patch does replace writel with writel_relaxed there is no
 strong need for barriers in the operations that we perform here.
 
 I agree that the commit message should probably be a little more
 detailed at this point.
 
 
 How about:
 Currently we use __raw_readl and writel in this driver. Considering
 there is no specific need for a memory barrier, replacing writel with
 endian-neutral writel_relaxed and replacing __raw_readls with the
 corresponding endian-neutral readl_relaxed allows us to have a
 standard set of register operations for the driver.
 
 While at it, simplify address computation using variables for register.

reads a lot better, thanks

Acked-by: Felipe Balbi ba...@ti.com


-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH V2 06/19] bus: omap_l3_noc: un-obfuscate l3_targ address computation

2014-04-21 Thread Felipe Balbi
On Mon, Apr 21, 2014 at 08:08:43AM -0500, Nishanth Menon wrote:
 On 04/17/2014 05:00 PM, Felipe Balbi wrote:
  On Thu, Apr 17, 2014 at 03:49:22PM -0500, Nishanth Menon wrote:
  just simplify derefencing that is equivalent.
 
  Signed-off-by: Nishanth Menon n...@ti.com
  ---
  V2: just ordering change
  V1: https://patchwork.kernel.org/patch/3984201/
   drivers/bus/omap_l3_noc.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
  index c8facb0..f7d3bf4 100644
  --- a/drivers/bus/omap_l3_noc.c
  +++ b/drivers/bus/omap_l3_noc.c
  @@ -76,7 +76,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void 
  *_l3)
 err_src = __ffs(err_reg);
   
 /* Read the stderrlog_main_source from clk domain */
  -  l3_targ_base = base + *(l3_targ[i] + err_src);
  +  l3_targ_base = base + l3_targ[i][err_src];
  
  hmmm, wasn't it so that pointer arithmetic was slightly faster than
  array indexing ? In that case would it be best to:
  
  l3_targ_base = base + *(l3_targ + i + err_src);
  
 Yes, if this was a hot path (example: interrupt handler that gets
 invoked very often), I would probably have preferred optimization at
 this point.
 
 However, the patch is just a step away from patches that converts the
 target information into a structure under flagmux structure allowing
 us to get rid of multiple array operations.
 
 This patch just makes the further changes a bit readable.

alright, the error IRQ doesn't fire very often indeed.

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH V2 05/19] bus: omap_l3_noc: switch over to relaxed variants of readl/writel

2014-04-21 Thread Nishanth Menon
On 10:09-20140421, Felipe Balbi wrote:
 On Mon, Apr 21, 2014 at 08:16:28AM -0500, Nishanth Menon wrote:
  On 04/17/2014 05:03 PM, Felipe Balbi wrote:
   On Thu, Apr 17, 2014 at 05:56:15PM -0400, Santosh Shilimkar wrote:
   On Thursday 17 April 2014 05:52 PM, Felipe Balbi wrote:
   Hi,
  
   On Thu, Apr 17, 2014 at 03:49:21PM -0500, Nishanth Menon wrote:
   Currently we use __raw_readl and writel in this driver, however, there
  
   __raw_* and *_relaxed variants are the same, just have a look asm/io.h
  
   Except the relaxed version can take care of endian conversion if
   needed. :-)
   
   right, but according to commit log, this commit is more concerned about
   the memory barriers which writel()/readl() add, not endianness. Just a
   matter of fixing up commit log.
   
  
  yep, this patch does replace writel with writel_relaxed there is no
  strong need for barriers in the operations that we perform here.
  
  I agree that the commit message should probably be a little more
  detailed at this point.
  
  
  How about:
  Currently we use __raw_readl and writel in this driver. Considering
  there is no specific need for a memory barrier, replacing writel with
  endian-neutral writel_relaxed and replacing __raw_readls with the
  corresponding endian-neutral readl_relaxed allows us to have a
  standard set of register operations for the driver.
  
  While at it, simplify address computation using variables for register.
 
 reads a lot better, thanks
 
 Acked-by: Felipe Balbi ba...@ti.com

Thanks.
Updated branch with patches with Acked-bys pickedup is available here:
https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2-repost

I have dropped the empty commit while at it.

Updated patch below for the record:
--8-8
From a8198b8c78f2a2731fdd4df1ac540887a4c464be Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Fri, 11 Apr 2014 11:21:47 -0500
Subject: [PATCH V2 UPDATE 05/19] bus: omap_l3_noc: switch over to relaxed 
variants of
 readl/writel

Currently we use __raw_readl and writel in this driver. Considering
there is no specific need for a memory barrier, replacing writel
with endian-neutral writel_relaxed and replacing __raw_readls with
the corresponding endian-neutral readl_relaxed allows us to have a
standard set of register operations for the driver.

While at it, simplify address computation using variables for
register.

Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
 drivers/bus/omap_l3_noc.c |   26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 37d71b7..c8facb0 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -55,6 +55,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
int err_src = 0;
u32 std_err_main, err_reg, clear, masterid;
void __iomem *base, *l3_targ_base;
+   void __iomem *l3_targ_stderr, *l3_targ_slvofslsb, *l3_targ_mstaddr;
char *target_name, *master_name = UN IDENTIFIED;
 
/* Get the Type of interrupt */
@@ -66,8 +67,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
 * to determine the source
 */
base = l3-l3_base[i];
-   err_reg = __raw_readl(base + l3_flagmux[i] +
-   + L3_FLAGMUX_REGERR0 + (inttype  3));
+   err_reg = readl_relaxed(base + l3_flagmux[i] +
+   L3_FLAGMUX_REGERR0 + (inttype  3));
 
/* Get the corresponding error and analyse */
if (err_reg) {
@@ -76,10 +77,14 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
 
/* Read the stderrlog_main_source from clk domain */
l3_targ_base = base + *(l3_targ[i] + err_src);
-   std_err_main =  __raw_readl(l3_targ_base +
-   L3_TARG_STDERRLOG_MAIN);
-   masterid = __raw_readl(l3_targ_base +
-   L3_TARG_STDERRLOG_MSTADDR);
+   l3_targ_stderr = l3_targ_base + L3_TARG_STDERRLOG_MAIN;
+   l3_targ_slvofslsb = l3_targ_base +
+   L3_TARG_STDERRLOG_SLVOFSLSB;
+   l3_targ_mstaddr = l3_targ_base +
+ L3_TARG_STDERRLOG_MSTADDR;
+
+   std_err_main = readl_relaxed(l3_targ_stderr);
+   masterid = readl_relaxed(l3_targ_mstaddr);
 
switch (std_err_main  CUSTOM_ERROR) {
case STANDARD_ERROR:
@@ -87,12 +92,10 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

2014-04-21 Thread Tony Lindgren
* Joachim Eastwood manab...@gmail.com [140419 09:25]:
 On 19 April 2014 18:14, Joachim Eastwood manab...@gmail.com wrote:
  This was introduced in 43a348ea53eb5fd79 but hasn't caused
  any harm since it don't have any users yet.
 
 Or maybe I am confused about this macro.
 
 Tony which offset from the OMAP4 TRM should be used?
 
 Under section 18.6.8 there are is a column with address offset. Is
 this the number you want in the macro?

Oh I see, the offsets in the TRM in this case are from the base
of the wkup module padconf base instead of listing the physical
address for the register. Ideally the value would be what the
documentation lists in the Table 18-9. Device Wake-Up Control
Module Pad Configuration Register Fields with 2 added to it for
the upper registers as we're using 16-bit register address.
In any case something that's relatively easy to verify against
the documentation. But that seems to vary between the physical
address and the offset, so we need to specify some mask there.

Something like below (untested) should do the trick as long as
we never have padconf reg areas larger than 0xfff. We may want to
allow defining a custom mask for the macro if needed depending
how the documentation is defining the mux tables for.

--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -51,9 +51,9 @@
 
 /*
  * Macros to allow using the absolute physical address instead of the
- * padconf registers instead of the offset from padconf base.
+ * padconf register offset from padconf register base.
  */
-#define OMAP_IOPAD_OFFSET(pa, offset)  (((pa)  0x) - (offset))
+#define OMAP_IOPAD_OFFSET(pa, offset)   (((pa)  0xfff) - ((offset)  0xfff))
 
 #define OMAP2420_CORE_IOPAD(pa, val)   OMAP_IOPAD_OFFSET((pa), 0x0030) (val)
 #define OMAP2430_CORE_IOPAD(pa, val)   OMAP_IOPAD_OFFSET((pa), 0x2030) (val)
--
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: L3 custom error from dmtimer.c

2014-04-21 Thread Joel Fernandes
On 04/19/2014 05:25 PM, Joachim Eastwood wrote:
 Hello,
 
 Playing around with an old OMAP pwm driver from NeilBrown. I get the
 following warning:
 [ 0.979522] omap-pwm omap-pwm.14: omap_dm_timer_set_load
 [ 0.979553] [ cut here ]
 [ 0.979583] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:113
 l3_interrupt_handler+0xf4/0x154()
 [ 0.979583] L3 custom error: MASTER:MPU TARGET:L4 PER2
 [ 0.979614] Modules linked in:
 [ 0.979614] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
 3.15.0-rc1-00370-gd9d79f4b7b7d-dirty #65
 [ 0.979644] [c0014f48] (unwind_backtrace) from [c0011c2c]
 (show_stack+0x10/0x14)
 [ 0.979675] [c0011c2c] (show_stack) from [c05ad3bc] (dump_stack+0x84/0x94)
 [ 0.979705] [c05ad3bc] (dump_stack) from [c0036ba8]
 (warn_slowpath_common+0x70/0x8c)
 [ 0.979705] omap-pwm omap-pwm.14: omap_dm_timer_set_match
 [ 0.979736] [c0036ba8] (warn_slowpath_common) from [c0036bf4]
 (warn_slowpath_fmt+0x30/0x40)
 [ 0.979736] [c0036bf4] (warn_slowpath_fmt) from [c0286c90]
 (l3_interrupt_handler+0xf4/0x154)
 [ 0.979766] [c0286c90] (l3_interrupt_handler) from [c0085d1c]
 (handle_irq_event_percpu+0x54/0x1cc)
 [ 0.979766] [c0085d1c] (handle_irq_event_percpu) from [c0085ed0]
 (handle_irq_event+0x3c/0x5c)
 [ 0.979797] [c0085ed0] (handle_irq_event) from [c0088ed0]
 (handle_fasteoi_irq+0xac/0x1a0)
 [ 0.979797] [c0088ed0] (handle_fasteoi_irq) from [c00853fc]
 (generic_handle_irq+0x2c/0x3c)
 [ 0.979827] [c00853fc] (generic_handle_irq) from [c000eb20]
 (handle_IRQ+0x40/0x90)
 [ 0.979827] [c000eb20] (handle_IRQ) from [c0008594]
 (gic_handle_irq+0x2c/0x5c)
 [ 0.979858] [c0008594] (gic_handle_irq) from [c05b4a44]
 (__irq_svc+0x44/0x58)
 [ 0.979858] Exception stack(0xc0889f58 to 0xc0889fa0)
 [ 0.979858] 9f40: 0001 0001
 [ 0.979888] 9f60:  c0893678 c0888000 c0888000 c08e75a4
 c0890548 c0888000 ee7ffc00
 [ 0.979888] omap-pwm omap-pwm.14: load value: 0xfffd11fe (-192002),
 match value: 0xfffe (-2)
 [ 0.979888] 9f80: c08904e0 c05bdcec  c0889fa0 c007a190
 c000ee48 2113 
 [ 0.979919] [c05b4a44] (__irq_svc) from [c000ee48] 
 (arch_cpu_idle+0x24/0x30)
 [ 0.979919] [c000ee48] (arch_cpu_idle) from [c0071950]
 (cpu_startup_entry+0x138/0x204)
 [ 0.979949] [c0071950] (cpu_startup_entry) from [c0822b10]
 (start_kernel+0x370/0x37c)
 [ 0.979980] [c0822b10] (start_kernel) from [80008074] (0x80008074)
 [ 0.979980] omap-pwm omap-pwm.14: omap_dm_timer_set_pwm
 [ 0.980010] omap-pwm omap-pwm.14: omap_pwm_enable
 [ 0.980010] omap-pwm omap-pwm.14: omap_dm_timer_start
 [ 0.980010] omap-pwm omap-pwm.14: omap_dm_timer_write_counter
 [ 0.980041] ---[ end trace 5d002a14ec98c2ad ]---
 
 This seems to be caused by the call into omap_dm_timer_set_load.
 

Are you talking about this?
https://lkml.org/lkml/2012/12/12/51

It doesn't seem to be in mainline though.

I'll add a check for the enable/disable, thanks.

regards,
  -Joel

 dmtimer.c has a couple of calls to pm_runtime_get_sync where the
 return value is not checked. I assume it's same problem as with
 omap-des.c which Nishanth fixed some days ago.
 http://marc.info/?l=linux-omapm=139758112228474w=2
 
 regards
 Joachim Eastwood
 

--
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: L3 custom error from dmtimer.c

2014-04-21 Thread Joachim Eastwood
On 21 April 2014 17:40, Joel Fernandes jo...@ti.com wrote:
 On 04/19/2014 05:25 PM, Joachim Eastwood wrote:
 Hello,

 Playing around with an old OMAP pwm driver from NeilBrown. I get the
 following warning:
 [ 0.979522] omap-pwm omap-pwm.14: omap_dm_timer_set_load
 [ 0.979553] [ cut here ]
 [ 0.979583] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:113
 l3_interrupt_handler+0xf4/0x154()
 [ 0.979583] L3 custom error: MASTER:MPU TARGET:L4 PER2
 [ 0.979614] Modules linked in:
 [ 0.979614] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
 3.15.0-rc1-00370-gd9d79f4b7b7d-dirty #65
 [ 0.979644] [c0014f48] (unwind_backtrace) from [c0011c2c]
 (show_stack+0x10/0x14)
 [ 0.979675] [c0011c2c] (show_stack) from [c05ad3bc] 
 (dump_stack+0x84/0x94)
 [ 0.979705] [c05ad3bc] (dump_stack) from [c0036ba8]
 (warn_slowpath_common+0x70/0x8c)
 [ 0.979705] omap-pwm omap-pwm.14: omap_dm_timer_set_match
 [ 0.979736] [c0036ba8] (warn_slowpath_common) from [c0036bf4]
 (warn_slowpath_fmt+0x30/0x40)
 [ 0.979736] [c0036bf4] (warn_slowpath_fmt) from [c0286c90]
 (l3_interrupt_handler+0xf4/0x154)
 [ 0.979766] [c0286c90] (l3_interrupt_handler) from [c0085d1c]
 (handle_irq_event_percpu+0x54/0x1cc)
 [ 0.979766] [c0085d1c] (handle_irq_event_percpu) from [c0085ed0]
 (handle_irq_event+0x3c/0x5c)
 [ 0.979797] [c0085ed0] (handle_irq_event) from [c0088ed0]
 (handle_fasteoi_irq+0xac/0x1a0)
 [ 0.979797] [c0088ed0] (handle_fasteoi_irq) from [c00853fc]
 (generic_handle_irq+0x2c/0x3c)
 [ 0.979827] [c00853fc] (generic_handle_irq) from [c000eb20]
 (handle_IRQ+0x40/0x90)
 [ 0.979827] [c000eb20] (handle_IRQ) from [c0008594]
 (gic_handle_irq+0x2c/0x5c)
 [ 0.979858] [c0008594] (gic_handle_irq) from [c05b4a44]
 (__irq_svc+0x44/0x58)
 [ 0.979858] Exception stack(0xc0889f58 to 0xc0889fa0)
 [ 0.979858] 9f40: 0001 0001
 [ 0.979888] 9f60:  c0893678 c0888000 c0888000 c08e75a4
 c0890548 c0888000 ee7ffc00
 [ 0.979888] omap-pwm omap-pwm.14: load value: 0xfffd11fe (-192002),
 match value: 0xfffe (-2)
 [ 0.979888] 9f80: c08904e0 c05bdcec  c0889fa0 c007a190
 c000ee48 2113 
 [ 0.979919] [c05b4a44] (__irq_svc) from [c000ee48] 
 (arch_cpu_idle+0x24/0x30)
 [ 0.979919] [c000ee48] (arch_cpu_idle) from [c0071950]
 (cpu_startup_entry+0x138/0x204)
 [ 0.979949] [c0071950] (cpu_startup_entry) from [c0822b10]
 (start_kernel+0x370/0x37c)
 [ 0.979980] [c0822b10] (start_kernel) from [80008074] (0x80008074)
 [ 0.979980] omap-pwm omap-pwm.14: omap_dm_timer_set_pwm
 [ 0.980010] omap-pwm omap-pwm.14: omap_pwm_enable
 [ 0.980010] omap-pwm omap-pwm.14: omap_dm_timer_start
 [ 0.980010] omap-pwm omap-pwm.14: omap_dm_timer_write_counter
 [ 0.980041] ---[ end trace 5d002a14ec98c2ad ]---

 This seems to be caused by the call into omap_dm_timer_set_load.


 Are you talking about this?
 https://lkml.org/lkml/2012/12/12/51

 It doesn't seem to be in mainline though.

No, it isn't. I am trying to revive it and get it upstream.

 I'll add a check for the enable/disable, thanks.

Note that the warning I got might be cause by the pwm-omap and it's
use of dmtimer api. I will investigate further.

But either way add a check to enable/disable is a good idea.


regards
Joachim Eastwood
--
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 01/10] usb: dwc3: gadget: clear stall when disabling endpoint

2014-04-21 Thread Felipe Balbi
so it seems like DWC3 IP doesn't clear stalls
automatically when we disable an endpoint, because
of that, we _must_ make sure stalls are cleared
before clearing the proper bit in DALEPENA register.

Cc: sta...@vger.kernel.org # v3.4+
Reported-by: Johannes Stezenbach j...@sig21.net
Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/dwc3/gadget.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index a740eac..f0dc0ee 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -608,6 +608,10 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
 
dwc3_remove_requests(dwc, dep);
 
+   /* make sure HW endpoint isn't stalled */
+   if (dep-flags  DWC3_EP_STALL)
+   __dwc3_gadget_ep_set_halt(dep, 0);
+
reg = dwc3_readl(dwc-regs, DWC3_DALEPENA);
reg = ~DWC3_DALEPENA_EP(dep-number);
dwc3_writel(dwc-regs, DWC3_DALEPENA, reg);
-- 
1.9.2.459.g68773ac

--
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 04/10] usb: dwc3: core: refactor mode initialization to its own function

2014-04-21 Thread Felipe Balbi
Move mode (Host, Peripheral, OTG) initialization
to its own function in order to decrease the size
of our probe() routine.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/dwc3/core.c | 133 
 1 file changed, 67 insertions(+), 66 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 38976f3..af8c8f6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -553,6 +553,69 @@ static int dwc3_core_get_phy(struct dwc3 *dwc)
return 0;
 }
 
+static int dwc3_core_init_mode(struct dwc3 *dwc)
+{
+   struct device *dev = dwc-dev;
+   int ret;
+
+   switch (dwc-dr_mode) {
+   case USB_DR_MODE_PERIPHERAL:
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+   ret = dwc3_gadget_init(dwc);
+   if (ret) {
+   dev_err(dev, failed to initialize gadget\n);
+   return ret;
+   }
+   break;
+   case USB_DR_MODE_HOST:
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+   ret = dwc3_host_init(dwc);
+   if (ret) {
+   dev_err(dev, failed to initialize host\n);
+   return ret;
+   }
+   break;
+   case USB_DR_MODE_OTG:
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+   ret = dwc3_host_init(dwc);
+   if (ret) {
+   dev_err(dev, failed to initialize host\n);
+   return ret;
+   }
+
+   ret = dwc3_gadget_init(dwc);
+   if (ret) {
+   dev_err(dev, failed to initialize gadget\n);
+   return ret;
+   }
+   break;
+   default:
+   dev_err(dev, Unsupported mode of operation %d\n, 
dwc-dr_mode);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static void dwc3_core_exit_mode(struct dwc3 *dwc)
+{
+   switch (dwc-dr_mode) {
+   case USB_DR_MODE_PERIPHERAL:
+   dwc3_gadget_exit(dwc);
+   break;
+   case USB_DR_MODE_HOST:
+   dwc3_host_exit(dwc);
+   break;
+   case USB_DR_MODE_OTG:
+   dwc3_host_exit(dwc);
+   dwc3_gadget_exit(dwc);
+   break;
+   default:
+   /* do nothing */
+   break;
+   }
+}
+
 #define DWC3_ALIGN_MASK(16 - 1)
 
 static int dwc3_probe(struct platform_device *pdev)
@@ -682,41 +745,9 @@ static int dwc3_probe(struct platform_device *pdev)
goto err_usb3phy_power;
}
 
-   switch (dwc-dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
-   ret = dwc3_gadget_init(dwc);
-   if (ret) {
-   dev_err(dev, failed to initialize gadget\n);
-   goto err2;
-   }
-   break;
-   case USB_DR_MODE_HOST:
-   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
-   ret = dwc3_host_init(dwc);
-   if (ret) {
-   dev_err(dev, failed to initialize host\n);
-   goto err2;
-   }
-   break;
-   case USB_DR_MODE_OTG:
-   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
-   ret = dwc3_host_init(dwc);
-   if (ret) {
-   dev_err(dev, failed to initialize host\n);
-   goto err2;
-   }
-
-   ret = dwc3_gadget_init(dwc);
-   if (ret) {
-   dev_err(dev, failed to initialize gadget\n);
-   goto err2;
-   }
-   break;
-   default:
-   dev_err(dev, Unsupported mode of operation %d\n, 
dwc-dr_mode);
+   ret = dwc3_core_init_mode(dwc);
+   if (ret)
goto err2;
-   }
 
ret = dwc3_debugfs_init(dwc);
if (ret) {
@@ -729,21 +760,7 @@ static int dwc3_probe(struct platform_device *pdev)
return 0;
 
 err3:
-   switch (dwc-dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   dwc3_gadget_exit(dwc);
-   break;
-   case USB_DR_MODE_HOST:
-   dwc3_host_exit(dwc);
-   break;
-   case USB_DR_MODE_OTG:
-   dwc3_host_exit(dwc);
-   dwc3_gadget_exit(dwc);
-   break;
-   default:
-   /* do nothing */
-   break;
-   }
+   dwc3_core_exit_mode(dwc);
 
 err2:
dwc3_event_buffers_cleanup(dwc);
@@ -778,23 +795,7 @@ static int dwc3_remove(struct platform_device *pdev)
pm_runtime_disable(pdev-dev);
 
dwc3_debugfs_exit(dwc);
-
-   switch (dwc-dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   dwc3_gadget_exit(dwc);
-   break;
-   case 

[PATCH 00/10] usb: generic cleanup patches

2014-04-21 Thread Felipe Balbi
Hi folks,

I have been playing with following patches today and
I think they're ready to be queued up for v3.16 but
I wanted to get some comments/test results before
I apply them to my 'next' branch.

Changes since v1:
- modify arch/arm/mach-omap2/usb-host.c and
board-omap3beagle.c accordingly
- added a patch to switch over to IS_ENABLED()

Felipe Balbi (10):
  usb: dwc3: gadget: clear stall when disabling endpoint
  usb: dwc3: core: refactor PHY initialization
  usb: phy: mv-u3d: switch over to writel/readl
  usb: dwc3: core: refactor mode initialization to its own function
  usb: gadget: only GPL drivers in the gadget and phy framework
  usb: phy: rename usb_nop_xceiv to usb_phy_generic
  usb: phy: rename linux/usb/usb_phy_gen_xceiv.h to
linux/usb/usb_phy_generic.h
  usb: musb: move usb_phy_generic_{un,}register calls to
probe()/remove()
  usb: phy: generic: allow multiples calls to usb_phy_generic_register()
  usb: phy: generic: switch over to IS_ENABLED()

 arch/arm/mach-omap2/board-omap3beagle.c|   1 -
 arch/arm/mach-omap2/usb-host.c |  10 +-
 drivers/usb/dwc3/core.c| 253 +++--
 drivers/usb/dwc3/dwc3-exynos.c |   8 +-
 drivers/usb/dwc3/dwc3-pci.c|   8 +-
 drivers/usb/dwc3/gadget.c  |   4 +
 drivers/usb/gadget/configfs.c  |   2 +-
 drivers/usb/gadget/f_fs.c  |   6 +-
 drivers/usb/gadget/f_rndis.c   |   2 +-
 drivers/usb/gadget/rndis.c |  28 +--
 drivers/usb/gadget/storage_common.c|  52 ++---
 drivers/usb/gadget/u_ether.c   |  32 +--
 drivers/usb/gadget/u_f.c   |   2 +-
 drivers/usb/musb/am35x.c   |  14 +-
 drivers/usb/musb/blackfin.c|  14 +-
 drivers/usb/musb/da8xx.c   |  16 +-
 drivers/usb/musb/davinci.c |   8 +-
 drivers/usb/musb/musb_dsps.c   |   2 +-
 drivers/usb/musb/tusb6010.c|   8 +-
 drivers/usb/phy/phy-am335x.c   |   4 +-
 drivers/usb/phy/phy-generic.c  |  65 +++---
 drivers/usb/phy/phy-generic.h  |   8 +-
 drivers/usb/phy/phy-keystone.c |   4 +-
 drivers/usb/phy/phy-mv-u3d-usb.c   |  20 +-
 .../usb/{usb_phy_gen_xceiv.h = usb_phy_generic.h} |  13 +-
 25 files changed, 306 insertions(+), 278 deletions(-)
 rename include/linux/usb/{usb_phy_gen_xceiv.h = usb_phy_generic.h} (53%)

-- 
1.9.2.459.g68773ac

--
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 07/10] usb: phy: rename linux/usb/usb_phy_gen_xceiv.h to linux/usb/usb_phy_generic.h

2014-04-21 Thread Felipe Balbi
now that all functions match the driver name,
the only missing piece is to rename the header
file itself.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/mach-omap2/board-omap3beagle.c  | 1 -
 arch/arm/mach-omap2/usb-host.c   | 2 +-
 drivers/usb/dwc3/dwc3-exynos.c   | 2 +-
 drivers/usb/dwc3/dwc3-pci.c  | 2 +-
 drivers/usb/musb/am35x.c | 2 +-
 drivers/usb/musb/blackfin.c  | 2 +-
 drivers/usb/musb/da8xx.c | 2 +-
 drivers/usb/musb/davinci.c   | 2 +-
 drivers/usb/musb/musb_dsps.c | 2 +-
 drivers/usb/musb/tusb6010.c  | 2 +-
 drivers/usb/phy/phy-am335x.c | 2 +-
 drivers/usb/phy/phy-generic.c| 2 +-
 drivers/usb/phy/phy-generic.h| 2 +-
 drivers/usb/phy/phy-keystone.c   | 2 +-
 include/linux/usb/{usb_phy_gen_xceiv.h = usb_phy_generic.h} | 0
 15 files changed, 13 insertions(+), 14 deletions(-)
 rename include/linux/usb/{usb_phy_gen_xceiv.h = usb_phy_generic.h} (100%)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index d6ed819..660bfc5 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -33,7 +33,6 @@
 #include linux/mtd/nand.h
 #include linux/mmc/host.h
 #include linux/usb/phy.h
-#include linux/usb/usb_phy_gen_xceiv.h
 
 #include linux/regulator/machine.h
 #include linux/i2c/twl.h
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index ab983cd..745367c 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -28,7 +28,7 @@
 #include linux/io.h
 #include linux/gpio.h
 #include linux/usb/phy.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
 
 #include soc.h
 #include omap_device.h
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 821cc59..ed22d72 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -24,7 +24,7 @@
 #include linux/dma-mapping.h
 #include linux/clk.h
 #include linux/usb/otg.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
 #include linux/of.h
 #include linux/of_platform.h
 
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8b162f0..1ed95e0 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -23,7 +23,7 @@
 #include linux/platform_device.h
 
 #include linux/usb/otg.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
 
 /* FIXME define these in linux/pci_ids.h */
 #define PCI_VENDOR_ID_SYNOPSYS 0x16c3
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 77ed664..044cd82 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -32,7 +32,7 @@
 #include linux/io.h
 #include linux/platform_device.h
 #include linux/dma-mapping.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
 #include linux/platform_data/usb-omap.h
 
 #include musb_core.h
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 607f3ae..c9992a2 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -18,7 +18,7 @@
 #include linux/platform_device.h
 #include linux/dma-mapping.h
 #include linux/prefetch.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
 
 #include asm/cacheflush.h
 
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index bcdce8e..a0dabb0 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -32,7 +32,7 @@
 #include linux/io.h
 #include linux/platform_device.h
 #include linux/dma-mapping.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
 
 #include mach/da8xx.h
 #include linux/platform_data/usb-davinci.h
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index c0e07ed..7370354 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -32,7 +32,7 @@
 #include linux/gpio.h
 #include linux/platform_device.h
 #include linux/dma-mapping.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
 
 #include mach/cputype.h
 #include mach/hardware.h
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 3372ded..1888292 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -35,7 +35,7 @@
 #include linux/dma-mapping.h
 #include linux/pm_runtime.h
 #include linux/module.h
-#include linux/usb/usb_phy_gen_xceiv.h
+#include linux/usb/usb_phy_generic.h
 #include linux/platform_data/usb-omap.h
 #include linux/sizes.h
 
diff --git 

[PATCH 05/10] usb: gadget: only GPL drivers in the gadget and phy framework

2014-04-21 Thread Felipe Balbi
We only support GPL drivers in the USB Gadget Framework,
it sounds correct to make all exported symbols GPL too.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/gadget/configfs.c   |  2 +-
 drivers/usb/gadget/f_fs.c   |  6 ++---
 drivers/usb/gadget/f_rndis.c|  2 +-
 drivers/usb/gadget/rndis.c  | 28 ++--
 drivers/usb/gadget/storage_common.c | 52 ++---
 drivers/usb/gadget/u_ether.c| 32 +++
 drivers/usb/gadget/u_f.c|  2 +-
 drivers/usb/phy/phy-generic.c   |  4 +--
 8 files changed, 64 insertions(+), 64 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 7d1cc01..dcead55 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1005,7 +1005,7 @@ void unregister_gadget_item(struct config_item *item)
 
unregister_gadget(gi);
 }
-EXPORT_SYMBOL(unregister_gadget_item);
+EXPORT_SYMBOL_GPL(unregister_gadget_item);
 
 static int __init gadget_cfs_init(void)
 {
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 2e164dc..a01b3bd 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -190,7 +190,7 @@ ffs_sb_create_file(struct super_block *sb, const char 
*name, void *data,
 /* Devices management ***/
 
 DEFINE_MUTEX(ffs_lock);
-EXPORT_SYMBOL(ffs_lock);
+EXPORT_SYMBOL_GPL(ffs_lock);
 
 static struct ffs_dev *_ffs_find_dev(const char *name);
 static struct ffs_dev *_ffs_alloc_dev(void);
@@ -2876,7 +2876,7 @@ int ffs_name_dev(struct ffs_dev *dev, const char *name)
 
return ret;
 }
-EXPORT_SYMBOL(ffs_name_dev);
+EXPORT_SYMBOL_GPL(ffs_name_dev);
 
 int ffs_single_dev(struct ffs_dev *dev)
 {
@@ -2893,7 +2893,7 @@ int ffs_single_dev(struct ffs_dev *dev)
ffs_dev_unlock();
return ret;
 }
-EXPORT_SYMBOL(ffs_single_dev);
+EXPORT_SYMBOL_GPL(ffs_single_dev);
 
 /*
  * ffs_lock must be taken by the caller of this function
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index c11761c..139bc9c 100644
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -834,7 +834,7 @@ void rndis_borrow_net(struct usb_function_instance *f, 
struct net_device *net)
opts-borrowed_net = opts-bound = true;
opts-net = net;
 }
-EXPORT_SYMBOL(rndis_borrow_net);
+EXPORT_SYMBOL_GPL(rndis_borrow_net);
 
 static inline struct f_rndis_opts *to_f_rndis_opts(struct config_item *item)
 {
diff --git a/drivers/usb/gadget/rndis.c b/drivers/usb/gadget/rndis.c
index d822d82..4c36694 100644
--- a/drivers/usb/gadget/rndis.c
+++ b/drivers/usb/gadget/rndis.c
@@ -760,7 +760,7 @@ int rndis_signal_connect(int configNr)
return rndis_indicate_status_msg(configNr,
  RNDIS_STATUS_MEDIA_CONNECT);
 }
-EXPORT_SYMBOL(rndis_signal_connect);
+EXPORT_SYMBOL_GPL(rndis_signal_connect);
 
 int rndis_signal_disconnect(int configNr)
 {
@@ -769,7 +769,7 @@ int rndis_signal_disconnect(int configNr)
return rndis_indicate_status_msg(configNr,
  RNDIS_STATUS_MEDIA_DISCONNECT);
 }
-EXPORT_SYMBOL(rndis_signal_disconnect);
+EXPORT_SYMBOL_GPL(rndis_signal_disconnect);
 
 void rndis_uninit(int configNr)
 {
@@ -784,13 +784,13 @@ void rndis_uninit(int configNr)
while ((buf = rndis_get_next_response(configNr, length)))
rndis_free_response(configNr, buf);
 }
-EXPORT_SYMBOL(rndis_uninit);
+EXPORT_SYMBOL_GPL(rndis_uninit);
 
 void rndis_set_host_mac(int configNr, const u8 *addr)
 {
rndis_per_dev_params[configNr].host_mac = addr;
 }
-EXPORT_SYMBOL(rndis_set_host_mac);
+EXPORT_SYMBOL_GPL(rndis_set_host_mac);
 
 /*
  * Message Parser
@@ -873,7 +873,7 @@ int rndis_msg_parser(u8 configNr, u8 *buf)
 
return -ENOTSUPP;
 }
-EXPORT_SYMBOL(rndis_msg_parser);
+EXPORT_SYMBOL_GPL(rndis_msg_parser);
 
 int rndis_register(void (*resp_avail)(void *v), void *v)
 {
@@ -895,7 +895,7 @@ int rndis_register(void (*resp_avail)(void *v), void *v)
 
return -ENODEV;
 }
-EXPORT_SYMBOL(rndis_register);
+EXPORT_SYMBOL_GPL(rndis_register);
 
 void rndis_deregister(int configNr)
 {
@@ -904,7 +904,7 @@ void rndis_deregister(int configNr)
if (configNr = RNDIS_MAX_CONFIGS) return;
rndis_per_dev_params[configNr].used = 0;
 }
-EXPORT_SYMBOL(rndis_deregister);
+EXPORT_SYMBOL_GPL(rndis_deregister);
 
 int rndis_set_param_dev(u8 configNr, struct net_device *dev, u16 *cdc_filter)
 {
@@ -918,7 +918,7 @@ int rndis_set_param_dev(u8 configNr, struct net_device 
*dev, u16 *cdc_filter)
 
return 0;
 }
-EXPORT_SYMBOL(rndis_set_param_dev);
+EXPORT_SYMBOL_GPL(rndis_set_param_dev);
 
 int rndis_set_param_vendor(u8 configNr, u32 vendorID, const char *vendorDescr)
 {
@@ -931,7 +931,7 @@ int rndis_set_param_vendor(u8 configNr, u32 vendorID, const 
char *vendorDescr)
 
return 0;
 }

[PATCH 03/10] usb: phy: mv-u3d: switch over to writel/readl

2014-04-21 Thread Felipe Balbi
by removing the _relaxed suffix, we can build
this driver in other architectures.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/phy/phy-mv-u3d-usb.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/phy/phy-mv-u3d-usb.c b/drivers/usb/phy/phy-mv-u3d-usb.c
index d317903..d342175 100644
--- a/drivers/usb/phy/phy-mv-u3d-usb.c
+++ b/drivers/usb/phy/phy-mv-u3d-usb.c
@@ -39,8 +39,8 @@ static u32 mv_u3d_phy_read(void __iomem *base, u32 reg)
addr = base;
data = base + 0x4;
 
-   writel_relaxed(reg, addr);
-   return readl_relaxed(data);
+   writel(reg, addr);
+   return readl(data);
 }
 
 static void mv_u3d_phy_set(void __iomem *base, u32 reg, u32 value)
@@ -51,10 +51,10 @@ static void mv_u3d_phy_set(void __iomem *base, u32 reg, u32 
value)
addr = base;
data = base + 0x4;
 
-   writel_relaxed(reg, addr);
-   tmp = readl_relaxed(data);
+   writel(reg, addr);
+   tmp = readl(data);
tmp |= value;
-   writel_relaxed(tmp, data);
+   writel(tmp, data);
 }
 
 static void mv_u3d_phy_clear(void __iomem *base, u32 reg, u32 value)
@@ -65,10 +65,10 @@ static void mv_u3d_phy_clear(void __iomem *base, u32 reg, 
u32 value)
addr = base;
data = base + 0x4;
 
-   writel_relaxed(reg, addr);
-   tmp = readl_relaxed(data);
+   writel(reg, addr);
+   tmp = readl(data);
tmp = ~value;
-   writel_relaxed(tmp, data);
+   writel(tmp, data);
 }
 
 static void mv_u3d_phy_write(void __iomem *base, u32 reg, u32 value)
@@ -78,8 +78,8 @@ static void mv_u3d_phy_write(void __iomem *base, u32 reg, u32 
value)
addr = base;
data = base + 0x4;
 
-   writel_relaxed(reg, addr);
-   writel_relaxed(value, data);
+   writel(reg, addr);
+   writel(value, data);
 }
 
 static void mv_u3d_phy_shutdown(struct usb_phy *phy)
-- 
1.9.2.459.g68773ac

--
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 08/10] usb: musb: move usb_phy_generic_{un,}register calls to probe()/remove()

2014-04-21 Thread Felipe Balbi
This patch is in preparation to supporting
calling those functions multiple times.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/musb/am35x.c| 4 ++--
 drivers/usb/musb/blackfin.c | 6 +++---
 drivers/usb/musb/da8xx.c| 4 ++--
 drivers/usb/musb/davinci.c  | 4 ++--
 drivers/usb/musb/tusb6010.c | 5 ++---
 5 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 044cd82..05459b5 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -360,7 +360,6 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
 
-   usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -EPROBE_DEFER;
@@ -402,7 +401,6 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
 
usb_put_phy(musb-xceiv);
-   usb_phy_generic_unregister();
 
return 0;
 }
@@ -505,6 +503,7 @@ static int am35x_probe(struct platform_device *pdev)
 
pdata-platform_ops = am35x_ops;
 
+   usb_phy_generic_register();
platform_set_drvdata(pdev, glue);
 
pinfo = am35x_dev_info;
@@ -547,6 +546,7 @@ static int am35x_remove(struct platform_device *pdev)
struct am35x_glue   *glue = platform_get_drvdata(pdev);
 
platform_device_unregister(glue-musb);
+   usb_phy_generic_unregister();
clk_disable(glue-clk);
clk_disable(glue-phy_clk);
clk_put(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c9992a2..53acffe 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -401,7 +401,6 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb-config-gpio_vrsel, 0);
 
-   usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
gpio_free(musb-config-gpio_vrsel);
@@ -424,9 +423,8 @@ static int bfin_musb_init(struct musb *musb)
 static int bfin_musb_exit(struct musb *musb)
 {
gpio_free(musb-config-gpio_vrsel);
-
usb_put_phy(musb-xceiv);
-   usb_phy_generic_unregister();
+
return 0;
 }
 
@@ -477,6 +475,7 @@ static int bfin_probe(struct platform_device *pdev)
 
pdata-platform_ops = bfin_ops;
 
+   usb_phy_generic_register();
platform_set_drvdata(pdev, glue);
 
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -528,6 +527,7 @@ static int bfin_remove(struct platform_device *pdev)
struct bfin_glue*glue = platform_get_drvdata(pdev);
 
platform_device_unregister(glue-musb);
+   usb_phy_generic_unregister();
kfree(glue);
 
return 0;
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index a0dabb0..024751f 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -418,7 +418,6 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
 
-   usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
ret = -EPROBE_DEFER;
@@ -453,7 +452,6 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
 
usb_put_phy(musb-xceiv);
-   usb_phy_generic_unregister();
 
return 0;
 }
@@ -512,6 +510,7 @@ static int da8xx_probe(struct platform_device *pdev)
 
pdata-platform_ops = da8xx_ops;
 
+   usb_phy_generic_register();
platform_set_drvdata(pdev, glue);
 
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -561,6 +560,7 @@ static int da8xx_remove(struct platform_device *pdev)
struct da8xx_glue   *glue = platform_get_drvdata(pdev);
 
platform_device_unregister(glue-musb);
+   usb_phy_generic_unregister();
clk_disable(glue-clk);
clk_put(glue-clk);
kfree(glue);
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 7370354..de8492b 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -381,7 +381,6 @@ static int davinci_musb_init(struct musb *musb)
u32 revision;
int ret = -ENODEV;
 
-   usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
ret = -EPROBE_DEFER;
@@ -487,7 +486,6 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
 
usb_put_phy(musb-xceiv);
-   usb_phy_generic_unregister();
 
return 0;
 }
@@ -545,6 +543,7 @@ static int davinci_probe(struct platform_device *pdev)
 
pdata-platform_ops = davinci_ops;
 
+   usb_phy_generic_register();
platform_set_drvdata(pdev, glue);
 
memset(musb_resources, 0x00, 

[PATCH 10/10] usb: phy: generic: switch over to IS_ENABLED()

2014-04-21 Thread Felipe Balbi
when checking if our generic PHY is enabled,
it's a lot easier to use IS_ENABLED() instead
of manually checking for it. While at that, also
remove the bogus defined(MODULE) at the end of
the line.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 include/linux/usb/usb_phy_generic.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb/usb_phy_generic.h 
b/include/linux/usb/usb_phy_generic.h
index 8346bcc..68adae8 100644
--- a/include/linux/usb/usb_phy_generic.h
+++ b/include/linux/usb/usb_phy_generic.h
@@ -13,7 +13,7 @@ struct usb_phy_generic_platform_data {
int gpio_reset;
 };
 
-#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE)  
defined(MODULE))
+#if IS_ENABLED(CONFIG_NOP_USB_XCEIV)
 /* sometimes transceivers are accessed only through e.g. ULPI */
 extern struct platform_device *usb_phy_generic_register(void);
 extern void usb_phy_generic_unregister(struct platform_device *);
-- 
1.9.2.459.g68773ac

--
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 09/10] usb: phy: generic: allow multiples calls to usb_phy_generic_register()

2014-04-21 Thread Felipe Balbi
it's now very easy to return a platform_device pointer
and have the caller pass it as argument when calling
usb_phy_generic_unregister().

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/musb/am35x.c| 12 +---
 drivers/usb/musb/blackfin.c | 10 --
 drivers/usb/musb/da8xx.c| 14 +++---
 drivers/usb/musb/tusb6010.c |  3 ++-
 drivers/usb/phy/phy-generic.c   | 19 +--
 include/linux/usb/usb_phy_generic.h |  9 +
 6 files changed, 40 insertions(+), 27 deletions(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 05459b5..0a34dd8 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -85,6 +85,7 @@
 struct am35x_glue {
struct device   *dev;
struct platform_device  *musb;
+   struct platform_device  *phy;
struct clk  *phy_clk;
struct clk  *clk;
 };
@@ -503,7 +504,9 @@ static int am35x_probe(struct platform_device *pdev)
 
pdata-platform_ops = am35x_ops;
 
-   usb_phy_generic_register();
+   glue-phy = usb_phy_generic_register();
+   if (IS_ERR(glue-phy))
+   goto err7;
platform_set_drvdata(pdev, glue);
 
pinfo = am35x_dev_info;
@@ -517,11 +520,14 @@ static int am35x_probe(struct platform_device *pdev)
if (IS_ERR(musb)) {
ret = PTR_ERR(musb);
dev_err(pdev-dev, failed to register musb device: %d\n, 
ret);
-   goto err7;
+   goto err8;
}
 
return 0;
 
+err8:
+   usb_phy_generic_unregister(glue-phy);
+
 err7:
clk_disable(clk);
 
@@ -546,7 +552,7 @@ static int am35x_remove(struct platform_device *pdev)
struct am35x_glue   *glue = platform_get_drvdata(pdev);
 
platform_device_unregister(glue-musb);
-   usb_phy_generic_unregister();
+   usb_phy_generic_unregister(glue-phy);
clk_disable(glue-clk);
clk_disable(glue-phy_clk);
clk_put(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 53acffe..d40d5f0 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -29,6 +29,7 @@
 struct bfin_glue {
struct device   *dev;
struct platform_device  *musb;
+   struct platform_device  *phy;
 };
 #define glue_to_musb(g)platform_get_drvdata(g-musb)
 
@@ -475,7 +476,9 @@ static int bfin_probe(struct platform_device *pdev)
 
pdata-platform_ops = bfin_ops;
 
-   usb_phy_generic_register();
+   glue-phy = usb_phy_generic_register();
+   if (IS_ERR(glue-phy))
+   goto err2;
platform_set_drvdata(pdev, glue);
 
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -513,6 +516,9 @@ static int bfin_probe(struct platform_device *pdev)
return 0;
 
 err3:
+   usb_phy_generic_unregister(glue-phy);
+
+err2:
platform_device_put(musb);
 
 err1:
@@ -527,7 +533,7 @@ static int bfin_remove(struct platform_device *pdev)
struct bfin_glue*glue = platform_get_drvdata(pdev);
 
platform_device_unregister(glue-musb);
-   usb_phy_generic_unregister();
+   usb_phy_generic_unregister(glue-phy);
kfree(glue);
 
return 0;
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 024751f..058775e 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -85,6 +85,7 @@
 struct da8xx_glue {
struct device   *dev;
struct platform_device  *musb;
+   struct platform_device  *phy;
struct clk  *clk;
 };
 
@@ -510,7 +511,11 @@ static int da8xx_probe(struct platform_device *pdev)
 
pdata-platform_ops = da8xx_ops;
 
-   usb_phy_generic_register();
+   glue-phy = usb_phy_generic_register();
+   if (IS_ERR(glue-phy)) {
+   ret = PTR_ERR(glue-phy);
+   goto err5;
+   }
platform_set_drvdata(pdev, glue);
 
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -537,11 +542,14 @@ static int da8xx_probe(struct platform_device *pdev)
if (IS_ERR(musb)) {
ret = PTR_ERR(musb);
dev_err(pdev-dev, failed to register musb device: %d\n, 
ret);
-   goto err5;
+   goto err6;
}
 
return 0;
 
+err6:
+   usb_phy_generic_unregister(glue-phy);
+
 err5:
clk_disable(clk);
 
@@ -560,7 +568,7 @@ static int da8xx_remove(struct platform_device *pdev)
struct da8xx_glue   *glue = platform_get_drvdata(pdev);
 
platform_device_unregister(glue-musb);
-   usb_phy_generic_unregister();
+   usb_phy_generic_unregister(glue-phy);
clk_disable(glue-clk);
clk_put(glue-clk);
kfree(glue);
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index e1da199..f38a8db 

[PATCH 02/10] usb: dwc3: core: refactor PHY initialization

2014-04-21 Thread Felipe Balbi
our probe() routine is too large and we can
easily refactor PHY-related code out to another
function to make it slightly less painful to read.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/dwc3/core.c | 120 ++--
 1 file changed, 66 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index d001417..38976f3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -486,70 +486,20 @@ static void dwc3_core_exit(struct dwc3 *dwc)
phy_exit(dwc-usb3_generic_phy);
 }
 
-#define DWC3_ALIGN_MASK(16 - 1)
-
-static int dwc3_probe(struct platform_device *pdev)
+static int dwc3_core_get_phy(struct dwc3 *dwc)
 {
-   struct device   *dev = pdev-dev;
-   struct dwc3_platform_data *pdata = dev_get_platdata(dev);
+   struct device   *dev = dwc-dev;
struct device_node  *node = dev-of_node;
-   struct resource *res;
-   struct dwc3 *dwc;
-
-   int ret = -ENOMEM;
-
-   void __iomem*regs;
-   void*mem;
-
-   mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
-   if (!mem) {
-   dev_err(dev, not enough memory\n);
-   return -ENOMEM;
-   }
-   dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1);
-   dwc-mem = mem;
-
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (!res) {
-   dev_err(dev, missing IRQ\n);
-   return -ENODEV;
-   }
-   dwc-xhci_resources[1].start = res-start;
-   dwc-xhci_resources[1].end = res-end;
-   dwc-xhci_resources[1].flags = res-flags;
-   dwc-xhci_resources[1].name = res-name;
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(dev, missing memory resource\n);
-   return -ENODEV;
-   }
+   int ret;
 
if (node) {
-   dwc-maximum_speed = of_usb_get_maximum_speed(node);
-
dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
-
-   dwc-needs_fifo_resize = of_property_read_bool(node, 
tx-fifo-resize);
-   dwc-dr_mode = of_usb_get_dr_mode(node);
-   } else if (pdata) {
-   dwc-maximum_speed = pdata-maximum_speed;
-
-   dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
-
-   dwc-needs_fifo_resize = pdata-tx_fifo_resize;
-   dwc-dr_mode = pdata-dr_mode;
} else {
dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
 
-   /* default to superspeed if no maximum_speed passed */
-   if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
-   dwc-maximum_speed = USB_SPEED_SUPER;
-
if (IS_ERR(dwc-usb2_phy)) {
ret = PTR_ERR(dwc-usb2_phy);
if (ret == -ENXIO || ret == -ENODEV) {
@@ -600,6 +550,69 @@ static int dwc3_probe(struct platform_device *pdev)
}
}
 
+   return 0;
+}
+
+#define DWC3_ALIGN_MASK(16 - 1)
+
+static int dwc3_probe(struct platform_device *pdev)
+{
+   struct device   *dev = pdev-dev;
+   struct dwc3_platform_data *pdata = dev_get_platdata(dev);
+   struct device_node  *node = dev-of_node;
+   struct resource *res;
+   struct dwc3 *dwc;
+
+   int ret = -ENOMEM;
+
+   void __iomem*regs;
+   void*mem;
+
+   mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
+   if (!mem) {
+   dev_err(dev, not enough memory\n);
+   return -ENOMEM;
+   }
+   dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1);
+   dwc-mem = mem;
+   dwc-dev = dev;
+
+   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+   if (!res) {
+   dev_err(dev, missing IRQ\n);
+   return -ENODEV;
+   }
+   dwc-xhci_resources[1].start = res-start;
+   dwc-xhci_resources[1].end = res-end;
+   dwc-xhci_resources[1].flags = res-flags;
+   dwc-xhci_resources[1].name = res-name;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   dev_err(dev, missing memory resource\n);
+   return -ENODEV;
+   }
+
+   if (node) {
+   dwc-maximum_speed = of_usb_get_maximum_speed(node);
+
+   dwc-needs_fifo_resize = of_property_read_bool(node, 
tx-fifo-resize);
+   dwc-dr_mode = of_usb_get_dr_mode(node);
+   } else if (pdata) {
+   dwc-maximum_speed = pdata-maximum_speed;
+
+   dwc-needs_fifo_resize 

[PATCH 06/10] usb: phy: rename usb_nop_xceiv to usb_phy_generic

2014-04-21 Thread Felipe Balbi
no functional changes, just renaming the function
in order to make it slightly clearer what it should
be used for, also matching the driver name.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/mach-omap2/usb-host.c|  8 +++---
 drivers/usb/dwc3/dwc3-exynos.c|  6 ++---
 drivers/usb/dwc3/dwc3-pci.c   |  6 ++---
 drivers/usb/musb/am35x.c  |  4 +--
 drivers/usb/musb/blackfin.c   |  4 +--
 drivers/usb/musb/da8xx.c  |  4 +--
 drivers/usb/musb/davinci.c|  6 ++---
 drivers/usb/musb/tusb6010.c   |  6 ++---
 drivers/usb/phy/phy-am335x.c  |  2 +-
 drivers/usb/phy/phy-generic.c | 50 +--
 drivers/usb/phy/phy-generic.h |  6 ++---
 drivers/usb/phy/phy-keystone.c|  2 +-
 include/linux/usb/usb_phy_gen_xceiv.h | 10 +++
 13 files changed, 57 insertions(+), 57 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 10855eb..ab983cd 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -349,7 +349,7 @@ static struct fixed_voltage_config hsusb_reg_config = {
/* .init_data filled later */
 };
 
-static const char *nop_name = usb_phy_gen_xceiv; /* NOP PHY driver */
+static const char *nop_name = usb_phy_generic; /* NOP PHY driver */
 static const char *reg_name = reg-fixed-voltage; /* Regulator driver */
 
 /**
@@ -435,7 +435,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int 
num_phys)
struct platform_device *pdev;
char *phy_id;
struct platform_device_info pdevinfo;
-   struct usb_phy_gen_xceiv_platform_data nop_pdata;
+   struct usb_phy_generic_platform_data nop_pdata;
 
for (i = 0; i  num_phys; i++) {
 
@@ -469,8 +469,8 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int 
num_phys)
pdevinfo.id = phy-port;
pdevinfo.data = nop_pdata;
pdevinfo.size_data =
-   sizeof(struct usb_phy_gen_xceiv_platform_data);
-   scnprintf(phy_id, MAX_STR, usb_phy_gen_xceiv.%d,
+   sizeof(struct usb_phy_generic_platform_data);
+   scnprintf(phy_id, MAX_STR, usb_phy_generic.%d,
phy-port);
pdev = platform_device_register_full(pdevinfo);
if (IS_ERR(pdev)) {
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 28c8ad7..821cc59 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -38,13 +38,13 @@ struct dwc3_exynos {
 
 static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
 {
-   struct usb_phy_gen_xceiv_platform_data pdata;
+   struct usb_phy_generic_platform_data pdata;
struct platform_device  *pdev;
int ret;
 
memset(pdata, 0x00, sizeof(pdata));
 
-   pdev = platform_device_alloc(usb_phy_gen_xceiv, PLATFORM_DEVID_AUTO);
+   pdev = platform_device_alloc(usb_phy_generic, PLATFORM_DEVID_AUTO);
if (!pdev)
return -ENOMEM;
 
@@ -56,7 +56,7 @@ static int dwc3_exynos_register_phys(struct dwc3_exynos 
*exynos)
if (ret)
goto err1;
 
-   pdev = platform_device_alloc(usb_phy_gen_xceiv, PLATFORM_DEVID_AUTO);
+   pdev = platform_device_alloc(usb_phy_generic, PLATFORM_DEVID_AUTO);
if (!pdev) {
ret = -ENOMEM;
goto err1;
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index f393c18..8b162f0 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -40,13 +40,13 @@ struct dwc3_pci {
 
 static int dwc3_pci_register_phys(struct dwc3_pci *glue)
 {
-   struct usb_phy_gen_xceiv_platform_data pdata;
+   struct usb_phy_generic_platform_data pdata;
struct platform_device  *pdev;
int ret;
 
memset(pdata, 0x00, sizeof(pdata));
 
-   pdev = platform_device_alloc(usb_phy_gen_xceiv, 0);
+   pdev = platform_device_alloc(usb_phy_generic, 0);
if (!pdev)
return -ENOMEM;
 
@@ -58,7 +58,7 @@ static int dwc3_pci_register_phys(struct dwc3_pci *glue)
if (ret)
goto err1;
 
-   pdev = platform_device_alloc(usb_phy_gen_xceiv, 1);
+   pdev = platform_device_alloc(usb_phy_generic, 1);
if (!pdev) {
ret = -ENOMEM;
goto err1;
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index b3aa018..77ed664 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -360,7 +360,7 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
 
-   usb_nop_xceiv_register();
+   usb_phy_generic_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -EPROBE_DEFER;
@@ -402,7 +402,7 @@ static int 

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

2014-04-21 Thread Joachim Eastwood
On 21 April 2014 17:35, Tony Lindgren t...@atomide.com wrote:
 * Joachim Eastwood manab...@gmail.com [140419 09:25]:
 On 19 April 2014 18:14, Joachim Eastwood manab...@gmail.com wrote:
  This was introduced in 43a348ea53eb5fd79 but hasn't caused
  any harm since it don't have any users yet.

 Or maybe I am confused about this macro.

 Tony which offset from the OMAP4 TRM should be used?

 Under section 18.6.8 there are is a column with address offset. Is
 this the number you want in the macro?

 Oh I see, the offsets in the TRM in this case are from the base
 of the wkup module padconf base instead of listing the physical
 address for the register. Ideally the value would be what the
 documentation lists in the Table 18-9. Device Wake-Up Control
 Module Pad Configuration Register Fields with 2 added to it for
 the upper registers as we're using 16-bit register address.
 In any case something that's relatively easy to verify against
 the documentation. But that seems to vary between the physical
 address and the offset, so we need to specify some mask there.

 Something like below (untested) should do the trick as long as
 we never have padconf reg areas larger than 0xfff. We may want to
 allow defining a custom mask for the macro if needed depending
 how the documentation is defining the mux tables for.

 --- a/include/dt-bindings/pinctrl/omap.h
 +++ b/include/dt-bindings/pinctrl/omap.h
 @@ -51,9 +51,9 @@

  /*
   * Macros to allow using the absolute physical address instead of the
 - * padconf registers instead of the offset from padconf base.
 + * padconf register offset from padconf register base.
   */
 -#define OMAP_IOPAD_OFFSET(pa, offset)  (((pa)  0x) - (offset))
 +#define OMAP_IOPAD_OFFSET(pa, offset)   (((pa)  0xfff) - ((offset)  0xfff))

  #define OMAP2420_CORE_IOPAD(pa, val)   OMAP_IOPAD_OFFSET((pa), 0x0030) (val)
  #define OMAP2430_CORE_IOPAD(pa, val)   OMAP_IOPAD_OFFSET((pa), 0x2030) (val)

This give the same result as my patch so it's okay for me. Checked the
resulting dtb's and they are equivalent.

Your patch will also have an effect on some of the others macros but I
assume that is okey.

Will this be sent as a fix for 3.15?

regards
Joachim Eastwood
--
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: dts: Correct offset in OMAP4_WKUP_IOPAD macro

2014-04-21 Thread Joachim Eastwood
On 21 April 2014 18:12, Joachim  Eastwood manab...@gmail.com wrote:
 On 21 April 2014 17:35, Tony Lindgren t...@atomide.com wrote:
 * Joachim Eastwood manab...@gmail.com [140419 09:25]:
 On 19 April 2014 18:14, Joachim Eastwood manab...@gmail.com wrote:
  This was introduced in 43a348ea53eb5fd79 but hasn't caused
  any harm since it don't have any users yet.

 Or maybe I am confused about this macro.

 Tony which offset from the OMAP4 TRM should be used?

 Under section 18.6.8 there are is a column with address offset. Is
 this the number you want in the macro?

 Oh I see, the offsets in the TRM in this case are from the base
 of the wkup module padconf base instead of listing the physical
 address for the register. Ideally the value would be what the
 documentation lists in the Table 18-9. Device Wake-Up Control
 Module Pad Configuration Register Fields with 2 added to it for
 the upper registers as we're using 16-bit register address.
 In any case something that's relatively easy to verify against
 the documentation. But that seems to vary between the physical
 address and the offset, so we need to specify some mask there.

 Something like below (untested) should do the trick as long as
 we never have padconf reg areas larger than 0xfff. We may want to
 allow defining a custom mask for the macro if needed depending
 how the documentation is defining the mux tables for.

 --- a/include/dt-bindings/pinctrl/omap.h
 +++ b/include/dt-bindings/pinctrl/omap.h
 @@ -51,9 +51,9 @@

  /*
   * Macros to allow using the absolute physical address instead of the
 - * padconf registers instead of the offset from padconf base.
 + * padconf register offset from padconf register base.
   */
 -#define OMAP_IOPAD_OFFSET(pa, offset)  (((pa)  0x) - (offset))
 +#define OMAP_IOPAD_OFFSET(pa, offset)   (((pa)  0xfff) - ((offset)  
 0xfff))

  #define OMAP2420_CORE_IOPAD(pa, val)   OMAP_IOPAD_OFFSET((pa), 0x0030) (val)
  #define OMAP2430_CORE_IOPAD(pa, val)   OMAP_IOPAD_OFFSET((pa), 0x2030) (val)

 This give the same result as my patch so it's okay for me. Checked the
 resulting dtb's and they are equivalent.

 Your patch will also have an effect on some of the others macros but I
 assume that is okey.

For reference my var-som-om44.dtsi now looks like this:
http://slexy.org/raw/s213OvSZfF


 Will this be sent as a fix for 3.15?

 regards
 Joachim Eastwood
--
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: [PATCHv3 09/14] Documentation: DT: omap-ssi binding documentation

2014-04-21 Thread Rob Herring
On Fri, Mar 28, 2014 at 7:31 PM, Sebastian Reichel s...@kernel.org wrote:
 Create device tree binding documentation for
 OMAP Synchronous Serial Interface (SSI) device.

 Signed-off-by: Sebastian Reichel s...@kernel.org
 ---
  Documentation/devicetree/bindings/hsi/omap-ssi.txt | 85 
 ++
  1 file changed, 85 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt

 diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt 
 b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
 new file mode 100644
 index 000..709419b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
 @@ -0,0 +1,85 @@
 +OMAP SSI controller bindings
 +
 +OMAP Synchronous Serial Interface (SSI) controller implements a legacy
 +variant of MIPI's High Speed Synchronous Serial Interface (HSI).
 +
 +Required properties:
 +- compatible:  Should include ti,omap3-ssi.
 +- reg-names:   Contains the values sys and gdd.
 +- reg: Contains a register specifier for each entry in
 +   reg-names.

You need to define the order here unless you have a strong argument
why you can't.

 +- interrupt-names:  Contains the value gdd_mpu.
 +- interrupts:  Contains interrupt information for each entry in
 +   interrupt-names.
 +- ranges:  Represents the bus address mapping between the main
 +   controller node and the child nodes below.
 +- clocks:  Contains clock specifiers for each entry in
 +clock-names.
 +- clock-names: Must include the following entries:
 +  ssi_ssr_fck: The OMAP clock of that name
 +  ssi_sst_fck: The OMAP clock of that name
 +  ssi_ick: The OMAP clock of that name
 +- #address-cells:  Should be set to 1
 +- #size-cells: Should be set to 1
 +
 +Each port is represented as a sub-node of the ti,omap3-ssi device.
 +
 +Required Port sub-node properties:
 +- compatible:  Should be set to the following value
 +ti,omap3-ssi-port (applicable to OMAP34xx devices)
 +- reg-names:   Contains the values rx and tx.
 +- reg: Contains a register specifier for each entry in
 +   reg-names.

You need to define the order here unless you have a strong argument
why you can't.

 +- interrupt-parent Should be a phandle for the interrupt controller
 +- interrupt-names: Contains the values mpu_irq0 and mpu_irq1.

Those names aren't exactly useful.

 +- interrupts:  Contains interrupt information for each entry in
 +   interrupt-names.

You need to define the order here unless you have a strong argument
why you can't.

 +- ti,ssi-cawake-gpio:  Defines which GPIO pin is used to signify CAWAKE
 +   events for the port. This is an optional 
 board-specific
 +   property. If it's missing the port will not be
 +   enabled.
 +
 +Example for Nokia N900:
 +
 +ssi-controller@48058000 {
 +   compatible = ti,omap3-ssi;
 +
 +   /* needed until hwmod is updated to use the compatible string */
 +   ti,hwmods = ssi;
 +
 +   reg = 0x48058000 0x1000,
 + 0x48059000 0x1000;
 +   reg-names = sys,
 +   gdd;
 +
 +   interrupts = 55;
 +   interrupt-names = gdd_mpu;
 +
 +   clocks = ssi_ssr_fck,
 +ssi_sst_fck,
 +ssi_ick;
 +   clock-names = ssi_ssr_fck,
 + ssi_sst_fck,
 + ssi_ick;
 +
 +   #address-cells = 1;
 +   #size-cells = 1;
 +   ranges;
 +
 +   ssi-port@0 {

Does this h/w really have more than 1 port?

This should really be ssi-port@4805a800 Or you need to fill in
ranges to have a local offset.

 +   compatible = ti,omap3-ssi-port;
 +
 +   reg = 0x4805a000 0x800,
 + 0x4805a800 0x800;
 +   reg-names = tx,
 +   rx;
 +
 +   interrupt-parent = intc;
 +   interrupts = 51,
 +52;
 +   interrupt-names = mpu_irq0,
 + mpu_irq1;
 +
 +   ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
 +   }
 +}
 --
 1.9.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: L3 custom error from dmtimer.c

2014-04-21 Thread Joel Fernandes
On 04/21/2014 11:36 AM, Joel Fernandes wrote:
 On 04/21/2014 10:57 AM, Joachim Eastwood wrote:
 On 21 April 2014 17:40, Joel Fernandes jo...@ti.com wrote:
 On 04/19/2014 05:25 PM, Joachim Eastwood wrote:
 Hello,

 Playing around with an old OMAP pwm driver from NeilBrown. I get the
 following warning:
 [ 0.979522] omap-pwm omap-pwm.14: omap_dm_timer_set_load
 [ 0.979553] [ cut here ]
 [ 0.979583] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:113
 l3_interrupt_handler+0xf4/0x154()
 [ 0.979583] L3 custom error: MASTER:MPU TARGET:L4 PER2
 [ 0.979614] Modules linked in:
 [ 0.979614] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
 3.15.0-rc1-00370-gd9d79f4b7b7d-dirty #65
 [ 0.979644] [c0014f48] (unwind_backtrace) from [c0011c2c]
 (show_stack+0x10/0x14)
 [ 0.979675] [c0011c2c] (show_stack) from [c05ad3bc] 
 (dump_stack+0x84/0x94)
 [ 0.979705] [c05ad3bc] (dump_stack) from [c0036ba8]
 (warn_slowpath_common+0x70/0x8c)
 [ 0.979705] omap-pwm omap-pwm.14: omap_dm_timer_set_match
 [ 0.979736] [c0036ba8] (warn_slowpath_common) from [c0036bf4]
 (warn_slowpath_fmt+0x30/0x40)
 [ 0.979736] [c0036bf4] (warn_slowpath_fmt) from [c0286c90]
 (l3_interrupt_handler+0xf4/0x154)
 [ 0.979766] [c0286c90] (l3_interrupt_handler) from [c0085d1c]
 (handle_irq_event_percpu+0x54/0x1cc)
 [ 0.979766] [c0085d1c] (handle_irq_event_percpu) from [c0085ed0]
 (handle_irq_event+0x3c/0x5c)
 [ 0.979797] [c0085ed0] (handle_irq_event) from [c0088ed0]
 (handle_fasteoi_irq+0xac/0x1a0)
 [ 0.979797] [c0088ed0] (handle_fasteoi_irq) from [c00853fc]
 (generic_handle_irq+0x2c/0x3c)
 [ 0.979827] [c00853fc] (generic_handle_irq) from [c000eb20]
 (handle_IRQ+0x40/0x90)
 [ 0.979827] [c000eb20] (handle_IRQ) from [c0008594]
 (gic_handle_irq+0x2c/0x5c)
 [ 0.979858] [c0008594] (gic_handle_irq) from [c05b4a44]
 (__irq_svc+0x44/0x58)
 [ 0.979858] Exception stack(0xc0889f58 to 0xc0889fa0)
 [ 0.979858] 9f40: 0001 0001
 [ 0.979888] 9f60:  c0893678 c0888000 c0888000 c08e75a4
 c0890548 c0888000 ee7ffc00
 [ 0.979888] omap-pwm omap-pwm.14: load value: 0xfffd11fe (-192002),
 match value: 0xfffe (-2)
 [ 0.979888] 9f80: c08904e0 c05bdcec  c0889fa0 c007a190
 c000ee48 2113 
 [ 0.979919] [c05b4a44] (__irq_svc) from [c000ee48] 
 (arch_cpu_idle+0x24/0x30)
 [ 0.979919] [c000ee48] (arch_cpu_idle) from [c0071950]
 (cpu_startup_entry+0x138/0x204)
 [ 0.979949] [c0071950] (cpu_startup_entry) from [c0822b10]
 (start_kernel+0x370/0x37c)
 [ 0.979980] [c0822b10] (start_kernel) from [80008074] (0x80008074)
 [ 0.979980] omap-pwm omap-pwm.14: omap_dm_timer_set_pwm
 [ 0.980010] omap-pwm omap-pwm.14: omap_pwm_enable
 [ 0.980010] omap-pwm omap-pwm.14: omap_dm_timer_start
 [ 0.980010] omap-pwm omap-pwm.14: omap_dm_timer_write_counter
 [ 0.980041] ---[ end trace 5d002a14ec98c2ad ]---

 This seems to be caused by the call into omap_dm_timer_set_load.


 Are you talking about this?
 https://lkml.org/lkml/2012/12/12/51

 It doesn't seem to be in mainline though.

 No, it isn't. I am trying to revive it and get it upstream.

 I'll add a check for the enable/disable, thanks.

 Note that the warning I got might be cause by the pwm-omap and it's
 use of dmtimer api. I will investigate further.

 But either way add a check to enable/disable is a good idea.

 
 Sure, I added the check. The patch depends on a few other pending
 patches so I just zipped all together. It would be great if you could
 apply them and confirm it fixes the problem, then I can add your
 tested-by and include it in the next series.

Lost track that the mailing list was CC'd so included the latest patch
(check for pm_runtime_get_sync) inline below. Dependent patches are at [1].

Regards,
  -Joel

[1] https://lkml.org/lkml/2014/4/16/737

---8--
From b5884b869a21ffe5472edc59bd07d58b104284b9 Mon Sep 17 00:00:00 2001
From: Joel Fernandes jo...@ti.com
Date: Mon, 21 Apr 2014 11:05:10 -0500
Subject: [PATCH 10/10] ARM: OMAP: dmtimer: Check return of
 pm_runtime_get_sync

omap_timer_enable doesn't check return value, this can lead to nasty bus
errors. Add a check and report issues.

Signed-off-by: Joel Fernandes jo...@ti.com
---
 arch/arm/plat-omap/dmtimer.c  |   61
+++--
 arch/arm/plat-omap/include/plat/dmtimer.h |2 +-
 2 files changed, 50 insertions(+), 13 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 1fd30fa..9403d450 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -164,7 +164,9 @@ static int omap_dm_timer_prepare(struct
omap_dm_timer *timer)
}
}

-   omap_dm_timer_enable(timer);
+   rc = omap_dm_timer_enable(timer);
+   if(rc)
+   return rc;

if (timer-capability  OMAP_TIMER_NEEDS_RESET) {
rc = omap_dm_timer_reset(timer);
@@ -375,11 +377,15 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
 }
 EXPORT_SYMBOL_GPL(omap_dm_timer_free);

-void omap_dm_timer_enable(struct omap_dm_timer 

Re: [PATCHv3 07/14] HSI: Add common DT binding for HSI client devices

2014-04-21 Thread Rob Herring
On Fri, Mar 28, 2014 at 7:31 PM, Sebastian Reichel s...@kernel.org wrote:
 Implement and document generic DT bindings for HSI clients.

 Signed-off-by: Sebastian Reichel s...@kernel.org

Seems pretty reasonable although I know little about HSI.

 ---
  .../devicetree/bindings/hsi/client-devices.txt |  44 +
  drivers/hsi/hsi.c  | 197 
 -
  include/linux/hsi/hsi.h|   2 +
  3 files changed, 241 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt

 diff --git a/Documentation/devicetree/bindings/hsi/client-devices.txt 
 b/Documentation/devicetree/bindings/hsi/client-devices.txt
 new file mode 100644
 index 000..7504cb1
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/hsi/client-devices.txt
 @@ -0,0 +1,44 @@
 +Each HSI port is supposed to have one child node, which
 +symbols the remote device connected to the HSI port. The
 +following properties are standardized for HSI clients:
 +
 +Required HSI configuration properties:
 +
 +- reg: A list of channel ids
 +
 +- hsi-rx-mode: Receiver Bit transmission mode (stream or frame)
 +- hsi-tx-mode: Transmitter Bit transmission mode (stream or 
 frame)
 +- hsi-mode:May be used instead hsi-rx-mode and hsi-tx-mode if
 +   the transmission mode is the same for receiver and
 +   transmitter
 +- hsi-speed-kbps:  Max bit transmission speed in kbit/s
 +- hsi-flow:RX flow type (synchronized or pipeline)
 +- hsi-arb-mode:Arbitration mode for TX frame (round-robin, 
 priority)
 +
 +Optional HSI configuration properties:
 +
 +- reg-names:   A list with one name per channel specified in the
 +   reg property
 +
 +
 +Device Tree node example for an HSI client:
 +
 +hsi-controller {
 +   hsi-port {
 +   modem: hsi-client {
 +   compatible = nokia,n900-modem;

Is there only 1 version of HSI? If not, then perhaps you need to know
what version a client is.

 +
 +   reg = 0, 1, 2, 3;

Where do these numbers get defined? Are they always 0-N?

I don't see much advantage to using reg. Perhaps something like
hsi-channel-ids would be better.

Rob
--
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/10] dma: edma: Fixes for cyclic (audio) operation

2014-04-21 Thread Joel Fernandes
Hi Vinod, Dan,

On 04/14/2014 06:41 AM, Peter Ujfalusi wrote:
 Hi,
 
 Changes since v2:
 - Dropped patch 10 from v2 (simplify direction configuration...)
 - Dropped the channel priority related patches since we are going to go via
   different route for configuring the priority.
 - Added ACK from Joel for the patches since they are not changed since v2
 
 Changes since v1:
 - ASoC patches removed
 - Comments from Andriy Shevchenko addressed
 - patch added to fix cases when src/dst_maxburst is set to 0
 
 The series contains now only:
 Support for DMA pause/resume in cyclic mode
 device_slave_caps callback and DMA_CYCLIC flag correction.
 While debugging the edma to get things sorted out I noticed that the debug was
 too verbose and the important information was hidden even when the we did not
 asked for verbose dmaengine debug.
 I have included some debug cleanups for the edma dmaengine driver also.

I reviewed/tested these patches and they look OK to me. Also the point
of contention was priority which is now dropped from the series. If the
patches look OK and there are no further review comments can they be
queued for -next?

I also have a memcpy and another fix patch for edma so I could queue all
together in my tree and send a consolidated pull request to make it easier.

thanks,
 -Joel

--
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: L3 custom error from dmtimer.c

2014-04-21 Thread Joachim Eastwood
On 21 April 2014 18:36, Joel Fernandes jo...@ti.com wrote:
 On 04/21/2014 10:57 AM, Joachim Eastwood wrote:
 On 21 April 2014 17:40, Joel Fernandes jo...@ti.com wrote:
 On 04/19/2014 05:25 PM, Joachim Eastwood wrote:
 Hello,

 Playing around with an old OMAP pwm driver from NeilBrown. I get the
 following warning:
 [ 0.979522] omap-pwm omap-pwm.14: omap_dm_timer_set_load
 [ 0.979553] [ cut here ]
 [ 0.979583] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:113
 l3_interrupt_handler+0xf4/0x154()
 [ 0.979583] L3 custom error: MASTER:MPU TARGET:L4 PER2
 [ 0.979614] Modules linked in:
 [ 0.979614] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
 3.15.0-rc1-00370-gd9d79f4b7b7d-dirty #65
 [ 0.979644] [c0014f48] (unwind_backtrace) from [c0011c2c]
 (show_stack+0x10/0x14)
 [ 0.979675] [c0011c2c] (show_stack) from [c05ad3bc] 
 (dump_stack+0x84/0x94)
 [ 0.979705] [c05ad3bc] (dump_stack) from [c0036ba8]
 (warn_slowpath_common+0x70/0x8c)
 [ 0.979705] omap-pwm omap-pwm.14: omap_dm_timer_set_match
 [ 0.979736] [c0036ba8] (warn_slowpath_common) from [c0036bf4]
 (warn_slowpath_fmt+0x30/0x40)
 [ 0.979736] [c0036bf4] (warn_slowpath_fmt) from [c0286c90]
 (l3_interrupt_handler+0xf4/0x154)
 [ 0.979766] [c0286c90] (l3_interrupt_handler) from [c0085d1c]
 (handle_irq_event_percpu+0x54/0x1cc)
 [ 0.979766] [c0085d1c] (handle_irq_event_percpu) from [c0085ed0]
 (handle_irq_event+0x3c/0x5c)
 [ 0.979797] [c0085ed0] (handle_irq_event) from [c0088ed0]
 (handle_fasteoi_irq+0xac/0x1a0)
 [ 0.979797] [c0088ed0] (handle_fasteoi_irq) from [c00853fc]
 (generic_handle_irq+0x2c/0x3c)
 [ 0.979827] [c00853fc] (generic_handle_irq) from [c000eb20]
 (handle_IRQ+0x40/0x90)
 [ 0.979827] [c000eb20] (handle_IRQ) from [c0008594]
 (gic_handle_irq+0x2c/0x5c)
 [ 0.979858] [c0008594] (gic_handle_irq) from [c05b4a44]
 (__irq_svc+0x44/0x58)
 [ 0.979858] Exception stack(0xc0889f58 to 0xc0889fa0)
 [ 0.979858] 9f40: 0001 0001
 [ 0.979888] 9f60:  c0893678 c0888000 c0888000 c08e75a4
 c0890548 c0888000 ee7ffc00
 [ 0.979888] omap-pwm omap-pwm.14: load value: 0xfffd11fe (-192002),
 match value: 0xfffe (-2)
 [ 0.979888] 9f80: c08904e0 c05bdcec  c0889fa0 c007a190
 c000ee48 2113 
 [ 0.979919] [c05b4a44] (__irq_svc) from [c000ee48] 
 (arch_cpu_idle+0x24/0x30)
 [ 0.979919] [c000ee48] (arch_cpu_idle) from [c0071950]
 (cpu_startup_entry+0x138/0x204)
 [ 0.979949] [c0071950] (cpu_startup_entry) from [c0822b10]
 (start_kernel+0x370/0x37c)
 [ 0.979980] [c0822b10] (start_kernel) from [80008074] (0x80008074)
 [ 0.979980] omap-pwm omap-pwm.14: omap_dm_timer_set_pwm
 [ 0.980010] omap-pwm omap-pwm.14: omap_pwm_enable
 [ 0.980010] omap-pwm omap-pwm.14: omap_dm_timer_start
 [ 0.980010] omap-pwm omap-pwm.14: omap_dm_timer_write_counter
 [ 0.980041] ---[ end trace 5d002a14ec98c2ad ]---

 This seems to be caused by the call into omap_dm_timer_set_load.


 Are you talking about this?
 https://lkml.org/lkml/2012/12/12/51

 It doesn't seem to be in mainline though.

 No, it isn't. I am trying to revive it and get it upstream.

 I'll add a check for the enable/disable, thanks.

 Note that the warning I got might be cause by the pwm-omap and it's
 use of dmtimer api. I will investigate further.

 But either way add a check to enable/disable is a good idea.


 Sure, I added the check. The patch depends on a few other pending
 patches so I just zipped all together. It would be great if you could
 apply them and confirm it fixes the problem, then I can add your
 tested-by and include it in the next series.

Thanks for zip-file, Joel.

I can confirm that the pwm-omap driver still works with dmtimer after
applying your patch set.
So feel free to add: Tested-by: Joachim Eastwood manab...@gmail.com

Have just a small comment on the dmtimer: Check return of
pm_runtime_get_sync. I see that you use pr_err, but since you have a
dev pointer available maybe you should use dev_err instead.

regards
Joachim Eastwood
--
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/5] mmc: host: omap_hsmmc: a few improvements

2014-04-21 Thread Felipe Balbi
Hi,

On Wed, Mar 26, 2014 at 07:04:45PM -0500, Felipe Balbi wrote:
 this series lets us access the newer registers introduced
 back in OMAP4 which give us some valid information about
 the OMAP HSMMC IP like max block size, support for ADMA,
 support for Retention.
 
 Right now, only setting max_blk_size correctly as supporting
 ADMA and Retention will take a lot of work.
 
 Tested on OMAP5 uEVM.
 
 Felipe Balbi (5):
   mmc: host: omap_hsmmc: pass host as an argument
   mmc: host: omap_hsmmc: add reg_offset field
   mmc: host: omap_hsmmc: introduce new accessor functions
   mmc: host: omap_hsmmc: switch over to new accessors
   mmc: host: omap_hsmmc: set max_blk_size correctly

this has been here for almost a month, any comments ?

-- 
balbi


signature.asc
Description: Digital signature


GPMC fails at clk_get

2014-04-21 Thread Ben Davis
my client has volun-told me update my design from my functional 3.12 kernel 
to the 3.15 kernel.  On doing so, my GPMC kernel modules no longer load due to 
the following:

omap-gpmc 5000.gpmc: error: clk_get
omap-gpmc: probe of 5000.gpmc failed with error -2

this is at line 1643 of gpmc.c.

I had to hack the kernel to get my GPMC f-clock operational in 3.12 and presume 
my issue is due to the evolution of the clocks and integration of the DT.  
Perhaps I am coming in mid-modification?

I am continuing to investigate but if there is a simple solution I would love 
to any help you can offer.

Cheers,
Benjamin --
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 05/10] usb: gadget: only GPL drivers in the gadget and phy framework

2014-04-21 Thread Greg KH
On Mon, Apr 21, 2014 at 10:56:47AM -0500, Felipe Balbi wrote:
 We only support GPL drivers in the USB Gadget Framework,
 it sounds correct to make all exported symbols GPL too.
 
 Signed-off-by: Felipe Balbi ba...@ti.com

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
--
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 03/10] usb: phy: mv-u3d: switch over to writel/readl

2014-04-21 Thread Felipe Balbi
On Mon, Apr 21, 2014 at 12:04:44PM -0700, Greg KH wrote:
 On Mon, Apr 21, 2014 at 10:56:45AM -0500, Felipe Balbi wrote:
  by removing the _relaxed suffix, we can build
  this driver in other architectures.
 
 Odd, why was the _relaxed variants used here at all?  Someone trying to
 optimize something ahead of time?

that has been there since its inception in commit
a67e76ac904cb48946262bf353f1df0d1b349368. My guess is that someone
wanted to avoid the memory barriers imposed by writel()/readl().

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH 03/10] usb: phy: mv-u3d: switch over to writel/readl

2014-04-21 Thread Greg KH
On Mon, Apr 21, 2014 at 10:56:45AM -0500, Felipe Balbi wrote:
 by removing the _relaxed suffix, we can build
 this driver in other architectures.

Odd, why was the _relaxed variants used here at all?  Someone trying to
optimize something ahead of time?

greg k-h
--
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: L3 custom error from dmtimer.c

2014-04-21 Thread Joel Fernandes
On 04/21/2014 12:04 PM, Joachim Eastwood wrote:
[..]
 Note that the warning I got might be cause by the pwm-omap and it's
 use of dmtimer api. I will investigate further.

 But either way add a check to enable/disable is a good idea.


 Sure, I added the check. The patch depends on a few other pending
 patches so I just zipped all together. It would be great if you could
 apply them and confirm it fixes the problem, then I can add your
 tested-by and include it in the next series.
 
 Thanks for zip-file, Joel.
 
 I can confirm that the pwm-omap driver still works with dmtimer after
 applying your patch set.
 So feel free to add: Tested-by: Joachim Eastwood manab...@gmail.com
 
 Have just a small comment on the dmtimer: Check return of
 pm_runtime_get_sync. I see that you use pr_err, but since you have a
 dev pointer available maybe you should use dev_err instead.

Thanks, I fixed it up to use the dev pointer and added your Tested-by.

  -Joel

8
From f2c5a92f42da56266cc4da1a15a1cea4b9dabb49 Mon Sep 17 00:00:00 2001
From: Joel Fernandes jo...@ti.com
Date: Mon, 21 Apr 2014 11:05:10 -0500
Subject: [PATCH] ARM: OMAP: dmtimer: Check return of pm_runtime_get_sync

omap_timer_enable doesn't check return value, this can lead to nasty bus
errors. Add a check and report issues.

Tested-by: Joachim Eastwood manab...@gmail.com
Signed-off-by: Joel Fernandes jo...@ti.com
---
 arch/arm/plat-omap/dmtimer.c  |   62
+++--
 arch/arm/plat-omap/include/plat/dmtimer.h |2 +-
 2 files changed, 51 insertions(+), 13 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 1fd30fa..a897d6d 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -164,7 +164,9 @@ static int omap_dm_timer_prepare(struct
omap_dm_timer *timer)
}
}

-   omap_dm_timer_enable(timer);
+   rc = omap_dm_timer_enable(timer);
+   if(rc)
+   return rc;

if (timer-capability  OMAP_TIMER_NEEDS_RESET) {
rc = omap_dm_timer_reset(timer);
@@ -375,11 +377,16 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
 }
 EXPORT_SYMBOL_GPL(omap_dm_timer_free);

-void omap_dm_timer_enable(struct omap_dm_timer *timer)
+int omap_dm_timer_enable(struct omap_dm_timer *timer)
 {
-   int c;
+   int c, err;

-   pm_runtime_get_sync(timer-pdev-dev);
+   err = pm_runtime_get_sync(timer-pdev-dev);
+   if (err  0) {
+   dev_err(timer-pdev-dev, %s: pm_runtime_get_sync failed 
(err=%d).,
+   __func__, err);
+   return err;
+   }

if (!(timer-capability  OMAP_TIMER_ALWON)) {
if (timer-get_context_loss_count) {
@@ -392,6 +399,7 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
omap_timer_restore_context(timer);
}
}
+   return 0;
 }
 EXPORT_SYMBOL_GPL(omap_dm_timer_enable);

@@ -432,11 +440,14 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
 int omap_dm_timer_start(struct omap_dm_timer *timer)
 {
u32 l;
+   int rc;

if (unlikely(!timer))
return -EINVAL;

-   omap_dm_timer_enable(timer);
+   rc = omap_dm_timer_enable(timer);
+   if (rc)
+   return rc;

l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
if (!(l  OMAP_TIMER_CTRL_ST)) {
@@ -534,11 +545,15 @@ int omap_dm_timer_set_load(struct omap_dm_timer
*timer, int autoreload,
unsigned int load)
 {
u32 mask = ~0, val = 0;
+   int rc;

if (unlikely(!timer))
return -EINVAL;

-   omap_dm_timer_enable(timer);
+   rc = omap_dm_timer_enable(timer);
+   if (rc)
+   return rc;
+
if (autoreload)
val |= OMAP_TIMER_CTRL_AR;
else
@@ -560,11 +575,14 @@ int omap_dm_timer_set_load_start(struct
omap_dm_timer *timer, int autoreload,
 unsigned int load)
 {
u32 l;
+   int rc;

if (unlikely(!timer))
return -EINVAL;

-   omap_dm_timer_enable(timer);
+   rc = omap_dm_timer_enable(timer);
+   if (rc)
+   return rc;

l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
if (autoreload) {
@@ -588,11 +606,15 @@ int omap_dm_timer_set_match(struct omap_dm_timer
*timer, int enable,
 unsigned int match)
 {
u32 mask = ~0, val = 0;
+   int rc;

if (unlikely(!timer))
return -EINVAL;

-   omap_dm_timer_enable(timer);
+   rc = omap_dm_timer_enable(timer);
+   if (rc)
+   return rc;
+
if (enable)
val |= OMAP_TIMER_CTRL_CE;
else
@@ -613,11 +635,15 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer
*timer, int def_on,
   int toggle, int trigger)
 {
u32 mask = ~0, val = 0;
+   int rc;

if 

[PATCH 2/2] ARM: OMAP2+: Fix GPMC remap for devices using an offset

2014-04-21 Thread Tony Lindgren
At least the smc91x driver expects the device to be at 0x300
offset from bus base address. This does not work currently
for GPMC when booted in device tree mode as it attempts to
remap the the allocated GPMC partition to the address
configured by the device tree plus the device offset.

Note that this works just fine when booted with legacy mode.

Let's fix the issue by just ignoring any device specific
offset while remapping. And let's make sure the remap
address confirms to the GPMC 16MB minimum granularity
as listed in the TRM for GPMC_CONFIG7 BASEADDRESS bits.

Otherwise we can get something like this:

omap-gpmc 6e00.gpmc: cannot remap GPMC CS 1 to 0x01000300

Cc: Pekon Gupta pe...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/gpmc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 84e57e6..9fe8c94 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -527,6 +527,14 @@ static int gpmc_cs_remap(int cs, u32 base)
pr_err(%s: requested chip-select is disabled\n, __func__);
return -ENODEV;
}
+
+   /*
+* Make sure we ignore any device offsets from the GPMC partition
+* allocated for the chip select and that the new base confirms
+* to the GPMC 16MB minimum granularity.
+*/ 
+   base = ~(SZ_16M - 1);
+
gpmc_cs_get_memconf(cs, old_base, size);
if (base == old_base)
return 0;
-- 
1.8.1.1

--
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] Fix few omap gpmc regressions when booted with device tree

2014-04-21 Thread Tony Lindgren
Hi all,

Here are two fixes to GPMC issues I've seen. It seems that we have
few more issues left to solve:

1. The remap of a device with gpmc_cs_remap seems to fail for
   a device if it's address specified in the .dts file is
   different from the address used by the bootloader

2. There seems to be some timing issues with smc911x where
   rsync of larger files and apt-get dist-upgrade can produce 
   strange errors. This seems to work reliably when booted in
   legacy mode.

3. The DT mappings of GPMC devices are wrong for most devices
   where the ranges property should contain the GPMC partition
   size (16, 32, 128 or 256 MB), and the reg property for the
   device should only contain the device IO range. So only NOR
   should use large values for ranges and IO range, the rest
   should use the minimum 16 MB range for GPMC partition, and
   0x4 - 0x2 for the IO range. And while patching these
   it makes sense to also unify the GPMC ranges being used for
   devices.

Pekon, can you take a look at 1 and 2 above?

Then for 3 above, it seems that we cannot safely change
ranges before 1 and 2 are working reliably. Or else we have
patch things twice, once to fix the range sizes, then to
unify the mappings for the range address...

Regards,

Tony

Tony Lindgren (2):
  ARM: OMAP2+: Fix oops for GPMC free
  ARM: OMAP2+: Fix GPMC remap for devices using an offset

 arch/arm/mach-omap2/gpmc.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

-- 
1.8.1.1

--
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] ARM: OMAP2+: Fix oops for GPMC free

2014-04-21 Thread Tony Lindgren
If gpmc_cs_remap() fails we will get an error because we are calling
release_resource() on an uninitialized resource. Let's fix that by
checking the resource flags. And while at it, let's also make
gpmc_cs_delete_mem() use the res pointer that we already have to
avoid confusion.

Without this patch we can get the following error:

omap-gpmc 6e00.gpmc: cannot remap GPMC CS 1 to 0x01000300
Unable to handle kernel NULL pointer dereference at virtual address 0018
...
(gpmc_cs_free+0x94/0xc8)
(gpmc_probe_generic_child+0x178/0x1ec)
(gpmc_probe_dt+0x1bc/0x2cc)
(gpmc_probe+0x250/0x44c)
(platform_drv_probe+0x3c/0x6c)
(really_probe+0x74/0x208)
(driver_probe_device+0x34/0x50)
(bus_for_each_drv+0x60/0x8c)
(device_attach+0x80/0xa4)
(bus_probe_device+0x88/0xb0)
(device_add+0x320/0x450)
(of_platform_device_create_pdata+0x80/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
(pdata_quirks_init+0x30/0x48)
(customize_machine+0x20/0x48)
(do_one_initcall+0x2c/0x14c)
(do_basic_setup+0x98/0xd8)
(kernel_init_freeable+0x12c/0x1e0)
(kernel_init+0x8/0xf0)
(ret_from_fork+0x14/0x2c)
Code: e1a04000 e59f0070 eb195136 e5942010 (e5923018)

Cc: Pekon Gupta pe...@ti.com
Signed-off-by: tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/gpmc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ab43755..84e57e6 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -501,7 +501,7 @@ static int gpmc_cs_delete_mem(int cs)
int r;
 
spin_lock(gpmc_mem_lock);
-   r = release_resource(gpmc_cs_mem[cs]);
+   r = release_resource(res);
res-start = 0;
res-end = 0;
spin_unlock(gpmc_mem_lock);
@@ -586,6 +586,8 @@ EXPORT_SYMBOL(gpmc_cs_request);
 
 void gpmc_cs_free(int cs)
 {
+   struct resource *res = gpmc_cs_mem[cs];
+
spin_lock(gpmc_mem_lock);
if (cs = gpmc_cs_num || cs  0 || !gpmc_cs_reserved(cs)) {
printk(KERN_ERR Trying to free non-reserved GPMC CS%d\n, cs);
@@ -594,7 +596,8 @@ void gpmc_cs_free(int cs)
return;
}
gpmc_cs_disable_mem(cs);
-   release_resource(gpmc_cs_mem[cs]);
+   if (res-flags)
+   release_resource(res);
gpmc_cs_set_reserved(cs, 0);
spin_unlock(gpmc_mem_lock);
 }
-- 
1.8.1.1

--
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 3/3] ARM: OMAP2+: AM43x: L2 cache support

2014-04-21 Thread Sekhar Nori
On Friday 11 April 2014 04:55 PM, Russell King - ARM Linux wrote:
 On Fri, Apr 11, 2014 at 11:03:57AM +0530, Sekhar Nori wrote:
 Here is a revised patch which is just an extension of your patch 
 with L2C-220 case handled. I dont really have L2C-220 hardware so even 
 if you want to handle that at a later time, it would be perfectly okay 
 with me.
 
 This is what I came up with, which of course is very similar to yours.
 I think the only difference is that I'm allowing the state of the NS
 access bits to be preserved by the OMAP code, getting OMAP closer to
 the target of a ~0 mask.  The only bits which are clear in the mask
 passed into the L2 code by OMAP now are:
 
 - L310_AUX_CTRL_INSTR_PREFETCH
 - L310_AUX_CTRL_DATA_PREFETCH
 - L310_AUX_CTRL_CACHE_REPLACE_RR
 - L2C_AUX_CTRL_SHARED_OVERRIDE
 - L2C_AUX_CTRL_PARITY_ENABLE
 
 It sounds like we can kill L310_AUX_CTRL_CACHE_REPLACE_RR as well since
 that's already set for us (and fwir is the power-on-reset default too.)
 
  arch/arm/mach-omap2/omap4-common.c |  4 +---
  arch/arm/mm/cache-l2x0.c   | 23 +--
  2 files changed, 22 insertions(+), 5 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/omap4-common.c 
 b/arch/arm/mach-omap2/omap4-common.c
 index c0f9a81a2d32..3b01c5223b11 100644
 --- a/arch/arm/mach-omap2/omap4-common.c
 +++ b/arch/arm/mach-omap2/omap4-common.c
 @@ -213,8 +213,6 @@ static int __init omap_l2_cache_init(void)
  
   /* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
   aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR |
 -L310_AUX_CTRL_NS_LOCKDOWN |
 -L310_AUX_CTRL_NS_INT_CTRL |
  L2C_AUX_CTRL_SHARED_OVERRIDE |
  L310_AUX_CTRL_DATA_PREFETCH |
  L310_AUX_CTRL_INSTR_PREFETCH;
 @@ -223,7 +221,7 @@ static int __init omap_l2_cache_init(void)
   if (of_have_populated_dt())
   l2x0_of_init(aux_ctrl, 0xc19f);

Just noticed that the mask here too should have been changed to
0xcd9f. I will be making this change to the local version I am
committing to base my AM43x support series on.

   else
 - l2x0_init(l2cache_base, aux_ctrl, 0xc19f);
 + l2x0_init(l2cache_base, aux_ctrl, 0xcd9f);

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