верните себе реальность превосходно замечать

[ktshiu]

Вы можете обладать великолепнейшим зрением http://goo.gl/w9JgWO
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 06/10] Documentation: dt bindings: move ..usb/usb-phy.txt to ..phy/ti-phy.txt

[Kishon Vijay Abraham I]

Since now we have a separate folder for phy, move the PHY dt binding
documentation of TI to that folder.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 .../devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt}|8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename Documentation/devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt} 
(88%)

diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
similarity index 88%
rename from Documentation/devicetree/bindings/usb/usb-phy.txt
rename to Documentation/devicetree/bindings/phy/ti-phy.txt
index c0245c8..207e14c 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -1,4 +1,4 @@
-USB PHY
+TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
 
 OMAP USB2 PHY
 
@@ -21,10 +21,10 @@ usb2phy@4a0ad080 {
#phy-cells = 0;
 };
 
-OMAP USB3 PHY
+TI PIPE3 PHY
 
 Required properties:
- - compatible: Should be ti,omap-usb3
+ - compatible: Should be ti,phy-usb3. ti,omap-usb3 is deprecated.
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the 
registers
filled in reg.
@@ -38,7 +38,7 @@ Optional properties:
 This is usually a subnode of ocp2scp to which it is connected.
 
 usb3phy@4a084400 {
-   compatible = ti,omap-usb3;
+   compatible = ti,phy-usb3;
reg = 0x4a084400 0x80,
  0x4a084800 0x64,
  0x4a084c00 0x40;
-- 
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 v3 00/10] Make dwc3 use Generic PHY Framework

[Kishon Vijay Abraham I]

Modified dwc3 core to find PHYs only if the platform indicates that it has 
to use a PHY (using quirks). Adapted DWC3 and USB3 PHY to use Generic PHY
framework. Also  changed the name of USB3 PHY driver to PIPE3 PHY driver
since the same driver has to be used for SATA and PCIE too.

Changes from v2:
* added a couple of fixes. One is invoking phy_resume after phy_init and the
other is power off phy in error patch
* used quirks to identify if a particular platform does not have PHYs
* removed using separate header for pipe3 driver and also removed all referencs
to SATA and PCIe in pipe3 driver since it's not yet adapted for those drivers.

Changes from v1:
* The logic in which the driver detects the presence of PHYs has changed.
* patch ordering has changed
* udelay is replaced with usleep_range
* A patch to remove set_suspend callback which was deferred from Generic
PHY Framework series has been included.

Kishon Vijay Abraham I (10):
  usb: dwc3: invoke phy_resume after phy_init
  usb: dwc3: power off usb phy in error path
  usb: dwc3: preparation for adapting dwc3 to generic phy framework
  usb: dwc3: use quirks to know if a particualr platform doesn't have
PHY
  usb: dwc3: adapt dwc3 core to use Generic PHY Framework
  Documentation: dt bindings: move ..usb/usb-phy.txt to
..phy/ti-phy.txt
  drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
  arm/dts: added dt properties to adapt to the new phy framwork

 .../bindings/{usb/usb-phy.txt = phy/ti-phy.txt}   |8 +-
 Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
 arch/arm/boot/dts/omap5.dtsi   |4 +
 drivers/phy/Kconfig|   11 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-omap-usb2.c|   27 +--
 .../phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} |  232 
 drivers/usb/dwc3/Kconfig   |2 +
 drivers/usb/dwc3/core.c|  189 +++-
 drivers/usb/dwc3/core.h|   22 ++
 drivers/usb/dwc3/platform_data.h   |5 +
 drivers/usb/phy/Kconfig|   11 -
 drivers/usb/phy/Makefile   |1 -
 include/linux/{usb = phy}/omap_usb.h  |3 -
 14 files changed, 320 insertions(+), 202 deletions(-)
 rename Documentation/devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt} 
(88%)
 rename drivers/{usb/phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} (55%)
 rename include/linux/{usb = phy}/omap_usb.h (95%)

-- 
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 v3 08/10] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2

[Kishon Vijay Abraham I]

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 drivers/phy/phy-omap-usb2.c |   25 -
 1 file changed, 25 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index bfc5c33..9b3e867 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -98,28 +98,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-   struct omap_usb *phy = phy_to_omapusb(x);
-   int ret;
-
-   if (suspend  !phy-is_suspended) {
-   omap_control_usb_phy_power(phy-control_dev, 0);
-   pm_runtime_put_sync(phy-dev);
-   phy-is_suspended = 1;
-   } else if (!suspend  phy-is_suspended) {
-   ret = pm_runtime_get_sync(phy-dev);
-   if (ret  0) {
-   dev_err(phy-dev, get_sync failed with err %d\n, ret);
-   return ret;
-   }
-   omap_control_usb_phy_power(phy-control_dev, 1);
-   phy-is_suspended = 0;
-   }
-
-   return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
struct omap_usb *phy = phy_get_drvdata(x);
@@ -173,7 +151,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
phy-phy.dev= phy-dev;
phy-phy.label  = omap-usb2;
-   phy-phy.set_suspend= omap_usb2_suspend;
phy-phy.otg= otg;
phy-phy.type   = USB_PHY_TYPE_USB2;
 
@@ -195,8 +172,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
 
phy-control_dev = control_pdev-dev;
-
-   phy-is_suspended   = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
 
otg-set_host   = omap_usb_set_host;
-- 
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 v3 09/10] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/

[Kishon Vijay Abraham I]

No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
Also removed the unused members of struct omap_usb (after phy-omap-pipe3
started using it's own header file)

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/phy/phy-omap-usb2.c   |2 +-
 include/linux/{usb = phy}/omap_usb.h |3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)
 rename include/linux/{usb = phy}/omap_usb.h (95%)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 9b3e867..d738dc3 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -21,7 +21,7 @@
 #include linux/slab.h
 #include linux/of.h
 #include linux/io.h
-#include linux/usb/omap_usb.h
+#include linux/phy/omap_usb.h
 #include linux/usb/phy_companion.h
 #include linux/clk.h
 #include linux/err.h
diff --git a/include/linux/usb/omap_usb.h b/include/linux/phy/omap_usb.h
similarity index 95%
rename from include/linux/usb/omap_usb.h
rename to include/linux/phy/omap_usb.h
index 6ae2936..19d343c3 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -33,13 +33,10 @@ struct usb_dpll_params {
 struct omap_usb {
struct usb_phy  phy;
struct phy_companion*comparator;
-   void __iomem*pll_ctrl_base;
struct device   *dev;
struct device   *control_dev;
struct clk  *wkupclk;
-   struct clk  *sys_clk;
struct clk  *optclk;
-   u8  is_suspended:1;
 };
 
 #definephy_to_omapusb(x)   container_of((x), struct omap_usb, phy)
-- 
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 v3 10/10] arm/dts: added dt properties to adapt to the new phy framwork

[Kishon Vijay Abraham I]

Added device tree bindings for dwc3, usb2 and usb3 PHYs. The documentation
of these can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt
and Documentation/devicetree/bindings/phy/ti-phy.txt.

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

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 29a6354..c135677 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -678,6 +678,8 @@
reg = 0x4a03 0x1;
interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
usb-phy = usb2_phy, usb3_phy;
+   phys = usb2_phy, usb3_phy;
+   phy-names = usb2-phy, usb3-phy;
dr_mode = peripheral;
tx-fifo-resize;
};
@@ -694,6 +696,7 @@
compatible = ti,omap-usb2;
reg = 0x4a084000 0x7c;
ctrl-module = omap_control_usb2phy;
+   #phy-cells = 0;
};
 
usb3_phy: usb3phy@4a084400 {
@@ -703,6 +706,7 @@
  0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb3phy;
+   #phy-cells = 0;
};
};
 
-- 
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 v3 02/10] usb: dwc3: power off usb phy in error path

[Kishon Vijay Abraham I]

usb phy was power'ed on but was never power'ed off in the error path.
Fix it.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/dwc3/core.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4dd1f7e..a49217a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -569,6 +569,8 @@ err2:
dwc3_event_buffers_cleanup(dwc);
 
 err1:
+   usb_phy_set_suspend(dwc-usb2_phy, 1);
+   usb_phy_set_suspend(dwc-usb3_phy, 1);
dwc3_core_exit(dwc);
 
 err0:
-- 
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 v3 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY

[Kishon Vijay Abraham I]

There can be systems which does not have an external phy, so get
phy only if no quirks are added that indicates the PHY is not present.
Introduced two quirk flags to indicate the *absence* of usb2 phy and
usb3 phy. Also remove checking if return value is -ENXIO since it's now
changed to always enable usb_phy layer.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/dwc3/Kconfig |1 +
 drivers/usb/dwc3/core.c  |   93 --
 drivers/usb/dwc3/core.h  |   15 ++
 drivers/usb/dwc3/platform_data.h |5 ++
 4 files changed, 69 insertions(+), 45 deletions(-)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 70fc430..8e385b4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,6 +1,7 @@
 config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET)  HAS_DMA
+   select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT  USB_XHCI_HCD
help
  Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 986674f..f20f4a1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -32,6 +32,7 @@
 #include linux/delay.h
 #include linux/dma-mapping.h
 #include linux/of.h
+#include linux/of_device.h
 
 #include linux/usb/ch9.h
 #include linux/usb/gadget.h
@@ -351,13 +352,28 @@ static void dwc3_core_exit(struct dwc3 *dwc)
 
 #define DWC3_ALIGN_MASK(16 - 1)
 
+#ifdef CONFIG_OF
+static const struct of_device_id of_dwc3_match[] = {
+   {
+   .compatible = snps,dwc3
+   },
+   {
+   .compatible = synopsys,dwc3
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, of_dwc3_match);
+#endif
+
 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;
+   const struct of_device_id *of_id;
struct resource *res;
struct dwc3 *dwc;
+   struct dwc3_data*dwc_data;
 
int ret = -ENOMEM;
 
@@ -391,16 +407,36 @@ static int dwc3_probe(struct platform_device *pdev)
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);
+   of_id = of_match_device(of_match_ptr(of_dwc3_match),
+   pdev-dev);
+   if (!of_id)
+   return -EINVAL;
+
+   dwc_data = (struct dwc3_data *)of_id-data;
+
+   if (dwc_data)
+   dwc-quirks = dwc_data-quirks;
+
+   if (!(dwc-quirks  DWC3_QUIRK_NO_USB2_PHY))
+   dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+   usb-phy, 0);
+
+   if (!(dwc-quirks  DWC3_QUIRK_NO_USB3_PHY))
+   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);
+   if (!(pdata-quirks  DWC3_QUIRK_NO_USB2_PHY))
+   dwc-usb2_phy = devm_usb_get_phy(dev,
+   USB_PHY_TYPE_USB2);
+
+   if (!(pdata-quirks  DWC3_QUIRK_NO_USB3_PHY))
+   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;
@@ -409,40 +445,20 @@ static int dwc3_probe(struct platform_device *pdev)
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 -ENXIO is returned, it means PHY layer wasn't
-* enabled, so it makes no sense to return -EPROBE_DEFER
-* in that case, since no PHY driver will ever probe.
-*/
-   if (ret == -ENXIO)
-   return ret;
-
-   dev_err(dev, no usb2 phy configured\n);
-   return -EPROBE_DEFER;
+   dev_err(dev, usb2 phy not found\n);
+   return 

[PATCH v3 03/10] usb: dwc3: preparation for adapting dwc3 to generic phy framework

[Kishon Vijay Abraham I]

Invoke usb_phy api's only if usb_phy does not have error value. This is
needed for both the legacy usb_phy and generic phy to co-exist in dwc3 core.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/dwc3/core.c |   42 --
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a49217a..986674f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -80,8 +80,10 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
dwc3_writel(dwc-regs, DWC3_GUSB2PHYCFG(0), reg);
 
-   usb_phy_init(dwc-usb2_phy);
-   usb_phy_init(dwc-usb3_phy);
+   if (!IS_ERR(dwc-usb2_phy))
+   usb_phy_init(dwc-usb2_phy);
+   if (!IS_ERR(dwc-usb3_phy))
+   usb_phy_init(dwc-usb3_phy);
mdelay(100);
 
/* Clear USB3 PHY reset */
@@ -341,8 +343,10 @@ err0:
 
 static void dwc3_core_exit(struct dwc3 *dwc)
 {
-   usb_phy_shutdown(dwc-usb2_phy);
-   usb_phy_shutdown(dwc-usb3_phy);
+   if (!IS_ERR(dwc-usb2_phy))
+   usb_phy_shutdown(dwc-usb2_phy);
+   if (!IS_ERR(dwc-usb3_phy))
+   usb_phy_shutdown(dwc-usb3_phy);
 }
 
 #define DWC3_ALIGN_MASK(16 - 1)
@@ -485,8 +489,10 @@ static int dwc3_probe(struct platform_device *pdev)
goto err0;
}
 
-   usb_phy_set_suspend(dwc-usb2_phy, 0);
-   usb_phy_set_suspend(dwc-usb3_phy, 0);
+   if (!IS_ERR(dwc-usb2_phy))
+   usb_phy_set_suspend(dwc-usb2_phy, 0);
+   if (!IS_ERR(dwc-usb3_phy))
+   usb_phy_set_suspend(dwc-usb3_phy, 0);
 
ret = dwc3_event_buffers_setup(dwc);
if (ret) {
@@ -569,8 +575,10 @@ err2:
dwc3_event_buffers_cleanup(dwc);
 
 err1:
-   usb_phy_set_suspend(dwc-usb2_phy, 1);
-   usb_phy_set_suspend(dwc-usb3_phy, 1);
+   if (!IS_ERR(dwc-usb2_phy))
+   usb_phy_set_suspend(dwc-usb2_phy, 1);
+   if (!IS_ERR(dwc-usb3_phy))
+   usb_phy_set_suspend(dwc-usb3_phy, 1);
dwc3_core_exit(dwc);
 
 err0:
@@ -583,8 +591,10 @@ static int dwc3_remove(struct platform_device *pdev)
 {
struct dwc3 *dwc = platform_get_drvdata(pdev);
 
-   usb_phy_set_suspend(dwc-usb2_phy, 1);
-   usb_phy_set_suspend(dwc-usb3_phy, 1);
+   if (!IS_ERR(dwc-usb2_phy))
+   usb_phy_set_suspend(dwc-usb2_phy, 1);
+   if (!IS_ERR(dwc-usb3_phy))
+   usb_phy_set_suspend(dwc-usb3_phy, 1);
 
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
@@ -680,8 +690,10 @@ static int dwc3_suspend(struct device *dev)
dwc-gctl = dwc3_readl(dwc-regs, DWC3_GCTL);
spin_unlock_irqrestore(dwc-lock, flags);
 
-   usb_phy_shutdown(dwc-usb3_phy);
-   usb_phy_shutdown(dwc-usb2_phy);
+   if (!IS_ERR(dwc-usb3_phy))
+   usb_phy_shutdown(dwc-usb3_phy);
+   if (!IS_ERR(dwc-usb2_phy))
+   usb_phy_shutdown(dwc-usb2_phy);
 
return 0;
 }
@@ -691,8 +703,10 @@ static int dwc3_resume(struct device *dev)
struct dwc3 *dwc = dev_get_drvdata(dev);
unsigned long   flags;
 
-   usb_phy_init(dwc-usb3_phy);
-   usb_phy_init(dwc-usb2_phy);
+   if (!IS_ERR(dwc-usb3_phy))
+   usb_phy_init(dwc-usb3_phy);
+   if (!IS_ERR(dwc-usb2_phy))
+   usb_phy_init(dwc-usb2_phy);
 
spin_lock_irqsave(dwc-lock, flags);
 
-- 
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 v3 05/10] usb: dwc3: adapt dwc3 core to use Generic PHY Framework

[Kishon Vijay Abraham I]

Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().

However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
 drivers/usb/dwc3/Kconfig   |1 +
 drivers/usb/dwc3/core.c|   66 +---
 drivers/usb/dwc3/core.h|7 +++
 4 files changed, 70 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
  - compatible: must be snps,dwc3
  - reg : Address and length of the register set for the device
  - interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
  - usb-phy : array of phandle for the PHY device.  The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
  - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
 
 This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8e385b4..64eed6f 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,6 +2,7 @@ config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET)  HAS_DMA
select USB_PHY
+   select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT  USB_XHCI_HCD
help
  Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index f20f4a1..628b372 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -85,6 +85,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
if (!IS_ERR(dwc-usb3_phy))
usb_phy_init(dwc-usb3_phy);
+
+   if (!IS_ERR(dwc-usb2_generic_phy))
+   phy_init(dwc-usb2_generic_phy);
+   if (!IS_ERR(dwc-usb3_generic_phy))
+   phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
 
/* Clear USB3 PHY reset */
@@ -348,6 +354,12 @@ static void dwc3_core_exit(struct dwc3 *dwc)
usb_phy_shutdown(dwc-usb2_phy);
if (!IS_ERR(dwc-usb3_phy))
usb_phy_shutdown(dwc-usb3_phy);
+
+   if (!IS_ERR(dwc-usb2_generic_phy))
+   phy_power_off(dwc-usb2_generic_phy);
+   if (!IS_ERR(dwc-usb3_generic_phy))
+   phy_power_off(dwc-usb3_generic_phy);
+
 }
 
 #define DWC3_ALIGN_MASK(16 - 1)
@@ -417,26 +429,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc_data)
dwc-quirks = dwc_data-quirks;
 
-   if (!(dwc-quirks  DWC3_QUIRK_NO_USB2_PHY))
+   if (!(dwc-quirks  DWC3_QUIRK_NO_USB2_PHY)) {
+   dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+   }
 
-   if (!(dwc-quirks  DWC3_QUIRK_NO_USB3_PHY))
+   if (!(dwc-quirks  DWC3_QUIRK_NO_USB3_PHY)) {
+   dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
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;
 
-   if (!(pdata-quirks  DWC3_QUIRK_NO_USB2_PHY))
+   if (!(pdata-quirks  DWC3_QUIRK_NO_USB2_PHY)) {
+   dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+   }
 
-   if (!(pdata-quirks  DWC3_QUIRK_NO_USB3_PHY))
+   if (!(pdata-quirks  DWC3_QUIRK_NO_USB3_PHY)) {
+   dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
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;
@@ -445,14 +465,20 @@ static int 

[PATCH v3 07/10] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework

[Kishon Vijay Abraham I]

Adapted omap-usb3 PHY driver to Generic PHY Framework and moved phy-omap-usb3
driver in drivers/usb/phy to drivers/phy and also renamed the file to
phy-ti-pipe3 since this same driver will be used for SATA PHY and
PCIE PHY.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/phy/Kconfig|   11 +
 drivers/phy/Makefile   |1 +
 .../phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} |  232 
 drivers/usb/phy/Kconfig|   11 -
 drivers/usb/phy/Makefile   |1 -
 5 files changed, 149 insertions(+), 107 deletions(-)
 rename drivers/{usb/phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} (55%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a344f3d..1abbfcc 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -33,6 +33,17 @@ config OMAP_USB2
  The USB OTG controller communicates with the comparator using this
  driver.
 
+config TI_PIPE3
+   tristate TI PIPE3 PHY Driver
+   depends on ARCH_OMAP2PLUS || COMPILE_TEST
+   select GENERIC_PHY
+   select OMAP_CONTROL_USB
+   help
+ Enable this to support the PIPE3 PHY that is part of TI SOCs. This
+ driver takes care of all the PHY functionality apart from comparator.
+ This driver interacts with the OMAP Control PHY Driver to power
+ on/off the PHY.
+
 config TWL4030_USB
tristate TWL4030 USB Transceiver Driver
depends on TWL4030_CORE  REGULATOR_TWL4030  USB_MUSB_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..94a1a79 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_GENERIC_PHY)   += phy-core.o
 obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)  += phy-exynos-dp-video.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
+obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/phy/phy-ti-pipe3.c
similarity index 55%
rename from drivers/usb/phy/phy-omap-usb3.c
rename to drivers/phy/phy-ti-pipe3.c
index 0c6ba29..410b286 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -1,5 +1,5 @@
 /*
- * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ * phy-ti-pipe3 - PIPE3 PHY driver.
  *
  * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
  * This program is free software; you can redistribute it and/or modify
@@ -19,10 +19,11 @@
 #include linux/module.h
 #include linux/platform_device.h
 #include linux/slab.h
-#include linux/usb/omap_usb.h
+#include linux/phy/phy.h
 #include linux/of.h
 #include linux/clk.h
 #include linux/err.h
+#include linux/io.h
 #include linux/pm_runtime.h
 #include linux/delay.h
 #include linux/usb/omap_control_usb.h
@@ -52,17 +53,34 @@
 
 /*
  * This is an Empirical value that works, need to confirm the actual
- * value required for the USB3PHY_PLL_CONFIGURATION2.PLL_IDLE status
- * to be correctly reflected in the USB3PHY_PLL_STATUS register.
+ * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
+ * to be correctly reflected in the PIPE3PHY_PLL_STATUS register.
  */
 # define PLL_IDLE_TIME  100;
 
