Re: [RFC/PATCH 3/3] i2c: omap: Add support for I2C_M_STOP message flag
Laurent, A minor comment below. On Tuesday 26 June 2012 07:47 PM, Laurent Pinchart wrote: Generate a stop condition after each message marked with I2C_M_STOP. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 801df60..cf1bda0 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -545,6 +545,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, if (dev-speed 400) w |= OMAP_I2C_CON_OPMODE_HS; + if (msg-flags I2C_M_STOP) + stop = 1; How about patching omap_i2c_xfer (caller) instead. There are some debug prints of stop above that will not reflect the real value. if (msg-flags I2C_M_TEN) w |= OMAP_I2C_CON_XA; if (!(msg-flags I2C_M_RD)) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] omap: add ocp2scp as a bus driver
This patch series is done as a preparatory step for adding phy drivers for dwc3 and musb. This series adds a new driver for ocp2scp (only dt) to which phy drivers are connected. Since currently there is no generic way to create a child device along with doing a pm_runtime_enable (the exact requirement for ocp2scp), I'm creating a separate driver for ocp2scp. Changes from v1: Fixed Sergei's comments to remove the address in the node name of ocp2scp since the ocp2scp node doesn't have a reg property. Changes from [RFC PATCH v2 0/2] omap: add ocp2scp as a misc driver: Created a new folder drivers/bus and moved ocp2scp driver from misc to drivers/bus. This patch was developed and tested on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git Kishon Vijay Abraham I (2): drivers: bus: add a new driver for omap-ocp2scp arm/dts: omap4: Add ocp2scp data .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 ++ arch/arm/boot/dts/omap4.dtsi |8 ++ drivers/Kconfig|2 + drivers/Makefile |2 + drivers/bus/Kconfig| 15 +++ drivers/bus/Makefile |5 + drivers/bus/omap-ocp2scp.c | 98 7 files changed, 140 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt create mode 100644 drivers/bus/Kconfig create mode 100644 drivers/bus/Makefile create mode 100644 drivers/bus/omap-ocp2scp.c -- 1.7.5.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 v2 2/2] arm/dts: omap4: Add ocp2scp data
Add ocp2scp data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..29c6243 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,13 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ocp2scp {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp_usb_phy;
+ };
};
};
--
1.7.5.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 v2 1/2] drivers: bus: add a new driver for omap-ocp2scp
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of
creating all the devices that is connected to OCP2SCP. In the case of OMAP4,
USB2PHY is connected to ocp2scp.
This also includes device tree support for ocp2scp driver and
the documentation with device tree binding information is updated.
Cc: Felipe Balbi ba...@ti.com
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/bus/omap-ocp2scp.txt | 10 ++
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/bus/Kconfig| 15 +++
drivers/bus/Makefile |5 +
drivers/bus/omap-ocp2scp.c | 98
6 files changed, 132 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
create mode 100644 drivers/bus/Kconfig
create mode 100644 drivers/bus/Makefile
create mode 100644 drivers/bus/omap-ocp2scp.c
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
new file mode 100644
index 000..d2fe064
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -0,0 +1,10 @@
+* OMAP OCP2SCP - ocp interface to scp interface
+
+properties:
+- compatible : Should be ti,omap-ocp2scp
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+- ranges : the child address space are mapped 1:1 onto the parent address space
+- ti,hwmods : must be ocp2scp_usb_phy
+
+Sub-nodes:
+All the devices connected to ocp2scp are described using sub-node to ocp2scp
diff --git a/drivers/Kconfig b/drivers/Kconfig
index bfc9186..4fe1e4c 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -2,6 +2,8 @@ menu Device Drivers
source drivers/base/Kconfig
+source drivers/bus/Kconfig
+
source drivers/connector/Kconfig
source drivers/mtd/Kconfig
diff --git a/drivers/Makefile b/drivers/Makefile
index 2ba29ff..cac3819 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -5,6 +5,8 @@
# Rewritten to use lists instead of if-statements.
#
+obj-y += bus/
+
# GPIO must come after pinctrl as gpios may need to mux pins etc
obj-y += pinctrl/
obj-y += gpio/
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
new file mode 100644
index 000..6270415
--- /dev/null
+++ b/drivers/bus/Kconfig
@@ -0,0 +1,15 @@
+#
+# Bus Devices
+#
+
+menu Bus devices
+
+config OMAP_OCP2SCP
+ tristate OMAP OCP2SCP DRIVER
+ help
+ Driver to enable ocp2scp module which transforms ocp interface
+ protocol to scp protocol. In OMAP4, USB PHY is connected via
+ OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
+ OCP2SCP.
+
+endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
new file mode 100644
index 000..0ec50bc
--- /dev/null
+++ b/drivers/bus/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the bus drivers.
+#
+
+obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
new file mode 100644
index 000..8c3db3a
--- /dev/null
+++ b/drivers/bus/omap-ocp2scp.c
@@ -0,0 +1,98 @@
+/*
+ * omap-ocp2scp.c - transform ocp interface protocol to scp protocol
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
+
+static int ocp2scp_remove_devices(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ platform_device_unregister(pdev);
+
+ return 0;
+}
+
+static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct device_node *np = pdev-dev.of_node;
+
+ if (np) {
+ ret = of_platform_populate(np, NULL, NULL, pdev-dev);
+ if (ret) {
+ dev_err(pdev-dev, failed to add resources for
ocp2scp child\n);
+ goto err0;
+ }
+ }
+ pm_runtime_enable(pdev-dev);
+
+ return 0;
+
+err0:
+ device_for_each_child(pdev-dev, NULL,
[PATCH v3 00/11] omap: musb: Add device tree support
This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 48 .../devicetree/bindings/usb/twl-usb.txt| 41 +++ arch/arm/boot/dts/omap3-beagle.dts |6 + arch/arm/boot/dts/omap3-evm.dts|6 + arch/arm/boot/dts/omap3.dtsi |8 + arch/arm/boot/dts/omap4-panda.dts | 10 + arch/arm/boot/dts/omap4-sdp.dts| 10 + arch/arm/boot/dts/omap4.dtsi | 13 + arch/arm/boot/dts/twl4030.dtsi | 21 ++ arch/arm/boot/dts/twl6030.dtsi |6 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/omap2430.c| 107 +++- drivers/usb/musb/omap2430.h|9 + drivers/usb/otg/Kconfig| 10 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/omap-usb2.c| 271 drivers/usb/otg/twl4030-usb.c | 26 ++- drivers/usb/otg/twl6030-usb.c | 153 +++ include/linux/usb/omap_usb.h | 45 include/linux/usb/phy_companion.h | 34 +++ 24 files changed, 706 insertions(+), 273 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 drivers/usb/otg/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 1.7.5.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 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/bus/omap-ocp2scp.txt |3 +
Documentation/devicetree/bindings/usb/omap-usb.txt | 16 ++
drivers/usb/otg/Kconfig| 10 +
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap-usb2.c| 271
include/linux/usb/omap_usb.h | 45
include/linux/usb/phy_companion.h | 34 +++
7 files changed, 380 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
create mode 100644 drivers/usb/otg/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
index d2fe064..bb0c7f4 100644
--- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -8,3 +8,6 @@ properties:
Sub-nodes:
All the devices connected to ocp2scp are described using sub-node to ocp2scp
+- usb2phy :
+ The binding details of usb2phy can be found in:
+ Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..80a28c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,16 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@0x4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58;
+};
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..c751db7 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,16 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP_USB2
+ tristate OMAP USB2 PHY Driver
+ depends on OMAP_OCP2SCP
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..2c2a3ca 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..2f9e257
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,271 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include
[PATCH v3 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 22 +++
drivers/usb/otg/twl6030-usb.c | 39 +---
2 files changed, 48 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..e3f6d73
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,22 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts when
+ the controller has to act as host and the second interrupt number is the
+ usb interrupt number that raises VBUS interrupts when the controller has to
+ act as device
+ - usb-supply : phandle to the regulator device tree node. It should be vusb
+ if it is twl6030 or ldousb if it is twl6025 subclass.
+
+twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ regulator = vusb;
+};
+
+Board specific device node entry
+twl6030-usb {
+ usb-supply = vusb;
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 9994dd22..6b0d0a1 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8 asleep;
boolirq_enabled;
boolvbus_enable;
- unsigned long features;
+ const char *regulator;
};
#definecomparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
- char *regulator_name;
-
- if (twl-features TWL6025_SUBCLASS)
- regulator_name = ldousb;
- else
- regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+ twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
@@ -321,9 +314,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
{
struct twl6030_usb *twl;
int status, err;
- struct twl4030_usb_data *pdata;
- struct device *dev = pdev-dev;
- pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct device *dev = pdev-dev;
+ struct twl4030_usb_data *pdata = dev-platform_data;
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -332,13 +325,24 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-dev= pdev-dev;
twl-irq1 = platform_get_irq(pdev, 0);
twl-irq2 = platform_get_irq(pdev, 1);
- twl-features = pdata-features;
twl-linkstat = OMAP_MUSB_UNKNOWN;
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp = twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
+ if (np) {
+ twl-regulator = usb;
+ } else if (pdata) {
+ if (pdata-features TWL6025_SUBCLASS)
+ twl-regulator = ldousb;
+ else
+ twl-regulator = vusb;
+ } else {
+ dev_err(pdev-dev, twl6030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -400,12 +404,21 @@ static int __exit twl6030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+ { .compatible = ti,twl6030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl6030_usb_id_table);
+#endif
+
static struct platform_driver twl6030_usb_driver = {
.probe = twl6030_usb_probe,
.remove = __exit_p(twl6030_usb_remove),
.driver = {
.name = twl6030_usb,
.owner = THIS_MODULE,
+ .of_match_table =
[PATCH v3 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Writing to control module which is now handled in omap2430.c should be
removed once a driver for control module is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 52 ---
drivers/usb/musb/omap2430.h |9 +++
drivers/usb/otg/twl6030-usb.c | 114 +
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..addbebf 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -44,6 +44,7 @@ struct omap2430_glue {
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
+ u32 __iomem *control_otghs;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -51,6 +52,26 @@ struct omap2430_glue *_glue;
static struct timer_list musb_idle_timer;
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+ if (glue-control_otghs)
+ writel(val, glue-control_otghs);
+}
+
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
@@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
+ u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
}
- usb_phy_shutdown(musb-xceiv);
+ val = SESSEND | IDDIG;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, ID float\n);
@@ -366,6 +391,7 @@ err1:
static void omap2430_musb_enable(struct musb *musb)
{
u8 devctl;
+ u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
@@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue-status) {
case OMAP_MUSB_ID_GROUND:
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
if (data-interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
@@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
case OMAP_MUSB_VBUS_VALID:
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
@@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb)
static void omap2430_musb_disable(struct musb *musb)
{
+ u32 val;
struct device *dev = musb-controller;
struct omap2430_glue *glue =
[PATCH v3 06/11] arm/dts: Add twl6030-usb data
Add twl6030-usb data node in twl6030 device tree file
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts |4
arch/arm/boot/dts/omap4-sdp.dts |4
arch/arm/boot/dts/twl6030.dtsi|6 ++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 1efe0c5..7052422 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -89,3 +89,7 @@
ti,non-removable;
bus-width = 4;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..6326d7c 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,3 +158,7 @@
bus-width = 4;
ti,non-removable;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..5efd6d3 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -83,4 +83,10 @@
clk32kg: regulator@12 {
compatible = ti,twl6030-clk32kg;
};
+
+ twlusb: twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ regulator = vusb;
+ };
};
--
1.7.5.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/11] arm/dts: Add twl4030-usb data
Add twl4030-usb data node in twl4030 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..761a5a5 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = 315;
};
+ vusb1v5: regulator-vusb1v5 {
+ compatible = ti,twl4030-vusb1v5;
+ };
+
+ vusb1v8: regulator-vusb1v8 {
+ compatible = ti,twl4030-vusb1v8;
+ };
+
+ vusb3v1: regulator-vusb3v1 {
+ compatible = ti,twl4030-vusb3v1;
+ };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+ };
};
--
1.7.5.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/11] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba24d15..c50d828 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5922,6 +5922,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
1.7.5.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/11] arm/dts: omap: Add omap-usb2 dt data
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29c6243..15f1890 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x1;
+ };
};
};
};
--
1.7.5.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 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb
Add device tree support for twl4030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 19 ++
drivers/usb/otg/twl4030-usb.c | 26 +++
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index e3f6d73..bdf1dd4 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -20,3 +20,22 @@ Board specific device node entry
twl6030-usb {
usb-supply = vusb;
};
+
+TWL4030 USB PHY AND COMPARATOR
+ - compatible : Should be ti,twl4030-usb
+ - interrupts : The interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts
+ and VBUS interrupts. The second interrupt number is optional.
+ - supply-name-supply : phandle to the regulator device tree node.
+ supply-name should be vusb1v5, vusb1v8 and vusb3v1
+ - usb_mode : The mode used by the phy to connect to the controller. 1
+ specifies ULPI mode and 2 specifies CEA2011_3PIN mode.
+
+twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+};
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 523cad5..f0d2e75 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
struct twl4030_usb *twl;
int status, err;
struct usb_otg *otg;
-
- if (!pdata) {
- dev_dbg(pdev-dev, platform_data not available\n);
- return -EINVAL;
- }
+ struct device_node *np = pdev-dev.of_node;
twl = devm_kzalloc(pdev-dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
+ if (np)
+ of_property_read_u32(np, usb_mode,
+ (enum twl4030_usb_mode *)twl-usb_mode);
+ else if (pdata)
+ twl-usb_mode = pdata-usb_mode;
+ else {
+ dev_err(pdev-dev, twl4030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
otg = devm_kzalloc(pdev-dev, sizeof *otg, GFP_KERNEL);
if (!otg)
return -ENOMEM;
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
- twl-usb_mode = pdata-usb_mode;
twl-vbus_supplied = false;
twl-asleep = 1;
twl-linkstat = OMAP_MUSB_UNKNOWN;
@@ -690,12 +695,21 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_usb_id_table[] = {
+ { .compatible = ti,twl4030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl4030_usb_id_table);
+#endif
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
.driver = {
.name = twl4030_usb,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl4030_usb_id_table),
},
};
--
1.7.5.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/11] drivers: usb: musb: Add device tree support for omap musb glue
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
drivers/usb/musb/omap2430.c| 55
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..331e477 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +638,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
+
[PATCH v3 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 138 ---
arch/arm/mach-omap2/twl-common.c|5 -
arch/arm/mach-omap2/usb-musb.c |3 -
3 files changed, 0 insertions(+), 146 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..874aecc 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
#include plat/usb.h
#include control.h
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF 0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL 0x33c
-#defineAVALID BIT(0)
-#defineBVALID BIT(1)
-#defineVBUSVALID BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
- ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
- if (!ctrl_base) {
- pr_err(control module ioremap failed\n);
- return -ENOMEM;
- }
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- if (!dev) {
- iounmap(ctrl_base);
- return 0;
- }
-
- phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
- if (IS_ERR(phyclk)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
- iounmap(ctrl_base);
- return PTR_ERR(phyclk);
- }
-
- clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
- if (IS_ERR(clk48m)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
- clk_put(phyclk);
- iounmap(ctrl_base);
- return PTR_ERR(clk48m);
- }
-
- clk32k = clk_get(dev, usb_phy_cm_clk32k);
- if (IS_ERR(clk32k)) {
- dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
- clk_put(phyclk);
- clk_put(clk48m);
- iounmap(ctrl_base);
- return PTR_ERR(clk32k);
- }
- return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
- static int state;
-
- if (on !state) {
- /* Enable the phy clocks */
- clk_enable(phyclk);
- clk_enable(clk48m);
- clk_enable(clk32k);
- state = 1;
- } else if (state) {
- /* Disable the phy clocks */
- clk_disable(phyclk);
- clk_disable(clk48m);
- clk_disable(clk32k);
- state = 0;
- }
- return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
- if (on) {
- if (ID)
- /* enable VBUS valid, IDDIG groung */
- __raw_writel(AVALID | VBUSVALID, ctrl_base +
- USBOTGHS_CONTROL);
- else
- /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
- __raw_writel(IDDIG | AVALID | VBUSVALID,
- ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable session END and IDIG to high impedance. */
- __raw_writel(SESSEND | IDDIG, ctrl_base +
- USBOTGHS_CONTROL);
- }
- return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
- if (suspend) {
- /* Disable the clocks */
- omap4430_phy_set_clk(dev, 0);
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- /* save the context */
- usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable the internel phy clcoks */
- omap4430_phy_set_clk(dev, 1);
- /* power on the phy */
- if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) PHY_PD) {
- __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
- }
-
- /* restore the context */
- __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
- }
-
- return 0;
-}
-
-int omap4430_phy_exit(struct device *dev)
-{
- if (ctrl_base)
-
[PATCH v3 10/11] arm/dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3.dtsi |8
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi |8
6 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
mmc3 {
status = disable;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..f2694c9 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap3-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 7052422..dd19370 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -93,3 +93,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 6326d7c..0fc10d4 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -162,3 +162,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 15f1890..3a6c3fa 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -285,5 +285,13 @@
0x4a002300 0x1;
};
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
--
1.7.5.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] regulator: tps65217: fix build error if REGULATOR is not enabled
Fixes below build error if CONFIG_REGULATOR is not enabled. drivers/built-in.o: In function `tps65217_probe': tps65217.c:(.devinit.text+0x13e37): undefined reference to `of_regulator_match' Signed-off-by: AnilKumar Ch anilku...@ti.com --- drivers/mfd/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index e129c82..01c929a 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -159,6 +159,7 @@ config TPS6507X config MFD_TPS65217 tristate TPS65217 Power Management / White LED chips depends on I2C + depends on REGULATOR select MFD_CORE select REGMAP_I2C help -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] memory: emif: add device tree support to emif driver
On Tue, Jul 17, 2012 at 11:28 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, Jul 17, 2012 at 10:37:45PM +0530, Shilimkar, Santosh wrote:
On Tue, Jul 17, 2012 at 10:06 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Jul 09, 2012 at 07:02:36PM +0530, Shilimkar, Santosh wrote:
Greg,
[..]
From 74688a87fd490909e9122bf757c0096480e9fc11 Mon Sep 17 00:00:00 2001
From: Aneesh V ane...@ti.com
Date: Mon, 30 Jan 2012 20:06:30 +0530
Subject: [PATCH 4/4] memory: emif: add device tree support to emif driver
Device tree support for the EMIF driver. LPDDR2 generic timings
extraction from device is managed using couple of helper
functions which can be used by other memory controller
drivers.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/memory/Makefile|1 +
drivers/memory/emif.c | 182
+++-
drivers/memory/of_memory.c | 153 +
drivers/memory/of_memory.h | 36 +
4 files changed, 371 insertions(+), 1 deletion(-)
create mode 100644 drivers/memory/of_memory.c
create mode 100644 drivers/memory/of_memory.h
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 42b3ce9..cd8486b 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -2,6 +2,7 @@
# Makefile for memory devices
#
+obj-$(CONFIG_OF) += of_memory.o
obj-$(CONFIG_TI_EMIF)+= emif.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 33a4396..06b4eb7 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/of.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
@@ -25,6 +26,7 @@
#include linux/spinlock.h
#include memory/jedec_ddr.h
#include emif.h
+#include of_memory.h
/**
* struct emif_data - Per device static data for driver's use
@@ -49,6 +51,7 @@
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
* @debugfs_root:dentry to the root folder for EMIF in debugfs
+ * @np_ddr: Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +66,7 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+ struct device_node *np_ddr;
};
static struct emif_data *emif1;
@@ -1148,6 +1152,168 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init_or_module of_get_custom_configs(struct device_node
*np_emif,
+ struct emif_data *emif)
Why can't all of this code be in the of_memory.c file?
Primarily because the parameters are very much specific to EMIF
memory controller and won't be of much use for other memory controllers.
Currently the information extracted from DT with these function is like:
- EMIF controller IP version : EMIF_4D or EMIF_4D5
- Which analog phy is integrated : EMIF_ATTILAPHY or EMIF_ATTILAPHY
- IP hardware interface: EMIF Low latency port or sys port interface.
- EMIF connections - Whether EMIF1 only, EMIF2 only or EMIF1 EMIF2
- Memory connections to EMIF - Same type and size memories or asymmetric
- Chip select usage per controller: Whether CS0, CS1, CS0 CS1
- ZQ calibration - Per chip select or enable EMIF dual calibration feature.
- Enable/disable EMIF Low power mode and temperature alerts.
- EMIF low power mode configuration:
- Clock stop, self refresh, Deep power down.
- Low power time out values for performance and power mode.
- DDR frequency threshold to switch between power and
performance settings.
- EMIF temperature polling cycle configuration.
As you can see these are very specific to the EMIF memory controller and hence
I didn't move them to of_memory.c
+static struct emif_data * __init_or_module of_get_device_details(
+ struct device_node *np_emif, struct device *dev)
of_get_memory_device_details()?
Right. Will rename it as you suggested.
+{
+ struct emif_data*emif = NULL;
+ struct ddr_device_info *dev_info = NULL;
+ struct emif_platform_data *pd = NULL;
+ struct device_node *np_ddr;
+ int len;
+
+ np_ddr = of_parse_phandle(np_emif,
RE: [PATCH v2 07/11] usb: otg: nop: add dt support
Hi, On 17-07-2012 13:13, Ajay Kumar Gupta wrote: Added device tree support for nop transceiver driver and updated the Documentation with device tree binding information for am33xx platform. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- .../devicetree/bindings/usb/am33xx-usb.txt |3 +++ drivers/usb/otg/nop-usb-xceiv.c| 12 2 files changed, 15 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index ca8fa56..a314720 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -12,3 +12,6 @@ AM33XX MUSB GLUE represents PERIPHERAL. - power : Should be 250. This signifies the controller can supply upto 500mA when operating in host mode. + +NOP USB PHY + - compatible : Should be ti,nop-xceiv-usb Why are you declaring it as TI specific. There's nothing company specific in the NOP transceiver. Thanks for review. I will change this to nop-xceiv-usb. Ajay WBR, Sergei -- 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/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
* Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. 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 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. 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 v2 08/11] arm/dts: am33xx: add dt data for usb nop phy
Hi,
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index b572803..3bd9911 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = i2c3;
};
+ usb0_phy: phy@1 {
+ compatible = ti,nop-xceiv-usb;
+ };
+
+ usb1_phy: phy@2 {
+ compatible = ti,nop-xceiv-usb;
+ };
No reg property again, and address postfix in the node name?
I will update this to
+ usb0_phy: phy0 {
+ usb1_phy: phy1 {
Thanks,
Ajay
WBR, Sergei
--
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/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
* Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. 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: [PATCHv4 7/8] ARM: OMAP: clockdomain: add support for preventing autodep delete
On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote: Anyway, it also looks like this fix is no longer needed with the latest kernel, something has changed with the gpio code / or latencies and it doesn't crash anymore. Thus, it looks like patches 7 8 can be dropped from this set for now. This is the behavior with beagleboard at least, if someone can verify this with some other omap3 hw that would be nice. I can test it on a omap3 SDP. What do you want me to test? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
* Jon Hunter jon-hun...@ti.com [120716 09:01]: On 07/13/2012 09:15 PM, Rob Herring wrote: Tony, Tarun, How would you feel on replacing omap_dmtimer_request_specific(int id) with say omap_dm_timer_request_by_cap(int cap)? I was thinking of changing the name so that it is clear that the API has changed. The int cap passed to the above function would be an OR of the appropriate the capabilities flags we have in dmtimer.h ... /* timer capabilities used in hwmod database */ #define OMAP_TIMER_SECURE 0x8000 #define OMAP_TIMER_ALWON0x4000 #define OMAP_TIMER_HAS_PWM 0x2000 ... That may break coprocessors where the firmware may expect a hardcoded specific timer.. So at least that should be checked before the change. If the specific timer is still needed for some firmware, it's best to add a separate function for the capabilities. Also, I believe it's up to the firmware running in secure mode to select the secure timers. So unless there's some way to query which timers are claimed by the secure mode, that too needs to be passed via DT. 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 1/1] ARM: OMAP3: igep0020: set GPIO mode for mux mcspi1_cs2 pin
* Javier Martinez Canillas jav...@dowhile0.org [120717 00:16]: Hi Tony, Just pinging to see if you have further comments on this patch or if it can be applied. It solves a bug on IGEPv2 boards. I know the trend is to move away from board code. I'll start working on an device tree for the IGEPv2 but it will take some time until is ready (and I'm not sure if all the OMAP3 support is already present on DT). So could you please take bug fixes for the board code in the meantime? Yes seems like something for the v3.6-rc series. 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
am3517: issue with omap3_l3_app_irq during heavy USB load
My system: am3517 based board with SMSC9514 attached to EHCI port 0 (not OTG), the rest of the USB ports are marked as disabled - OMAP_USBHS_PORT_MODE_UNUSED. Kernel: 3.3-rc7 from linux-omap (so far the latest kernel, where all hardware is supported) When performing network test only (nuttcp over SMSC9514's network interface) the system work reliably. But as soon as I start other USB activities (talking to a 3G modem/FTDI serial interfaces) I get following error: irq 10: nobody cared (try booting with the irqpoll option) [c0019d34] (unwind_backtrace+0x0/0x138) from [c007c1d4] (__report_bad_irq+0x24/0xc4) [c007c1d4] (__report_bad_irq+0x24/0xc4) from [c007c4a8] (note_interrupt+0x1d4/0x230) [c007c4a8] (note_interrupt+0x1d4/0x230) from [c007a99c] (handle_irq_event_percpu+0xa8/0x1a0) [c007a99c] (handle_irq_event_percpu+0xa8/0x1a0) from [c007aad0] (handle_irq_event+0x3c/0x5c) [c007aad0] (handle_irq_event+0x3c/0x5c) from [c007cb98] (handle_level_irq+0x8c/0x114) [c007cb98] (handle_level_irq+0x8c/0x114) from [c007a2e0] (generic_handle_irq+0x30/0x44) [c007a2e0] (generic_handle_irq+0x30/0x44) from [c0014e6c] (handle_IRQ+0x30/0x84) [c0014e6c] (handle_IRQ+0x30/0x84) from [c0008708] (omap3_intc_handle_irq+0x48/0x4c) [c0008708] (omap3_intc_handle_irq+0x48/0x4c) from [c0013b84] (__irq_svc+0x44/0x60) Exception stack(0xcf0e7f08 to 0xcf0e7f50) 7f00: 0001 cf0e5640 0040 c0730a44 7f20: cf0e6000 004e c0730a44 c0730a00 c06cfac8 000a cf0e7f50 7f40: c0071020 c003e96c 6113 [c0013b84] (__irq_svc+0x44/0x60) from [c003e96c] (__do_softirq+0x68/0x13c) [c003e96c] (__do_softirq+0x68/0x13c) from [c003ee7c] (irq_exit+0x8c/0x94) [c003ee7c] (irq_exit+0x8c/0x94) from [c0014e70] (handle_IRQ+0x34/0x84) [c0014e70] (handle_IRQ+0x34/0x84) from [c0008708] (omap3_intc_handle_irq+0x48/0x4c) [c0008708] (omap3_intc_handle_irq+0x48/0x4c) from [c0013d1c] (__irq_usr+0x3c/0x60) Exception stack(0xcf0e7fb0 to 0xcf0e7ff8) 7fa0: 00080188 0001 4000 7fc0: b6f85258 00080188 00080180 004e 2008 0058 1ffc 0006bcef 7fe0: b6f8400c be9e8bf8 b6eeecb9 b6ef9fa0 2030 handlers: [c002d2dc] omap3_l3_app_irq Disabling IRQ #10 and after some time this one: Unable to handle kernel NULL pointer dereference at virtual address 0034 pgd = c0004000 [0034] *pgd= Internal error: Oops: 17 [#1] CPU: 0Not tainted (3.3.0-rc7-dirty #127) PC is at usb_hcd_unlink_urb+0x48/0xc0 LR is at mark_held_locks+0x68/0x13c pc : [c0305560]lr : [c0070ea4]psr: 20070013 sp : cf189ec8 ip : cf188000 fp : cf189f40 r10: cfba0540 r9 : cf1f7cc0 r8 : c0718660 r7 : r6 : a0070013 r5 : cf1f7cc0 r4 : ff98 r3 : r2 : ff98 r1 : cf1f7cc0 r0 : 0001 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8f178019 DAC: 0015 Process kworker/0:1 (pid: 797, stack limit = 0xcf1882f0) Stack: (0xcf189ec8 to 0xcf18a000) 9ec0: c0718660 c04f614c cfba066c cfba0678 cfba066c c02fa22c 9ee0: cfba0540 cfba075c c06cecf4 cf820e00 0002 cf188000 c02fb350 9f00: cf194bc0 c06cecf4 cfba075c cf194bc0 c06cecf4 cf820e00 c004cb4c 9f20: 0002 c004cad0 0080 c02fb24c cf820e05 9f40: c0c48510 c07fc330 c060ef6c cf194bd0 cf194bc0 c06cecf4 c06ced14 9f60: cf194bd0 c0731c78 c06cecf0 cf188000 0009 c004e02c cf188038 9f80: 6013 cf1c9ed0 cf189fb4 cf194bc0 c004ded0 9fa0: c0052ae4 cf194bc0 0001 dead4ead 9fc0: c0732220 c05d0af0 cf189fd8 cf189fd8 9fe0: cf1c9ed0 cf1c9ed0 c0052a58 c0014f50 0013 c0014f50 [c0305560] (usb_hcd_unlink_urb+0x48/0xc0) from [c02fa22c] (unlink_urbs+0x4c/0xb4) [c02fa22c] (unlink_urbs+0x4c/0xb4) from [c02fb350] (kevent+0x104/0x354) [c02fb350] (kevent+0x104/0x354) from [c004cb4c] (process_one_work+0x190/0x448) [c004cb4c] (process_one_work+0x190/0x448) from [c004e02c] (worker_thread+0x15c/0x350) [c004e02c] (worker_thread+0x15c/0x350) from [c0052ae4] (kthread+0x8c/0x98) [c0052ae4] (kthread+0x8c/0x98) from [c0014f50] (kernel_thread_exit+0x0/0x8) Code: eb07c2f1 e5953028 e1a02004 e1a01005 (e5930034) ---[ end trace e4b7da5b6a7deeaf ]--- Unable to handle kernel paging request at virtual address fffc pgd = c0004000 [fffc] *pgd=8fefe821, *pte=, *ppte= Internal error: Oops: 17 [#2] CPU: 0Tainted: G D (3.3.0-rc7-dirty #127) PC is at kthread_data+0x4/0xc LR is at wq_worker_sleeping+0xc/0x98 pc : [c0052b78]lr : [c004e278]psr: 20070193 sp : cf189c28 ip : c06cf5e0 fp : cf189cc4 r10: c04fb1bc r9 : cf1cc298 r8 : cf1cc314 r7 : cf188000 r6 : cf1cc0b8 r5 : c06cf5e0 r4 : r3 : r2 : c06cf5e0 r1 : r0 : cf1cc0c0 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control:
Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. -- 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: [PATCHv4 7/8] ARM: OMAP: clockdomain: add support for preventing autodep delete
On Wed, 2012-07-18 at 12:45 +0530, Rajendra Nayak wrote: On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote: Anyway, it also looks like this fix is no longer needed with the latest kernel, something has changed with the gpio code / or latencies and it doesn't crash anymore. Thus, it looks like patches 7 8 can be dropped from this set for now. This is the behavior with beagleboard at least, if someone can verify this with some other omap3 hw that would be nice. I can test it on a omap3 SDP. What do you want me to test? Just try suspend + cpuidle with and without off-mode enabled and see if there are any problems. I've usually seen problems with off-mode myself. -Tero -- 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/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 8:59 AM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Regards, Tony -- Hi Tony, That was my first approach in fact, I sent this patch: https://patchwork.kernel.org/patch/1198401/ But then was told by Kevin Hilman that the right solution was to do the select on the drives to fix not only omap2plus_defconfig but any config. So I sent this patch and Santosh agrees with Kevin. I don't really know the hardware nor the driver well enough to have a strong position on this. 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 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. 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 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. Regards Santosh -- Hi Santosh, And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index aa131b3..314c7bd 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA config MMC_OMAP tristate TI OMAP Multimedia Card Interface support - depends on ARCH_OMAP + depends on ARCH_OMAP DMADEVICES DMA_OMAP select TPS65010 if MACH_OMAP_H2 help This selects the TI OMAP Multimedia card Interface. @@ -242,7 +242,8 @@ config MMC_OMAP config MMC_OMAP_HS tristate TI OMAP High Speed Multimedia Card Interface support - depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4 + depends on (SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4) \ + DMADEVICES DMA_OMAP help This selects the TI OMAP High Speed Multimedia card Interface. If you have an OMAP2430 or OMAP3 board or OMAP4 board with a diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index cd2fe35..1c23242 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -237,7 +237,7 @@ config SPI_OMAP_UWIRE config SPI_OMAP24XX tristate McSPI driver for OMAP - depends on ARCH_OMAP2PLUS + depends on ARCH_OMAP2PLUS DMADEVICES DMA_OMAP help SPI master controller for OMAP24XX and later Multichannel SPI (McSPI) modules. 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: [v3.6 3/3] iommu/tegra: smmu: Fix unsleepable memory allocation at alloc_pdir()
joerg.roe...@amd.com joerg.roe...@amd.com wrote @ Tue, 17 Jul 2012 15:23:00 +0200: On Tue, Jul 17, 2012 at 02:25:24PM +0200, Hiroshi Doyu wrote: The above spin_lock is always necessary. as-lock should be held to protect as-pdir_page. Only when as-pdir_page is NULL, as-pdir_page would be allocated in alloc_pdir(). Without this lock, the following race could happen: Without as-lock: A: B: i == 3 pdir_page == NULL i == 3 pdir_page == NULL pdir_page = a; pdir_page = b; !! OVERWRITTEN !! Unless I am missing something, this is not the correct situation with my patch. It would look more like this: A: B: i == 3 pdir_page == NULL i == 3 pdir_page == NULL take as-lock /* race check */ pdir_page == NULL - proceed /* spinning on as-lock */ pdir_page = a; release as-lock take as-lock /* race check */ pdir_page != NULL - return This should be fine, no? Do I miss something? You are right. I didn't get the point of your patch. In the case that you can return -EAGAIN, the complicated lock,unlock,lock,check race is not necessary as you did. Verified the patch w/ Tegra3 based board. Please put this into next queue. Thanks. -- 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: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Tue, 2012-07-17 at 03:11 -0500, Menon, Nishanth wrote:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 86fc513..828e7b8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -208,6 +208,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+ .context_offs = USHRT_MAX,
OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will
need to know when it lost context to be able to reload it's firmware,
no?
You are right, this should be possible to use. I just searched for
modules which didn't have context_offs defined and added USHRT_MAX
blindly there.
-Tero
--
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: [PATCHv4 7/8] ARM: OMAP: clockdomain: add support for preventing autodep delete
On Wednesday 18 July 2012 01:35 PM, Tero Kristo wrote: On Wed, 2012-07-18 at 12:45 +0530, Rajendra Nayak wrote: On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote: Anyway, it also looks like this fix is no longer needed with the latest kernel, something has changed with the gpio code / or latencies and it doesn't crash anymore. Thus, it looks like patches 7 8 can be dropped from this set for now. This is the behavior with beagleboard at least, if someone can verify this with some other omap3 hw that would be nice. I can test it on a omap3 SDP. What do you want me to test? Just try suspend + cpuidle with and without off-mode enabled and see if there are any problems. I've usually seen problems with off-mode myself. So I just knocked off the last 2 patches from 'mainline-3.5-rc6-pwrdm- changes-v4' and tested on my 3430 SDP. I was able to hit RET and OFF in both suspend and cpuidle. Did not see any issues. -Tero -- 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/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 2:19 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. Regards Santosh -- Hi Santosh, And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index aa131b3..314c7bd 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA config MMC_OMAP tristate TI OMAP Multimedia Card Interface support - depends on ARCH_OMAP + depends on ARCH_OMAP DMADEVICES DMA_OMAP May be. But since for sure a driver knows that it needs DMA support to be enabled, I will just select it rather than depends on. 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: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Tue, 2012-07-17 at 02:59 -0500, Menon, Nishanth wrote:
Couple of minor comments:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
[...]
/**
+ * _omap4_update_context_lost - increment hwmod context loss counter if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ return;
would'nt it be better to return a dummy incremental counter instead of
returning no context loss (count = 0)?
I guess you are right, this way we may have some extra context restores
for modules which don't have context offs defined, rather than not
restoring them at all. Only thing I can think might prevent this is if
there are modules that never lose context but don't have context
register? How about omap5+?
+
+ r =
omap4_prminst_read_inst_reg(oh-clkdm-pwrdm.ptr-prcm_partition,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.context_offs);
+
+ if (!r)
+ return;
+
+ oh-prcm.omap4.context_lost_counter++;
need to be careful about counter overflow.
Well, this code can't do much for that even if it overflows... the type
for the context_lost_counter is unsigned though, maybe it should be
expanded if you are worried...?
-Tero
--
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: [PATCHv4 7/8] ARM: OMAP: clockdomain: add support for preventing autodep delete
On Wed, 2012-07-18 at 14:34 +0530, Rajendra Nayak wrote: On Wednesday 18 July 2012 01:35 PM, Tero Kristo wrote: On Wed, 2012-07-18 at 12:45 +0530, Rajendra Nayak wrote: On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote: Anyway, it also looks like this fix is no longer needed with the latest kernel, something has changed with the gpio code / or latencies and it doesn't crash anymore. Thus, it looks like patches 7 8 can be dropped from this set for now. This is the behavior with beagleboard at least, if someone can verify this with some other omap3 hw that would be nice. I can test it on a omap3 SDP. What do you want me to test? Just try suspend + cpuidle with and without off-mode enabled and see if there are any problems. I've usually seen problems with off-mode myself. So I just knocked off the last 2 patches from 'mainline-3.5-rc6-pwrdm- changes-v4' and tested on my 3430 SDP. I was able to hit RET and OFF in both suspend and cpuidle. Did not see any issues. Okay thanks, so it looks pretty safe then. -Tero -- 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/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 11:11 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 2:19 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. Regards Santosh -- Hi Santosh, And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index aa131b3..314c7bd 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA config MMC_OMAP tristate TI OMAP Multimedia Card Interface support - depends on ARCH_OMAP + depends on ARCH_OMAP DMADEVICES DMA_OMAP May be. But since for sure a driver knows that it needs DMA support to be enabled, I will just select it rather than depends on. Regards santosh Yes I agree with you, I was just exploring other options :-) 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: [PATCHv6 2/7] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.
Hi
one trivial comment
On Mon, 11 Jun 2012, Tero Kristo wrote:
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 46ab9d9..8d7de4f 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -88,6 +88,8 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
+#define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_xxx(1 0)
xxx isn't unique, nor is it descriptive :-)
Looking at the mail threads on this one, it sounds like there may not be a
public erratum number associated with this. If there is, the 'xxx' should
be replaced with the number. If there isn't, then it would be good to
make up something short, like GICD to replace the xxx.
- 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 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 2:46 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Wed, Jul 18, 2012 at 11:11 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 2:19 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. Regards Santosh -- Hi Santosh, And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index aa131b3..314c7bd 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA config MMC_OMAP tristate TI OMAP Multimedia Card Interface support - depends on ARCH_OMAP + depends on ARCH_OMAP DMADEVICES DMA_OMAP May be. But since for sure a driver knows that it needs DMA support to be enabled, I will just select it rather than depends on. Regards santosh Yes I agree with you, I was just exploring other options :-) For MMC atleast, there's already a patch in mmc-next to do a Depends On http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=7c68046c99f0b96d965c31cf42814b9a0f15ad46 -- 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] OMAP4: 4430sdp: OTG: increase max allowed output current
Hi,
On Fri, Jul 13, 2012 at 8:53 AM, ABRAHAM, KISHON VIJAY kis...@ti.com
wrote:
Hi,
On Thu, Jul 12, 2012 at 6:55 PM, Ruslan Bilovol ruslan.bilo...@ti.com
wrote:
TWL6030/32 that is used on 4430sdp board can deliver up to 200mA
for OTG port power supply in the HOST mode.
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 8e17284..10223f5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -429,7 +429,7 @@ static struct platform_device *sdp4430_devices[]
__initdata = {
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
.mode = MUSB_OTG,
- .power = 100,
+ .power = 200,
};
Shouldn't this change be made for omap4 panda as well.
Yes, omap4 panda uses same TWL IC. Should I fix this patch or send
separate for panda?
--
Best regards,
Ruslan Bilovol
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: tps65217: fix build error if REGULATOR is not enabled
On Wed, Jul 18, 2012 at 12:11:03PM +0530, AnilKumar Ch wrote: Fixes below build error if CONFIG_REGULATOR is not enabled. drivers/built-in.o: In function `tps65217_probe': tps65217.c:(.devinit.text+0x13e37): undefined reference to `of_regulator_match' This isn't a patch to the regulator driver, this is a patch to the MFD. Normally this would be fixed by making the MFD driver not depend on the regulator API - why is the MFD driver using the regulator API? signature.asc Description: Digital signature
Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 3:08 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 2:46 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: [...] And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index aa131b3..314c7bd 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA config MMC_OMAP tristate TI OMAP Multimedia Card Interface support - depends on ARCH_OMAP + depends on ARCH_OMAP DMADEVICES DMA_OMAP May be. But since for sure a driver knows that it needs DMA support to be enabled, I will just select it rather than depends on. Regards santosh Yes I agree with you, I was just exploring other options :-) For MMC atleast, there's already a patch in mmc-next to do a Depends On http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=7c68046c99f0b96d965c31cf42814b9a0f15ad46 Change log assumes says . The patch simply make them depend on DMA_OMAP since DMA_OMAP will select DMA_ENGINE automatically This won't be true if the DMA selection are not done at ARCH_OMAP level as discussed in this thread. Having said that, I think Russell and Tony need to take call on how this needs to be handled. 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-V2 4/4] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
On Wed, Jul 18, 2012 at 01:29:01, Paul Walmsley wrote:
Hi Vaibhav
a comment.
On Tue, 29 May 2012, Vaibhav Hiremath wrote:
This patch adds HWMOD data for all the peripherals of
AM335X device and also hooks up to the existing OMAP framework.
...
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
new file mode 100644
index 000..df888fe
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -0,0 +1,3368 @@
...
+static struct omap_hwmod_irq_info am33xx_emif_irqs[] = {
+ { .name = ddrerr0, .irq = 101 },
+ { .irq = -1 }
+};
So the above array of struct omap_hwmod_irq_info records has a terminator
(which is correct), but many similar arrays do not, such as:
+/* l3_main (l3_fast) */
+static struct omap_hwmod_irq_info am33xx_l3_main_irqs[] = {
+ { .name = l3debug, .irq = 9 },
+ { .name = l3appint, .irq = 10 },
+};
and
+static struct omap_hwmod_irq_info am33xx_mpu_irqs[] = {
+ { .name = emuint, .irq = 0 },
+ { .name = commtx, .irq = 1 },
+ { .name = commrx, .irq = 2 },
+ { .name = bench, .irq = 3 },
+};
and
+static struct omap_hwmod_rst_info am33xx_wkup_m3_resets[] = {
+ { .name = wkup_m3, .rst_shift = 3, .st_shift = 5 },
+};
+
+static struct omap_hwmod_irq_info am33xx_wkup_m3_irqs[] = {
+ { .name = txev, .irq = 78 },
+};
and several others.
Could you add those, please?
Thanks Paul for the review, I will fix it next version.
The omap_hwmod_dma_info arrays look clean to me.
Have you done with review? Should I wait for further comments or submit the
next version?
Thanks,
Vaibhav
--
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: [PATCHv6 2/7] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.
On Wed, 2012-07-18 at 03:17 -0600, Paul Walmsley wrote:
Hi
one trivial comment
On Mon, 11 Jun 2012, Tero Kristo wrote:
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 46ab9d9..8d7de4f 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -88,6 +88,8 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
+#define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_xxx (1 0)
xxx isn't unique, nor is it descriptive :-)
Looking at the mail threads on this one, it sounds like there may not be a
public erratum number associated with this. If there is, the 'xxx' should
be replaced with the number. If there isn't, then it would be good to
make up something short, like GICD to replace the xxx.
There isn't public erratum number for this, thats the reason for xxx. I
can change the xxx to GICD though if that is better.
-Tero
--
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: OMAP3: clockdomain: fix accidental duplicate registration
Hi On Mon, 16 Jul 2012, Tony Lindgren wrote: Hmm well it seems that we should apply this fix into arm-soc next/cleanup branch if that's where the mismerge happened? It seems the same mismerge is there even without 16e5e2c4? The arm-soc next/cleanup copy of mach-omap2/clockdomains3xxx_data.c is correct. The problem that my patch was designed to fix doesn't exist in that version of the file (868c157df9721675c19729eed2c96bac6c3f1d01). You patch applies into arm-soc next/cleanup with fuzz: patching file arch/arm/mach-omap2/clockdomain.c patching file arch/arm/mach-omap2/clockdomain.h Hunk #1 succeeded at 82 (offset -4 lines). patching file arch/arm/mach-omap2/clockdomains3xxx_data.c Hunk #1 succeeded at 347 with fuzz 2 (offset -107 lines). So that's why I'm wondering if it needs some changes. OK, I understand why you're asking. I went back and researched it. The patch that I sent is only needed because the conflict resolution in merge commit 3dd50d0545bd5a8ad83d4339f07935cd3e883271 (Merge tag 'omap-cleanup-for-v3.6' into tmp-merge) adds mpu_3xxx_clkdm back into the clockdomains_common list. The previous commit on that file 16e5e2c471ab889f838bfe1c44032d0481c115e1 removed mpu_3xxx_clkdm from the common list, because the AM35xx chips needed to use a different MPU clockdomain structure from the OMAP3xxx chips. Or, put differently: Before 16e5e2c471ab889f838bfe1c44032d0481c115e1, it was correct to have mpu_3xxx_clkdm in the common list. That's what's in arm-soc next/cleanup and that data is correct. After 16e5e2c471ab889f838bfe1c44032d0481c115e1, it's incorrect to have mpu_3xxx_clkdm in the common list. Hope this isn't even more confusing :-) - 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 4/4] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
On Wed, 18 Jul 2012, Hiremath, Vaibhav wrote: Have you done with review? Should I wait for further comments or submit the next version? Please go ahead and post the next version, I haven't found any other issues with it yet. - 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: [PATCHv6 2/7] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.
On Wed, 18 Jul 2012, Tero Kristo wrote: There isn't public erratum number for this, thats the reason for xxx. I can change the xxx to GICD though if that is better. Yep please do (or something else more meaningful than GICD if you can think of something better). - 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] regulator: tps65217: fix build error if REGULATOR is not enabled
Mark, On Wed, Jul 18, 2012 at 15:14:49, Mark Brown wrote: On Wed, Jul 18, 2012 at 12:11:03PM +0530, AnilKumar Ch wrote: Fixes below build error if CONFIG_REGULATOR is not enabled. drivers/built-in.o: In function `tps65217_probe': tps65217.c:(.devinit.text+0x13e37): undefined reference to `of_regulator_match' This isn't a patch to the regulator driver, this is a patch to the MFD. Normally this would be fixed by making the MFD driver not depend on the regulator API - why is the MFD driver using the regulator API? Regulators platform data is added to platform device in MFD driver, which we need for regulator driver, of_regulator_match() is used to check the regulator consumers if we pass DT data. If we do not enable CONFIG_REGULATOR then of_regulator_match() is not exported, so we see this error. Regards AnilKumar -- 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] regulator: tps65217: fix build error if REGULATOR is not enabled
On Wed, Jul 18, 2012 at 09:55:57AM +, AnilKumar, Chimata wrote: Regulators platform data is added to platform device in MFD driver, which we need for regulator driver, of_regulator_match() is used to check the regulator consumers if we pass DT data. If we do not enable CONFIG_REGULATOR then of_regulator_match() is not exported, so we see this error. Why are you doing that in the MFD driver? signature.asc Description: Digital signature
RE: [PATCH v2 06/11] arm/dts: am33xx: Add dt data for usbss
Hi,
On 17-07-2012 13:13, Ajay Kumar Gupta wrote:
Added device tree data for usbss on am33xx. There are two musb
controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..b572803 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ usb_otg_hs: usb_otg_hs@4740 {
The reg property is absent, so why did you give the node name the
address postfix?
Currently reg property is coming from ti hwmods.
Thanks,
Ajay
+ compatible = ti,musb-am33xx;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ port0_mode = 3;
+ port1_mode = 1;
+ power = 250;
+ };
WBR, Sergei
--
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: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
-Original Message-
From: Mark A. Greer mgr...@animalcreek.com
To: Paul Walmsley p...@pwsan.com
Cc: Joe Woodward j...@terrafix.co.uk, Kevin Hilman khil...@ti.com,
linux-omap@vger.kernel.org
Date: Tue, 17 Jul 2012 19:20:35 -0700
Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
On Tue, Jul 17, 2012 at 01:28:13PM -0600, Paul Walmsley wrote:
Hi Joe, Mark,
On Tue, 17 Jul 2012, Joe Woodward wrote:
The patch you sent is basically in two halves:
- the writes to the registers
- the calling of omap3_iva_idle().
If I patch only the writes to the registers then suspend still
fails.
If I patch only the calling of omap3_iva_idle() then suspend works.
If I patch both the writes to the registers and the calling of
omap3_iva_idle() then suspend works.
Wow, that's unexpected. Thanks very much for trying this.
Well Mark, I guess that's your answer. Looks like the IVA is still
running on that AM3703 chip. I guess it's probably best to do both
halves, anyway.
How does this look?
Based on linux-omap/master (ce6b8b760e2fef013b1038e5398580d187f80c00).
I'm not very creative when it comes to naming this thing so I'm
happy if you have a better idea. I tested it on an am37xevm and
tried to test on an am35xevm but it appears that the am35xevm is
broken in that branch. :(
Mark
--
From b889b2642bd16b3d8e5856f39a3ea08d10102aad Mon Sep 17 00:00:00 2001
From: Mark A. Greer mgr...@animalcreek.com
Date: Tue, 17 Jul 2012 18:50:01 -0700
Subject: [PATCH] ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature
It appears that the am3703 and possibly the am3715 SoCs
have an active IVA subsystem even though the CONTROL_IDCODE
register indicates that they don't. From experimentation,
it seems that the IVA still requires some registers to be
initialized even though we don't want it fully functional.
To accomplish this, add a new feature (OMAP3_HAS_IVA_REGS)
that indicates that the IVA should be initialized but not
really used.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/pm34xx.c |4 ++--
arch/arm/plat-omap/include/plat/cpu.h | 22 --
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 40373db..4072fbd 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -242,7 +242,7 @@ void __init omap3xxx_check_features(void)
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
if (cpu_is_omap3630())
- omap_features |= OMAP3_HAS_192MHZ_CLK;
+ omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS;
if (cpu_is_omap3430() || cpu_is_omap3630())
omap_features |= OMAP3_HAS_IO_WAKEUP;
if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..119cbf0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -545,7 +545,7 @@ static void __init prcm_setup_regs(void)
OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
/* Don't attach IVA interrupts */
- if (omap3_has_iva()) {
+ if (omap3_has_iva() || omap3_has_iva_regs()) {
omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
@@ -565,7 +565,7 @@ static void __init prcm_setup_regs(void)
/* Clear any pending PRCM interrupts */
omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- if (omap3_has_iva())
+ if (omap3_has_iva() || omap3_has_iva_regs())
omap3_iva_idle();
omap3_d2d_idle();
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 68b180e..2509bf4 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -451,16 +451,17 @@ extern u32 omap_features;
#define OMAP3_HAS_L2CACHEBIT(0)
#define OMAP3_HAS_IVABIT(1)
-#define OMAP3_HAS_SGXBIT(2)
-#define OMAP3_HAS_NEON BIT(3)
-#define OMAP3_HAS_ISPBIT(4)
-#define OMAP3_HAS_192MHZ_CLK BIT(5)
-#define OMAP3_HAS_IO_WAKEUP BIT(6)
-#define OMAP3_HAS_SDRC BIT(7)
-#define OMAP3_HAS_IO_CHAIN_CTRL BIT(8)
-#define OMAP4_HAS_MPU_1GHZ BIT(9)
-#define OMAP4_HAS_MPU_1_2GHZ BIT(10)
-#define OMAP4_HAS_MPU_1_5GHZ BIT(11)
+#define OMAP3_HAS_IVA_REGS BIT(2)
+#define OMAP3_HAS_SGXBIT(3)
+#define OMAP3_HAS_NEON BIT(4)
+#define
[RFC][PATCH 1/1] ARM: OMAP2+: PM: Register suspend ops even in the presence of DT blob
As per the comment in omap2_common_late_init() looks like the
original intent of the DT check was to treat only the PMIC
and SR initialization differently. Recent changes to consolidate
the suspend-resume code across OMAP3/4 resulted into the
registration of suspend ops also being dependent on the check
for DT blob. Since the suspend-resume operation should not
really be dependent on the usage of DT, move the suspend ops
registration before the check for DT.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/pm.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 9cb5ced..21761c0 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -297,6 +297,10 @@ postcore_initcall(omap2_common_pm_init);
int __init omap2_common_pm_late_init(void)
{
+#ifdef CONFIG_SUSPEND
+ suspend_set_ops(omap_pm_ops);
+#endif
+
/*
* In the case of DT, the PMIC and SR initialization will be done using
* a completely different mechanism.
@@ -316,9 +320,5 @@ int __init omap2_common_pm_late_init(void)
/* Smartreflex device init */
omap_devinit_smartreflex();
-#ifdef CONFIG_SUSPEND
- suspend_set_ops(omap_pm_ops);
-#endif
-
return 0;
}
--
1.7.0.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 v4 04/11] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba24d15..c50d828 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5922,6 +5922,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
1.7.5.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 v4 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 22 +++
drivers/usb/otg/twl6030-usb.c | 39 +---
2 files changed, 48 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..e3f6d73
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,22 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts when
+ the controller has to act as host and the second interrupt number is the
+ usb interrupt number that raises VBUS interrupts when the controller has to
+ act as device
+ - usb-supply : phandle to the regulator device tree node. It should be vusb
+ if it is twl6030 or ldousb if it is twl6025 subclass.
+
+twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ regulator = vusb;
+};
+
+Board specific device node entry
+twl6030-usb {
+ usb-supply = vusb;
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 9994dd22..6b0d0a1 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8 asleep;
boolirq_enabled;
boolvbus_enable;
- unsigned long features;
+ const char *regulator;
};
#definecomparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
- char *regulator_name;
-
- if (twl-features TWL6025_SUBCLASS)
- regulator_name = ldousb;
- else
- regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+ twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
@@ -321,9 +314,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
{
struct twl6030_usb *twl;
int status, err;
- struct twl4030_usb_data *pdata;
- struct device *dev = pdev-dev;
- pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct device *dev = pdev-dev;
+ struct twl4030_usb_data *pdata = dev-platform_data;
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -332,13 +325,24 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-dev= pdev-dev;
twl-irq1 = platform_get_irq(pdev, 0);
twl-irq2 = platform_get_irq(pdev, 1);
- twl-features = pdata-features;
twl-linkstat = OMAP_MUSB_UNKNOWN;
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp = twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
+ if (np) {
+ twl-regulator = usb;
+ } else if (pdata) {
+ if (pdata-features TWL6025_SUBCLASS)
+ twl-regulator = ldousb;
+ else
+ twl-regulator = vusb;
+ } else {
+ dev_err(pdev-dev, twl6030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -400,12 +404,21 @@ static int __exit twl6030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+ { .compatible = ti,twl6030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl6030_usb_id_table);
+#endif
+
static struct platform_driver twl6030_usb_driver = {
.probe = twl6030_usb_probe,
.remove = __exit_p(twl6030_usb_remove),
.driver = {
.name = twl6030_usb,
.owner = THIS_MODULE,
+ .of_match_table =
[PATCH v4 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/bus/omap-ocp2scp.txt |3 +
Documentation/devicetree/bindings/usb/omap-usb.txt | 16 ++
drivers/usb/otg/Kconfig| 10 +
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap-usb2.c| 271
include/linux/usb/omap_usb.h | 45
include/linux/usb/phy_companion.h | 34 +++
7 files changed, 380 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
create mode 100644 drivers/usb/otg/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
index d2fe064..bb0c7f4 100644
--- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -8,3 +8,6 @@ properties:
Sub-nodes:
All the devices connected to ocp2scp are described using sub-node to ocp2scp
+- usb2phy :
+ The binding details of usb2phy can be found in:
+ Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..80a28c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,16 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@0x4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58;
+};
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..c751db7 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,16 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP_USB2
+ tristate OMAP USB2 PHY Driver
+ depends on OMAP_OCP2SCP
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..2c2a3ca 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..2f9e257
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,271 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include
[PATCH v4 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Writing to control module which is now handled in omap2430.c should be
removed once a driver for control module is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 52 ---
drivers/usb/musb/omap2430.h |9 +++
drivers/usb/otg/twl6030-usb.c | 114 +
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..addbebf 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -44,6 +44,7 @@ struct omap2430_glue {
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
+ u32 __iomem *control_otghs;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -51,6 +52,26 @@ struct omap2430_glue *_glue;
static struct timer_list musb_idle_timer;
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+ if (glue-control_otghs)
+ writel(val, glue-control_otghs);
+}
+
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
@@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
+ u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
}
- usb_phy_shutdown(musb-xceiv);
+ val = SESSEND | IDDIG;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, ID float\n);
@@ -366,6 +391,7 @@ err1:
static void omap2430_musb_enable(struct musb *musb)
{
u8 devctl;
+ u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
@@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue-status) {
case OMAP_MUSB_ID_GROUND:
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
if (data-interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
@@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
case OMAP_MUSB_VBUS_VALID:
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
@@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb)
static void omap2430_musb_disable(struct musb *musb)
{
+ u32 val;
struct device *dev = musb-controller;
struct omap2430_glue *glue =
[PATCH v4 08/11] arm/dts: Add twl4030-usb data
Add twl4030-usb data node in twl4030 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..761a5a5 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = 315;
};
+ vusb1v5: regulator-vusb1v5 {
+ compatible = ti,twl4030-vusb1v5;
+ };
+
+ vusb1v8: regulator-vusb1v8 {
+ compatible = ti,twl4030-vusb1v8;
+ };
+
+ vusb3v1: regulator-vusb3v1 {
+ compatible = ti,twl4030-vusb3v1;
+ };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+ };
};
--
1.7.5.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 v4 06/11] arm/dts: Add twl6030-usb data
Add twl6030-usb data node in twl6030 device tree file
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts |4
arch/arm/boot/dts/omap4-sdp.dts |4
arch/arm/boot/dts/twl6030.dtsi|6 ++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 1efe0c5..7052422 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -89,3 +89,7 @@
ti,non-removable;
bus-width = 4;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..6326d7c 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,3 +158,7 @@
bus-width = 4;
ti,non-removable;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..5efd6d3 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -83,4 +83,10 @@
clk32kg: regulator@12 {
compatible = ti,twl6030-clk32kg;
};
+
+ twlusb: twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ regulator = vusb;
+ };
};
--
1.7.5.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 v4 02/11] arm/dts: omap: Add omap-usb2 dt data
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29c6243..15f1890 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x1;
+ };
};
};
};
--
1.7.5.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 v4 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
drivers/usb/musb/omap2430.c| 55
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..331e477 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +638,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
+
[PATCH v4 00/11] omap: musb: Add device tree support
This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v3: remove the address in the node name of usb_otg_hs since the usb_otg_hs node doesn't have a reg property. Thanks Ajay Gupta for finding this. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 48 .../devicetree/bindings/usb/twl-usb.txt| 41 +++ arch/arm/boot/dts/omap3-beagle.dts |6 + arch/arm/boot/dts/omap3-evm.dts|6 + arch/arm/boot/dts/omap3.dtsi |8 + arch/arm/boot/dts/omap4-panda.dts | 10 + arch/arm/boot/dts/omap4-sdp.dts| 10 + arch/arm/boot/dts/omap4.dtsi | 13 + arch/arm/boot/dts/twl4030.dtsi | 21 ++ arch/arm/boot/dts/twl6030.dtsi |6 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/omap2430.c| 107 +++- drivers/usb/musb/omap2430.h|9 + drivers/usb/otg/Kconfig| 10 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/omap-usb2.c| 271 drivers/usb/otg/twl4030-usb.c | 26 ++- drivers/usb/otg/twl6030-usb.c | 153 +++ include/linux/usb/omap_usb.h | 45 include/linux/usb/phy_companion.h | 34 +++ 24 files changed, 706 insertions(+), 273 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 drivers/usb/otg/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 1.7.5.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 v4 10/11] arm/dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3.dtsi |8
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi |8
6 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
mmc3 {
status = disable;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..f2694c9 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = ti,omap3-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 7052422..dd19370 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -93,3 +93,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 6326d7c..0fc10d4 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -162,3 +162,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 15f1890..3a6c3fa 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -285,5 +285,13 @@
0x4a002300 0x1;
};
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
--
1.7.5.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 v4 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb
Add device tree support for twl4030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 19 ++
drivers/usb/otg/twl4030-usb.c | 26 +++
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index e3f6d73..bdf1dd4 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -20,3 +20,22 @@ Board specific device node entry
twl6030-usb {
usb-supply = vusb;
};
+
+TWL4030 USB PHY AND COMPARATOR
+ - compatible : Should be ti,twl4030-usb
+ - interrupts : The interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts
+ and VBUS interrupts. The second interrupt number is optional.
+ - supply-name-supply : phandle to the regulator device tree node.
+ supply-name should be vusb1v5, vusb1v8 and vusb3v1
+ - usb_mode : The mode used by the phy to connect to the controller. 1
+ specifies ULPI mode and 2 specifies CEA2011_3PIN mode.
+
+twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+};
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 523cad5..f0d2e75 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
struct twl4030_usb *twl;
int status, err;
struct usb_otg *otg;
-
- if (!pdata) {
- dev_dbg(pdev-dev, platform_data not available\n);
- return -EINVAL;
- }
+ struct device_node *np = pdev-dev.of_node;
twl = devm_kzalloc(pdev-dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
+ if (np)
+ of_property_read_u32(np, usb_mode,
+ (enum twl4030_usb_mode *)twl-usb_mode);
+ else if (pdata)
+ twl-usb_mode = pdata-usb_mode;
+ else {
+ dev_err(pdev-dev, twl4030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
otg = devm_kzalloc(pdev-dev, sizeof *otg, GFP_KERNEL);
if (!otg)
return -ENOMEM;
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
- twl-usb_mode = pdata-usb_mode;
twl-vbus_supplied = false;
twl-asleep = 1;
twl-linkstat = OMAP_MUSB_UNKNOWN;
@@ -690,12 +695,21 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_usb_id_table[] = {
+ { .compatible = ti,twl4030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl4030_usb_id_table);
+#endif
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
.driver = {
.name = twl4030_usb,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl4030_usb_id_table),
},
};
--
1.7.5.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 v4 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 138 ---
arch/arm/mach-omap2/twl-common.c|5 -
arch/arm/mach-omap2/usb-musb.c |3 -
3 files changed, 0 insertions(+), 146 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..874aecc 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
#include plat/usb.h
#include control.h
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF 0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL 0x33c
-#defineAVALID BIT(0)
-#defineBVALID BIT(1)
-#defineVBUSVALID BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
- ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
- if (!ctrl_base) {
- pr_err(control module ioremap failed\n);
- return -ENOMEM;
- }
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- if (!dev) {
- iounmap(ctrl_base);
- return 0;
- }
-
- phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
- if (IS_ERR(phyclk)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
- iounmap(ctrl_base);
- return PTR_ERR(phyclk);
- }
-
- clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
- if (IS_ERR(clk48m)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
- clk_put(phyclk);
- iounmap(ctrl_base);
- return PTR_ERR(clk48m);
- }
-
- clk32k = clk_get(dev, usb_phy_cm_clk32k);
- if (IS_ERR(clk32k)) {
- dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
- clk_put(phyclk);
- clk_put(clk48m);
- iounmap(ctrl_base);
- return PTR_ERR(clk32k);
- }
- return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
- static int state;
-
- if (on !state) {
- /* Enable the phy clocks */
- clk_enable(phyclk);
- clk_enable(clk48m);
- clk_enable(clk32k);
- state = 1;
- } else if (state) {
- /* Disable the phy clocks */
- clk_disable(phyclk);
- clk_disable(clk48m);
- clk_disable(clk32k);
- state = 0;
- }
- return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
- if (on) {
- if (ID)
- /* enable VBUS valid, IDDIG groung */
- __raw_writel(AVALID | VBUSVALID, ctrl_base +
- USBOTGHS_CONTROL);
- else
- /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
- __raw_writel(IDDIG | AVALID | VBUSVALID,
- ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable session END and IDIG to high impedance. */
- __raw_writel(SESSEND | IDDIG, ctrl_base +
- USBOTGHS_CONTROL);
- }
- return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
- if (suspend) {
- /* Disable the clocks */
- omap4430_phy_set_clk(dev, 0);
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- /* save the context */
- usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable the internel phy clcoks */
- omap4430_phy_set_clk(dev, 1);
- /* power on the phy */
- if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) PHY_PD) {
- __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
- }
-
- /* restore the context */
- __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
- }
-
- return 0;
-}
-
-int omap4430_phy_exit(struct device *dev)
-{
- if (ctrl_base)
-
RE: OMAP PM late init with DT blob
Hi Paul, On Wed, Jul 18, 2012 at 02:03:04, Paul Walmsley wrote: On Tue, 17 Jul 2012, Bedia, Vaibhav wrote: I am looking at adding PM support for AM335x based on l-o/master. arch/arm/mach-omap2/pm.c has the following comment: /* * In the case of DT, the PMIC and SR initialization will be done using * a completely different mechanism. * Disable this part if a DT blob is available. */ if (of_have_populated_dt()) return 0; Basic DT support for AM335x is already in mainline so this check causes various PM related inits and also the registration of the suspend ops to be skipped. I tried searching the list archives for any discussion on this but could not find anything. Can someone shed some light on the how the device tree is to be used for PMIC and SR initialization. Any objections to moving the suspend ops registration before the DT blob check? Moving the registration makes sense to me, based on a quick look. IMHO, a better approach for this code would be to reverse the sense of that of_have_populated_dt() test, and specifically wrap the parts that are going to be changed by DT. The rationale here is that only certain steps need to be skipped, so those should probably be skipped explicitly rather than skipping the whole function. I checked the different inits which get skipped right now. I think _init_voltages() should not really be dependent on the DT check to cover the cases wherein the voltages are controlled using a regular regulator driver. However right now I don't know what approach to take here. For now I have sent an RFC patch [1] with just the movement of suspend ops. Regards, Vaibhav B. [1] http://marc.info/?l=linux-omapm=134260813520149w=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: [RFC/PATCH 3/3] i2c: omap: Add support for I2C_M_STOP message flag
Hi Shubhrajyoti, On Wednesday 18 July 2012 11:49:24 Shubhrajyoti wrote: On Tuesday 26 June 2012 07:47 PM, Laurent Pinchart wrote: Generate a stop condition after each message marked with I2C_M_STOP. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 801df60..cf1bda0 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -545,6 +545,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, if (dev-speed 400) w |= OMAP_I2C_CON_OPMODE_HS; + if (msg-flags I2C_M_STOP) + stop = 1; How about patching omap_i2c_xfer (caller) instead. There are some debug prints of stop above that will not reflect the real value. omap_i2c_xfer() doesn't look at the content of individual messages, I thought it was cleaner not to modify that. Note that the message flags are printed in the debug message you mention, which is why I've decided to modify the stop variable after printing the message. If you think it's better to modify it before, we can move this chunk above the dev_dbg(). if (msg-flags I2C_M_TEN) w |= OMAP_I2C_CON_XA; if (!(msg-flags I2C_M_RD)) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 3/3] i2c: omap: Add support for I2C_M_STOP message flag
On Wed, Jul 18, 2012 at 4:43 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Shubhrajyoti, On Wednesday 18 July 2012 11:49:24 Shubhrajyoti wrote: On Tuesday 26 June 2012 07:47 PM, Laurent Pinchart wrote: Generate a stop condition after each message marked with I2C_M_STOP. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 801df60..cf1bda0 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -545,6 +545,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, if (dev-speed 400) w |= OMAP_I2C_CON_OPMODE_HS; + if (msg-flags I2C_M_STOP) + stop = 1; How about patching omap_i2c_xfer (caller) instead. There are some debug prints of stop above that will not reflect the real value. omap_i2c_xfer() doesn't look at the content of individual messages, I thought it was cleaner not to modify that. OK fair enough. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 06/11] arm/dts: am33xx: Add dt data for usbss
Hi
On 17-07-2012 13:13, Ajay Kumar Gupta wrote:
Added device tree data for usbss on am33xx. There are two musb
controllers
on am33xx platform so have port0_mode and port1_mode additional
data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..b572803 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ usb_otg_hs: usb_otg_hs@4740 {
The reg property is absent, so why did you give the node name
the
address postfix?
Currently reg property is coming from ti hwmods.
I meant base addresses are coming from hwmods and so there is no reg
property added here. I will update the patch dropping address postfix.
Ajay
+ compatible = ti,musb-am33xx;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ port0_mode = 3;
+ port1_mode = 1;
+ power = 250;
+ };
WBR, Sergei
--
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
--
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] PWM: Add support for configuring polarity of PWM
Duty cycle inversion of PWM wave should achieved through PWM polarity
inversion. Also polarity of PWM wave should configurable from slave
drivers,
Configure polarity
1. PWM_POLARITY_NORMAL - duty ns defines ON period of PWM wave
2. PWM_POLARITY_INVERSE - duty ns defines OFF period of PWM wave.
This patch adds support for configuring PWM polarity in PWM frame work.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
Configuring polarity to be done with PWM device disabled, if not
failure reported.
If PWM device is enabled while configuring polarity, disabling and
re_enabling make it complex. Whoever uses this API has to taken
care of the basic rules.
Discussions related to this can found at
http://www.spinics.net/lists/kernel/msg1372110.html
:100644 100644 ecb7690... 24d5495... M drivers/pwm/core.c
:100644 100644 21d076c... 2e4e960... M include/linux/pwm.h
drivers/pwm/core.c | 32
include/linux/pwm.h | 15 +++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index ecb7690..24d5495 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -379,6 +379,38 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int
period_ns)
EXPORT_SYMBOL_GPL(pwm_config);
/**
+ * pwm_set_polarity() - change PWM device Polarity
+ * @pwm: PWM device
+ * @polarity: Configure polarity of PWM
+ *
+ * Polarity to be configured with PWM device disabled.
+ */
+int pwm_set_polarity(struct pwm_device *pwm, int polarity)
+{
+ int pwm_flags = PWM_POLARITY_NORMAL;
+
+ if (!pwm || !pwm-chip-ops-set_polarity)
+ return -EINVAL;
+
+ if (test_bit(PWMF_ENABLED, pwm-flags)) {
+ dev_err(pwm-chip-dev,
+ Polarity configuration Failed!, PWM device enabled\n);
+ return -EBUSY;
+ }
+
+ if (polarity == PWM_POLARITY_INVERSE)
+ pwm_flags = PWM_POLARITY_INVERSE;
+
+ if (!pwm_flags)
+ clear_bit(PWMF_POLARITY_INVERSE, pwm-flags);
+ else
+ set_bit(PWMF_POLARITY_INVERSE, pwm-flags);
+
+ return pwm-chip-ops-set_polarity(pwm-chip, pwm, polarity);
+}
+EXPORT_SYMBOL_GPL(pwm_set_polarity);
+
+/**
* pwm_enable() - start a PWM output toggling
* @pwm: PWM device
*/
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 21d076c..2e4e960 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -21,6 +21,16 @@ void pwm_free(struct pwm_device *pwm);
*/
int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
+enum {
+ PWM_POLARITY_NORMAL,/* ON period depends on duty_ns */
+ PWM_POLARITY_INVERSE, /* OFF period depends on duty_ns */
+};
+
+/*
+ * pwm_set_polarity - set polarity of PWM device
+ */
+int pwm_set_polarity(struct pwm_device *pwm, int polarity);
+
/*
* pwm_enable - start a PWM output toggling
*/
@@ -37,6 +47,7 @@ struct pwm_chip;
enum {
PWMF_REQUESTED = 1 0,
PWMF_ENABLED = 1 1,
+ PWMF_POLARITY_INVERSE = 1 2,
};
struct pwm_device {
@@ -66,6 +77,7 @@ static inline unsigned int pwm_get_period(struct pwm_device
*pwm)
* @request: optional hook for requesting a PWM
* @free: optional hook for freeing a PWM
* @config: configure duty cycles and period length for this PWM
+ * @set_polarity: configure polarity of PWM
* @enable: enable PWM output toggling
* @disable: disable PWM output toggling
* @dbg_show: optional routine to show contents in debugfs
@@ -79,6 +91,9 @@ struct pwm_ops {
int (*config)(struct pwm_chip *chip,
struct pwm_device *pwm,
int duty_ns, int period_ns);
+ int (*set_polarity)(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ int polarity);
int (*enable)(struct pwm_chip *chip,
struct pwm_device *pwm);
void(*disable)(struct pwm_chip *chip,
--
1.7.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: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Hi Tony, On 07/18/2012 02:19 AM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120716 09:01]: On 07/13/2012 09:15 PM, Rob Herring wrote: Tony, Tarun, How would you feel on replacing omap_dmtimer_request_specific(int id) with say omap_dm_timer_request_by_cap(int cap)? I was thinking of changing the name so that it is clear that the API has changed. The int cap passed to the above function would be an OR of the appropriate the capabilities flags we have in dmtimer.h ... /* timer capabilities used in hwmod database */ #define OMAP_TIMER_SECURE 0x8000 #define OMAP_TIMER_ALWON0x4000 #define OMAP_TIMER_HAS_PWM 0x2000 ... That may break coprocessors where the firmware may expect a hardcoded specific timer.. So at least that should be checked before the change. If the specific timer is still needed for some firmware, it's best to add a separate function for the capabilities. I have seen that timers are used by the GPU and Ducati. Maybe I can check with the authors to see if we can get them to request by capability instead. If we can't then I need to figure out a way to resolve the timer ID when using DT. Per Rob's comments using alias is not the intended use. An alternative would be to extract the ID from the hwmod name, but was not sure if that would be appropriate either :-( Also, I believe it's up to the firmware running in secure mode to select the secure timers. So unless there's some way to query which timers are claimed by the secure mode, that too needs to be passed via DT. Yes, that is handled by patch 2/4. If we are on a secure device, then will not register any timers marked with the ti,timer-secure property. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] Add cyclic DMA support to OMAP DMA engine driver
+ Peter, On Wed, Jun 27, 2012 at 5:10 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Mon, Jun 25, 2012 at 12:18:47PM +0100, Russell King - ARM Linux wrote: It appears to be something to do with the jack detection that's going wrong. If I start the audio with the jack disconnected, I never get anything out of the board. It requires the jack to be connected before the first use. The on-board speakers used to work without the jack plugged in at one time but they seem to be completely non-functional now. Confused. Me too - there's nothing obvious in the code just from inspection that would affect this. Does audio work with $subject series after your mux fixes which you posted recently. 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 PM late init with DT blob
On Wed, 18 Jul 2012, Bedia, Vaibhav wrote: I checked the different inits which get skipped right now. I think _init_voltages() should not really be dependent on the DT check to cover the cases wherein the voltages are controlled using a regular regulator driver. However right now I don't know what approach to take here. For now I have sent an RFC patch [1] with just the movement of suspend ops. That seems reasonable based on a quick glance. Why not update your patch to just keep that code where it is and wrap the the pmic and voltage late init in that DT 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: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Tue, 2012-07-17 at 03:11 -0500, Menon, Nishanth wrote:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 86fc513..828e7b8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -208,6 +208,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+ .context_offs = USHRT_MAX,
OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will
need to know when it lost context to be able to reload it's firmware,
no?
It looks like current hwmod data doesn't support specific bits to be
used for the context declaration, it is only specifying the register
offset. Also, the same register is used by aess hwmod, so this will
cause a conflict if I take the same register into use.
This could be fixed by adding a field for the context bits, but I guess
this should be commented upon by someone (Benoit / Paul) before I craft
some sort of patch for that.
Meanwhile, I will keep the USHRT_MAX here until better solution is
available.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
On 17 July 2012 05:51, Ohad Ben-Cohen o...@wizery.com wrote: + Paul On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel joerg.roe...@amd.com wrote: On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote: Omar Ramirez Luna (6): ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected ARM: OMAP3: hwmod data: add mmu data for iva and isp ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp ARM: OMAP3/4: iommu: migrate to hwmod framework ARM: OMAP2+: iommu: add reset handling ARM: OMAP3/4: iommu: adapt to runtime pm What happens with this patch-set. Comments anyone? Ohad? Looks like it depends on a few OMAP hwmod changes (reset handling) which require Paul's ACK. That's correct, sorry if I failed to mention that in the cover-letter, but it does depend on: http://lkml.indiana.edu/hypermail/linux/kernel/1207.2/00361.html For the hwmod reset handling. Mainly, I wanted to gather comments for this patch set. - omar -- 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: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Wed, 18 Jul 2012, Tero Kristo wrote: On Tue, 2012-07-17 at 03:11 -0500, Menon, Nishanth wrote: OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will need to know when it lost context to be able to reload it's firmware, no? It looks like current hwmod data doesn't support specific bits to be used for the context declaration, it is only specifying the register offset. Also, the same register is used by aess hwmod, so this will cause a conflict if I take the same register into use. This could be fixed by adding a field for the context bits, but I guess this should be commented upon by someone (Benoit / Paul) before I craft some sort of patch for that. If you need to add a u8 there to specify the bitshift, go ahead and do it. u8 lostmem_bit, perhaps? - 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: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
On Wed, Jul 18, 2012 at 11:06:34AM +0100, Joe Woodward wrote: From: Mark A. Greer mgr...@animalcreek.com How does this look? Subject: [PATCH] ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature It appears that the am3703 and possibly the am3715 SoCs have an active IVA subsystem even though the CONTROL_IDCODE register indicates that they don't. From experimentation, it seems that the IVA still requires some registers to be initialized even though we don't want it fully functional. To accomplish this, add a new feature (OMAP3_HAS_IVA_REGS) that indicates that the IVA should be initialized but not really used. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- Tested on a GUMSTIX Overo AirSTORM (AM3703-based), and that fixes the problem for me, thanks! Great! Thanks for testing, Joe. Paul, Kevin, any comments? -- 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: am3517: issue with omap3_l3_app_irq during heavy USB load
On Wed, Jul 18, 2012 at 09:27:40AM +0200, Yegor Yefremov wrote: My system: am3517 based board with SMSC9514 attached to EHCI port 0 (not OTG), the rest of the USB ports are marked as disabled - OMAP_USBHS_PORT_MODE_UNUSED. Kernel: 3.3-rc7 from linux-omap (so far the latest kernel, where all hardware is supported) When performing network test only (nuttcp over SMSC9514's network interface) the system work reliably. But as soon as I start other USB activities (talking to a 3G modem/FTDI serial interfaces) I get following error: Any idea? Nope, sorry... -- 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: omap3: am35x: Disable hlt when using Davinci EMAC
On Tue, Jul 17, 2012 at 09:54:53PM -0600, Paul Walmsley wrote:
Hi
Hi Paul.
From the patch description, it doesn't sound like it's WFI entry that's
the problem. The EMAC can assert its interrupt lines to the INTC, since
the EMAC is active. If the MPU and CORE powerdomains are ON, then the ARM
core should wake up out of WFI. (Unless there's some weird bug; always
possible.)
Probably the MPU DPLL has to stay running for it all to work, since I
think that is activated and deactivated by the PRCM. Maybe the CORE DPLL
has to stay running too (but I doubt it). But I'll bet that all the
clocks downstream of the DPLLs can be gated. If it works, that would save
a lot of energy over the disable_hlt() approach. With disable_hlt(), the
ARM interconnect is just going to be burning power waiting for the
interrupt to come in.
Makes sense.
Want to try something like this? It's your patch but modified to not use
disable/enable_hlt(). If it doesn't work in your test case, maybe
try uncommenting that second set of deny_idle / allow_idle ...
I tested the modified patch (to get it to compile) below.
It did not work with or without the core_dpll_ck deny_idle/allow_idle
commented out.
Mark
---
arch/arm/mach-omap2/am35xx-emac.c | 56 ++---
arch/arm/mach-omap2/am35xx-emac.h | 13 ++-
arch/arm/mach-omap2/board-am3517evm.c |3 +-
arch/arm/mach-omap2/board-cm-t3517.c |3 +-
4 files changed, 66 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 2c90ac6..ed695e8 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -16,13 +16,50 @@
*/
#include linux/err.h
+#include linux/clk.h
#include linux/davinci_emac.h
#include asm/system.h
+#include plat/clock.h
#include plat/omap_device.h
#include mach/am35xx.h
#include control.h
#include am35xx-emac.h
+static struct clk *mpu_dpll_ck, *core_dpll_ck;
+
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+ mpu_dpll_ck-ops-deny_idle(mpu_dpll_ck);
+ /* core_dpll_ck-ops-deny_idle(core_dpll_ck); */
+ return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+ mpu_dpll_ck-ops-allow_idle(mpu_dpll_ck);
+ /* core_dpll_ck-ops-allow_idle(core_dpll_ck); */
+ return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+ {
+ .deactivate_func= am35xx_emac_deactivate_func,
+ .activate_func = am35xx_emac_activate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int am35xx_emac_pm_lats_size = ARRAY_SIZE(am35xx_emac_pm_lats);
+
static void am35xx_enable_emac_int(void)
{
u32 v;
@@ -58,12 +95,14 @@ static struct emac_platform_data am35xx_emac_pdata = {
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
+void *pdata, int pdata_len,
+struct omap_device_pm_latency
*pm_lats,
+int pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
-NULL, 0, false);
+pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
oh-class-name, oh-name);
@@ -73,7 +112,8 @@ static int __init omap_davinci_emac_dev_init(struct
omap_hwmod *oh,
return 0;
}
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
+void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct omap_hwmod *oh;
u32 v;
@@ -88,7 +128,7 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8
rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
-sizeof(am35xx_mdio_pdata));
+sizeof(am35xx_mdio_pdata), NULL, 0);
if (ret) {
pr_err(Could not build davinci_mdio hwmod device\n);
return;
@@ -103,12 +143,18 @@ void __init am35xx_emac_init(unsigned long
Re: [PATCH 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
On Wed, 18 Jul 2012, Mark A. Greer wrote:
On Tue, Jul 17, 2012 at 09:54:53PM -0600, Paul Walmsley wrote:
Want to try something like this? It's your patch but modified to not use
disable/enable_hlt(). If it doesn't work in your test case, maybe
try uncommenting that second set of deny_idle / allow_idle ...
I tested the modified patch (to get it to compile) below.
Doh, sorry about that.
It did not work with or without the core_dpll_ck deny_idle/allow_idle
commented out.
Here's a version with some of the CPUIdle states restricted. Maybe try
this one if you're using CPUIdle?
If it happens to work, it would also be interesting to know if it works
with the CORE DPLL part commented out.
- Paul
---
arch/arm/mach-omap2/am35xx-emac.c | 56 ++---
arch/arm/mach-omap2/am35xx-emac.h | 13 ++--
arch/arm/mach-omap2/board-am3517evm.c |3 +-
arch/arm/mach-omap2/board-cm-t3517.c |3 +-
arch/arm/mach-omap2/cpuidle34xx.c |5 +++
5 files changed, 71 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 2c90ac6..6b0edcd 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -16,13 +16,50 @@
*/
#include linux/err.h
+#include linux/clk.h
#include linux/davinci_emac.h
#include asm/system.h
+#include plat/clock.h
#include plat/omap_device.h
#include mach/am35xx.h
#include control.h
#include am35xx-emac.h
+static struct clk *mpu_dpll_ck, *core_dpll_ck;
+
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+ mpu_dpll_ck-ops-deny_idle(mpu_dpll_ck);
+ core_dpll_ck-ops-deny_idle(core_dpll_ck);
+ return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+ mpu_dpll_ck-ops-allow_idle(mpu_dpll_ck);
+ core_dpll_ck-ops-allow_idle(core_dpll_ck);
+ return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+ {
+ .deactivate_func= am35xx_emac_deactivate_func,
+ .activate_func = am35xx_emac_activate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int am35xx_emac_pm_lats_size = ARRAY_SIZE(am35xx_emac_pm_lats);
+
static void am35xx_enable_emac_int(void)
{
u32 v;
@@ -58,12 +95,14 @@ static struct emac_platform_data am35xx_emac_pdata = {
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
+void *pdata, int pdata_len,
+struct omap_device_pm_latency
*pm_lats,
+int pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh-class-name, 0, oh, pdata, pdata_len,
-NULL, 0, false);
+pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
oh-class-name, oh-name);
@@ -73,7 +112,8 @@ static int __init omap_davinci_emac_dev_init(struct
omap_hwmod *oh,
return 0;
}
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
+void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct omap_hwmod *oh;
u32 v;
@@ -88,7 +128,7 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8
rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, am35xx_mdio_pdata,
-sizeof(am35xx_mdio_pdata));
+sizeof(am35xx_mdio_pdata), NULL, 0);
if (ret) {
pr_err(Could not build davinci_mdio hwmod device\n);
return;
@@ -103,12 +143,18 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq,
u8 rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
ret = omap_davinci_emac_dev_init(oh, am35xx_emac_pdata,
-sizeof(am35xx_emac_pdata));
+sizeof(am35xx_emac_pdata),
+pm_lats, pm_lats_size);
if (ret) {
pr_err(Could not build davinci_emac hwmod device\n);
return;
}
+
[PATCH v3 08/11] arm/dts: am33xx: add dt data for usb nop phy
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 08e9a40..b03a9b5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = i2c3;
};
+ usb0_phy: phy0 {
+ compatible = nop-xceiv-usb;
+ };
+
+ usb1_phy: phy1 {
+ compatible = nop-xceiv-usb;
+ };
+
usb_otg_hs: usb_otg_hs {
compatible = ti,musb-am33xx;
ti,hwmods = usb_otg_hs;
--
1.7.0.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/11] usb: musb: kill global and static for multi instance
Moved global variable musb_debugfs_root and static variable
old_state to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable orig_dma_mask and filled the
dev-dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_core.c| 16 +++-
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c | 14 --
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3e09984..a5db4dd 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1802,10 +1802,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb-xceiv-state != old_state) {
- old_state = musb-xceiv-state;
+ if (musb-xceiv-state != musb-xceiv_old_state) {
+ musb-xceiv_old_state = musb-xceiv-state;
sysfs_notify(musb-controller-kobj, NULL, mode);
}
}
@@ -2115,11 +2114,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -2138,10 +2132,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev-dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status 0)
iounmap(base);
@@ -2166,7 +2156,7 @@ static int __devexit musb_remove(struct platform_device
*pdev)
iounmap(ctrl_base);
device_init_wakeup(pdev-dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev-dev.dma_mask = orig_dma_mask;
+ pdev-dev.dma_mask = (dev-dev.parent)-dma_mask;
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 69ed141..6b6cee9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -452,6 +452,10 @@ struct musb {
#endif
/* id for multiple musb instances */
u8 id;
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..b1e8f21 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s-private;
@@ -240,20 +238,24 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *root;
struct dentry *file;
int ret;
+ charname[10];
- root = debugfs_create_dir(musb, NULL);
+ sprintf(name, musb%d, musb-id);
+ root = debugfs_create_dir(name, NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
}
- file = debugfs_create_file(regdump, S_IRUGO, root, musb,
+ sprintf(name, regdump%d, musb-id);
+ file = debugfs_create_file(name, S_IRUGO, root, musb,
musb_regdump_fops);
if (!file) {
ret = -ENOMEM;
goto err1;
}
+ sprintf(name, testmode%d, musb-id);
file = debugfs_create_file(testmode, S_IRUGO | S_IWUSR,
root, musb, musb_test_mode_fops);
if (!file) {
@@ -261,7 +263,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb-debugfs_root = root;
return 0;
@@ -274,5 +276,5 @@ err0:
void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
{
- debugfs_remove_recursive(musb_debugfs_root);
+ debugfs_remove_recursive(musb-debugfs_root);
}
--
1.7.0.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 11/11] arm/dts: am33xx: add phy phandle to usbss
Added NOP PHY phandle to usbss device node as same will be used to get the phy from otg framework. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- arch/arm/boot/dts/am33xx.dtsi |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index b03a9b5..d3ab69a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -172,6 +172,8 @@ port0_mode = 3; port1_mode = 1; power = 250; + usb0-phy = usb0_phy; + usb1-phy = usb1_phy; }; }; }; -- 1.7.0.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/11] usb: otg: nop: add support for multiple tranceiver
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
drivers/usb/musb/am35x.c |4 ++--
drivers/usb/musb/blackfin.c |4 ++--
drivers/usb/musb/da8xx.c |4 ++--
drivers/usb/musb/davinci.c |6 +++---
drivers/usb/musb/musb_dsps.c | 10 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/otg/nop-usb-xceiv.c | 20
include/linux/usb/otg.h |9 +
9 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ef230a0..a3393bc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -704,7 +704,7 @@ static void __init omap3_evm_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(0);
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..eb6220f 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -364,7 +364,7 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -ENODEV;
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..03d081c 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -415,7 +415,7 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb-config-gpio_vrsel, 0);
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
gpio_free(musb-config-gpio_vrsel);
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb-config-gpio_vrsel);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..3ce4a92 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -425,7 +425,7 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto fail;
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..d5156b3 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -385,7 +385,7 @@ static int davinci_musb_init(struct musb *musb)
void __iomem*tibase = musb-ctrl_base;
u32 revision;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto unregister;
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb-xceiv);
unregister:
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return -ENODEV;
}
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index a2c8a06..9fcacff 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -420,8 +420,8 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb-mregs += wrp-musb_core_offset;
- /* NOP driver needs change if supporting dual instance */
[PATCH v3 01/11] usb: musb: add musb-id to identify core instance
Added 'id' field within 'struct musb' which can be used to determine
the current instance of musb controller.
Also defined musb_ida in musb_core.c to manage the core ids.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/am35x.c | 42 --
drivers/usb/musb/blackfin.c | 26 --
drivers/usb/musb/da8xx.c | 34 --
drivers/usb/musb/davinci.c | 34 --
drivers/usb/musb/musb_core.c | 31 +++
drivers/usb/musb/musb_core.h |4
drivers/usb/musb/musb_dsps.c | 25 ++---
drivers/usb/musb/omap2430.c | 26 --
drivers/usb/musb/tusb6010.c | 26 --
drivers/usb/musb/ux500.c | 33 +++--
10 files changed, 212 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 7a95ab8..01203eb 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -468,6 +468,7 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
struct clk *clk;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -475,38 +476,47 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err0;
}
- musb = platform_device_alloc(musb-hdrc, -1);
+ /* get the musb id */
+ musbid = musb_get_id(pdev-dev, GFP_KERNEL);
+ if (musbid 0) {
+ dev_err(pdev-dev, failed to allocate musb id\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ musb = platform_device_alloc(musb-hdrc, musbid);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
+ goto err2;
}
phy_clk = clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
ret = PTR_ERR(phy_clk);
- goto err2;
+ goto err3;
}
clk = clk_get(pdev-dev, ick);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
- goto err3;
+ goto err4;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(pdev-dev, failed to enable PHY clock\n);
- goto err4;
+ goto err5;
}
ret = clk_enable(clk);
if (ret) {
dev_err(pdev-dev, failed to enable clock\n);
- goto err5;
+ goto err6;
}
+ musb-id= musbid;
musb-dev.parent= pdev-dev;
musb-dev.dma_mask = am35x_dmamask;
musb-dev.coherent_dma_mask = am35x_dmamask;
@@ -524,38 +534,41 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
- goto err6;
+ goto err7;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(pdev-dev, failed to add platform_data\n);
- goto err6;
+ goto err7;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(pdev-dev, failed to register musb device\n);
- goto err6;
+ goto err7;
}
return 0;
-err6:
+err7:
clk_disable(clk);
-err5:
+err6:
clk_disable(phy_clk);
-err4:
+err5:
clk_put(clk);
-err3:
+err4:
clk_put(phy_clk);
-err2:
+err3:
platform_device_put(musb);
+err2:
+ musb_put_id(pdev-dev, musbid);
+
err1:
kfree(glue);
@@ -567,6 +580,7 @@ static int __devexit am35x_remove(struct platform_device
*pdev)
{
struct am35x_glue *glue = platform_get_drvdata(pdev);
+ musb_put_id(pdev-dev, glue-musb-id);
platform_device_del(glue-musb);
platform_device_put(glue-musb);
clk_disable(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 428e6aa..c848b82 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -471,6 +471,7 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
struct bfin_glue*glue;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -478,12 +479,21 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
goto err0;
[PATCH v3 09/11] usb: musb: dsps: remove explicit NOP device creation
As NOP device node is now added in am33xx tree so remove the call which creates the NOP platform_device. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/musb_dsps.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 18a16dd..4c59809 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -425,8 +425,7 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb-mregs += wrp-musb_core_offset; - /* Register NOP driver */ - usb_nop_xceiv_register(musb-id); + /* Get the NOP PHY */ musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb-xceiv)) return -ENODEV; -- 1.7.0.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/11] usb: musb: adding multi instance support
This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to linux-omap (master branch) + Vaibhav baseport patches on his tree at [3] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [1] + AM33xx musb glue compile and bugfix patches at [4], [5], [6] and [7] + Damodar's recent patch at [2] and have been tested on Beaglebone board. 1. http://marc.info/?l=linux-usbm=134070369306112w=2 2. http://marc.info/?l=linux-usbm=134200284230689w=2 3. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging 4. http://marc.info/?l=linux-usbm=134131746111637w=2 5. http://marc.info/?l=linux-usbm=134131746411639w=2 6. http://marc.info/?l=linux-usbm=134062716011251w=2 7. http://marc.info/?l=linux-usbm=134061179405213w=2 Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the ti string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] Ajay Kumar Gupta (11): usb: musb: add musb-id to identify core instance usb: musb: kill global and static for multi instance usb: musb: am335x: add support for dual instance usb: otg: nop: add support for multiple tranceiver usb: musb: dsps: add dt support arm/dts: am33xx: Add dt data for usbss usb: otg: nop: add dt support arm/dts: am33xx: add dt data for usb nop phy usb: musb: dsps: remove explicit NOP device creation usb: musb: dsps: get the PHY using phandle api arm/dts: am33xx: add phy phandle to usbss .../devicetree/bindings/usb/am33xx-usb.txt | 19 ++ arch/arm/boot/dts/am33xx.dtsi | 21 +++ arch/arm/mach-omap2/board-omap3evm.c |2 +- drivers/usb/musb/am35x.c | 46 +++-- drivers/usb/musb/blackfin.c| 30 +++- drivers/usb/musb/da8xx.c | 38 +++-- drivers/usb/musb/davinci.c | 40 +++-- drivers/usb/musb/musb_core.c | 47 -- drivers/usb/musb/musb_core.h |8 + drivers/usb/musb/musb_debugfs.c| 14 +- drivers/usb/musb/musb_dsps.c | 191 ++-- drivers/usb/musb/omap2430.c| 26 ++- drivers/usb/musb/tusb6010.c| 32 +++- drivers/usb/musb/ux500.c | 33 +++- drivers/usb/otg/nop-usb-xceiv.c| 32 +++- include/linux/usb/otg.h|9 +- 16 files changed, 425 insertions(+), 163 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt -- 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/11] usb: musb: dsps: get the PHY using phandle api
AM33xx has two PHY of same type used by each musb controller so use phandle of phy nodes to get the phy pointer. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- .../devicetree/bindings/usb/am33xx-usb.txt |2 ++ drivers/usb/musb/musb_dsps.c |4 +++- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index 9782585..e2702df 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -12,6 +12,8 @@ AM33XX MUSB GLUE represents PERIPHERAL. - power : Should be 250. This signifies the controller can supply upto 500mA when operating in host mode. + - usb0-phy : phandle for usb0 NOP PHY + - usb1-phy : phandle for usb1 NOP PHY NOP USB PHY - compatible : Should be nop-xceiv-usb diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 4c59809..e2b0729 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -419,6 +419,7 @@ static int dsps_musb_init(struct musb *musb) struct dsps_glue *glue = platform_get_drvdata(pdev); const struct dsps_musb_wrapper *wrp = glue-wrp; void __iomem *reg_base = musb-ctrl_base; + char name[10]; u32 rev, val; int status; @@ -426,7 +427,8 @@ static int dsps_musb_init(struct musb *musb) musb-mregs += wrp-musb_core_offset; /* Get the NOP PHY */ - musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); + sprintf(name, usb%d-phy, musb-id); + musb-xceiv = devm_usb_get_phy_by_phandle(pdev-dev, name); if (IS_ERR_OR_NULL(musb-xceiv)) return -ENODEV; -- 1.7.0.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 07/11] usb: otg: nop: add dt support
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 12
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 2e5e889..102e7d8 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
@@ -152,12 +153,23 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = nop-xceiv-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#else
+#define nop_xceiv_id_table NULL
+#endif
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
--
1.7.0.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 06/11] arm/dts: am33xx: Add dt data for usbss
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..08e9a40 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = ti,musb-am33xx;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ port0_mode = 3;
+ port1_mode = 1;
+ power = 250;
+ };
};
};
--
1.7.0.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 03/11] usb: musb: am335x: add support for dual instance
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_dsps.c | 93 +
1 files changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2174699..a2c8a06 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
+ /* number of musb instances */
+ u8 instances;
};
/**
@@ -112,16 +114,18 @@ struct dsps_musb_wrapper {
*/
struct dsps_glue {
struct device *dev;
- struct platform_device *musb; /* child musb pdev */
+ struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
- struct timer_list timer;/* otg_workaround timer */
- u32 __iomem *usb_ctrl;
+ struct timer_list timer[2]; /* otg_workaround timer */
+ unsigned long last_timer[2];/* last timer data for each instance */
+ u32 __iomem *usb_ctrl[2];
u8 usbss_rev;
};
/**
* musb_dsps_phy_control - phy on/off
* @glue: struct dsps_glue *
+ * @id: musb instance
* @on: flag for phy to be switched on or off
*
* This is to enable the PHY using usb_ctrl register in system control
@@ -130,11 +134,11 @@ struct dsps_glue {
* XXX: This function will be removed once we have a seperate driver for
* control module
*/
-static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
{
u32 usbphycfg;
- usbphycfg = __raw_readl(glue-usb_ctrl);
+ usbphycfg = __raw_readl(glue-usb_ctrl[id]);
if (on) {
if (glue-usbss_rev == MUSB_USBSS_REV_816X) {
@@ -157,7 +161,7 @@ static void musb_dsps_phy_control(struct dsps_glue *glue,
u8 on)
glue-usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
- __raw_writel(usbphycfg, glue-usb_ctrl);
+ __raw_writel(usbphycfg, glue-usb_ctrl[id]);
}
/**
* dsps_musb_enable - enable interrupts
@@ -247,7 +251,7 @@ static void otg_timer(unsigned long _musb)
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl MUSB_DEVCTL_BDEVICE)
- mod_timer(glue-timer,
+ mod_timer(glue-timer[musb-id],
jiffies + wrp-poll_seconds * HZ);
else
musb-xceiv-state = OTG_STATE_A_IDLE;
@@ -263,7 +267,6 @@ static void dsps_musb_try_idle(struct musb *musb, unsigned
long timeout)
struct device *dev = musb-controller;
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
- static unsigned long last_timer;
if (!is_otg_enabled(musb))
return;
@@ -276,22 +279,23 @@ static void dsps_musb_try_idle(struct musb *musb,
unsigned long timeout)
musb-xceiv-state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb-controller, %s active, deleting timer\n,
otg_state_string(musb-xceiv-state));
- del_timer(glue-timer);
- last_timer = jiffies;
+ del_timer(glue-timer[musb-id]);
+ glue-last_timer[musb-id] = jiffies;
return;
}
- if (time_after(last_timer, timeout) timer_pending(glue-timer)) {
+ if (time_after(glue-last_timer[musb-id], timeout)
+ timer_pending(glue-timer[musb-id])) {
dev_dbg(musb-controller,
Longer idle timer already pending, ignoring...\n);
return;
}
- last_timer = timeout;
+ glue-last_timer[musb-id] = timeout;
dev_dbg(musb-controller, %s inactive, starting idle timer for %u
ms\n,
otg_state_string(musb-xceiv-state),
jiffies_to_msecs(timeout - jiffies));
- mod_timer(glue-timer, timeout);
+ mod_timer(glue-timer[musb-id], timeout);
}
static irqreturn_t dsps_interrupt(int irq, void *hci)
@@ -360,7 +364,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
*/
musb-int_usb = ~MUSB_INTR_VBUSERROR;
musb-xceiv-state = OTG_STATE_A_WAIT_VFALL;
- mod_timer(glue-timer,
+
[PATCH v3 05/11] usb: musb: dsps: add dt support
Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt | 14 +
drivers/usb/musb/musb_dsps.c | 62 +---
2 files changed, 67 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
new file mode 100644
index 000..ca8fa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -0,0 +1,14 @@
+AM33XX MUSB GLUE
+ - compatible : Should be ti,musb-am33xx
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - port0_mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - port1_mode : Should be 1 to represent HOST. 3 signifies OTG and 2
+ represents PERIPHERAL.
+ - power : Should be 250. This signifies the controller can supply upto
+ 500mA when operating in host mode.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9fcacff..18a16dd 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -31,6 +31,7 @@
#include linux/init.h
#include linux/io.h
+#include linux/of.h
#include linux/err.h
#include linux/platform_device.h
#include linux/dma-mapping.h
@@ -45,6 +46,10 @@
#include musb_core.h
+#ifdef CONFIG_OF
+static const struct of_device_id musb_dsps_of_match[];
+#endif
+
/**
* avoid using musb_readx()/musb_writex() as glue layer should not be
* dependent on musb core layer symbols.
@@ -496,6 +501,8 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue
*glue, u8 id)
struct device *dev = glue-dev;
struct platform_device *pdev = to_platform_device(dev);
struct musb_hdrc_platform_data *pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct platform_device *musb;
struct resource *res;
struct resource resources[2];
@@ -562,14 +569,40 @@ static int __devinit dsps_create_musb_pdev(struct
dsps_glue *glue, u8 id)
glue-musb[id] = musb;
- pdata-platform_ops = dsps_ops;
-
ret = platform_device_add_resources(musb, resources, 2);
if (ret) {
dev_err(dev, failed to add resources\n);
goto err2;
}
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err2;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!config) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err2;
+ }
+
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ sprintf(res_name, port%d_mode, id);
+ of_property_read_u32(np, res_name, (u32 *)pdata-mode);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-config = config;
+ }
+
+ pdata-platform_ops = dsps_ops;
+
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(dev, failed to add platform_data\n);
@@ -601,14 +634,22 @@ static void __devexit dsps_delete_musb_pdev(struct
dsps_glue *glue, u8 id)
static int __devinit dsps_probe(struct platform_device *pdev)
{
- const struct platform_device_id *id = platform_get_device_id(pdev);
- const struct dsps_musb_wrapper *wrp =
- (struct dsps_musb_wrapper *)id-driver_data;
+ struct device_node *np = pdev-dev.of_node;
+ const struct of_device_id *match;
+ const struct dsps_musb_wrapper *wrp;
struct dsps_glue *glue;
struct resource *iomem;
u32 __iomem *usbss;
int ret, i;
+ match = of_match_node(musb_dsps_of_match, np);
+ if (!match) {
+ dev_err(pdev-dev, fail to get matching of_match struct\n);
+ ret = -EINVAL;
+ goto err0;
+ }
+
Re: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Wed, Jul 18, 2012 at 4:15 AM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2012-07-17 at 02:59 -0500, Menon, Nishanth wrote:
Couple of minor comments:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
[...]
/**
+ * _omap4_update_context_lost - increment hwmod context loss counter
if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ return;
would'nt it be better to return a dummy incremental counter instead of
returning no context loss (count = 0)?
I guess you are right, this way we may have some extra context restores
for modules which don't have context offs defined, rather than not
restoring them at all. Only thing I can think might prevent this is if
there are modules that never lose context but don't have context
register? How about omap5+?
there has been an interesting debate ongoing with HWAUTO and context
loss count handling - since we update only on _enable, this might
actually be interesting to consider:
enable
idle
un_idle (lost context)
read counter - no update
Now to handle modules that never loose context - they have to be in
wakeup domain.. should we consider a flag for those? would'nt matter
o5 or not, context is still the same.. this issue could be resolved if
counter update is done even when a check is done.
+
+ r =
omap4_prminst_read_inst_reg(oh-clkdm-pwrdm.ptr-prcm_partition,
+
oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.context_offs);
+
+ if (!r)
+ return;
+
+ oh-prcm.omap4.context_lost_counter++;
need to be careful about counter overflow.
Well, this code can't do much for that even if it overflows... the type
for the context_lost_counter is unsigned though, maybe it should be
expanded if you are worried...?
it can hit 0 with overflow(no context loss). that will not be good, right?
How about something like:
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eac813a..5fb9572 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1606,6 +1606,18 @@ static void _reconfigure_io_chain(void)
spin_unlock_irqrestore(io_chain_lock, flags);
}
+static inline void _omap4_inc_context_loss(unsigned int *v)
+{
+
+ /*
+* Context loss count has to be a non-negative value.
+* Clear the sign bit to get a value range from 1 to
+* INT_MAX.
+*/
+ *v = (*v + 1) INT_MAX;
+ *v = *v ? *v : 1;
+}
+
/**
* _omap4_update_context_lost - increment hwmod context loss counter if
* hwmod context was lost, and clear hardware context loss reg
@@ -1629,7 +1641,7 @@ static void _omap4_update_context_lost(struct
omap_hwmod *oh)
if (!r)
return;
- oh-prcm.omap4.context_lost_counter++;
+ _omap4_inc_context_loss(oh-prcm.omap4.context_lost_counter);
omap4_prminst_write_inst_reg(r, oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