-struct usb_dpll_map {
+struct pipe3_dpll_params {
+   u16 m;
+   u8  n;
+   u8  freq:3;
+   u8  sd;
+   u32 mf;
+};
+
+struct ti_pipe3 {
+   void __iomem*pll_ctrl_base;
+   struct device   *dev;
+   struct device   *control_dev;
+   struct clk  *wkupclk;
+   struct clk  *sys_clk;
+   struct clk  *optclk;
+};
+
+struct pipe3_dpll_map {
unsigned long rate;
-   struct usb_dpll_params params;
+   struct pipe3_dpll_params params;
 };
 
-static struct usb_dpll_map dpll_map[] = {
+static struct pipe3_dpll_map dpll_map[] = {
{1200, {1250, 5, 4, 20, 0} },   /* 12 MHz */
{1680, {3125, 20, 4, 20, 0} },  /* 16.8 MHz */
{1920, {1172, 8, 4, 20, 65537} },   /* 19.2 MHz */
@@ -71,7 +89,18 @@ static struct usb_dpll_map dpll_map[] = {
{3840, {3125, 47, 4, 20, 92843} },  /* 38.4 MHz */
 };
 
-static struct usb_dpll_params *omap_usb3_get_dpll_params(unsigned long rate)
+static inline u32 ti_pipe3_readl(void __iomem *addr, unsigned offset)
+{
+   return __raw_readl(addr + offset);
+}
+
+static inline void ti_pipe3_writel(void __iomem *addr, unsigned offset,
+   u32 data)
+{
+   __raw_writel(data, addr + offset);
+}
+
+static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(unsigned long rate)
 {
int i;
 
@@ -83,110 +112,113 @@ static struct usb_dpll_params 
*omap_usb3_get_dpll_params(unsigned long rate)
return NULL;
 }
 
-static int omap_usb3_suspend(struct usb_phy *x, int 

[PATCH v3 01/10] usb: dwc3: invoke phy_resume after phy_init

[Kishon Vijay Abraham I]

usb_phy_set_suspend(phy, 0) is called before usb_phy_init. Fix it.

Reported-by: Roger Quadros rog...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/dwc3/core.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..4dd1f7e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -455,9 +455,6 @@ static int dwc3_probe(struct platform_device *pdev)
if (IS_ERR(regs))
return PTR_ERR(regs);
 
-   usb_phy_set_suspend(dwc-usb2_phy, 0);
-   usb_phy_set_suspend(dwc-usb3_phy, 0);
-
spin_lock_init(dwc-lock);
platform_set_drvdata(pdev, dwc);
 
@@ -488,6 +485,9 @@ static int dwc3_probe(struct platform_device *pdev)
goto err0;
}
 
+   usb_phy_set_suspend(dwc-usb2_phy, 0);
+   usb_phy_set_suspend(dwc-usb3_phy, 0);
+
ret = dwc3_event_buffers_setup(dwc);
if (ret) {
dev_err(dwc-dev, failed to setup event buffers\n);
-- 
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

Re: [PATCH 1/3] power_supply: add power_supply_get_by_phandle

[Pavel Machek]

On Sun 2013-11-24 17:49:29, Sebastian Reichel wrote:
 Add method to get power supply by device tree phandle.
 
 Signed-off-by: Sebastian Reichel s...@debian.org

Reviewed-by: Pavel Machek pa...@ucw.cz

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] bq2415x_charger: add DT support

[Pavel Machek]

On Sun 2013-11-24 17:49:30, Sebastian Reichel wrote:
 This adds DT support to the bq2415x driver.
 
 Signed-off-by: Sebastian Reichel s...@debian.org

Reviewed-by: Pavel Machek pa...@ucw.cz


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/6] OMAPDSS: APPLY: set infos to dirty on enable

[Archit Taneja]

On Monday 18 November 2013 06:20 PM, Tomi Valkeinen wrote:

Currently when DISPC is suspended, the driver stores all DISPC registers
to memory, so that they can be restored on resume. This is a bad way to
handle suspend/resume, as it's prone to failures and requires somewhat
large amount of extra space to store the registers.

A better approach is to program the DISPC from scratch when resuming.
This can be easily accomplished in apply layer by setting the manager
and overlay infos to dirty when the manager is to be enabled.


I guess this won't work if we wanted to support DSI command mode 
displays. I.e, only shut DSS off and keep the panel up. In that case, we 
would need to mark the flags dirty in dss_mgr_start_update_compat().


We don't support the above use case anyway, but just pointing out :)

Archit



Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
  drivers/video/omap2/dss/apply.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 60758db..6ab4cb6 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1072,6 +1072,7 @@ static void dss_setup_fifos(void)
  static int dss_mgr_enable_compat(struct omap_overlay_manager *mgr)
  {
struct mgr_priv_data *mp = get_mgr_priv(mgr);
+   struct omap_overlay *ovl;
unsigned long flags;
int r;

@@ -1091,6 +1092,27 @@ static int dss_mgr_enable_compat(struct 
omap_overlay_manager *mgr)
goto err;
}

+   /*
+* Mark the info  extra_info dirty for the manager and its enabled
+* overlays to force register writes. This ensures that the relevant
+* registers are set after DSS has been off and the registers have been
+* reset.
+*/
+
+   mp-info_dirty = true;
+   mp-extra_info_dirty = true;
+
+   list_for_each_entry(ovl, mgr-overlays, list) {
+   struct ovl_priv_data *op = get_ovl_priv(ovl);
+
+   if (!op-enabled)
+   continue;
+
+   op-info_dirty = true;
+   op-extra_info_dirty = true;
+   dispc_ovl_set_channel_out(ovl-id, mgr-id);
+   }
+
dss_setup_fifos();

dss_write_regs();



--
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 3/3] dt: binding documentation for bq2415x charger

[Pavel Machek]

On Sun 2013-11-24 17:49:31, Sebastian Reichel wrote:
 Add devicetree binding documentation for bq2415x charger.
 
 Signed-off-by: Sebastian Reichel s...@debian.org

Thanks!

 +- reg: integer, i2c address of the device
 +- ti,current-limit: integer, current limit in mA

Does this need to be ti, specific? Most of fields are likely to be
needed for other li-ion chargers

Specifies maximum current charger can pull from power supply

?

 +- ti,charge-current: integer, charging current in mA

...why/how is it different from current-limit? Is the current-limit on
5V, while the charge-current relative to battery voltage... so that
charge-current can be  current-limit when battery voltage is low?

Maximum current that will be supplied to the battery, as determined
by voltage on current sense resistor?

 +- ti,weak-battery-voltage: integer, weak battery voltage threshold in mV

It would be good to explain what this threshold means. Voltage so low
that system needs to be shut down?

Hmm, it looks to me like it is as long as battery is below this
voltage, fast charge is not started. Instead, slow 'precharge' is
performed.

 +- ti,battery-regulation-voltage: integer, battery regulation
  voltage in mV

Selects maximum voltage for charging.

 +- ti,termination-current: integer, termination current in mA

When current in constant-voltage phase drops below this value, charge
is terminated.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.

[Andreas Fenkart]

The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.

Idea of remuxing the pins by Tony Lindgren as well as the implementation
of omap_hsmmc_pin_init.

Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   28 ++-
 drivers/mmc/host/omap_hsmmc.c  |  202 ++--
 include/linux/platform_data/mmc-omap.h |1 +
 3 files changed, 215 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
 ti,needs-special-reset: Requires a special softreset sequence
 ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High 
Speed
 ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need to set
+named pinctrl states default, active and idle , see example below.  The
+MMC driver will then then toggle between default and idle during the runtime
+Affected chips are am335x,
 
 --
 | PRCM |
@@ -49,3 +52,24 @@ Example:
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+   mmc1_cirq_pin: pinmux_cirq_pin {
+   pinctrl-single,pins = 
+   0x0f8 0x3f  /* MMC0_DAT1 as GPIO2_28 */
+   ;
+   };
+
+   mmc1: mmc@4806 {
+   ti,non-removable;
+   bus-width = 4;
+   vmmc-supply = ldo2_reg;
+   vmmc_aux-supply = vmmc;
+   ti,quirk-swakeup-missing;
+   pinctrl-names = default, active, idle;
+   pinctrl-0 = mmc1_pins;
+   pinctrl-1 = mmc1_pins;
+   pinctrl-2 = mmc1_cirq_pin;
+   ti,cirq-gpio = gpio3 28 0;
+   };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6b0ec55..c8c54f5 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -36,6 +36,7 @@
 #include linux/mmc/core.h
 #include linux/mmc/mmc.h
 #include linux/io.h
+#include linux/irq.h
 #include linux/gpio.h
 #include linux/regulator/consumer.h
 #include linux/pinctrl/consumer.h
@@ -202,6 +203,7 @@ struct omap_hsmmc_host {
u32 hctl;
u32 capa;
int irq;
+   int gpio_sdio_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -213,11 +215,32 @@ struct omap_hsmmc_host {
int req_in_progress;
int flags;
 #define HSMMC_SDIO_IRQ_ENABLED (1  0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1  1)
+#define HSMMC_CIRQ_GPIO_ENABLED (1  2)
 
struct omap_hsmmc_next  next_data;
+   struct pinctrl  *pinctrl;
+   struct pinctrl_state*fixed, *active, *idle;
struct  omap_mmc_platform_data  *pdata;
 };
 
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+   struct omap_hsmmc_host *host = dev_id;
+   unsigned long flags;
+
+   spin_lock_irqsave(host-irq_lock, flags);
+   if (host-flags  HSMMC_CIRQ_GPIO_ENABLED) {
+   disable_irq_nosync(host-gpio_sdio_irq);
+   host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
+   }
+   spin_unlock_irqrestore(host-irq_lock, flags);
+
+   pm_request_resume(host-dev); /* no use counter */
+
+   return IRQ_HANDLED;
+}
+
 static int omap_hsmmc_card_detect(struct device *dev, int slot)
 {
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -452,10 +475,23 @@ static int omap_hsmmc_gpio_init(struct 
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
 
+   if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
+   ret = gpio_request_one(pdata-slots[0].gpio_cirq, GPIOF_DIR_IN,
+  sdio_cirq);
+   if (ret)
+   goto err_free_ro;
+
+   } else {
+   pdata-slots[0].gpio_cirq = -EINVAL;
+   }
+
+
return 0;
 
+err_free_ro:
+   if (gpio_is_valid(pdata-slots[0].gpio_wp))
 err_free_wp:

[PATCH v3 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.

[Andreas Fenkart]

Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending

Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
 drivers/mmc/host/omap_hsmmc.c |   19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c8c54f5..f7ceca0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -81,6 +81,7 @@ static void apply_clk_hack(struct device *dev)
 #define OMAP_HSMMC_RSP54   0x0118
 #define OMAP_HSMMC_RSP76   0x011C
 #define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE  0x0124
 #define OMAP_HSMMC_HCTL0x0128
 #define OMAP_HSMMC_SYSCTL  0x012C
 #define OMAP_HSMMC_STAT0x0130
@@ -1795,6 +1796,20 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void 
*data)
 {
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+   bool suspended;
+
+   seq_puts(s, \n);
+   seq_printf(s, sdio irq\t%s\n, ((host-flags  HSMMC_SDIO_IRQ_ENABLED)
+? enabled : disabled));
+   suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+   if (host-flags  HSMMC_SWAKEUP_QUIRK) {
+   seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
+   if (suspended)
+   seq_printf(s, sdio irq pin\t%s\n,
+  gpio_get_value(mmc_slot(host).gpio_cirq) ?
+  high : low);
+   }
 
if (host-suspended) {
seq_printf(s, host suspended, can't read registers\n);
@@ -1802,9 +1817,11 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void 
*data)
}
 
pm_runtime_get_sync(host-dev);
-
+   seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+   seq_printf(s, PSTATE:\t\t0x%08x\n,
+  OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
-- 
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

Re: [PATCH 6/6] OMAPDSS: use runtime PM's autosuspend

[Archit Taneja]

On Monday 18 November 2013 06:20 PM, Tomi Valkeinen wrote:

Use runtime PM's autosuspend support with delay of 100ms.

This will prevent the driver from turning the DSS modules off and on
multiple times e.g. when loading the module.


Could you explain this a bit more?

Are you saying that when we insert the omapdss module, we have a lot of 
runtime_get/put pairs in probe, which leads to us excessive writing of 
DISPC the registers during resume, and the autosuspend feature would 
delay the effect of runtime_put() for a while?


Also, do we need to do this for all the platform devices? Could we use 
autosuspend only for the parent platform device, and the children 
platform devices don't use it? Or am I understanding things wrongly here?


Archit



Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
  drivers/video/omap2/dss/dispc.c | 5 -
  drivers/video/omap2/dss/dsi.c   | 5 -
  drivers/video/omap2/dss/dss.c   | 5 -
  drivers/video/omap2/dss/dss.h   | 2 ++
  drivers/video/omap2/dss/hdmi4.c | 5 -
  drivers/video/omap2/dss/rfbi.c  | 5 -
  drivers/video/omap2/dss/venc.c  | 5 -
  7 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 58f3626..0643eb0 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -258,7 +258,8 @@ void dispc_runtime_put(void)

DSSDBG(dispc_runtime_put\n);

-   r = pm_runtime_put_sync(dispc.pdev-dev);
+   pm_runtime_mark_last_busy(dispc.pdev-dev);
+   r = pm_runtime_put_autosuspend(dispc.pdev-dev);
WARN_ON(r  0  r != -ENOSYS);
  }
  EXPORT_SYMBOL(dispc_runtime_put);
@@ -3440,6 +3441,8 @@ static int __init omap_dispchw_probe(struct 
platform_device *pdev)
}

pm_runtime_enable(pdev-dev);
+   pm_runtime_set_autosuspend_delay(pdev-dev, DSS_AUTOSUSPEND_DELAY);
+   pm_runtime_use_autosuspend(pdev-dev);

r = dispc_runtime_get();
if (r)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6b30a58..19e4cad 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1110,7 +1110,8 @@ void dsi_runtime_put(struct platform_device *dsidev)

DSSDBG(dsi_runtime_put\n);

-   r = pm_runtime_put_sync(dsi-pdev-dev);
+   pm_runtime_mark_last_busy(dsi-pdev-dev);
+   r = pm_runtime_put_autosuspend(dsi-pdev-dev);
WARN_ON(r  0  r != -ENOSYS);
  }

@@ -5416,6 +5417,8 @@ static int omap_dsihw_probe(struct platform_device 
*dsidev)
return r;

pm_runtime_enable(dsidev-dev);
+   pm_runtime_set_autosuspend_delay(dsidev-dev, DSS_AUTOSUSPEND_DELAY);
+   pm_runtime_use_autosuspend(dsidev-dev);

r = dsi_runtime_get(dsidev);
if (r)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index fa7bc00..d3b0122 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -689,7 +689,8 @@ static void dss_runtime_put(void)

DSSDBG(dss_runtime_put\n);

-   r = pm_runtime_put_sync(dss.pdev-dev);
+   pm_runtime_mark_last_busy(dss.pdev-dev);
+   r = pm_runtime_put_autosuspend(dss.pdev-dev);
WARN_ON(r  0  r != -ENOSYS  r != -EBUSY);
  }

@@ -821,6 +822,8 @@ static int __init omap_dsshw_probe(struct platform_device 
*pdev)
goto err_setup_clocks;

pm_runtime_enable(pdev-dev);
+   pm_runtime_set_autosuspend_delay(pdev-dev, DSS_AUTOSUSPEND_DELAY);
+   pm_runtime_use_autosuspend(pdev-dev);

r = dss_runtime_get();
if (r)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index af83c4d..96505f0 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -73,6 +73,8 @@
  #define FLD_MOD(orig, val, start, end) \
(((orig)  ~FLD_MASK(start, end)) | FLD_VAL(val, start, end))

+#define DSS_AUTOSUSPEND_DELAY 100  /* in ms */
+
  enum dss_io_pad_mode {
DSS_IO_PAD_MODE_RESET,
DSS_IO_PAD_MODE_RFBI,
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index f1a45fe..f255641 100644
--- a/drivers/video/omap2/dss/hdmi4.c
+++ b/drivers/video/omap2/dss/hdmi4.c
@@ -77,7 +77,8 @@ static void hdmi_runtime_put(void)

DSSDBG(hdmi_runtime_put\n);

-   r = pm_runtime_put_sync(hdmi.pdev-dev);
+   pm_runtime_mark_last_busy(hdmi.pdev-dev);
+   r = pm_runtime_put_autosuspend(hdmi.pdev-dev);
WARN_ON(r  0  r != -ENOSYS);
  }

@@ -631,6 +632,8 @@ static int omapdss_hdmihw_probe(struct platform_device 
*pdev)
}

pm_runtime_enable(pdev-dev);
+   pm_runtime_set_autosuspend_delay(pdev-dev, DSS_AUTOSUSPEND_DELAY);
+   pm_runtime_use_autosuspend(pdev-dev);

hdmi_init_output(pdev);

diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 74d3ed1..20dcbfb 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -147,7 

[PATCH v3 1/3] mmc: omap_hsmmc: Enable SDIO IRQ.

[Andreas Fenkart]

For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.

Broken hardware, missing the swakueup line, should fallback
to polling, by setting 'ti,quirk-swakup-missing' in the
device tree. Otherwise pending SDIO IRQ are not detected
while in suspend. This affects am33xx processors.

For the DT-Binding portion:
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Kumar Gala ga...@codeaurora.org
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   18 
 drivers/mmc/host/omap_hsmmc.c  |   86 ++--
 2 files changed, 95 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..1136e6b 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,6 +20,24 @@ ti,dual-volt: boolean, supports dual voltage cards
 ti,non-removable: non-removable slot (like eMMC)
 ti,needs-special-reset: Requires a special softreset sequence
 ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High 
Speed
+ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
+SDIO irq while in suspend. Fallback to polling. Affected chips are
+am335x,
+
+--
+| PRCM |
+ --
+  ^ |
+  swakeup | | fclk
+  | v
+  -----   -
+ | card | -- CIRQ --  | hsmmc | -- IRQ --  | CPU |
+  -----   -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request fclk
+restore, when an external event is detected. Once the clock is
+restored, the host detects the event normally.
 
 Example:
mmc1: mmc@0x4809c000 {
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b392130..6b0ec55 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -130,6 +130,7 @@ static void apply_clk_hack(struct device *dev)
 #define TC_EN  (1  1)
 #define BWR_EN (1  4)
 #define BRR_EN (1  5)
+#define CIRQ_EN(1  8)
 #define ERR_EN (1  15)
 #define CTO_EN (1  16)
 #define CCRC_EN(1  17)
@@ -210,6 +211,9 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+   int flags;
+#define HSMMC_SDIO_IRQ_ENABLED (1  0)/* SDIO irq enabled */
+
struct omap_hsmmc_next  next_data;
struct  omap_mmc_platform_data  *pdata;
 };
@@ -490,27 +494,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host 
*host)
 static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
  struct mmc_command *cmd)
 {
-   unsigned int irq_mask;
+   u32 irq_mask = INT_EN_MASK;
+   unsigned long flags;
 
if (host-use_dma)
-   irq_mask = INT_EN_MASK  ~(BRR_EN | BWR_EN);
-   else
-   irq_mask = INT_EN_MASK;
+   irq_mask = ~(BRR_EN | BWR_EN);
 
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
 
+   spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+   /* latch pending CIRQ, but don't signal */
+   if (host-flags  HSMMC_SDIO_IRQ_ENABLED)
+   irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+   spin_unlock_irqrestore(host-irq_lock, flags);
 }
 
 static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
 {
-   OMAP_HSMMC_WRITE(host-base, ISE, 0);
-   OMAP_HSMMC_WRITE(host-base, IE, 0);
+   u32 irq_mask = 0;
+   unsigned long flags;
+
+   spin_lock_irqsave(host-irq_lock, flags);
+   /* no transfer running, need to signal cirq if enabled */
+   if (host-flags  HSMMC_SDIO_IRQ_ENABLED)
+   irq_mask |= CIRQ_EN;
+   OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+   OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+   spin_unlock_irqrestore(host-irq_lock, flags);
 }
 
 /* Calculate divisor for the given clock frequency */
@@ -1067,8 +1084,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
 
status = 

[PATCH v3 0/3] mmc: omap_hsmmc: Enable SDIO IRQ.

[Andreas Fenkart]

v3:
- removed gpio_irq from platform_data

v2:
- incorparated changes as suggested by reviewers
- simplified workaround for am335x, gpio will now only wake
  the module from runtime suspend, not handle the sdio irq
  itself 

Andreas Fenkart (3):
  mmc: omap_hsmmc: Enable SDIO IRQ.
  mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on
AM335x.
  mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.

 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   42 +++
 drivers/mmc/host/omap_hsmmc.c  |  303 ++--
 include/linux/platform_data/mmc-omap.h |1 +
 3 files changed, 324 insertions(+), 22 deletions(-)

-- 
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: dts: omap3-beagle: Fix USB host on beagle boards (for 3.13)

[Roger Quadros]

Beagle (rev. C4) and Beagle-XM (all revs) need VAUX2 1.8V supply
for the USB PHY.

As the generic PHY driver can't handle more than one supply
at the moment, we configure this supply to be always on.
This will cause a very small power impact if the USB host subsystem
is not in use, about 76.86 micro-W + LDO power.

Older Beagle boards (prior to C4) don't have VAUX2 connected anywhere,
so there won't be any functional impact on those boards other than
some additional LDO power consumption.

Reported-by: Nishanth Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap3-beagle-xm.dts | 8 
 arch/arm/boot/dts/omap3-beagle.dts| 8 
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 31a632f..b39918e 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -215,3 +215,11 @@
 usbhsehci {
phys = 0 hsusb2_phy;
 };
+
+vaux2 {
+   regulator-name = usb_1v8;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   regulator-always-on;
+};
+
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index fa532aa..9764556 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -178,3 +178,11 @@
mode = 3;
power = 50;
 };
+
+vaux2 {
+   regulator-name = vdd_ehci;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   regulator-always-on;
+};
+
-- 
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

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Pavel Machek]

Hi!

On Sun 2013-11-24 20:41:46, Pali Rohár wrote:
 On Sunday 24 November 2013 20:26:09 Sebastian Reichel wrote:
  On Sun, Nov 24, 2013 at 08:01:16PM +0100, Pali Rohár wrote:
   Currently on Maemo 5 this is handled in userspace (with open
   source dsme daemon).
  
  I assume it currently also takes care of the bq2415x watchdog?
  That means if the daemon dies charging will stop, because the
  watchdog does no longer trigger.
  
  When your patch is applied you have introduced a safety issue.
  When the daemon dies charging will continue and temperature is
  no longer checked.
  
  -- Sebastian
 
 No dsme checking battery temperature and does not handle bq24510 
 timer (previously this was in closed bme daemon which 
 functionality is now in kernel drivers). But dsme daemon also 
 kicking tlw4030 watchdog, so when daemon dies after 30s tlw4030 
 reboot device.
 
 But right you can implement correctly this in userspace (e.g. 
 when daemon not running/crashed, you can restart daemon or reboot 
 system or disable charing, whatever...) and you do not need to 
 have it in kernel...

Charging handling really should be in kernel.

1st) you want charging to work with init=/bin/bash, and you want it
with regular (not n900-specific) debian/arm.

2st) normally hardware, firmware or kernel does the charging. (PCs,
Sharp Zaurus). Yes, it pulls us farther away from Maemo...

Where can I get dsme sources?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Pali Rohár]

On Monday 25 November 2013 15:01:27 Pavel Machek wrote:
 Where can I get dsme sources?
   Pavel

dsme daemon: https://gitorious.org/community-ssu/dsme
dsme thermal plugin: 
https://gitorious.org/rx51-bme-replacement/dsme-thermalobject-surface

dsme thermal plugin is responsible for checking temperature of 
battery and send it to dsme damon. dsme daemon itself checking 
temperature limits and do something (e.g reboot device)

in dsme thermal plugin git history you can find both old version 
(which asking temperature from proprietary nokia bme daemon) and 
new version which reading temperature from power supply kernel 
modules.

-- 
Pali Rohár
pali.ro...@gmail.com


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

OMAP build failure after this merge window - caused by usb or phy Kconfig krap

[Russell King - ARM Linux]

There's no other way to say it, and I've no idea who is responsible for
this:

  LD  init/built-in.o
drivers/built-in.o: In function `omap_usb2_remove':
powercap_sys.c:(.text+0x1c60): undefined reference to `usb_remove_phy'
drivers/built-in.o: In function `omap_usb_power_off':
powercap_sys.c:(.text+0x1c84): undefined reference to 
`omap_control_usb_phy_power'
drivers/built-in.o: In function `omap_usb_power_on':
powercap_sys.c:(.text+0x1ca8): undefined reference to 
`omap_control_usb_phy_power'
drivers/built-in.o: In function `omap_usb2_probe':
powercap_sys.c:(.text+0x1dac): undefined reference to 
`omap_control_usb_phy_power'
powercap_sys.c:(.text+0x1e5c): undefined reference to `usb_add_phy_dev'
drivers/built-in.o: In function `omap_usb2_suspend':
powercap_sys.c:(.text+0x1ec8): undefined reference to 
`omap_control_usb_phy_power'
powercap_sys.c:(.text+0x1f20): undefined reference to 
`omap_control_usb_phy_power'
drivers/built-in.o: In function `omap_usb2_set_comparator':
powercap_sys.c:(.text+0x1f54): undefined reference to `usb_get_phy'
arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys':
dss-common.c:(.text+0xf824): undefined reference to `usb_bind_phy'
make[1]: *** [vmlinux] Error 1
make: *** [sub-make] Error 2

These warnings probably have something to do with it:

scripts/kconfig/conf --silentoldconfig Kconfig
warning: (OMAP_USB2  TWL4030_USB) selects USB_PHY which has unmet direct 
dependencies (USB_SUPPORT)
warning: (OMAP_USB2) selects OMAP_CONTROL_USB which has unmet direct 
dependencies (USB_SUPPORT  (ARCH_OMAP2PLUS || COMPILE_TEST))
warning: (OMAP_USB2  TWL4030_USB) selects USB_PHY which has unmet direct 
dependencies (USB_SUPPORT)
warning: (OMAP_USB2) selects OMAP_CONTROL_USB which has unmet direct 
dependencies (USB_SUPPORT  (ARCH_OMAP2PLUS || COMPILE_TEST))

which just illustrates why select in Kconfig is soo fscking bad that
it shouldn't be used.

It certainly should not be used without running through a series of
randconfig builds to make absolutely sure you have the dependencies
correct... or an allnoconfig with just the options required to select
the new option enabled.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs

[Christoffer Dall]

On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read from 
 AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*

hmm, this means that currently running this in a guest will fail to
bring-up SMP, right?

Couldn't you create a little wrapper-pen in U-Boot instead, which
replicates the omap boot protocol and takes care of the hyp-mode
startup there instead, keeping this completely out of the kernel?

-Christoffer
--
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: OMAP baseline test results for v3.13-rc1 (toolchain Debian 4.7.2-5)

[Paul Walmsley]

On Mon, 25 Nov 2013, Paul Walmsley wrote:

 Boot to userspace:
 FAIL ( 1/11): 37xxevm

An auto-bisect traced this to:

commit 95807689eab8441737572d1a9daaa1025429a908
Author: Tony Lindgren t...@atomide.com
Date:   Mon Oct 14 11:31:43 2013 -0700

ARM: OMAP2+: Remove legacy booting support for omap3 EVM

We now have pretty decent support with the device tree
based booting. Patches to add more features are welcome.

Signed-off-by: Tony Lindgren t...@atomide.com


So looks like this is due to the switchover to DT-based booting for 37xx 
EVM.  Will plug that in here and re-test.
  

- Paul
--
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 2/3] bq2415x_charger: Use power_supply notifier for automode

[Pavel Machek]

On Mon 2013-11-25 15:10:00, Pali Rohár wrote:
 On Monday 25 November 2013 15:01:27 Pavel Machek wrote:
  Where can I get dsme sources?
  Pavel
 
 dsme daemon: https://gitorious.org/community-ssu/dsme
 dsme thermal plugin: 
 https://gitorious.org/rx51-bme-replacement/dsme-thermalobject-surface
 
 dsme thermal plugin is responsible for checking temperature of 
 battery and send it to dsme damon. dsme daemon itself checking 
 temperature limits and do something (e.g reboot device)

Thanks for links!

AFAICT dsme daemon does some kind of system management, not
directly controlling charging, right? It does monitor system temperature.

Now.. Imagine phone left in car in charger (on sun). Likely
temperature will reach high values, kernel is charging, dsme will
reboot the system, but kernel will start charging again, dsme will
reboot again, ...

And it is not only high temperatures that are problem for li-ion
charging; battery should not be fast charged below 5C and should not
be charged below 0C. (Again, both are likely to happen if you leave
your phone in car).

AFAICT, we should simply disable charging below 5C or above 45C.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/11]: add remaining support for IGEP boards

[Javier Martinez Canillas]

On Wed, Nov 20, 2013 at 2:06 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 In order to make mach-omap2 Device Tree only, the board file for
 IGEP boards was removed even when support for wifi and display
 was still not supported by its DTS.

 This is a second version of a patch-set that adds support for
 these remaining peripherals and also adds support for USB,
 HDMI and user LED for the am33xx SoC based IGEP Aquila board.

 The patch-set is composed of the following patches:

 Enric Balletbo i Serra (7):
   ARM: dts: omap3-igep: Fix bus-width for mmc1.
   ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO.
   ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor.
   ARM: dts: AM33XX BASE0033: add pinmux and hdmi node to enable display
   ARM: dts: AM33XX BASE0033: add pinmux and user led support.
   ARM: dts: AM33XX BASE0033: add 32KBit EEPROM support.
   ARM: dts: AM33XX IGEP0033: add USB support.

 Javier Martinez Canillas (4):
   ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices
   ARM: dts: omap3-igep0020: Add pinmuxing for DVI output
   ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus
   ARM: dts: omap3-igep0020: name twl4030 VPLL2 regulator as vdds_dsi

 Changes since v1:

  Don't add a workaround in drivers/video/omap2/dss/dpi.c to use the
  VPLL2 regulator from twl4030 if VDDS_DSI regulator is not linked to
  the DPI device since the used regulator is a per board configuration.

  Instead add a regulator-name = vdds_dsi property to the regulator
  in the IGEPv2 DTS file as suggested by Tony Lindgren.

 Tony,

 Most of these patches are just DTS changes so they have to be picked
 by Benoit besides the following patch that has to go through your tree

 [PATCH 10/11] ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus

 Since we have removed the board file for IGEP boards I think these
 can be considered as regression fixes for 3.13 although I don't mind
 if you prefer to wait for 3.14.

 Thanks a lot and best regards,
 Javier
 --

Hi Benoit and Tony,

Now that 3.13-rc1 is out, do you think that it would be possible to
include this series as a fix for the -rc cycle?

Otherwise we will have missing functionality for IGEP boards on 3.13
due the board file removal. The changes are mostly DT and won't affect
other boards.

Thanks a lot and best regards,
Javier
--
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: omap3-beagle: Fix USB host on beagle boards (for 3.13)

[Nishanth Menon]

On Mon, Nov 25, 2013 at 7:55 AM, Roger Quadros rog...@ti.com wrote:
 Beagle (rev. C4) and Beagle-XM (all revs) need VAUX2 1.8V supply
 for the USB PHY.

 As the generic PHY driver can't handle more than one supply
 at the moment, we configure this supply to be always on.
 This will cause a very small power impact if the USB host subsystem
 is not in use, about 76.86 micro-W + LDO power.


 Older Beagle boards (prior to C4) don't have VAUX2 connected anywhere,
 so there won't be any functional impact on those boards other than
 some additional LDO power consumption.

 Reported-by: Nishanth Menon n...@ti.com
 Signed-off-by: Roger Quadros rog...@ti.com

Tested-by: Nishanth Menon n...@ti.com

I might suggest though that the better alternative might be to get phy
driver to handle multiple regulators considering that DT is supposed
to represent the h/w topology.

 ---
  arch/arm/boot/dts/omap3-beagle-xm.dts | 8 
  arch/arm/boot/dts/omap3-beagle.dts| 8 
  2 files changed, 16 insertions(+)

 diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
 b/arch/arm/boot/dts/omap3-beagle-xm.dts
 index 31a632f..b39918e 100644
 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
 +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
 @@ -215,3 +215,11 @@
  usbhsehci {
 phys = 0 hsusb2_phy;
  };
 +
 +vaux2 {
 +   regulator-name = usb_1v8;
 +   regulator-min-microvolt = 180;
 +   regulator-max-microvolt = 180;
 +   regulator-always-on;
 +};
 +
 diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
 b/arch/arm/boot/dts/omap3-beagle.dts
 index fa532aa..9764556 100644
 --- a/arch/arm/boot/dts/omap3-beagle.dts
 +++ b/arch/arm/boot/dts/omap3-beagle.dts
 @@ -178,3 +178,11 @@
 mode = 3;
 power = 50;
  };
 +
 +vaux2 {
 +   regulator-name = vdd_ehci;
 +   regulator-min-microvolt = 180;
 +   regulator-max-microvolt = 180;
 +   regulator-always-on;
 +};
 +
 --
 1.8.3.2


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs

[Santosh Shilimkar]

On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read from 
 AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*
 
 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?
 
Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build 
will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
Right ? 

 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?
 
Its not just booting but CPU hotplug also follows the same path
so we need the mechanism in kernel to switch mode.

In general, I think its important to consider the aspect with
CPU PM. CPUs are not going to go through the boot-loaders in
those paths and hence need of HYP entry in the kernel will
be must.

Regards,
Santosh

Regards,
Santosh
--
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: OMAP baseline test results for v3.13-rc1 (toolchain Debian 4.7.2-5)

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [131125 07:16]:
 On Mon, 25 Nov 2013, Paul Walmsley wrote:
 
  Boot to userspace:
  FAIL ( 1/11): 37xxevm
 
 An auto-bisect traced this to:
 
 commit 95807689eab8441737572d1a9daaa1025429a908
 Author: Tony Lindgren t...@atomide.com
 Date:   Mon Oct 14 11:31:43 2013 -0700
 
 ARM: OMAP2+: Remove legacy booting support for omap3 EVM
 
 We now have pretty decent support with the device tree
 based booting. Patches to add more features are welcome.
 
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 
 So looks like this is due to the switchover to DT-based booting for 37xx 
 EVM.  Will plug that in here and re-test.

Yes. Also there's the patch missing to enable wake-up interrupts, but
that has a dependency to populating IRQ resources dynamically to avoid
nasty warnings. Both should get fixed during the -rc cycle though.

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 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs

[Christoffer Dall]

On 25 November 2013 08:28, Santosh Shilimkar santosh.shilim...@ti.com wrote:
 On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read from 
 AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*

 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?

 Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build
 will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
 Right ?


That really goes against the whole single binary on all platforms
thing. With multi-platform support you really shouldn't have to
compile your kernel any differently for running as a guest as when
you're running on a host.  Someone may even emulate an OMAP5 in QEMU
and you'd certainly want your kvm-enabled kernel to run as both guest
and host.  After all, this is not a paravirtualization solution.

 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?

 Its not just booting but CPU hotplug also follows the same path
 so we need the mechanism in kernel to switch mode.

 In general, I think its important to consider the aspect with
 CPU PM. CPUs are not going to go through the boot-loaders in
 those paths and hence need of HYP entry in the kernel will
 be must.

I agree, and PSCI is the obvious only correct answer to this.

We have discussed this a bit earlier (I think Will Deacon brought this
up - cc'ed), but I don't think anyone had any bright ideas.

However, we broadly agreed on the fact that for KVM/hyp support, you
need to boot your kernel in that mode, and this is definitely pulling
in the wrong direction.

-Christoffer
--
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: ARM: v3.13-rc1: USB regression

[Aaro Koskinen]

Hi,

On Sun, Nov 24, 2013 at 10:43:59PM +, Russell King - ARM Linux wrote:
 On Mon, Nov 25, 2013 at 12:22:47AM +0200, Aaro Koskinen wrote:
  [   33.967324] ohci ohci: Coherent DMA mask 0x (pfn 
  0xe-0xe) covers a smaller range of system memory than the DMA zone 
  pfn 0x0-0x10
  
  I bisected this to 4dcfa60071b3d23f0181f27d8519f12e37cefbb9 (ARM: DMA-API:
  better handing of DMA masks for coherent allocations). Reverting that
  commit makes the USB work again fine.

[...]

 Better would be:
 
 #define __arch_dma_to_pfn(dev, addr)  \
   ({ unsigned long pfn = (addr)  PAGE_SHIFT;\
  if (is_lbus_device(dev)) \
   pfn += PHYS_PFN_OFFSET -\
   (OMAP1510_LB_OFFSET  PAGE_SHIFT); \
  pfn; \
   })
 
 Can you try that in arch/arm/mach-omap1/include/mach/memory.h please?

Still doesn't work:

[   33.878790] ohci ohci: Coherent DMA mask 0x (pfn 0xfffe-0xe) 
covers a smaller range of system memory than the DMA zone pfn 0x0-0x10
[   33.894019] ohci ohci: can't setup: -12

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

Re: [PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs

[Marc Zyngier]

On 25/11/13 16:28, Santosh Shilimkar wrote:
 On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read from 
 AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*

 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?

 Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build 
 will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
 Right ? 

Absolutely not. We're way past the one image per usage model, and I
fully expect the same kernel to boot both as a guest and a host.
Otherwise, multiplatform is just a joke.

 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?

 Its not just booting but CPU hotplug also follows the same path
 so we need the mechanism in kernel to switch mode.
 
 In general, I think its important to consider the aspect with
 CPU PM. CPUs are not going to go through the boot-loaders in
 those paths and hence need of HYP entry in the kernel will
 be must.

I definitely agree that you need to consider PM as well. But we've
decided a long time ago that we wouldn't take that kind of code in the
kernel. Your CPU has to reach the kernel in HYP, and that is down to
your boot protocol to take care off that.

There are a few options. Christoffer mentioned having a pen, and you
also could implement PSCI fairly easily (I've recently posted a u-boot
patch series to take care of this, though there is still a fair bit of
work required).

Whatever the approach is, the bottom line remains: your CPU enters the
kernel in HYP.

Cheers,

M.
-- 
Jazz is not dead. It just smells funny...

--
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: configs: OMAP2+: Enable PREEMPT and crypto USER API config

[Joel Fernandes]

Enable PREEMPT config option as some in-kernel tests such as tcrypt produce RCU
sched stalls when the test is running.  Also enable options for crypto AF_ALG
users so that OpenSSL can uses the crypto HW accel drivers.

Signed-off-by: Joel Fernandes jo...@ti.com
---
 arch/arm/configs/omap2plus_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 254cf05..b6f39f6 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -295,6 +295,8 @@ CONFIG_DEBUG_INFO=y
 CONFIG_SECURITY=y
 CONFIG_CRYPTO_MICHAEL_MIC=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRYPTO_USER_API_HASH=y
+CONFIG_CRYPTO_USER_API_SKCIPHER=y
 CONFIG_CRC_CCITT=y
 CONFIG_CRC_T10DIF=y
 CONFIG_CRC_ITU_T=y
@@ -306,3 +308,4 @@ CONFIG_TI_DAVINCI_CPDMA=y
 CONFIG_TI_CPSW=y
 CONFIG_AT803X_PHY=y
 CONFIG_SOC_DRA7XX=y
+CONFIG_PREEMPT=y
-- 
1.8.1.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

HYP Kernel boot requirements [Was ...Re: [PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs]

[Santosh Shilimkar]

On Monday 25 November 2013 11:33 AM, Christoffer Dall wrote:
 On 25 November 2013 08:28, Santosh Shilimkar santosh.shilim...@ti.com wrote:
 On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read 
 from AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*

 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?

 Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build
 will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
 Right ?

 
 That really goes against the whole single binary on all platforms
 thing. With multi-platform support you really shouldn't have to
 compile your kernel any differently for running as a guest as when
 you're running on a host.  Someone may even emulate an OMAP5 in QEMU
 and you'd certainly want your kvm-enabled kernel to run as both guest
 and host.  After all, this is not a paravirtualization solution.
 
Fair enough.

 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?

 Its not just booting but CPU hotplug also follows the same path
 so we need the mechanism in kernel to switch mode.

 In general, I think its important to consider the aspect with
 CPU PM. CPUs are not going to go through the boot-loaders in
 those paths and hence need of HYP entry in the kernel will
 be must.

 I agree, and PSCI is the obvious only correct answer to this.
 
 We have discussed this a bit earlier (I think Will Deacon brought this
 up - cc'ed), but I don't think anyone had any bright ideas.
 
 However, we broadly agreed on the fact that for KVM/hyp support, you
 need to boot your kernel in that mode, and this is definitely pulling
 in the wrong direction.
 
What I am saying is the platforms like OMAP5 already support PM in
mainline kernel and we can't break that for KVM. Boot-loaders
would be thrashed after boot so you need something which runs
in Kernel or along with Kernel to have equivalent of hyp
switching.

Am not challenging the agreed direction but we need to solve the
PM problem as well before making all CPU runs boot-loader for
HYP kernels as a must have. At least its is a change in boot
strategy from existing kernels.

CC'ing few more folks and changing the subject line

Regards,
Santosh

 

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

Re: [PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs

[Santosh Shilimkar]

On Monday 25 November 2013 11:42 AM, Marc Zyngier wrote:
 On 25/11/13 16:28, Santosh Shilimkar wrote:
 On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read 
 from AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*

 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?

 Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build 
 will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
 Right ? 
 
 Absolutely not. We're way past the one image per usage model, and I
 fully expect the same kernel to boot both as a guest and a host.
 Otherwise, multiplatform is just a joke.
 
 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?

 Its not just booting but CPU hotplug also follows the same path
 so we need the mechanism in kernel to switch mode.

 In general, I think its important to consider the aspect with
 CPU PM. CPUs are not going to go through the boot-loaders in
 those paths and hence need of HYP entry in the kernel will
 be must.
 
 I definitely agree that you need to consider PM as well. But we've
 decided a long time ago that we wouldn't take that kind of code in the
 kernel. Your CPU has to reach the kernel in HYP, and that is down to
 your boot protocol to take care off that.
 
 There are a few options. Christoffer mentioned having a pen, and you
 also could implement PSCI fairly easily (I've recently posted a u-boot
 patch series to take care of this, though there is still a fair bit of
 work required).
 
 Whatever the approach is, the bottom line remains: your CPU enters the
 kernel in HYP.
 
Our emails crossed. I understand the stand from you guys. Lets
continue discussion on other thread.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: configs: OMAP2+: Enable PREEMPT and crypto USER API config

[Joel Fernandes]

Enable PREEMPT config option as some in-kernel tests such as tcrypt produce RCU
sched stalls when the test is running.  Also enable options for crypto AF_ALG
users so that OpenSSL can uses the crypto HW accel drivers.

Signed-off-by: Joel Fernandes jo...@ti.com
---
Previous version was based on 3.12, in the v2- rebased now on 3.13-rc1. thanks

 arch/arm/configs/omap2plus_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 98a50c3..044dc04 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -283,6 +283,8 @@ CONFIG_PROVE_LOCKING=y
 CONFIG_SECURITY=y
 CONFIG_CRYPTO_MICHAEL_MIC=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRYPTO_USER_API_HASH=y
+CONFIG_CRYPTO_USER_API_SKCIPHER=y
 CONFIG_CRC_CCITT=y
 CONFIG_CRC_T10DIF=y
 CONFIG_CRC_ITU_T=y
@@ -291,3 +293,4 @@ CONFIG_LIBCRC32C=y
 CONFIG_FONTS=y
 CONFIG_FONT_8x8=y
 CONFIG_FONT_8x16=y
+CONFIG_PREEMPT=y
-- 
1.8.1.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

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Sebastian Reichel]

On Mon, Nov 25, 2013 at 07:01:54PM +0200, Ивайло Димитров wrote:
 Now.. Imagine phone left in car in charger (on sun). Likely
 temperature will reach high values, kernel is charging, dsme will
 reboot the system, but kernel will start charging again, dsme will
 reboot again, ...

 And it is not only high temperatures that are problem for li-ion
 charging; battery should not be fast charged below 5C and should not
 be charged below 0C. (Again, both are likely to happen if you leave
 your phone in car).

 AFAICT, we should simply disable charging below 5C or above 45C.
 
 AFAIK dsme will not restart it, but power it off, so the above
 scenario won't happen.

Just assume what happens, when dsme does not start (e.g. system boot
hangs).

If everything is controlled from userspace, charger would not start
(- safe!). If everything is controlled by the kernel, temperature
safety checks are taken (- safe!). But in the currently proposed
variant: No safety checks.

-- Sebastian



signature.asc
Description: Digital signature

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Ивайло Димитров]

 




  Оригинално писмо 
 От:  Pavel Machek 
 Относно: Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for
 automode
 До: Pali Rohár 
 Изпратено на: Понеделник, 2013, Ноември 25 17:18:39 EET
 
 
 On Mon 2013-11-25 15:10:00, Pali Rohár wrote:
  On Monday 25 November 2013 15:01:27 Pavel Machek wrote:
   Where can I get dsme sources?
 Pavel
  
  dsme daemon: https://gitorious.org/community-ssu/dsme
  dsme thermal plugin: 
  https://gitorious.org/rx51-bme-replacement/dsme-thermalobject-surface
  
  dsme thermal plugin is responsible for checking temperature of 
  battery and send it to dsme damon. dsme daemon itself checking 
  temperature limits and do something (e.g reboot device)
 
 Thanks for links!
 
 AFAICT dsme daemon does some kind of system management, not
 directly controlling charging, right? It does monitor system temperature.
 
 Now.. Imagine phone left in car in charger (on sun). Likely
 temperature will reach high values, kernel is charging, dsme will
 reboot the system, but kernel will start charging again, dsme will
 reboot again, ...
 
 And it is not only high temperatures that are problem for li-ion
 charging; battery should not be fast charged below 5C and should not
 be charged below 0C. (Again, both are likely to happen if you leave
 your phone in car).
 
 AFAICT, we should simply disable charging below 5C or above 45C.
 
   Pavel
 -- 
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
 

AFAIK dsme will not restart it, but power it off, so the above scenario won't 
happen.

Regards,
Ivo
--
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: ARM: v3.13-rc1: USB regression

[Russell King - ARM Linux]

On Mon, Nov 25, 2013 at 06:33:02PM +0200, Aaro Koskinen wrote:
 Hi,
 
 On Sun, Nov 24, 2013 at 10:43:59PM +, Russell King - ARM Linux wrote:
  On Mon, Nov 25, 2013 at 12:22:47AM +0200, Aaro Koskinen wrote:
   [   33.967324] ohci ohci: Coherent DMA mask 0x (pfn 
   0xe-0xe) covers a smaller range of system memory than the DMA 
   zone pfn 0x0-0x10
   
   I bisected this to 4dcfa60071b3d23f0181f27d8519f12e37cefbb9 (ARM: DMA-API:
   better handing of DMA masks for coherent allocations). Reverting that
   commit makes the USB work again fine.
 
 [...]
 
  Better would be:
  
  #define __arch_dma_to_pfn(dev, addr)\
  ({ unsigned long pfn = (addr)  PAGE_SHIFT;\
 if (is_lbus_device(dev)) \
  pfn += PHYS_PFN_OFFSET -\
  (OMAP1510_LB_OFFSET  PAGE_SHIFT); \
 pfn; \
  })
  
  Can you try that in arch/arm/mach-omap1/include/mach/memory.h please?
 
 Still doesn't work:
 
 [   33.878790] ohci ohci: Coherent DMA mask 0x (pfn 
 0xfffe-0xe) covers a smaller range of system memory than the DMA zone 
 pfn 0x0-0x10
 [   33.894019] ohci ohci: can't setup: -12

Well, that looks technically better, rather unfortunate that we end up
going to negative PFNs though.

Without that change, could you try this instead please:

 arch/arm/mm/dma-mapping.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f0ea0134e5a3..a18cfc53f445 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -9,6 +9,7 @@
  *
  *  DMA uncached mapping support.
  */
+#include linux/bootmem.h
 #include linux/module.h
 #include linux/mm.h
 #include linux/gfp.h
@@ -162,6 +163,8 @@ static u64 get_coherent_dma_mask(struct device *dev)
u64 mask = (u64)DMA_BIT_MASK(32);
 
if (dev) {
+   unsigned long max_dma_pfn;
+
mask = dev-coherent_dma_mask;
 
/*
@@ -173,6 +176,8 @@ static u64 get_coherent_dma_mask(struct device *dev)
return 0;
}
 
+   max_dma_pfn = min(max_pfn, arm_dma_pfn_limit);
+
/*
 * If the mask allows for more memory than we can address,
 * and we actually have that much memory, then fail the
@@ -180,7 +185,7 @@ static u64 get_coherent_dma_mask(struct device *dev)
 */
if (sizeof(mask) != sizeof(dma_addr_t) 
mask  (dma_addr_t)~0 
-   dma_to_pfn(dev, ~0)  arm_dma_pfn_limit) {
+   dma_to_pfn(dev, ~0)  max_dma_pfn) {
dev_warn(dev, Coherent DMA mask %#llx is larger than 
dma_addr_t allows\n,
 mask);
dev_warn(dev, Driver did not use or check the return 
value from dma_set_coherent_mask()?\n);
@@ -192,7 +197,7 @@ static u64 get_coherent_dma_mask(struct device *dev)
 * fits within the allowable addresses which we can
 * allocate.
 */
-   if (dma_to_pfn(dev, mask)  arm_dma_pfn_limit) {
+   if (dma_to_pfn(dev, mask)  max_dma_pfn) {
dev_warn(dev, Coherent DMA mask %#llx (pfn %#lx-%#lx) 
covers a smaller range of system memory than the DMA zone pfn 0x0-%#lx\n,
 mask,
 dma_to_pfn(dev, 0), dma_to_pfn(dev, mask) + 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: HYP Kernel boot requirements [Was ...Re: [PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs]

[Catalin Marinas]

On Mon, Nov 25, 2013 at 04:59:16PM +, Santosh Shilimkar wrote:
 On Monday 25 November 2013 11:33 AM, Christoffer Dall wrote:
  On 25 November 2013 08:28, Santosh Shilimkar santosh.shilim...@ti.com 
  wrote:
  On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
  On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com 
  wrote:
  Boot-CPU entry into the HYP mode is managed in boot-loader but
  the secondary CPUs directly jumps to kernel during boot. Same
  path is also used for CPU hotplug as well during suspend for
  secondary CPU.
 
  Hence patch the secondary CPU boot path for hyp mode etry.
 
  Cc: Marc Zyngier marc.zyng...@arm.com
  Cc: Christoffer Dall christoffer.d...@linaro.org
  Cc: Tony Lindgren t...@atomide.com
  Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
  ---
   arch/arm/mach-omap2/omap-headsmp.S |7 +++
   1 file changed, 7 insertions(+)
 
  diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
  b/arch/arm/mach-omap2/omap-headsmp.S
  index 75e9295..4844dd8 100644
  --- a/arch/arm/mach-omap2/omap-headsmp.S
  +++ b/arch/arm/mach-omap2/omap-headsmp.S
  @@ -22,6 +22,7 @@
 
   /* Physical address needed since MMU not enabled yet on secondary core 
  */
   #define AUX_CORE_BOOT0_PA  0x48281800
  +#define API_HYP_ENTRY  0x102
 
   /*
* OMAP5 specific entry point for secondary CPU to jump from ROM
  @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read 
  from AuxCoreBoot0
  and r4, r4, #0x0f
  cmp r0, r4
  bne wait
  +#ifdef CONFIG_KVM_ARM_HOST
  +   ldr r12, =API_HYP_ENTRY
  +   adr r0, hyp_boot
  +   smc #0
  +hyp_boot:
  +#endif
  b   secondary_startup
   END(omap5_secondary_startup)
   /*
 
  hmm, this means that currently running this in a guest will fail to
  bring-up SMP, right?
 
  Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build
  will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
  Right ?
 
  
  That really goes against the whole single binary on all platforms
  thing. With multi-platform support you really shouldn't have to
  compile your kernel any differently for running as a guest as when
  you're running on a host.  Someone may even emulate an OMAP5 in QEMU
  and you'd certainly want your kvm-enabled kernel to run as both guest
  and host.  After all, this is not a paravirtualization solution.
 
 Fair enough.
 
  Couldn't you create a little wrapper-pen in U-Boot instead, which
  replicates the omap boot protocol and takes care of the hyp-mode
  startup there instead, keeping this completely out of the kernel?
 
  Its not just booting but CPU hotplug also follows the same path
  so we need the mechanism in kernel to switch mode.
 
  In general, I think its important to consider the aspect with
  CPU PM. CPUs are not going to go through the boot-loaders in
  those paths and hence need of HYP entry in the kernel will
  be must.
 
  I agree, and PSCI is the obvious only correct answer to this.
  
  We have discussed this a bit earlier (I think Will Deacon brought this
  up - cc'ed), but I don't think anyone had any bright ideas.
  
  However, we broadly agreed on the fact that for KVM/hyp support, you
  need to boot your kernel in that mode, and this is definitely pulling
  in the wrong direction.
 
 What I am saying is the platforms like OMAP5 already support PM in
 mainline kernel and we can't break that for KVM. Boot-loaders
 would be thrashed after boot so you need something which runs
 in Kernel or along with Kernel to have equivalent of hyp
 switching.
 
 Am not challenging the agreed direction but we need to solve the
 PM problem as well before making all CPU runs boot-loader for
 HYP kernels as a must have. At least its is a change in boot
 strategy from existing kernels.

Of course I recommend PSCI which covers both hotplug and suspend ;), but
I guess it's not the case for OMAP5. Since OMAP has its own secondary
booting protocol and CPU hotplug re-entry, can you not just use
different entry point when the primary CPU was initially started in Hyp
mode (e.g. omap5_hyp_secondary_startup)?

-- 
Catalin
--
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 v6] ARM: omap: edma: add suspend suspend/resume hooks

[Joel Fernandes]

On 11/17/2013 04:19 PM, Daniel Mack wrote:
 This patch makes the edma driver resume correctly after suspend. Tested
 on an AM33xx platform with cyclic audio streams and omap_hsmmc.
 
 All information can be reconstructed by already known runtime
 information.
 
 As we now use some functions that were previously only used from __init
 context, annotations had to be dropped.
 
 [n...@ti.com: added error handling for runtime + suspend_late/early_resume]
 Signed-off-by: Nishanth Menon n...@ti.com
 Signed-off-by: Daniel Mack zon...@gmail.com
 Tested-by: Joel Fernandes jo...@ti.com
 Acked-by: Joel Fernandes jo...@ti.com

Hi Sekhar,

Can you consider pulling this patch? It has been tested and Acked. Thanks.

regards,

-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: Help needed to force USB host mode on AM335x CPU

[Felipe Balbi]

Hi,

On Fri, Nov 22, 2013 at 02:28:50PM +, Mark Jackson wrote:
 We have a custom AM335x board where the USB0_ID pin has been left floating.
 
 By default, this puts the USB controller into peripheral mode, but we need
 to force it into host mode.
 
 This can be achieved in s/w by setting some bits in the relevant USB mode
 register (see TRM 16.5.2.35).
 
 This mode register's offset is already defined in musb_dsps.c
 
 static const struct dsps_musb_wrapper am33xx_driver_data = {
 ...
   .mode   = 0xe8,
 ...
 };
 
 I can manually set this register to the correct value in musb_host.c and
 the USB all seems to work as expected.
 
 int musb_host_setup(struct musb *musb, int power_budget)
 {
   int ret;
   struct usb_hcd *hcd = musb-hcd;
 
 /* Force HOST mode */
 unsigned long __iomem *p;
 p = ioremap(0x474010e8, 4);
 *p = 0x80;/* IDDIG = 0, IDDIG_MUX = 1 */
 
   MUSB_HST_MODE(musb);
 ...
 };
 
 Ideally I'd like to add an entry in my dts file to flag for this force mode
 to be setup, such as:-
 
 usb@47401000 {
   status = okay;
   dr_mode = host;
   ti,force-host;  /* force host mode */
 };
 
 Can anyone point me in the right direction as to where to put this extra code 
 ?
 
 I see there's a musb_am335x.c file, but that just seems to be a wrapper.
 
 Any help would be greatly apperciated.

I just sent two patches to linux-usb and I suppose they can help. In
fact, I remember now that I have to fix commit log on one of them. I'll
do that now.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: OMAP build failure after this merge window - caused by usb or phy Kconfig krap

[Arend van Spriel]

On 11/25/2013 03:09 PM, Russell King - ARM Linux wrote:

which just illustrates why select in Kconfig is soo fscking bad that
it shouldn't be used.


The problem is that instinctively people assume that select is the 
opposite from depends. Unfortunately, it is not and it is a pitfall for 
many.


Gr. AvS

--
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: OMAP build failure after this merge window - caused by usb or phy Kconfig krap

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 02:09:27PM +, Russell King - ARM Linux wrote:
 There's no other way to say it, and I've no idea who is responsible for
 this:
 
   LD  init/built-in.o
 drivers/built-in.o: In function `omap_usb2_remove':
 powercap_sys.c:(.text+0x1c60): undefined reference to `usb_remove_phy'
 drivers/built-in.o: In function `omap_usb_power_off':
 powercap_sys.c:(.text+0x1c84): undefined reference to 
 `omap_control_usb_phy_power'
 drivers/built-in.o: In function `omap_usb_power_on':
 powercap_sys.c:(.text+0x1ca8): undefined reference to 
 `omap_control_usb_phy_power'
 drivers/built-in.o: In function `omap_usb2_probe':
 powercap_sys.c:(.text+0x1dac): undefined reference to 
 `omap_control_usb_phy_power'
 powercap_sys.c:(.text+0x1e5c): undefined reference to `usb_add_phy_dev'
 drivers/built-in.o: In function `omap_usb2_suspend':
 powercap_sys.c:(.text+0x1ec8): undefined reference to 
 `omap_control_usb_phy_power'
 powercap_sys.c:(.text+0x1f20): undefined reference to 
 `omap_control_usb_phy_power'
 drivers/built-in.o: In function `omap_usb2_set_comparator':
 powercap_sys.c:(.text+0x1f54): undefined reference to `usb_get_phy'
 arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys':
 dss-common.c:(.text+0xf824): undefined reference to `usb_bind_phy'
 make[1]: *** [vmlinux] Error 1
 make: *** [sub-make] Error 2

Kishon, can you send a patch fixing these ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: musb: Fix unstable init of OTG_INTERFSEL.

[Felipe Balbi]

Hi,

On Fri, Nov 22, 2013 at 10:37:49AM +0100, anaum...@ultratronik.de wrote:
 From: Andreas Naumann anaum...@ultratronik.de
 
 This is a hard to reproduce problem which leads to non-functional USB-OTG 
 port in 0.1%-1% of all boots.
 Tracked it down to commit e25bec160158abe86c276d7d206264afc3646281, which 
 introduces save/restore of OTG_INTERFSEL over suspend.
 Since the resume function is also called early in driver init, it uses a 
 non-initialized value (which is 0 and a non-supported setting in DM37xx for 
 INTERFSEL).
 Shortly after the correct value is set. Apparently this works most time, but 
 not always.
 
 The fix is to initialize the value, BEFORE being written in the resume 
 function.
 
 Signed-off-by: Andreas Naumann anaum...@ultratronik.de

please resend with linux-usb in Cc as well. Also make sure that your
lines (in commit log) aren't over 72 characters.

thanks

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Ивайло Димитров]

   Оригинално писмо 
 От:  Sebastian Reichel 
 Относно: Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for
 automode
 До: Ивайло Димитров 
 Изпратено на: Понеделник, 2013, Ноември 25 19:14:21 EET
 
 
 On Mon, Nov 25, 2013 at 07:01:54PM +0200, Ивайло Димитров wrote:
  Now.. Imagine phone left in car in charger (on sun). Likely
  temperature will reach high values, kernel is charging, dsme will
  reboot the system, but kernel will start charging again, dsme will
  reboot again, ...
 
  And it is not only high temperatures that are problem for li-ion
  charging; battery should not be fast charged below 5C and should not
  be charged below 0C. (Again, both are likely to happen if you leave
  your phone in car).
 
  AFAICT, we should simply disable charging below 5C or above 45C.
  
  AFAIK dsme will not restart it, but power it off, so the above
  scenario won't happen.
 
 Just assume what happens, when dsme does not start (e.g. system boot
 hangs).
 
 If everything is controlled from userspace, charger would not start
 (- safe!). If everything is controlled by the kernel, temperature
 safety checks are taken (- safe!). But in the currently proposed
 variant: No safety checks.
 
 -- Sebastian
 
 

Hmm, you have a point here :)

So, AIUI there are 2 options:

1. charger driver polls the battery driver every n (60?) seconds.
2. battery driver sends PSY_EVENT_PROP_CHANGED on every degree up or
down
 
In both cases if the temperature is outside of the safe margins, the
charging should be stopped.

2 seems more generic to me, but as rx51-battery is missing the
functionality to send events on temperature change, I guess 1 will
be easier to implement.

And I think there should be some method (sysfs entry?, /dev/bqxxx
opened?) to tell the charger driver to stop polling the battery 
driver once (and if) the userspace has started to take care of the 
battery temperature - makes no sense to duplicate the checks IMO.

--
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 2/3] bq2415x_charger: Use power_supply notifier for automode

[Pali Rohár]

On Monday 25 November 2013 16:18:39 Pavel Machek wrote:
 On Mon 2013-11-25 15:10:00, Pali Rohár wrote:
  On Monday 25 November 2013 15:01:27 Pavel Machek wrote:
   Where can I get dsme sources?
   
 Pavel
  
  dsme daemon: https://gitorious.org/community-ssu/dsme
  dsme thermal plugin:
  https://gitorious.org/rx51-bme-replacement/dsme-thermalobje
  ct-surface
  
  dsme thermal plugin is responsible for checking temperature
  of battery and send it to dsme damon. dsme daemon itself
  checking temperature limits and do something (e.g reboot
  device)
 
 Thanks for links!
 
 AFAICT dsme daemon does some kind of system management,
 not directly controlling charging, right? It does monitor
 system temperature.
 

Yes.

 Now.. Imagine phone left in car in charger (on sun). Likely
 temperature will reach high values, kernel is charging, dsme
 will reboot the system, but kernel will start charging again,
 dsme will reboot again, ...
 
 And it is not only high temperatures that are problem for
 li-ion charging; battery should not be fast charged below 5C
 and should not be charged below 0C. (Again, both are likely
 to happen if you leave your phone in car).
 
 AFAICT, we should simply disable charging below 5C or above
 45C.
 
   Pavel

Similar patch (as this) can be added to check for temperature 
from specified power supply driver (in timer reset thread). This 
can be easy and will fix this problem.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Michael Trimarchi]

Hi

On Sun, Nov 24, 2013 at 8:01 PM, Pali Rohár pali.ro...@gmail.com wrote:
 On Sunday 24 November 2013 18:18:03 Michael Trimarchi wrote:
 Hi

 On Tue, Nov 19, 2013 at 11:18 AM, Pali Rohár
 pali.ro...@gmail.com wrote:
  This patch removing set_mode_hook function from board data
  and replacing it with new string variable of notifier power
  supply device. After this change it is possible to add DT
  support because driver does not need specific board
  function anymore. Only static data and name of power supply
  device is required.
 
  Signed-off-by: Pali Rohár pali.ro...@gmail.com
  ---
 
   drivers/power/bq2415x_charger.c   |   77
   +
   include/linux/power/bq2415x_charger.h |   48
   +++- 2 files changed, 65 insertions(+), 60
   deletions(-)
 
 ...
 
  -   struct bq2415x_device *bq = data;
  +   struct bq2415x_device *bq =
  +   container_of(nb, struct bq2415x_device, nb);
  +   struct power_supply *psy = v;
  +   enum bq2415x_mode mode;
  +   union power_supply_propval prop;
  +   int ret;
  +   int mA;
 
  -   if (!bq)
  -   return;
  +   if (val != PSY_EVENT_PROP_CHANGED)
  +   return NOTIFY_OK;
  +
  +   if (strcmp(psy-name, bq-init_data.notify_device)
  != 0) +   return NOTIFY_OK;
  +
  +   dev_dbg(bq-dev, notifier call was called\n);
  +
  +   ret = psy-get_property(psy,
  POWER_SUPPLY_PROP_CURRENT_MAX, prop); +   if (ret !=
  0)
  +   return NOTIFY_OK;

 So you can read this value without any type of synchronization
 with the power_supply_core
 and sysfs implementation?


 Michael


 I do not see reason why I cannot use it. When isp1704 driver send
 PSY_EVENT_PROP_CHANGED then property
 POWER_SUPPLY_PROP_CURRENT_MAX is already updated and can be read
 by get_property function.


https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html

I found and equivalent scenario that I was trying to said

Michael


 --
 Pali Rohár
 pali.ro...@gmail.com
--
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/5] usb: musb: conditionally save and restore the context on suspend

[Daniel Mack]

It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.

The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 17 -
 include/linux/usb/musb.h |  3 +++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..a8ded57 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
 {
struct musb *musb = dev_to_musb(dev);
unsigned long   flags;
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
 
spin_lock_irqsave(musb-lock, flags);
 
@@ -2215,16 +2216,30 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   if (plat-restore_after_suspend)
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* The plaform data tells us about the necessity of saving and
+* restoring the context across a suspend cycle.
 */
+
+   if (plat-restore_after_suspend)
+   musb_restore_context(musb);
+
return 0;
 }
 
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..e5a581c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,9 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8  mode;
 
+   /* should the musb core restore registers after suspend? */
+   u8  restore_after_suspend:1;
+
/* for clk_get() */
const char  *clock;
 
-- 
1.8.4.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/5] musb/dsps: suspend related patches for 3.14 (rebased)

[Daniel Mack]

Hi Felipe,

These five patches for musb/dsps didn't make it into 3.13, which is no
big deal, at least as far as I'm concerned :)

I rebased the missing bits on top of 3.13-rc1. There are no functional
changes in comparison to what was posted earlier on this list.

Successfully tested on a AM33xx board.


Thanks,
Daniel


Daniel Mack (5):
  usb: musb: conditionally save and restore the context on suspend
  usb: musb: call musb_port_suspend from musb_bus_suspend
  usb: musb: dsps: add {tx,rx}_mode to wrapper
  usb: musb: dsps: add support for suspend and resume
  usb: musb: dsps: indentation and whitespace fixes

 drivers/usb/musb/musb_core.c| 17 +++-
 drivers/usb/musb/musb_core.h|  1 +
 drivers/usb/musb/musb_dsps.c| 86 +++--
 drivers/usb/musb/musb_host.c|  2 +
 drivers/usb/musb/musb_host.h|  4 ++
 drivers/usb/musb/musb_virthub.c |  4 +-
 include/linux/usb/musb.h|  3 ++
 7 files changed, 102 insertions(+), 15 deletions(-)

-- 
1.8.4.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 4/5] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

We also have to call musb_port_reset() for this platform upon resume, so
this function has to be made non-static.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.h|  1 +
 drivers/usb/musb/musb_dsps.c| 59 +
 drivers/usb/musb/musb_host.h|  2 ++
 drivers/usb/musb/musb_virthub.c |  2 +-
 4 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 29f7cd7..a423037 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -295,6 +295,7 @@ struct musb {
 
irqreturn_t (*isr)(int, void *);
struct work_struct  irq_work;
+
u16 hwvers;
 
u16 intrrxe;
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e57d712..361ddf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -506,6 +521,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+   pdata.restore_after_suspend = 1;
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
@@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   musb_port_reset(musb, false);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
 };
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index e660af9..7436c24 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
 extern void musb_port_suspend(struct musb *musb, bool do_suspend);
+extern void musb_port_reset(struct musb *musb, bool do_reset);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -123,6 +124,7 @@ static inline void musb_host_resume_root_hub(struct musb 
*musb) {}
 static inline void musb_host_poll_rh_status(struct 

[PATCH 3/5] usb: musb: dsps: add {tx,rx}_mode to wrapper

[Daniel Mack]

rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..e57d712 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.4.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 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..81caf9f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
 
 #include musb_core.h
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.4.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 5/5] usb: musb: dsps: indentation and whitespace fixes

[Daniel Mack]

Just a cosmetic thing, no functional change.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 361ddf8..b27c072 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -131,9 +131,9 @@ struct dsps_context {
 struct dsps_glue {
struct device *dev;
struct platform_device *musb;   /* child musb pdev */
-   const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
+   const struct dsps_musb_wrapper *wrp;/* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
-   unsigned long last_timer;/* last timer data for each instance */
+   unsigned long last_timer;   /* last timer data for each instance */
 
struct dsps_context context;
 };
@@ -213,7 +213,7 @@ static void dsps_musb_disable(struct musb *musb)
 
dsps_writel(reg_base, wrp-coreintr_clear, wrp-usb_bitmap);
dsps_writel(reg_base, wrp-epintr_clear,
-wrp-txep_bitmap | wrp-rxep_bitmap);
+   wrp-txep_bitmap | wrp-rxep_bitmap);
dsps_writeb(musb-mregs, MUSB_DEVCTL, 0);
 }
 
@@ -234,7 +234,7 @@ static void otg_timer(unsigned long _musb)
 */
devctl = dsps_readb(mregs, MUSB_DEVCTL);
dev_dbg(musb-controller, Poll devctl %02x (%s)\n, devctl,
-   usb_otg_state_string(musb-xceiv-state));
+   usb_otg_state_string(musb-xceiv-state));
 
spin_lock_irqsave(musb-lock, flags);
switch (musb-xceiv-state) {
@@ -298,7 +298,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
dsps_writel(reg_base, wrp-coreintr_status, usbintr);
 
dev_dbg(musb-controller, usbintr (%x) epintr(%x)\n,
-   usbintr, epintr);
+   usbintr, epintr);
/*
 * DRVVBUS IRQs are the only proxy we have (a very poor one!) for
 * DSPS IP's missing ID change IRQ.  We need an ID change IRQ to
@@ -348,10 +348,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
 
/* NOTE: this must complete power-on within 100 ms. */
dev_dbg(musb-controller, VBUS %s (%s)%s, devctl %02x\n,
-   drvvbus ? on : off,
-   usb_otg_state_string(musb-xceiv-state),
-   err ?  ERROR : ,
-   devctl);
+   drvvbus ? on : off,
+   usb_otg_state_string(musb-xceiv-state),
+   err ?  ERROR : , devctl);
ret = IRQ_HANDLED;
}
 
@@ -692,9 +691,9 @@ static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, 
dsps_resume);
 
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
-   .remove = dsps_remove,
-   .driver = {
-   .name   = musb-dsps,
+   .remove = dsps_remove,
+   .driver = {
+   .name   = musb-dsps,
.pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
-- 
1.8.4.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

Re: [PATCH 1/5] usb: musb: conditionally save and restore the context on suspend

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 08:39:49PM +0100, Daniel Mack wrote:
 It appears not all platforms featuring a musb core need to save the musb
 core registers at suspend time and restore them on resume.
 
 The dsps platform does, however. So add a bit in struct
 musb_hdrc_platform_data to let platforms specify their need of such
 action being taken.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.c | 17 -
  include/linux/usb/musb.h |  3 +++
  2 files changed, 19 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 0a43329..a8ded57 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
  {
   struct musb *musb = dev_to_musb(dev);
   unsigned long   flags;
 + struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);

we don't want to have platform_data on DT-based boot. It's best to just
save those registers unconditionally as it doesn't hurt.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Felipe Balbi]

On Mon, Nov 25, 2013 at 08:39:50PM +0100, Daniel Mack wrote:
 Make musb_port_suspend() externally available, and call it when to host
 goes into suspend. This allows the core to go into suspend while a
 device is connected.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_host.c| 2 ++
  drivers/usb/musb/musb_host.h| 2 ++
  drivers/usb/musb/musb_virthub.c | 2 +-
  3 files changed, 5 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
 index 6582a20..81caf9f 100644
 --- a/drivers/usb/musb/musb_host.c
 +++ b/drivers/usb/musb/musb_host.c
 @@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
   struct musb *musb = hcd_to_musb(hcd);
   u8  devctl;
  
 + musb_port_suspend(musb, true);

have you considered the fact that when musb looses context it'll cause a
disconnect on the bus because soft_connect bit is lost ?

What if you have a mounted file system on a pendrive ? Should we allow
suspend in that case ?

Alan, Greg, any hints ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 4/5] usb: musb: dsps: add support for suspend and resume

[Felipe Balbi]

On Mon, Nov 25, 2013 at 08:39:52PM +0100, Daniel Mack wrote:
 The dsps platform needs to save save some registers at suspend time and
 restore them after resume. This patch adds a struct for these registers,
 and also lets the musb core know that the core registers need to be
 saved as well.
 
 We also have to call musb_port_reset() for this platform upon resume, so
 this function has to be made non-static.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.h|  1 +
  drivers/usb/musb/musb_dsps.c| 59 
 +
  drivers/usb/musb/musb_host.h|  2 ++
  drivers/usb/musb/musb_virthub.c |  2 +-
  4 files changed, 63 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
 index 29f7cd7..a423037 100644
 --- a/drivers/usb/musb/musb_core.h
 +++ b/drivers/usb/musb/musb_core.h
 @@ -295,6 +295,7 @@ struct musb {
  
   irqreturn_t (*isr)(int, void *);
   struct work_struct  irq_work;
 +
   u16 hwvers;
  
   u16 intrrxe;
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index e57d712..361ddf8 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
   u8  poll_seconds;
  };
  
 +/*
 + * register shadow for suspend
 + */
 +struct dsps_context {
 + u32 control;
 + u32 epintr;
 + u32 coreintr;
 + u32 phy_utmi;
 + u32 mode;
 + u32 tx_mode;
 + u32 rx_mode;
 +};
 +
  /**
   * DSPS glue structure.
   */
 @@ -121,6 +134,8 @@ struct dsps_glue {
   const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
   struct timer_list timer;/* otg_workaround timer */
   unsigned long last_timer;/* last timer data for each instance */
 +
 + struct dsps_context context;
  };
  
  static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
 @@ -506,6 +521,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
   }
   pdata.config = config;
   pdata.platform_ops = dsps_ops;
 + pdata.restore_after_suspend = 1;
  
   config-num_eps = get_int_prop(dn, mentor,num-eps);
   config-ram_bits = get_int_prop(dn, mentor,ram-bits);
 @@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[] = 
 {
  };
  MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
  
 +#ifdef CONFIG_PM
 +static int dsps_suspend(struct device *dev)
 +{
 + struct dsps_glue *glue = dev_get_drvdata(dev);
 + const struct dsps_musb_wrapper *wrp = glue-wrp;
 + struct musb *musb = platform_get_drvdata(glue-musb);
 + void __iomem *mbase = musb-ctrl_base;
 +
 + glue-context.control = dsps_readl(mbase, wrp-control);
 + glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
 + glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
 + glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
 + glue-context.mode = dsps_readl(mbase, wrp-mode);
 + glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
 + glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
 +
 + return 0;
 +}
 +
 +static int dsps_resume(struct device *dev)
 +{
 + struct dsps_glue *glue = dev_get_drvdata(dev);
 + const struct dsps_musb_wrapper *wrp = glue-wrp;
 + struct musb *musb = platform_get_drvdata(glue-musb);
 + void __iomem *mbase = musb-ctrl_base;
 +
 + dsps_writel(mbase, wrp-control, glue-context.control);
 + dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
 + dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
 + dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
 + dsps_writel(mbase, wrp-mode, glue-context.mode);
 + dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
 + dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
 +
 + musb_port_reset(musb, false);
 +
 + return 0;
 +}
 +#endif
 +
 +static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
 +
  static struct platform_driver dsps_usbss_driver = {
   .probe  = dsps_probe,
   .remove = dsps_remove,
   .driver = {
   .name   = musb-dsps,
 + .pm = dsps_pm_ops,
   .of_match_table = musb_dsps_of_match,
   },
  };
 diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
 index e660af9..7436c24 100644
 --- a/drivers/usb/musb/musb_host.h
 +++ b/drivers/usb/musb/musb_host.h
 @@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
  extern void musb_host_resume_root_hub(struct musb *musb);
  extern void musb_host_poke_root_hub(struct musb *musb);
  extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 +extern void musb_port_reset(struct musb *musb, bool do_reset);
  #else
  static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
  {
 @@ -123,6 +124,7 @@ static inline void 

Re: [PATCH 5/5] usb: musb: dsps: indentation and whitespace fixes

[Felipe Balbi]

On Mon, Nov 25, 2013 at 08:39:53PM +0100, Daniel Mack wrote:
 Just a cosmetic thing, no functional change.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_dsps.c | 23 +++
  1 file changed, 11 insertions(+), 12 deletions(-)
 
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 361ddf8..b27c072 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -131,9 +131,9 @@ struct dsps_context {
  struct dsps_glue {
   struct device *dev;
   struct platform_device *musb;   /* child musb pdev */
 - const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
 + const struct dsps_musb_wrapper *wrp;/* wrapper register offsets */
   struct timer_list timer;/* otg_workaround timer */
 - unsigned long last_timer;/* last timer data for each instance */
 + unsigned long last_timer;   /* last timer data for each instance */
  
   struct dsps_context context;
  };
 @@ -213,7 +213,7 @@ static void dsps_musb_disable(struct musb *musb)
  
   dsps_writel(reg_base, wrp-coreintr_clear, wrp-usb_bitmap);
   dsps_writel(reg_base, wrp-epintr_clear,
 -  wrp-txep_bitmap | wrp-rxep_bitmap);
 + wrp-txep_bitmap | wrp-rxep_bitmap);

quite frankly, I don't what checkpatch.pl is trying to force here. I
much prefer a tab-only indentation, matching with ( characters forces us
to add some spaces. I would rather not take this patch.

-- 
balbi


signature.asc
Description: Digital signature

Re: HYP Kernel boot requirements

[Santosh Shilimkar]

On Monday 25 November 2013 12:28 PM, Catalin Marinas wrote:
 On Mon, Nov 25, 2013 at 04:59:16PM +, Santosh Shilimkar wrote:
 On Monday 25 November 2013 11:33 AM, Christoffer Dall wrote:
 On 25 November 2013 08:28, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core 
 */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read 
 from AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*

 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?

 Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build
 will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
 Right ?


 That really goes against the whole single binary on all platforms
 thing. With multi-platform support you really shouldn't have to
 compile your kernel any differently for running as a guest as when
 you're running on a host.  Someone may even emulate an OMAP5 in QEMU
 and you'd certainly want your kvm-enabled kernel to run as both guest
 and host.  After all, this is not a paravirtualization solution.

 Fair enough.

 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?

 Its not just booting but CPU hotplug also follows the same path
 so we need the mechanism in kernel to switch mode.

 In general, I think its important to consider the aspect with
 CPU PM. CPUs are not going to go through the boot-loaders in
 those paths and hence need of HYP entry in the kernel will
 be must.

 I agree, and PSCI is the obvious only correct answer to this.

 We have discussed this a bit earlier (I think Will Deacon brought this
 up - cc'ed), but I don't think anyone had any bright ideas.

 However, we broadly agreed on the fact that for KVM/hyp support, you
 need to boot your kernel in that mode, and this is definitely pulling
 in the wrong direction.

 What I am saying is the platforms like OMAP5 already support PM in
 mainline kernel and we can't break that for KVM. Boot-loaders
 would be thrashed after boot so you need something which runs
 in Kernel or along with Kernel to have equivalent of hyp
 switching.

 Am not challenging the agreed direction but we need to solve the
 PM problem as well before making all CPU runs boot-loader for
 HYP kernels as a must have. At least its is a change in boot
 strategy from existing kernels.
 
 Of course I recommend PSCI which covers both hotplug and suspend ;), but
 I guess it's not the case for OMAP5. Since OMAP has its own secondary
 booting protocol and CPU hotplug re-entry, can you not just use
 different entry point when the primary CPU was initially started in Hyp
 mode (e.g. omap5_hyp_secondary_startup)?
 
How will that solve the guest secondary boot failure case when using
the same kernel binary for guest-boot ? Even for primary CPU which
will be suspended it needs to resume already in HYP mode and its not
going to go through boot-loader. So the low power code needs to have
HYP switch code so that CPU resumes in HYP mode.

I will look at PSCI more closely and see what can be done here.

Regards,
Santosh



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

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

On 11/25/2013 08:46 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:50PM +0100, Daniel Mack wrote:
 Make musb_port_suspend() externally available, and call it when to host
 goes into suspend. This allows the core to go into suspend while a
 device is connected.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_host.c| 2 ++
  drivers/usb/musb/musb_host.h| 2 ++
  drivers/usb/musb/musb_virthub.c | 2 +-
  3 files changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
 index 6582a20..81caf9f 100644
 --- a/drivers/usb/musb/musb_host.c
 +++ b/drivers/usb/musb/musb_host.c
 @@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
  struct musb *musb = hcd_to_musb(hcd);
  u8  devctl;
  
 +musb_port_suspend(musb, true);
 
 have you considered the fact that when musb looses context it'll cause a
 disconnect on the bus because soft_connect bit is lost ?

 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?

Well, I would have expected that, but in fact, the opposite is true.
With 3.12, mounting a filesystem on a USB media and accessing it after
resume was exactly my test case, and it worked just fine with that patch.

In 3.13, something about the parition table reading seems to be broken
currently, I'll have a closer look.


Thanks,
Daniel

--
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 5/5] usb: musb: dsps: indentation and whitespace fixes

[Daniel Mack]

On 11/25/2013 08:49 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:53PM +0100, Daniel Mack wrote:
 Just a cosmetic thing, no functional change.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_dsps.c | 23 +++
  1 file changed, 11 insertions(+), 12 deletions(-)

 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 361ddf8..b27c072 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -131,9 +131,9 @@ struct dsps_context {
  struct dsps_glue {
  struct device *dev;
  struct platform_device *musb;   /* child musb pdev */
 -const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
 +const struct dsps_musb_wrapper *wrp;/* wrapper register offsets */
  struct timer_list timer;/* otg_workaround timer */
 -unsigned long last_timer;/* last timer data for each instance */
 +unsigned long last_timer;   /* last timer data for each instance */
  
  struct dsps_context context;
  };
 @@ -213,7 +213,7 @@ static void dsps_musb_disable(struct musb *musb)
  
  dsps_writel(reg_base, wrp-coreintr_clear, wrp-usb_bitmap);
  dsps_writel(reg_base, wrp-epintr_clear,
 - wrp-txep_bitmap | wrp-rxep_bitmap);
 +wrp-txep_bitmap | wrp-rxep_bitmap);
 
 quite frankly, I don't what checkpatch.pl is trying to force here. I
 much prefer a tab-only indentation, matching with ( characters forces us
 to add some spaces. I would rather not take this patch.
 

Alright, I really don't care much. I'll drop the patch when resending.

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

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 08:58:22PM +0100, Daniel Mack wrote:
 On 11/25/2013 08:46 PM, Felipe Balbi wrote:
  On Mon, Nov 25, 2013 at 08:39:50PM +0100, Daniel Mack wrote:
  Make musb_port_suspend() externally available, and call it when to host
  goes into suspend. This allows the core to go into suspend while a
  device is connected.
 
  Signed-off-by: Daniel Mack zon...@gmail.com
  ---
   drivers/usb/musb/musb_host.c| 2 ++
   drivers/usb/musb/musb_host.h| 2 ++
   drivers/usb/musb/musb_virthub.c | 2 +-
   3 files changed, 5 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
  index 6582a20..81caf9f 100644
  --- a/drivers/usb/musb/musb_host.c
  +++ b/drivers/usb/musb/musb_host.c
  @@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
 struct musb *musb = hcd_to_musb(hcd);
 u8  devctl;
   
  +  musb_port_suspend(musb, true);
  
  have you considered the fact that when musb looses context it'll cause a
  disconnect on the bus because soft_connect bit is lost ?
 
  What if you have a mounted file system on a pendrive ? Should we allow
  suspend in that case ?
 
 Well, I would have expected that, but in fact, the opposite is true.
 With 3.12, mounting a filesystem on a USB media and accessing it after
 resume was exactly my test case, and it worked just fine with that patch.

so you had a mounted file system, suspend, resume, it was still mounted?
or did it reenumerate and you remounted it ?

Try to do the same with transfers in flight, it's likely to corrupt your
file system.

 In 3.13, something about the parition table reading seems to be broken
 currently, I'll have a closer look.

cool

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 4/5] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

On 11/25/2013 08:48 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:52PM +0100, Daniel Mack wrote:
 The dsps platform needs to save save some registers at suspend time and
 restore them after resume. This patch adds a struct for these registers,
 and also lets the musb core know that the core registers need to be
 saved as well.

 We also have to call musb_port_reset() for this platform upon resume, so
 this function has to be made non-static.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.h|  1 +
  drivers/usb/musb/musb_dsps.c| 59 
 +
  drivers/usb/musb/musb_host.h|  2 ++
  drivers/usb/musb/musb_virthub.c |  2 +-
  4 files changed, 63 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
 index 29f7cd7..a423037 100644
 --- a/drivers/usb/musb/musb_core.h
 +++ b/drivers/usb/musb/musb_core.h
 @@ -295,6 +295,7 @@ struct musb {
  
  irqreturn_t (*isr)(int, void *);
  struct work_struct  irq_work;
 +
  u16 hwvers;
  
  u16 intrrxe;
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index e57d712..361ddf8 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
  u8  poll_seconds;
  };
  
 +/*
 + * register shadow for suspend
 + */
 +struct dsps_context {
 +u32 control;
 +u32 epintr;
 +u32 coreintr;
 +u32 phy_utmi;
 +u32 mode;
 +u32 tx_mode;
 +u32 rx_mode;
 +};
 +
  /**
   * DSPS glue structure.
   */
 @@ -121,6 +134,8 @@ struct dsps_glue {
  const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
  struct timer_list timer;/* otg_workaround timer */
  unsigned long last_timer;/* last timer data for each instance */
 +
 +struct dsps_context context;
  };
  
  static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
 @@ -506,6 +521,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
  }
  pdata.config = config;
  pdata.platform_ops = dsps_ops;
 +pdata.restore_after_suspend = 1;
  
  config-num_eps = get_int_prop(dn, mentor,num-eps);
  config-ram_bits = get_int_prop(dn, mentor,ram-bits);
 @@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[] 
 = {
  };
  MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
  
 +#ifdef CONFIG_PM
 +static int dsps_suspend(struct device *dev)
 +{
 +struct dsps_glue *glue = dev_get_drvdata(dev);
 +const struct dsps_musb_wrapper *wrp = glue-wrp;
 +struct musb *musb = platform_get_drvdata(glue-musb);
 +void __iomem *mbase = musb-ctrl_base;
 +
 +glue-context.control = dsps_readl(mbase, wrp-control);
 +glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
 +glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
 +glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
 +glue-context.mode = dsps_readl(mbase, wrp-mode);
 +glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
 +glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
 +
 +return 0;
 +}
 +
 +static int dsps_resume(struct device *dev)
 +{
 +struct dsps_glue *glue = dev_get_drvdata(dev);
 +const struct dsps_musb_wrapper *wrp = glue-wrp;
 +struct musb *musb = platform_get_drvdata(glue-musb);
 +void __iomem *mbase = musb-ctrl_base;
 +
 +dsps_writel(mbase, wrp-control, glue-context.control);
 +dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
 +dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
 +dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
 +dsps_writel(mbase, wrp-mode, glue-context.mode);
 +dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
 +dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
 +
 +musb_port_reset(musb, false);
 +
 +return 0;
 +}
 +#endif
 +
 +static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
 +
  static struct platform_driver dsps_usbss_driver = {
  .probe  = dsps_probe,
  .remove = dsps_remove,
  .driver = {
  .name   = musb-dsps,
 +.pm = dsps_pm_ops,
  .of_match_table = musb_dsps_of_match,
  },
  };
 diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
 index e660af9..7436c24 100644
 --- a/drivers/usb/musb/musb_host.h
 +++ b/drivers/usb/musb/musb_host.h
 @@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
  extern void musb_host_resume_root_hub(struct musb *musb);
  extern void musb_host_poke_root_hub(struct musb *musb);
  extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 +extern void musb_port_reset(struct musb *musb, bool do_reset);
  #else
  static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
  {
 @@ -123,6 +124,7 @@ static inline void 

Re: [PATCH 1/5] usb: musb: conditionally save and restore the context on suspend

[Daniel Mack]

On 11/25/2013 08:44 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 08:39:49PM +0100, Daniel Mack wrote:
 It appears not all platforms featuring a musb core need to save the musb
 core registers at suspend time and restore them on resume.

 The dsps platform does, however. So add a bit in struct
 musb_hdrc_platform_data to let platforms specify their need of such
 action being taken.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.c | 17 -
  include/linux/usb/musb.h |  3 +++
  2 files changed, 19 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 0a43329..a8ded57 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
  {
  struct musb *musb = dev_to_musb(dev);
  unsigned long   flags;
 +struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
 
 we don't want to have platform_data on DT-based boot. It's best to just
 save those registers unconditionally as it doesn't hurt.
 

My concern about doing it unconditionally from the core is simply that I
fear regressions for other platforms. I can of course drop it if you're
certain that that's correct.

I can only test this on a dsps glue layer, and I have no documentation
for the musb core. All I'm left with here is fishing in muddy waters :/


Daniel

--
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 4/5] usb: musb: dsps: add support for suspend and resume

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 09:04:16PM +0100, Daniel Mack wrote:
  diff --git a/drivers/usb/musb/musb_virthub.c 
  b/drivers/usb/musb/musb_virthub.c
  index e977441..24e46c0 100644
  --- a/drivers/usb/musb/musb_virthub.c
  +++ b/drivers/usb/musb/musb_virthub.c
  @@ -109,7 +109,7 @@ void musb_port_suspend(struct musb *musb, bool 
  do_suspend)
 }
   }
   
  -static void musb_port_reset(struct musb *musb, bool do_reset)
  +void musb_port_reset(struct musb *musb, bool do_reset)
  
  NAK, this should not be called from the glue layers at all. If anything
  call from musb_core's resume callback. That will only be called after
  parent's resume has been called anyway.
 
 Given that this driver is successfully used with suspend/resume on other
 platforms without that reset, but it's clearly needed for dsps, I'm
 fairly sure this should be a glue-layer specific thing. Hence the change.
 
 I think it'll break things on other platforms if we unconditionally
 reset the port after resume, but I can't test it. Anyone?

your original commit log only says we need to issue port reset but it
never explains why. It could very well be you just found a device which
needs to be reset when coming out of suspend and it misses a quirk flag ?

In any case, those functions should never be called by the glue, if
reset needs to be called, it must be called by musb-hdrc.ko, if you need
a flag, pass a flag but I need a really good explanation in your commit
log of why that's necessary.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] ARM: dts: Fix omap serial wake-up when booted with device tree

[Tony Lindgren]

We've had deeper idle states working on omaps for few years now,
but only in the legacy mode. When booted with device tree, the
wake-up events did not have a chance to work until commit
3e6cee1786a1 (pinctrl: single: Add support for wake-up interrupts)
that recently got merged. In addition to that we also needed commit
79d9701559a9 (of/irq: create interrupts-extended property) that's
now also merged.

So let's fix the wake-up events for some selected omaps so devices
booted in device tree mode won't just hang if deeper power states
are enabled, and so systems can wake up from suspend to the serial
port event.

Note that there's no longer need to specify the wake-up bit in
the pinctrl settings, the request_irq on the wake-up pin takes
care of that.

Cc: devicet...@vger.kernel.org
Cc: Benoît Cousson bcous...@baylibre.com
Signed-off-by: Tony Lindgren t...@atomide.com

---

FYI, this depends on the device resource populating patch posted in
thread [PATCH] of/platform: Fix no irq domain found errors when
populating interrupts to avoid intoducing nasty warnings.

--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -89,7 +89,16 @@
status = disabled;
 };
 
+uart1 {
+   interrupts-extended = intc 72 omap3_pmx_core OMAP3_UART1_RX;
+};
+
+uart2 {
+   interrupts-extended = intc 73 omap3_pmx_core OMAP3_UART2_RX;
+};
+
 uart3 {
+   interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX;
pinctrl-names = default;
pinctrl-0 = uart3_pins;
 };
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -495,11 +495,13 @@
 };
 
 uart2 {
+   interrupts-extended = intc 73 omap3_pmx_core OMAP3_UART2_RX;
pinctrl-names = default;
pinctrl-0 = uart2_pins;
 };
 
 uart3 {
+   interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX;
pinctrl-names = default;
pinctrl-0 = uart3_pins;
 };
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -207,7 +207,7 @@
uart1: serial@4806a000 {
compatible = ti,omap3-uart;
reg = 0x4806a000 0x2000;
-   interrupts = 72;
+   interrupts-extended = intc 72;
dmas = sdma 49 sdma 50;
dma-names = tx, rx;
ti,hwmods = uart1;
@@ -217,7 +217,7 @@
uart2: serial@4806c000 {
compatible = ti,omap3-uart;
reg = 0x4806c000 0x400;
-   interrupts = 73;
+   interrupts-extended = intc 73;
dmas = sdma 51 sdma 52;
dma-names = tx, rx;
ti,hwmods = uart2;
@@ -227,7 +227,7 @@
uart3: serial@4902 {
compatible = ti,omap3-uart;
reg = 0x4902 0x400;
-   interrupts = 74;
+   interrupts-extended = intc 74;
dmas = sdma 53 sdma 54;
dma-names = tx, rx;
ti,hwmods = uart3;
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -396,6 +396,21 @@
usb-supply = vusb;
 };
 
+uart2 {
+   interrupts-extended = gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH
+  omap4_pmx_core OMAP4_UART2_RX;
+};
+
+uart3 {
+   interrupts-extended = gic GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH
+  omap4_pmx_core OMAP4_UART3_RX;
+};
+
+uart4 {
+   interrupts-extended = gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH
+  omap4_pmx_core OMAP4_UART4_RX;
+};
+
 usb_otg_hs {
interface-type = 1;
mode = 3;
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -523,16 +523,22 @@
 };
 
 uart2 {
+   interrupts-extended = gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH
+  omap4_pmx_core OMAP4_UART2_RX;
pinctrl-names = default;
pinctrl-0 = uart2_pins;
 };
 
 uart3 {
+   interrupts-extended = gic GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH
+  omap4_pmx_core OMAP4_UART3_RX;
pinctrl-names = default;
pinctrl-0 = uart3_pins;
 };
 
 uart4 {
+   interrupts-extended = gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH
+  omap4_pmx_core OMAP4_UART4_RX;
pinctrl-names = default;
pinctrl-0 = uart4_pins;
 };
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -236,7 +236,7 @@
uart2: serial@4806c000 {
compatible = ti,omap4-uart;
reg = 0x4806c000 0x100;
-   interrupts = GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH;
+   interrupts-extended = gic GIC_SPI 73 
IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart2;

Re: [PATCH 1/5] usb: musb: conditionally save and restore the context on suspend

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 09:08:51PM +0100, Daniel Mack wrote:
 On 11/25/2013 08:44 PM, Felipe Balbi wrote:
  Hi,
  
  On Mon, Nov 25, 2013 at 08:39:49PM +0100, Daniel Mack wrote:
  It appears not all platforms featuring a musb core need to save the musb
  core registers at suspend time and restore them on resume.
 
  The dsps platform does, however. So add a bit in struct
  musb_hdrc_platform_data to let platforms specify their need of such
  action being taken.
 
  Signed-off-by: Daniel Mack zon...@gmail.com
  ---
   drivers/usb/musb/musb_core.c | 17 -
   include/linux/usb/musb.h |  3 +++
   2 files changed, 19 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
  index 0a43329..a8ded57 100644
  --- a/drivers/usb/musb/musb_core.c
  +++ b/drivers/usb/musb/musb_core.c
  @@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
   {
 struct musb *musb = dev_to_musb(dev);
 unsigned long   flags;
  +  struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
  
  we don't want to have platform_data on DT-based boot. It's best to just
  save those registers unconditionally as it doesn't hurt.
  
 
 My concern about doing it unconditionally from the core is simply that I
 fear regressions for other platforms. I can of course drop it if you're
 certain that that's correct.
 
 I can only test this on a dsps glue layer, and I have no documentation
 for the musb core. All I'm left with here is fishing in muddy waters :/

I really don't think it should cause any issues with any other platform.

We can make to leave this soaking in linux-next for a long time and hope
people test it.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

On 11/25/2013 09:01 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 08:58:22PM +0100, Daniel Mack wrote:
 On 11/25/2013 08:46 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:50PM +0100, Daniel Mack wrote:
 Make musb_port_suspend() externally available, and call it when to host
 goes into suspend. This allows the core to go into suspend while a
 device is connected.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_host.c| 2 ++
  drivers/usb/musb/musb_host.h| 2 ++
  drivers/usb/musb/musb_virthub.c | 2 +-
  3 files changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
 index 6582a20..81caf9f 100644
 --- a/drivers/usb/musb/musb_host.c
 +++ b/drivers/usb/musb/musb_host.c
 @@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
  
 +  musb_port_suspend(musb, true);

 have you considered the fact that when musb looses context it'll cause a
 disconnect on the bus because soft_connect bit is lost ?

 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?

 Well, I would have expected that, but in fact, the opposite is true.
 With 3.12, mounting a filesystem on a USB media and accessing it after
 resume was exactly my test case, and it worked just fine with that patch.
 
 so you had a mounted file system, suspend, resume, it was still mounted?

Yes, exactly.

 or did it reenumerate and you remounted it ?

No, it did not reenumerate, but the core did a reset on it. See the
following log.

# mount /dev/sda /mnt
# md5sum /mnt/sine_left.wav
bcd90548c1ebf293289072f1a6161f0f  /mnt/sine_left.wav
#
#
# echo mem  /sys/power/state
[   31.553425] PM: Syncing filesystems ... done.
[   31.575462] Freezing user space processes ... (elapsed 0.002 seconds)
done.
[   31.585275] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[   31.595953] PM: Sending message for entering DeepSleep mode
[   31.628887] PM: suspend of devices complete after 21.097 msecs
[   31.641082] PM: late suspend of devices complete after 5.906 msecs
[   31.653834] PM: noirq suspend of devices complete after 6.135 msecs
[   31.660558] PM: GFX domain entered low power state
[   31.660558] PM: Successfully put all powerdomains to target state
[   31.660558] PM: Wakeup source GPIO0
[   31.679130] PM: noirq resume of devices complete after 17.941 msecs
[   31.693371] PM: early resume of devices complete after 4.388 msecs
[   31.702750] net eth0: initializing cpsw version 1.12 (0)
[   31.712084] net eth0: phy found : id is : 0x4dd076
[   31.717317] libphy: PHY  not found
[   31.722448] net eth0: phy  not found on slave 1
[   32.030792] usb 1-1: reset high-speed USB device number 2 using
musb-hdrc  !
[   32.395192] PM: resume of devices complete after 695.279 msecs
[   32.407816] PM: Sending message for resetting M3 state machine
[   32.414683] Restarting tasks ... done.
[   36.701568] libphy: 4a101000.mdio:04 - Link is Up - 100/Full
#
#
# md5sum /mnt/sine_left.wav
bcd90548c1ebf293289072f1a6161f0f  /mnt/sine_left.wav

 Try to do the same with transfers in flight, it's likely to corrupt your
 file system.

I did that as well, and it appeared stable to me. After all, the USB
device was properly put into suspend before VBUS went away, and the usb
storage driver caught up after the core's reset.

In my tests, this was the only approach that would work after resume.



Daniel

--
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 4/5] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

On 11/25/2013 09:08 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 09:04:16PM +0100, Daniel Mack wrote:
 diff --git a/drivers/usb/musb/musb_virthub.c 
 b/drivers/usb/musb/musb_virthub.c
 index e977441..24e46c0 100644
 --- a/drivers/usb/musb/musb_virthub.c
 +++ b/drivers/usb/musb/musb_virthub.c
 @@ -109,7 +109,7 @@ void musb_port_suspend(struct musb *musb, bool 
 do_suspend)
}
  }
  
 -static void musb_port_reset(struct musb *musb, bool do_reset)
 +void musb_port_reset(struct musb *musb, bool do_reset)

 NAK, this should not be called from the glue layers at all. If anything
 call from musb_core's resume callback. That will only be called after
 parent's resume has been called anyway.

 Given that this driver is successfully used with suspend/resume on other
 platforms without that reset, but it's clearly needed for dsps, I'm
 fairly sure this should be a glue-layer specific thing. Hence the change.

 I think it'll break things on other platforms if we unconditionally
 reset the port after resume, but I can't test it. Anyone?
 
 your original commit log only says we need to issue port reset but it
 never explains why. It could very well be you just found a device which
 needs to be reset when coming out of suspend and it misses a quirk flag ?

I think I can really rule that out, as I tested with multiple USB sticks
and also tested the same sticks on other embedded platforms.

 In any case, those functions should never be called by the glue, if
 reset needs to be called, it must be called by musb-hdrc.ko, if you need
 a flag, pass a flag but I need a really good explanation in your commit
 log of why that's necessary.

Well, if I'd only knew exactly why. All these patches are really the
result of many days of trial and error, with multiple drivers (musb,
cppi41, ...) involved. And as I said - I have no documentation of the
musb core itself.

So yes, I can do it the other way around and pass a flag, but what I
can't provide is a good explanantion why the dsps glue behaves
differently here than others. I'm curious myself, and all I know is that
with this reset in place, things work as expected on AM33xx.


Thanks for your feedback,
Daniel

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

Re: [PATCH 1/5] usb: musb: conditionally save and restore the context on suspend

[Daniel Mack]

On 11/25/2013 09:13 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 09:08:51PM +0100, Daniel Mack wrote:
 On 11/25/2013 08:44 PM, Felipe Balbi wrote:
 Hi,

 On Mon, Nov 25, 2013 at 08:39:49PM +0100, Daniel Mack wrote:
 It appears not all platforms featuring a musb core need to save the musb
 core registers at suspend time and restore them on resume.

 The dsps platform does, however. So add a bit in struct
 musb_hdrc_platform_data to let platforms specify their need of such
 action being taken.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.c | 17 -
  include/linux/usb/musb.h |  3 +++
  2 files changed, 19 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 0a43329..a8ded57 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
  {
struct musb *musb = dev_to_musb(dev);
unsigned long   flags;
 +  struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);

 we don't want to have platform_data on DT-based boot. It's best to just
 save those registers unconditionally as it doesn't hurt.


 My concern about doing it unconditionally from the core is simply that I
 fear regressions for other platforms. I can of course drop it if you're
 certain that that's correct.

 I can only test this on a dsps glue layer, and I have no documentation
 for the musb core. All I'm left with here is fishing in muddy waters :/
 
 I really don't think it should cause any issues with any other platform.
 
 We can make to leave this soaking in linux-next for a long time and hope
 people test it.
 

Ok, sounds good. I'll do it and repost, along with the other changes.


Many thanks,
Daniel


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

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Alan Stern]

On Mon, 25 Nov 2013, Felipe Balbi wrote:

 On Mon, Nov 25, 2013 at 08:39:50PM +0100, Daniel Mack wrote:
  Make musb_port_suspend() externally available, and call it when to host
  goes into suspend. This allows the core to go into suspend while a
  device is connected.

 have you considered the fact that when musb looses context it'll cause a
 disconnect on the bus because soft_connect bit is lost ?
 
 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?
 
 Alan, Greg, any hints ?

An HCD should strive to avoid losing power sessions over a
suspend/resume.  But if this is unavoidable, the USB Persist mechanism
should be able to cope by issuing a reset-resume.  (Unless userspace
has turned Persist off, of course -- I believe some distributions do
this.  Chrome?)

Alan Stern

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

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Alan Stern]

On Mon, 25 Nov 2013, Daniel Mack wrote:

  What if you have a mounted file system on a pendrive ? Should we allow
  suspend in that case ?
 
  Well, I would have expected that, but in fact, the opposite is true.
  With 3.12, mounting a filesystem on a USB media and accessing it after
  resume was exactly my test case, and it worked just fine with that patch.
  
  so you had a mounted file system, suspend, resume, it was still mounted?
 
 Yes, exactly.
 
  or did it reenumerate and you remounted it ?
 
 No, it did not reenumerate, but the core did a reset on it. See the
 following log.

...
 [   32.030792] usb 1-1: reset high-speed USB device number 2 using
 musb-hdrc  !

Like I said, you get a reset-resume.

  Try to do the same with transfers in flight, it's likely to corrupt your
  file system.

It's not so easy to suspend a system with USB mass-storage transfers in 
flight.  For one thing, userspace gets frozen before the suspend 
starts, so there's nothing to initiate new I/O requests (except perhaps 
for dirty-block writebacks).

Also, the child SCSI device gets suspended before the USB device, so
its I/O queue stops running.  In addition, the usb-storage suspend
routine and the main I/O thread are mutually exclusive (they both grab
the private mutex), so a suspend can't occur while a SCSI command is
underway.

Alan Stern

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

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

On 11/25/2013 09:41 PM, Alan Stern wrote:
 On Mon, 25 Nov 2013, Daniel Mack wrote:
 
 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?

 Well, I would have expected that, but in fact, the opposite is true.
 With 3.12, mounting a filesystem on a USB media and accessing it after
 resume was exactly my test case, and it worked just fine with that patch.

 so you had a mounted file system, suspend, resume, it was still mounted?

 Yes, exactly.

 or did it reenumerate and you remounted it ?

 No, it did not reenumerate, but the core did a reset on it. See the
 following log.
 
 ...
 [   32.030792] usb 1-1: reset high-speed USB device number 2 using
 musb-hdrc  !
 
 Like I said, you get a reset-resume.

Yup. We can't avoid losing VBUS on this platform, and even if we could,
we wouldn't want that, in order to save as much power as possible.

 Try to do the same with transfers in flight, it's likely to corrupt your
 file system.
 
 It's not so easy to suspend a system with USB mass-storage transfers in 
 flight.  For one thing, userspace gets frozen before the suspend 
 starts, so there's nothing to initiate new I/O requests (except perhaps 
 for dirty-block writebacks).
 
 Also, the child SCSI device gets suspended before the USB device, so
 its I/O queue stops running.  In addition, the usb-storage suspend
 routine and the main I/O thread are mutually exclusive (they both grab
 the private mutex), so a suspend can't occur while a SCSI command is
 underway.

Thanks Alan for the explanation. That was my understanding as well.


Best regards,
Daniel

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

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 03:41:14PM -0500, Alan Stern wrote:
 On Mon, 25 Nov 2013, Daniel Mack wrote:
 
   What if you have a mounted file system on a pendrive ? Should we allow
   suspend in that case ?
  
   Well, I would have expected that, but in fact, the opposite is true.
   With 3.12, mounting a filesystem on a USB media and accessing it after
   resume was exactly my test case, and it worked just fine with that patch.
   
   so you had a mounted file system, suspend, resume, it was still mounted?
  
  Yes, exactly.
  
   or did it reenumerate and you remounted it ?
  
  No, it did not reenumerate, but the core did a reset on it. See the
  following log.
 
 ...
  [   32.030792] usb 1-1: reset high-speed USB device number 2 using
  musb-hdrc  !
 
 Like I said, you get a reset-resume.
 
   Try to do the same with transfers in flight, it's likely to corrupt your
   file system.
 
 It's not so easy to suspend a system with USB mass-storage transfers in 
 flight.  For one thing, userspace gets frozen before the suspend 
 starts, so there's nothing to initiate new I/O requests (except perhaps 
 for dirty-block writebacks).
 
 Also, the child SCSI device gets suspended before the USB device, so
 its I/O queue stops running.  In addition, the usb-storage suspend
 routine and the main I/O thread are mutually exclusive (they both grab
 the private mutex), so a suspend can't occur while a SCSI command is
 underway.

awesome, thanks for the explanation Alan :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

On 11/25/2013 09:01 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:58:22PM +0100, Daniel Mack wrote:

 In 3.13, something about the parition table reading seems to be broken
 currently, I'll have a closer look.
 
 cool

Ah, and forget about this one. I didn't look close enough. There's no
such issue in 3.13. Sorry for the noise.




--
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 4/5] usb: musb: dsps: add support for suspend and resume

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 09:26:55PM +0100, Daniel Mack wrote:
 On 11/25/2013 09:08 PM, Felipe Balbi wrote:
  On Mon, Nov 25, 2013 at 09:04:16PM +0100, Daniel Mack wrote:
  diff --git a/drivers/usb/musb/musb_virthub.c 
  b/drivers/usb/musb/musb_virthub.c
  index e977441..24e46c0 100644
  --- a/drivers/usb/musb/musb_virthub.c
  +++ b/drivers/usb/musb/musb_virthub.c
  @@ -109,7 +109,7 @@ void musb_port_suspend(struct musb *musb, bool 
  do_suspend)
   }
   }
   
  -static void musb_port_reset(struct musb *musb, bool do_reset)
  +void musb_port_reset(struct musb *musb, bool do_reset)
 
  NAK, this should not be called from the glue layers at all. If anything
  call from musb_core's resume callback. That will only be called after
  parent's resume has been called anyway.
 
  Given that this driver is successfully used with suspend/resume on other
  platforms without that reset, but it's clearly needed for dsps, I'm
  fairly sure this should be a glue-layer specific thing. Hence the change.
 
  I think it'll break things on other platforms if we unconditionally
  reset the port after resume, but I can't test it. Anyone?
  
  your original commit log only says we need to issue port reset but it
  never explains why. It could very well be you just found a device which
  needs to be reset when coming out of suspend and it misses a quirk flag ?
 
 I think I can really rule that out, as I tested with multiple USB sticks
 and also tested the same sticks on other embedded platforms.
 
  In any case, those functions should never be called by the glue, if
  reset needs to be called, it must be called by musb-hdrc.ko, if you need
  a flag, pass a flag but I need a really good explanation in your commit
  log of why that's necessary.
 
 Well, if I'd only knew exactly why. All these patches are really the
 result of many days of trial and error, with multiple drivers (musb,
 cppi41, ...) involved. And as I said - I have no documentation of the
 musb core itself.
 
 So yes, I can do it the other way around and pass a flag, but what I
 can't provide is a good explanantion why the dsps glue behaves
 differently here than others. I'm curious myself, and all I know is that
 with this reset in place, things work as expected on AM33xx.

ok, then let's pass a flag. Meanwhile I'll try to figure out internally
why we need that reset. As Alan said, usb-persist should already for a
bus-reset when resuming, right ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Felipe Balbi]

On Mon, Nov 25, 2013 at 09:47:16PM +0100, Daniel Mack wrote:
 On 11/25/2013 09:01 PM, Felipe Balbi wrote:
  On Mon, Nov 25, 2013 at 08:58:22PM +0100, Daniel Mack wrote:
 
  In 3.13, something about the parition table reading seems to be broken
  currently, I'll have a closer look.
  
  cool
 
 Ah, and forget about this one. I didn't look close enough. There's no
 such issue in 3.13. Sorry for the noise.

no problem :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 4/5] usb: musb: dsps: add support for suspend and resume

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 09:54:56PM +0100, Daniel Mack wrote:
  As Alan said, usb-persist should already for a
  bus-reset when resuming, right ?
 
 The explicit un-reset is really needed, otherwise the port will
 reenumerate the device, and a previously mounted filesystem will become
 invalid of course. The log looks like this in that case:
 
 [   17.045641] PM: resume of devices complete after 166.084 msecs
 [   17.056461] PM: Sending message for resetting M3 state machine
 [   17.063451] Restarting tasks ... [   17.071767] usb 1-1: USB
 disconnect, device number 2
 done.
 [   17.403402] usb 1-1: new high-speed USB device number 3 using musb-hdrc
 [   17.766959] usb 1-1: New USB device found, idVendor=058f, idProduct=6387
 [   17.774849] usb 1-1: New USB device strings: Mfr=1, Product=2,
 SerialNumber=3

got it now ;-) Thanks

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 4/5] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

On 11/25/2013 09:46 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 09:26:55PM +0100, Daniel Mack wrote:
 On 11/25/2013 09:08 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 09:04:16PM +0100, Daniel Mack wrote:
 diff --git a/drivers/usb/musb/musb_virthub.c 
 b/drivers/usb/musb/musb_virthub.c
 index e977441..24e46c0 100644
 --- a/drivers/usb/musb/musb_virthub.c
 +++ b/drivers/usb/musb/musb_virthub.c
 @@ -109,7 +109,7 @@ void musb_port_suspend(struct musb *musb, bool 
 do_suspend)
  }
  }
  
 -static void musb_port_reset(struct musb *musb, bool do_reset)
 +void musb_port_reset(struct musb *musb, bool do_reset)

 NAK, this should not be called from the glue layers at all. If anything
 call from musb_core's resume callback. That will only be called after
 parent's resume has been called anyway.

 Given that this driver is successfully used with suspend/resume on other
 platforms without that reset, but it's clearly needed for dsps, I'm
 fairly sure this should be a glue-layer specific thing. Hence the change.

 I think it'll break things on other platforms if we unconditionally
 reset the port after resume, but I can't test it. Anyone?

 your original commit log only says we need to issue port reset but it
 never explains why. It could very well be you just found a device which
 needs to be reset when coming out of suspend and it misses a quirk flag ?

 I think I can really rule that out, as I tested with multiple USB sticks
 and also tested the same sticks on other embedded platforms.

 In any case, those functions should never be called by the glue, if
 reset needs to be called, it must be called by musb-hdrc.ko, if you need
 a flag, pass a flag but I need a really good explanation in your commit
 log of why that's necessary.

 Well, if I'd only knew exactly why. All these patches are really the
 result of many days of trial and error, with multiple drivers (musb,
 cppi41, ...) involved. And as I said - I have no documentation of the
 musb core itself.

 So yes, I can do it the other way around and pass a flag, but what I
 can't provide is a good explanantion why the dsps glue behaves
 differently here than others. I'm curious myself, and all I know is that
 with this reset in place, things work as expected on AM33xx.
 
 ok, then let's pass a flag. Meanwhile I'll try to figure out internally
 why we need that reset.

Well, we don't need a reset, I wasn't quite precise here. What we need
is to manually *de*assert the reset when we resume. Note the 'false'
flag that is passed to musb_port_reset().

 As Alan said, usb-persist should already for a
 bus-reset when resuming, right ?

The explicit un-reset is really needed, otherwise the port will
reenumerate the device, and a previously mounted filesystem will become
invalid of course. The log looks like this in that case:

[   17.045641] PM: resume of devices complete after 166.084 msecs
[   17.056461] PM: Sending message for resetting M3 state machine
[   17.063451] Restarting tasks ... [   17.071767] usb 1-1: USB
disconnect, device number 2
done.
[   17.403402] usb 1-1: new high-speed USB device number 3 using musb-hdrc
[   17.766959] usb 1-1: New USB device found, idVendor=058f, idProduct=6387
[   17.774849] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3



Thanks,
Daniel

--
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: ARM: v3.13-rc1: USB regression

[Aaro Koskinen]

Hi,

On Mon, Nov 25, 2013 at 05:18:53PM +, Russell King - ARM Linux wrote:
 On Mon, Nov 25, 2013 at 06:33:02PM +0200, Aaro Koskinen wrote:
  Hi,
  
  On Sun, Nov 24, 2013 at 10:43:59PM +, Russell King - ARM Linux wrote:
   On Mon, Nov 25, 2013 at 12:22:47AM +0200, Aaro Koskinen wrote:
[   33.967324] ohci ohci: Coherent DMA mask 0x (pfn 
0xe-0xe) covers a smaller range of system memory than the DMA 
zone pfn 0x0-0x10

I bisected this to 4dcfa60071b3d23f0181f27d8519f12e37cefbb9 (ARM: 
DMA-API:
better handing of DMA masks for coherent allocations). Reverting that
commit makes the USB work again fine.
  
  [...]
  
   Better would be:
   
   #define __arch_dma_to_pfn(dev, addr)  \
 ({ unsigned long pfn = (addr)  PAGE_SHIFT;\
if (is_lbus_device(dev)) \
 pfn += PHYS_PFN_OFFSET -\
 (OMAP1510_LB_OFFSET  PAGE_SHIFT); \
pfn; \
 })
   
   Can you try that in arch/arm/mach-omap1/include/mach/memory.h please?
  
  Still doesn't work:
  
  [   33.878790] ohci ohci: Coherent DMA mask 0x (pfn 
  0xfffe-0xe) covers a smaller range of system memory than the DMA 
  zone pfn 0x0-0x10
  [   33.894019] ohci ohci: can't setup: -12
 
 Well, that looks technically better, rather unfortunate that we end up
 going to negative PFNs though.
 
 Without that change, could you try this instead please:

This works, thanks.

A.

  arch/arm/mm/dma-mapping.c |9 +++--
  1 files changed, 7 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
 index f0ea0134e5a3..a18cfc53f445 100644
 --- a/arch/arm/mm/dma-mapping.c
 +++ b/arch/arm/mm/dma-mapping.c
 @@ -9,6 +9,7 @@
   *
   *  DMA uncached mapping support.
   */
 +#include linux/bootmem.h
  #include linux/module.h
  #include linux/mm.h
  #include linux/gfp.h
 @@ -162,6 +163,8 @@ static u64 get_coherent_dma_mask(struct device *dev)
   u64 mask = (u64)DMA_BIT_MASK(32);
  
   if (dev) {
 + unsigned long max_dma_pfn;
 +
   mask = dev-coherent_dma_mask;
  
   /*
 @@ -173,6 +176,8 @@ static u64 get_coherent_dma_mask(struct device *dev)
   return 0;
   }
  
 + max_dma_pfn = min(max_pfn, arm_dma_pfn_limit);
 +
   /*
* If the mask allows for more memory than we can address,
* and we actually have that much memory, then fail the
 @@ -180,7 +185,7 @@ static u64 get_coherent_dma_mask(struct device *dev)
*/
   if (sizeof(mask) != sizeof(dma_addr_t) 
   mask  (dma_addr_t)~0 
 - dma_to_pfn(dev, ~0)  arm_dma_pfn_limit) {
 + dma_to_pfn(dev, ~0)  max_dma_pfn) {
   dev_warn(dev, Coherent DMA mask %#llx is larger than 
 dma_addr_t allows\n,
mask);
   dev_warn(dev, Driver did not use or check the return 
 value from dma_set_coherent_mask()?\n);
 @@ -192,7 +197,7 @@ static u64 get_coherent_dma_mask(struct device *dev)
* fits within the allowable addresses which we can
* allocate.
*/
 - if (dma_to_pfn(dev, mask)  arm_dma_pfn_limit) {
 + if (dma_to_pfn(dev, mask)  max_dma_pfn) {
   dev_warn(dev, Coherent DMA mask %#llx (pfn %#lx-%#lx) 
 covers a smaller range of system memory than the DMA zone pfn 0x0-%#lx\n,
mask,
dma_to_pfn(dev, 0), dma_to_pfn(dev, mask) + 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 v3 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY

[Felipe Balbi]

On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote:
 There can be systems which does not have an external phy, so get
 phy only if no quirks are added that indicates the PHY is not present.
 Introduced two quirk flags to indicate the *absence* of usb2 phy and
 usb3 phy. Also remove checking if return value is -ENXIO since it's now
 changed to always enable usb_phy layer.
 
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  drivers/usb/dwc3/Kconfig |1 +
  drivers/usb/dwc3/core.c  |   93 
 --
  drivers/usb/dwc3/core.h  |   15 ++
  drivers/usb/dwc3/platform_data.h |5 ++
  4 files changed, 69 insertions(+), 45 deletions(-)
 
 diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
 index 70fc430..8e385b4 100644
 --- a/drivers/usb/dwc3/Kconfig
 +++ b/drivers/usb/dwc3/Kconfig
 @@ -1,6 +1,7 @@
  config USB_DWC3
   tristate DesignWare USB3 DRD Core Support
   depends on (USB || USB_GADGET)  HAS_DMA
 + select USB_PHY

no more selects, we've already had too many problems caused by bogus
usage of select.

 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index 986674f..f20f4a1 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
 @@ -32,6 +32,7 @@
  #include linux/delay.h
  #include linux/dma-mapping.h
  #include linux/of.h
 +#include linux/of_device.h
  
  #include linux/usb/ch9.h
  #include linux/usb/gadget.h
 @@ -351,13 +352,28 @@ static void dwc3_core_exit(struct dwc3 *dwc)
  
  #define DWC3_ALIGN_MASK  (16 - 1)
  
 +#ifdef CONFIG_OF
 +static const struct of_device_id of_dwc3_match[] = {
 + {
 + .compatible = snps,dwc3
 + },
 + {
 + .compatible = synopsys,dwc3
 + },
 + { },
 +};
 +MODULE_DEVICE_TABLE(of, of_dwc3_match);
 +#endif
 +

you can split this patch a little bit just to make it easier to review
because there are a few changes which are really obvious:

a) move of_device_id higher in source code so you can use it from probe.
while at that, aso use of_match_device() and return early if it
doesn't match anything.

b) introduce struct dwc3_data.

c) initialize of_id-data field.

d) start using struct dwc3_data

this will make to put all obvious changes (a-c) in separate patches so
review can focus on (d).

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] Allow MUSB DSPS to use force host mode

[Felipe Balbi]

Hi,

On Fri, Nov 22, 2013 at 03:55:59PM +, Mark Jackson wrote:
 The IDDIG input pin is normally used to determine the USB mode
 (i.e. HOST or DEVICE).
 
 On some systems (e.g. AM335x) leaving this pin floating allows
 the USB mode to be set via software.
 
 This patch adds support for this via the device tree.
 
 Signed-off-by: Mark Jackson m...@newflow.co.uk
 ---
  .../devicetree/bindings/usb/am33xx-usb.txt |2 ++
  drivers/usb/musb/musb_dsps.c   |   14 ++
  include/linux/usb/musb.h   |1 +
  3 files changed, 17 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
 b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
 index 20c2ff2..560b7ff 100644
 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
 +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
 @@ -47,6 +47,8 @@ USB
  - dmas: specifies the dma channels
  - dma-names: specifies the names of the channels. Use rxN for receive
and txN for transmit endpoints. N specifies the endpoint number.
 +- ti,force-host: specifies that the IDDIG input be ignored and the device be
 +  put into host mode regardless.
  
  The controller should have an usb alias numbered properly in the alias
  node.
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 1901f6f..6439809 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -105,6 +105,7 @@ struct dsps_musb_wrapper {
   unsignedotg_disable:5;
  
   /* bit positions for mode */
 + unsignediddig_mux:5;
   unsignediddig:5;
   /* miscellaneous stuff */
   u8  poll_seconds;
 @@ -387,6 +388,15 @@ static int dsps_musb_init(struct musb *musb)
  
   musb-isr = dsps_interrupt;
  
 + /* Force host mode, rather than relying on IDDIG input */
 + if (musb-config-force_host) {
 + val = dsps_readl(reg_base, wrp-mode);
 + /* clear IDDIG bit, set IDDIG_MUX bit */
 + val = ~(1  wrp-iddig);
 + val |= (1  wrp-iddig_mux);
 + dsps_writel(musb-ctrl_base, wrp-mode, val);
 + }
 +
   /* reset the otgdisable bit, needed for host mode to work */
   val = dsps_readl(reg_base, wrp-phy_utmi);
   val = ~(1  wrp-otg_disable);
 @@ -512,6 +522,9 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
   pdata.power = get_int_prop(dn, mentor,power) / 2;
   config-multipoint = of_property_read_bool(dn, mentor,multipoint);
  
 + if (of_property_read_bool(dn, ti,force-host))
 + config-force_host = true;
 +
   ret = platform_device_add_data(musb, pdata, sizeof(pdata));
   if (ret) {
   dev_err(dev, failed to add platform_data\n);
 @@ -607,6 +620,7 @@ static const struct dsps_musb_wrapper am33xx_driver_data 
 = {
   .mode   = 0xe8,
   .reset  = 0,
   .otg_disable= 21,
 + .iddig_mux  = 7,

I recently sent a patch to make this work, I'm attaching it here in case
it didn't reach mailing list.

-- 
balbi
From 5edc4b78bbfdc5fcff2cba46c7dbeebd2efddb76 Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Tue, 29 Oct 2013 12:17:16 -0500
Subject: [PATCH 1/2] usb: musb: dsps: implement -set_mode()

this will let us support broken designs such
as AM335x EVM SK where ID pin isn't routed
anywhere on a host port.

With this we can toggle internal IDDIG signal
and make sure MUSB goes into host mode as
necessary.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/musb/musb_dsps.c | 51 
 1 file changed, 51 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..ce7ec01 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -106,6 +106,7 @@ struct dsps_musb_wrapper {
 
 	/* bit positions for mode */
 	unsigned	iddig:5;
+	unsigned	iddig_mux:5;
 	/* miscellaneous stuff */
 	u8		poll_seconds;
 };
@@ -406,6 +407,54 @@ static int dsps_musb_exit(struct musb *musb)
 	return 0;
 }
 
+static int dsps_musb_set_mode(struct musb *musb, u8 mode)
+{
+	struct device *dev = musb-controller;
+	struct dsps_glue *glue = dev_get_drvdata(dev-parent);
+	const struct dsps_musb_wrapper *wrp = glue-wrp;
+	void __iomem *ctrl_base = musb-ctrl_base;
+	void __iomem *base = musb-mregs;
+	u32 reg;
+
+	reg = dsps_readl(base, wrp-mode);
+
+	switch (mode) {
+	case MUSB_HOST:
+		reg = ~(1  wrp-iddig);
+
+		/*
+		 * if we're setting mode to host-only or device-only, we're
+		 * going to ignore whatever the PHY sends us and just force
+		 * ID pin status by SW
+		 */
+		reg |= (1  wrp-iddig_mux);
+
+		dsps_writel(base, wrp-mode, reg);
+		dsps_writel(ctrl_base, wrp-phy_utmi, 0x02);
+		break;
+	case MUSB_PERIPHERAL:
+		reg |= (1  wrp-iddig);
+
+		/*
+		 * if we're setting mode to host-only or device-only, we're
+		 * going to ignore whatever 

[PATCH v2 2/4] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..81caf9f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
 
 #include musb_core.h
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.4.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 v2 1/4] usb: musb: unconditionally save and restore the context on suspend

[Daniel Mack]

It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.

The dsps platform does, however, and because it shouldn't cause any
trouble on other platforms, do it unconditionally for all of them.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..797709d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2215,16 +2215,28 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* For the DSPS glue layer though, a full register restore has to
+* be done. As it shouldn't harm other platforms, we do it
+* unconditionally.
 */
+
+   musb_restore_context(musb);
+
return 0;
 }
 
-- 
1.8.4.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 v2 3/4] usb: musb: dsps: add {tx,rx}_mode to wrapper

[Daniel Mack]

rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..e57d712 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.4.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 v2 4/4] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

We also have to explicitly de-assert the port reset upon resume on this
platform, but musb_port_reset() should not be called from glue layers.

Hence, introduce a flag in struct musb_hdrc_config for this.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c| 60 +
 drivers/usb/musb/musb_host.c|  7 -
 drivers/usb/musb/musb_host.h|  2 ++
 drivers/usb/musb/musb_virthub.c |  2 +-
 include/linux/usb/musb.h|  3 +++
 5 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e57d712..4a6ab1a 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -506,9 +521,11 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+   pdata.restore_after_suspend = 1;
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
+   config-host_port_deassert_reset_at_resume = 1;
pdata.mode = get_musb_port_mode(dev);
/* DT keeps this entry in mA, musb expects it as per USB spec */
pdata.power = get_int_prop(dn, mentor,power) / 2;
@@ -632,11 +649,54 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   //musb_port_reset(musb, false);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
 };
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 81caf9f..8224138 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2464,7 +2464,12 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
 
 static int musb_bus_resume(struct usb_hcd *hcd)
 {
-   /* resuming child port does the work */
+   struct musb *musb = hcd_to_musb(hcd);
+
+   if (musb-config 
+   musb-config-host_port_deassert_reset_at_resume)
+   musb_port_reset(musb, false);
+
return 0;
 }
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index e660af9..7436c24 100644
--- a/drivers/usb/musb/musb_host.h
+++ 

[PATCH v2 0/4] musb/dsps: suspend related patches for 3.14 (rebased)

[Daniel Mack]

v1 - v2:

 * *un*conditionally save and restore registers upon suspend/resume
   rather than only doing it for the DSPS glue.
 * do not call musb_port_reset() from glue, but rather introduce a
   flag and let musb-hdrc.ko do it.
 * dropped 'usb: musb: dsps: indentation and whitespace fixes'

Daniel Mack (4):
  usb: musb: unconditionally save and restore the context on suspend
  usb: musb: call musb_port_suspend from musb_bus_suspend
  usb: musb: dsps: add {tx,rx}_mode to wrapper
  usb: musb: dsps: add support for suspend and resume

 drivers/usb/musb/musb_core.c| 14 -
 drivers/usb/musb/musb_dsps.c| 64 +
 drivers/usb/musb/musb_host.c|  9 +-
 drivers/usb/musb/musb_host.h|  4 +++
 drivers/usb/musb/musb_virthub.c |  4 +--
 include/linux/usb/musb.h|  3 ++
 6 files changed, 94 insertions(+), 4 deletions(-)

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

Re: [PATCH v2 4/4] usb: musb: dsps: add support for suspend and resume

[Felipe Balbi]

Hi,

On Mon, Nov 25, 2013 at 10:26:43PM +0100, Daniel Mack wrote:
 +static int dsps_resume(struct device *dev)
 +{
 + struct dsps_glue *glue = dev_get_drvdata(dev);
 + const struct dsps_musb_wrapper *wrp = glue-wrp;
 + struct musb *musb = platform_get_drvdata(glue-musb);
 + void __iomem *mbase = musb-ctrl_base;
 +
 + dsps_writel(mbase, wrp-control, glue-context.control);
 + dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
 + dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
 + dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
 + dsps_writel(mbase, wrp-mode, glue-context.mode);
 + dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
 + dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
 +
 + //musb_port_reset(musb, false);



-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 4/4] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

On 11/25/2013 10:29 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 10:26:43PM +0100, Daniel Mack wrote:
 +static int dsps_resume(struct device *dev)
 +{
 +struct dsps_glue *glue = dev_get_drvdata(dev);
 +const struct dsps_musb_wrapper *wrp = glue-wrp;
 +struct musb *musb = platform_get_drvdata(glue-musb);
 +void __iomem *mbase = musb-ctrl_base;
 +
 +dsps_writel(mbase, wrp-control, glue-context.control);
 +dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
 +dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
 +dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
 +dsps_writel(mbase, wrp-mode, glue-context.mode);
 +dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
 +dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
 +
 +//musb_port_reset(musb, false);
 
 
 

Urgs. Development left-over. Sorry. You want me to resend the whole
series or just this last patch?


Daniel

--
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 4/4] usb: musb: dsps: add support for suspend and resume

[Felipe Balbi]

On Mon, Nov 25, 2013 at 10:30:37PM +0100, Daniel Mack wrote:
 On 11/25/2013 10:29 PM, Felipe Balbi wrote:
  Hi,
  
  On Mon, Nov 25, 2013 at 10:26:43PM +0100, Daniel Mack wrote:
  +static int dsps_resume(struct device *dev)
  +{
  +  struct dsps_glue *glue = dev_get_drvdata(dev);
  +  const struct dsps_musb_wrapper *wrp = glue-wrp;
  +  struct musb *musb = platform_get_drvdata(glue-musb);
  +  void __iomem *mbase = musb-ctrl_base;
  +
  +  dsps_writel(mbase, wrp-control, glue-context.control);
  +  dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
  +  dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
  +  dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
  +  dsps_writel(mbase, wrp-mode, glue-context.mode);
  +  dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
  +  dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
  +
  +  //musb_port_reset(musb, false);
  
  
  
 
 Urgs. Development left-over. Sorry. You want me to resend the whole
 series or just this last patch?

just the last patch is fine :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's

[Felipe Balbi]

Hi,

On Mon, Nov 11, 2013 at 08:06:12PM +0530, Kishon Vijay Abraham I wrote:
  diff --git a/drivers/usb/dwc3/platform_data.h 
  b/drivers/usb/dwc3/platform_data.h
  index 7db34f0..49ffa6d 100644
  --- a/drivers/usb/dwc3/platform_data.h
  +++ b/drivers/usb/dwc3/platform_data.h
  @@ -24,4 +24,6 @@ struct dwc3_platform_data {
 enum usb_device_speed maximum_speed;
 enum usb_dr_mode dr_mode;
 bool tx_fifo_resize;
  +  bool usb2_phy;
  +  bool usb3_phy;
  
  This would look better as a quirks flag, then we could:
  
  unsigned long quirks;
  #define DWC3_QUIRK_NO_USB3_PHY  BIT(0)
  #define DWC3_QUIRK_NO_USB2_PHY  BIT(1)
 
 Should this quirk be used for dt also? Currently we find if it has usb3 phy or
 usb2 phy from the dt data only. But if we add a quirk, we'll have to add a
 property to populate the quirk no?

either we use the quirk, or use the fact that no usb2_phy phandle is
defined, would work both ways, no ?

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 1/7] ARM: OMAP: hwmod: Add SYSC offsets for AES IP

[Joel Fernandes]

The AES IP has the SIDLE offset by 2 and not 3, to allow SIDLE modes
to work for AES, we add a new SYSC type to hwmod.

Signed-off-by: Joel Fernandes jo...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod.h | 11 +++
 arch/arm/mach-omap2/omap_hwmod_common_data.c | 10 ++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 0f97d63..b2efcc8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -41,6 +41,7 @@ struct omap_device;
 extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type1;
 extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2;
 extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
+extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4;
 
 /*
  * OCP SYSCONFIG bit shifts/masks TYPE1. These are for IPs compliant
@@ -81,6 +82,16 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
 #define SYSC_TYPE3_MIDLEMODE_SHIFT 2
 #define SYSC_TYPE3_MIDLEMODE_MASK  (0x3  SYSC_TYPE3_MIDLEMODE_SHIFT)
 
+/*
+ * OCP SYSCONFIG bit shifts/masks TYPE4.
+ */
+#define SYSC_TYPE4_SIDLEMODE_SHIFT 2
+#define SYSC_TYPE4_SIDLEMODE_MASK  (0x3  SYSC_TYPE4_SIDLEMODE_SHIFT)
+#define SYSC_TYPE4_SOFTRESET_SHIFT 1
+#define SYSC_TYPE4_SOFTRESET_MASK  (1  SYSC_TYPE4_SOFTRESET_SHIFT)
+#define SYSC_TYPE4_AUTOIDLE_SHIFT  0
+#define SYSC_TYPE4_AUTOIDLE_MASK   (1  SYSC_TYPE4_AUTOIDLE_SHIFT)
+
 /* OCP SYSSTATUS bit shifts/masks */
 #define SYSS_RESETDONE_SHIFT   0
 #define SYSS_RESETDONE_MASK(1  SYSS_RESETDONE_SHIFT)
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c 
b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 79d623b..7443dc0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -59,6 +59,16 @@ struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3 = {
.sidle_shift= SYSC_TYPE3_SIDLEMODE_SHIFT,
 };
 
+/**
+ * struct omap_hwmod_sysc_type4 - TYPE4 sysconfig scheme.
+ * Used by some IPs on AM33xx
+ */
+struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4 = {
+   .sidle_shift= SYSC_TYPE4_SIDLEMODE_SHIFT,
+   .srst_shift = SYSC_TYPE4_SOFTRESET_SHIFT,
+   .autoidle_shift = SYSC_TYPE4_AUTOIDLE_SHIFT,
+};
+
 struct omap_dss_dispc_dev_attr omap2_3_dss_dispc_dev_attr = {
.manager_count  = 2,
.has_framedonetv_irq= 0
-- 
1.8.1.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 4/7] ARM: OMAP4: hwmod: Add hwmod data for AES IP

[Joel Fernandes]

Crypto modules AES0/1 belong to:
PD_L4_PER power domain
CD_L4_SEC clock domain
On the L3, the AES modules are mapped to
L3_CLK2: Peripherals and multimedia sub clock domain

We add hwmod data for the same.

Signed-off-by: Joel Fernandes jo...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1e5b12c..664b2c6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4791,6 +4791,59 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__emif2 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/*
+Crypto modules AES0/1 belong to:
+   PD_L4_PER power domain
+   CD_L4_SEC clock domain
+   On the L3, the AES modules are mapped to
+   L3_CLK2: Peripherals and multimedia sub clock domain
+*/
+
+static struct omap_hwmod_class_sysconfig omap4_aes1_sysc = {
+   .rev_offs   = 0x80,
+   .sysc_offs  = 0x84,
+   .syss_offs  = 0x88,
+   .sysc_flags = SYSS_HAS_RESET_STATUS,
+   .sysc_fields= omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class omap4_aes1_hwmod_class = {
+   .name   = aes1,
+   .sysc   = omap4_aes1_sysc,
+};
+
+static struct omap_hwmod omap4_aes1_hwmod = {
+   .name   = aes,
+   .class  = omap4_aes1_hwmod_class,
+   .clkdm_name = l4_secure_clkdm,
+   .main_clk   = aes1_fck,
+   .prcm   = {
+   .omap4  = {
+   .clkctrl_offs = OMAP4_CM_L4SEC_AES1_CLKCTRL_OFFSET,
+   .context_offs = OMAP4_RM_L4SEC_AES1_CONTEXT_OFFSET,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/* l3_main_2 - aes1 */
+static struct omap_hwmod_addr_space omap4_aes1_addrs[] = {
+   {
+   .pa_start   = 0x4B50,
+   .pa_end = 0x4B50 + SZ_1M - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
+static struct omap_hwmod_ocp_if omap4_l3_main_2__aes1 = {
+   .master = omap44xx_l3_main_2_hwmod,
+   .slave  = omap4_aes1_hwmod,
+   .clk= aes1_fck,
+   .addr   = omap4_aes1_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
omap44xx_l3_main_1__dmm,
omap44xx_mpu__dmm,
@@ -4945,6 +4998,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] 
__initdata = {
omap44xx_l4_abe__wd_timer3_dma,
omap44xx_mpu__emif1,
omap44xx_mpu__emif2,
+   omap4_l3_main_2__aes1,
NULL,
 };
 
-- 
1.8.1.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 2/7] ARM: DRA7xx: hwmod: Add hwmod data for DES IP

[Joel Fernandes]

DRA7xx SoC has a DES module. Add hwmod data for the same.

Signed-off-by: Joel Fernandes jo...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index db32d53..efae736 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -561,6 +561,23 @@ static struct omap_hwmod_class dra7xx_gpio_hwmod_class = {
.rev= 2,
 };
 
+static struct omap_hwmod_class_sysconfig dra7xx_des_sysc = {
+   .rev_offs   = 0x0030,
+   .sysc_offs  = 0x0034,
+   .syss_offs  = 0x0038,
+   .sysc_flags = (SYSC_HAS_AUTOIDLE |
+  SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO),
+   .sysc_fields= omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class dra7xx_des_hwmod_class = {
+   .name   = des,
+   .sysc   = dra7xx_des_sysc,
+   .rev= 2,
+};
+
 /* gpio dev_attr */
 static struct omap_gpio_dev_attr gpio_dev_attr = {
.bank_width = 32,
@@ -750,6 +767,19 @@ static struct omap_hwmod dra7xx_gpio8_hwmod = {
.dev_attr   = gpio_dev_attr,
 };
 
+static struct omap_hwmod dra7xx_des_hwmod = {
+   .name   = des,
+   .class  = dra7xx_des_hwmod_class,
+   .clkdm_name = l4sec_clkdm,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4SEC_DES3DES_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4SEC_DES3DES_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
+
 /*
  * 'gpmc' class
  *
@@ -2171,6 +2201,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio8 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_per1 - des */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__des = {
+   .master = dra7xx_l4_per1_hwmod,
+   .slave  = dra7xx_des_hwmod,
+   .clk= l3_iclk_div,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_addr_space dra7xx_gpmc_addrs[] = {
{
.pa_start   = 0x5000,
@@ -2705,6 +2743,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
dra7xx_l4_per1__uart4,
dra7xx_l4_per1__uart5,
dra7xx_l4_per1__uart6,
+   dra7xx_l4_per1__des,
dra7xx_l4_per3__usb_otg_ss1,
dra7xx_l4_per3__usb_otg_ss2,
dra7xx_l4_per3__usb_otg_ss3,
-- 
1.8.1.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 6/7] ARM: OMAP: Disable POSTED mode for errata i103 and i767

[Joel Fernandes]

Enabling of Posted mode is seen to cause problems on dmtimer modules on AM33xx
(much like other OMAPs).  Reference discussions on forums [1] [2]. Earlier
patch solving this on other OMAPs [3].

For OMAP SoCs with this errata, the fix has been to not enable Posted mode.
However, on some SoCs (atleast AM33xx) which carry this errata, Posted mode
is enabled on reset. So we not only need to ignore enabling of the POSTED bit
when the timer is requested, but also disable Posted mode if errata is present.

[1] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/285744.aspx
[2] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/270632.aspx
[3] http://www.spinics.net/lists/linux-omap/msg81770.html

Reported-by: Russ Dill russ.d...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
---
 arch/arm/plat-omap/include/plat/dmtimer.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h 
b/arch/arm/plat-omap/include/plat/dmtimer.h
index fb92abb..2861b15 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -336,8 +336,11 @@ static inline void __omap_dm_timer_enable_posted(struct 
omap_dm_timer *timer)
if (timer-posted)
return;
 
-   if (timer-errata  OMAP_TIMER_ERRATA_I103_I767)
+   if (timer-errata  OMAP_TIMER_ERRATA_I103_I767) {
+   timer-posted = OMAP_TIMER_NONPOSTED;
+   __omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG, 0, 0);
return;
+   }
 
__omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG,
  OMAP_TIMER_CTRL_POSTED, 0);
-- 
1.8.1.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 5/7] ARM: OMAP4: hwmod: add hwmod data for DES IP

[Joel Fernandes]

OMAP4 has a DES IP for DES and 3DES encryption, Add hwmod data for the same.

Signed-off-by: Joel Fernandes jo...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 664b2c6..e0992d3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4844,6 +4844,52 @@ static struct omap_hwmod_ocp_if omap4_l3_main_2__aes1 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* DES3DES */
+static struct omap_hwmod_class_sysconfig omap4_des_sysc = {
+   .rev_offs   = 0x30,
+   .sysc_offs  = 0x34,
+   .syss_offs  = 0x38,
+   .sysc_flags = SYSS_HAS_RESET_STATUS,
+   .sysc_fields= omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class omap4_des_hwmod_class = {
+   .name   = des,
+   .sysc   = omap4_des_sysc,
+};
+
+
+static struct omap_hwmod omap4_des_hwmod = {
+   .name   = des,
+   .class  = omap4_des_hwmod_class,
+   .clkdm_name = l4_secure_clkdm,
+   .main_clk   = des_fck,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = OMAP4_CM_L4SEC_DES3DES_CLKCTRL_OFFSET,
+   .context_offs = OMAP4_RM_L4SEC_DES3DES_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+static struct omap_hwmod_addr_space omap4_des_addrs[] = {
+   {
+   .pa_start   = 0x480A4000,
+   .pa_end = 0x481A4000,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
+static struct omap_hwmod_ocp_if omap4_l4_per__des = {
+   .master = omap44xx_l4_per_hwmod,
+   .slave  = omap4_des_hwmod,
+   .clk= des_fck,
+   .addr   = omap4_des_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
omap44xx_l3_main_1__dmm,
omap44xx_mpu__dmm,
@@ -4999,6 +5045,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] 
__initdata = {
omap44xx_mpu__emif1,
omap44xx_mpu__emif2,
omap4_l3_main_2__aes1,
+   omap4_l4_per__des,
NULL,
 };
 
-- 
1.8.1.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/7] AES/DES hwmod data and dmtimer fix

[Joel Fernandes]

Here are patches adding hwmod for AES/DES crypto modules for OMAP4, DRA7 SoCs.

Also included is a fix that disables POSTED mode when dmtimer is requested.

Joel Fernandes (7):
  ARM: OMAP: hwmod: Add SYSC offsets for AES IP
  ARM: DRA7xx: hwmod: Add hwmod data for DES IP
  ARM: DRA7xx: hwmod: Add hwmod data for AES IP
  ARM: OMAP4: hwmod: Add hwmod data for AES IP
  ARM: OMAP4: hwmod: add hwmod data for DES IP
  ARM: OMAP: Disable POSTED mode for errata i103 and i767
  OMAP: AM33xx: hwmod: Correct AES module SYSC type

 arch/arm/mach-omap2/omap_hwmod.h   |  11 +++
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 101 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  78 
 arch/arm/mach-omap2/omap_hwmod_common_data.c   |  10 ++
 arch/arm/plat-omap/include/plat/dmtimer.h  |   5 +-
 6 files changed, 205 insertions(+), 1 deletion(-)

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