Re: [PATCH v6 02/16] OMAP2+: hwmod: Add API to check IO PAD wakeup status
On Tue, Oct 11, 2011 at 3:54 AM, Kevin Hilman khil...@ti.com wrote: Govindraj govindraj...@gmail.com writes: On Mon, Oct 3, 2011 at 10:53 AM, Rajendra Nayak rna...@ti.com wrote: On Monday 03 October 2011 10:30 AM, Govindraj wrote: On Sat, Oct 1, 2011 at 8:03 PM, Rajendra Nayakrna...@ti.com wrote: On Friday 30 September 2011 04:31 PM, Govindraj.R wrote: Add API to determine IO-PAD wakeup event status for a given hwmod dynamic_mux pad. Wake up event set will be cleared on pad mux_read. Are these api's even getting used in this series? Used in Tero's irq_chaining patches. So shouldn't this patch be part of his series instead? Yes it is. Part of his v9-series. Then please drop from this series and state the introductory patch (PATCH 0/n) that this series has a dependency on Tero's series. Okay. -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/16] OMAP2+: UART: Cleanup part of clock gating mechanism for uart
On Tue, Oct 11, 2011 at 4:00 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: Currently we use a shared irq handler to identify uart activity and then trigger a timer. OK. Based the timeout value set from sysfs the timer used to expire. Please re-phrase as I'm not sure what is being said here. If no uart-activity was detected timer-expiry func sets can_sleep flag. Based on this we will disable the uart clocks in idle path. Since the clock gating mechanism is outside the uart driver, we currently use this mechanism. In preparation to runtime implementation for omap-serial driver we can cleanup this mechanism and use runtime API's to gate uart clocks. Also remove timer related info from local uart_state struct and remove the code used to set timeout value from sysfs. Remove un-used function omap_uart_check_wakeup. Signed-off-by: Govindraj.R govindraj.r...@ti.com The patch itself fine, and is a well-neede cleanup, but changelog (especially the first part) does not read well. Okay, Will Correct. -- Thanks. Govindraj.R -- 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 8/8] OMAP3: powerdomain data: add wake-up latency figures
Hi Paul, On Tue, Oct 11, 2011 at 12:52 AM, Paul Walmsley p...@pwsan.com wrote: On Mon, 10 Oct 2011, Paul Walmsley wrote: OK. sys_offmode only applies to OFF mode. Voltage scaling can also occur during RETENTION and INACTIVE (sleep). So were these results with retention and voltage scaling disabled? This last sentence should have read: So were these results with retention and sleep voltage scaling disabled? In that case, yes. The scaling timings are only applicable to OFF mode. I think we need to have a bench setup for the latency measurements. That way I will be easier to repeat the measurements for next generation chips and variations. Regards, Jean - 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 5/5] regulator: map consumer regulator based on device tree
+ if (supply) {
+ struct regulator_dev *r;
+ struct device_node *node;
+
+ /* first do a dt based lookup */
+ if (dev) {
+ node = of_get_regulator(dev, supply);
+ if (node)
+ list_for_each_entry(r, regulator_list, list)
+ if (node == r-dev.parent-of_node)
+ goto found;
}
- if (!found) {
- dev_err(dev, Failed to find supply %s\n,
- init_data-supply_regulator);
- ret = -ENODEV;
- goto scrub;
- }
+ /* next try doing it non-dt way */
+ list_for_each_entry(r, regulator_list, list)
+ if (strcmp(rdev_get_name(r), supply) == 0)
+ goto found;
+ dev_err(dev, Failed to find supply %s\n, supply);
+ ret = -ENODEV;
+ goto scrub;
+
+found:
This is all getting *really* complicated and illegible. I'm not sure
what the best way to structure is but erroring out early looks useful.
How about this updated patch?
From f4c7d2b283740382c272c7971665375067d26dbe Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Thu, 22 Sep 2011 17:51:10 +0530
Subject: [PATCH 5/5] regulator: map consumer regulator based on device tree
Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = regulator1;
vpll-supply = regulator1;
};
The driver would then do a regulator_get(dev, vmmc); to get
regulator1 and do a regulator_get(dev, vpll); to get
regulator2.
of_get_regulator() extracts the regulator node for a given
device, based on the supply name.
Use it to look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
Also, since the regulator dt nodes can use the same binding to
associate with a parent regulator/supply, allow the drivers to
specify a supply_name, which can then be used to lookup dt
to find the parent phandle.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/regulator/core.c | 91 +++--
include/linux/regulator/driver.h |2 +
2 files changed, 78 insertions(+), 15 deletions(-)
Index: linux/drivers/regulator/core.c
===
--- linux.orig/drivers/regulator/core.c 2011-10-11 11:43:27.944140106 +0530
+++ linux/drivers/regulator/core.c 2011-10-11 12:25:53.540418748 +0530
@@ -25,9 +25,11 @@
#include linux/mutex.h
#include linux/suspend.h
#include linux/delay.h
+#include linux/of.h
#include linux/regulator/consumer.h
#include linux/regulator/driver.h
#include linux/regulator/machine.h
+#include linux/regulator/of_regulator.h
#define CREATE_TRACE_POINTS
#include trace/events/regulator.h
@@ -131,6 +133,33 @@
return NULL;
}
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+static struct device_node *of_get_regulator(struct device *dev, const
char *supply)
+{
+ struct device_node *regnode = NULL;
+ char prop_name[32]; /* 32 is max size of property name */
+
+ dev_dbg(dev, Looking up %s-supply from device tree\n, supply);
+
+ snprintf(prop_name, 32, %s-supply, supply);
+ regnode = of_parse_phandle(dev-of_node, prop_name, 0);
+
+ if (!regnode) {
+ pr_warn(%s: %s property in node %s references invalid phandle,
+ __func__, prop_name, dev-of_node-full_name);
+ return NULL;
+ }
+ return regnode;
+}
+
/* Platform voltage constraint check */
static int regulator_check_voltage(struct regulator_dev *rdev,
int *min_uV, int *max_uV)
@@ -1147,6 +1176,28 @@
return rdev-desc-ops-enable_time(rdev);
}
+static struct regulator_dev *regulator_dev_lookup(struct device *dev,
+const char *supply)
+{
+ struct regulator_dev *r;
+ struct device_node *node;
+
+ /* first do a dt based lookup */
+ if (dev dev-of_node)
+ node = of_get_regulator(dev, supply);
+ if (node)
+ list_for_each_entry(r, regulator_list, list)
+ if
Re: [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
On Monday 10 October 2011 11:31 PM, Kevin Hilman wrote:
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
suspend (S2R), CPU hotplug and CPUidle.
There are a few more compile errors when doing OMAP1-only builds.
You'll need a way to eliminate the secure calls for OMAP1.
This series causes a couple build errors when doing OMAP1-only builds
(I used omap1_defconfig):
OK. Thanks for catching it.
First:
/work/kernel/omap/pm/arch/arm/plat-omap/common.c:24:30: fatal error:
mach/omap-secure.h: No such file or directory
And trying creating a dummy header to see if it would continue to build gives:
/work/kernel/omap/pm/arch/arm/plat-omap/common.c: In function 'omap_reserve':
/work/kernel/omap/pm/arch/arm/plat-omap/common.c:70:2: error: implicit
declaration of function 'omap_secure_ram_reserve_memblock'
make[2]: *** [arch/arm/plat-omap/common.o] Error 1
make[1]: *** [arch/arm/plat-omap] Error 2
For OMAP1 build, omap_secure_ram_reserve_memblock() definition is
needed since common.c is built for OMAP1 as well.
The trivial change in the end of this email fixes the omap1 build.
Have folded that change in original patch and updated the OMAP4
PM branch - for_3_2/omap4-mpuss-pm_2
Regards
Santosh
P.S : Even with this fix, omap1_defconfig build breaks because of USB.
I removed USB from build to check rest of the build and it was
fine then.
---
diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h
b/arch/arm/mach-omap2/include/mach/omap-secure.h
index 6e929c5..48247ce 100644
--- a/arch/arm/mach-omap2/include/mach/omap-secure.h
+++ b/arch/arm/mach-omap2/include/mach/omap-secure.h
@@ -51,7 +51,6 @@ extern u32 omap_secure_dispatcher(u32 idx, u32 flag,
u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
-extern int omap_secure_ram_reserve_memblock(void);
#endif /* __ASSEMBLER__ */
#endif /* OMAP_ARCH_OMAP_SECURE_H */
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 827f896..d5ef8dc 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,7 +21,7 @@
#include plat/vram.h
#include plat/dsp.h
-#include mach/omap-secure.h
+#include plat/omap-secure.h
#define NO_LENGTH_CHECK 0x
diff --git a/arch/arm/plat-omap/include/plat/omap-secure.h
b/arch/arm/plat-omap/include/plat/omap-secure.h
new file mode 100644
index 000..64f9d1c
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap-secure.h
@@ -0,0 +1,13 @@
+#ifndef __OMAP_SECURE_H__
+#define __OMAP_SECURE_H__
+
+#include linux/types.h
+
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern int omap_secure_ram_reserve_memblock(void);
+#else
+static inline void omap_secure_ram_reserve_memblock(void)
+{ }
+#endif
+
+#endif /* __OMAP_SECURE_H__ */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5 v14] omap: usb: host: Runtime PM preparation for EHCI and OHCI drivers
From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures for ehci and ohci drivers are implemented for EHCI and OHCI drivers of OMAP3 and OMAP4. The ehci and ohci drivers does not use the APIs of the usbhs core driver; the runtime pm APIs are used for clock enable/disable. TODO: - Adding mux-information to Hwmods. - Aggressive Clock Management around USB bus suspend/resume. - Remote Wakeup support implementation using IO-ring Wakeup on EHCI/OHCI pads via PRCM IRQ chain handler. In Version 14: - for omap3 and omap4, Masters are added for the TLL hwmod - for omap3, OCPIF_SWSUP_IDLE option is removed for interface clocks In version 13: - for omap3, the ehci 120mhz clock is conditional enabled if ehci is selected for atleast one port in the omap platform. - the hardware erratas information is added. - the patches are split in to two series i) The hwmod and preparation for run time pm of ehci and ohci drivers ( this series) ii) The Runtime pm support for ehci and ohci drivers. Since the patches are split , both the series are SHOULD be applied to make the ehci and ohci drivers are functional with runtime pm support. In version 12: - The ehci, ohci and usb_host_hs hwmods combined as a single hwmod usb_host_hs. - for omap3 the usbhost_ick and and usbtll_ick clocks are changed as interface clocks. The usbtll_fck, usbhost_48m_fck clocks are changed as main clocks and the 120mhz functional clock is changed to optional clock - the usbhs mfd driver enable/disable this optional clock in runtime_resume and runtime_suspend callbacks of pm_runtime_get_sync and pm_runtime_put_sync APIs. Benoit Cousson (1): arm: omap: usb: ehci and ohci hwmod structures for omap4 Keshava Munegowda (4): arm: omap: usb: ehci and ohci hwmod structures for omap3 arm: omap: usb: register hwmods of usbhs arm: omap: usb: device name change for the clk names of usbhs omap: usb: host: Replace usbhs core driver APIs by Runtime pm APIs arch/arm/mach-omap2/clock3xxx_data.c | 26 ++-- arch/arm/mach-omap2/clock44xx_data.c | 10 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 230 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 220 ++- arch/arm/mach-omap2/usb-host.c | 100 arch/arm/plat-omap/include/plat/usb.h |3 - drivers/mfd/omap-usb-host.c|2 +- drivers/usb/host/ehci-omap.c | 17 +-- drivers/usb/host/ohci-omap3.c | 18 +-- 9 files changed, 515 insertions(+), 111 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5 v14] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Benoit Cousson b-cous...@ti.com
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
- rebased to kernel version 3.0
- Workarounds for hardware issues
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 221 +++-
1 files changed, 220 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..f85de42 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,8 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5338,220 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = omap44xx_usb_host_hs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = ohci,
+ .pa_start = 0x4a064800,
+ .pa_end = 0x4a064bff,
+ },
+ {
+ .name = ehci,
+ .pa_start = 0x4a064c00,
+ .pa_end = 0x4a064fff,
+ },
+ {}
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_host_hs_irqs[] = {
+ { .name = ohci-irq, .irq = 76 + OMAP44XX_IRQ_GIC_START },
+ { .name = ehci-irq, .irq = 77 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usb_host_hs_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap44xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .main_clk = usb_host_hs_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .mpu_irqs = omap44xx_usb_host_hs_irqs,
+ .slaves = omap44xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
+ .masters= omap44xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap44xx_usb_host_hs_masters),
+
+ /*
+* Errata: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
+* id: i660
+*
+* Description:
+* In the following configuration :
+* - USBHOST module is set to smart-idle mode
+* - PRCM asserts idle_req to the USBHOST module ( This typically
+* happens when the system is going to a low
[PATCH 2/5 v14] arm: omap: usb: ehci and ohci hwmod structures for omap3
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 230
1 files changed, 230 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..c06b4a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3198,229 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = ohci,
+ .pa_start = 0x48064400,
+ .pa_end = 0x480647ff,
+ },
+ {
+ .name = ehci,
+ .pa_start = 0x48064800,
+ .pa_end = 0x48064cff,
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__ick = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= usbhost_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_usb_host_hs__ick,
+};
+
+static struct omap_hwmod_opt_clk omap34xx_usb_host_hs_opt_clks[] = {
+ { .role = ehci_logic_fck, .clk = usbhost_120m_fck, },
+};
+
+static struct omap_hwmod_irq_info omap34xx_usb_host_hs_irqs[] = {
+ { .name = ohci-irq, .irq = 76 },
+ { .name = ehci-irq, .irq = 77 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap34xx_usb_host_hs_irqs,
+ .main_clk = usbhost_48m_fck,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430ES2_EN_USBHOST1_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430ES2_ST_USBHOST_IDLE_SHIFT,
+ .idlest_stdby_bit = OMAP3430ES2_ST_USBHOST_STDBY_SHIFT,
+ },
+ },
+ .opt_clks = omap34xx_usb_host_hs_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_opt_clks),
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters= omap34xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+
+ /*
+* Errata: USBHOST Configured In Smart-Idle Can
[PATCH 2/5 v14] arm: omap: usb: ehci and ohci hwmod structures for omap3
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 230
1 files changed, 230 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..c06b4a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3198,229 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = ohci,
+ .pa_start = 0x48064400,
+ .pa_end = 0x480647ff,
+ },
+ {
+ .name = ehci,
+ .pa_start = 0x48064800,
+ .pa_end = 0x48064cff,
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__ick = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= usbhost_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_usb_host_hs__ick,
+};
+
+static struct omap_hwmod_opt_clk omap34xx_usb_host_hs_opt_clks[] = {
+ { .role = ehci_logic_fck, .clk = usbhost_120m_fck, },
+};
+
+static struct omap_hwmod_irq_info omap34xx_usb_host_hs_irqs[] = {
+ { .name = ohci-irq, .irq = 76 },
+ { .name = ehci-irq, .irq = 77 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap34xx_usb_host_hs_irqs,
+ .main_clk = usbhost_48m_fck,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430ES2_EN_USBHOST1_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430ES2_ST_USBHOST_IDLE_SHIFT,
+ .idlest_stdby_bit = OMAP3430ES2_ST_USBHOST_STDBY_SHIFT,
+ },
+ },
+ .opt_clks = omap34xx_usb_host_hs_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_opt_clks),
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters= omap34xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+
+ /*
+* Errata: USBHOST Configured In Smart-Idle Can
[PATCH 3/5 v14] arm: omap: usb: register hwmods of usbhs
The hwmod structure of usb_host_hs and usb_tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 100 ++--
1 files changed, 34 insertions(+), 66 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 89ae298..771dc78 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -28,51 +28,28 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
+#include plat/omap_device.h
#include mux.h
#ifdef CONFIG_MFD_OMAP_USB_HOST
-#define OMAP_USBHS_DEVICE usbhs-omap
-
-static struct resource usbhs_resources[] = {
- {
- .name = uhh,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = tll,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci-irq,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = ohci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ohci-irq,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device usbhs_device = {
- .name = OMAP_USBHS_DEVICE,
- .id = 0,
- .num_resources = ARRAY_SIZE(usbhs_resources),
- .resource = usbhs_resources,
-};
+#define OMAP_USBHS_DEVICE usbhs_omap
+#defineUSBHS_UHH_HWMODNAME usb_host_hs
+#define USBHS_TLL_HWMODNAMEusb_tll_hs
static struct usbhs_omap_platform_data usbhs_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
+static struct omap_device_pm_latency omap_uhhtll_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
/* MUX settings for EHCI pins */
/*
* setup_ehci_io_mux - initialize IO pad mux for USBHOST
@@ -508,7 +485,10 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- int i;
+ struct omap_hwmod *oh[2];
+ struct omap_device *od;
+ int bus_id = -1;
+ int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
@@ -523,44 +503,34 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
- usbhs_resources[0].start = OMAP34XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP34XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP34XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start= OMAP34XX_EHCI_BASE;
- usbhs_resources[2].end = OMAP34XX_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = INT_34XX_EHCI_IRQ;
- usbhs_resources[4].start= OMAP34XX_OHCI_BASE;
- usbhs_resources[4].end = OMAP34XX_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = INT_34XX_OHCI_IRQ;
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
} else if (cpu_is_omap44xx()) {
- usbhs_resources[0].start = OMAP44XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP44XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP44XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP44XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start = OMAP44XX_HSUSB_EHCI_BASE;
- usbhs_resources[2].end = OMAP44XX_HSUSB_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = OMAP44XX_IRQ_EHCI;
- usbhs_resources[4].start = OMAP44XX_HSUSB_OHCI_BASE;
- usbhs_resources[4].end = OMAP44XX_HSUSB_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = OMAP44XX_IRQ_OHCI;
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
}
- if (platform_device_add_data(usbhs_device,
- usbhs_data, sizeof(usbhs_data)) 0) {
- printk(KERN_ERR USBHS platform_device_add_data failed\n);
- goto init_end;
+ oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!oh[0]) {
+ pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
+ return;
}
- if
[PATCH 4/5 v14] arm: omap: usb: device name change for the clk names of usbhs
From: Keshava Munegowda keshava_mgo...@ti.com
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap; The redudant clock nodes are removed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 26 --
arch/arm/mach-omap2/clock44xx_data.c | 10 +-
drivers/mfd/omap-usb-host.c |2 +-
3 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index ffd55b1..63a822f 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3285,7 +3285,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3321,7 +3321,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3367,20 +3367,18 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cam_ick, cam_ick, CK_34XX | CK_36XX),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_34XX | CK_36XX),
CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, hs_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, fs_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2af0e3f..088977a 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++
[PATCH 5/5 v14] omap: usb: host: Replace usbhs core driver APIs by Runtime pm APIs
From: Keshava Munegowda keshava_mgo...@ti.com
The ehci and ohci drivers does not use the APIs of the usbhs
core driver; the runtime pm APIs are used for clock
enable/disable. Since usbhs is parent platform device of the
ehci and ohci devices, the runtime apis indirectly uses the
usb hs core device as input parameter to for clock functions.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |3 ---
drivers/usb/host/ehci-omap.c | 17 +++--
drivers/usb/host/ohci-omap3.c | 18 +++---
3 files changed, 14 insertions(+), 24 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..2b66dc2 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -100,9 +100,6 @@ extern void usb_musb_init(struct omap_musb_board_data
*board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
-extern int omap_usbhs_enable(struct device *dev);
-extern void omap_usbhs_disable(struct device *dev);
-
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 4524032..82cd3ea 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -41,6 +41,7 @@
#include linux/usb/ulpi.h
#include plat/usb.h
#include linux/regulator/consumer.h
+#include linux/pm_runtime.h
/* EHCI Register Set */
#define EHCI_INSNREG04 (0xA0)
@@ -190,11 +191,8 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
}
}
- ret = omap_usbhs_enable(dev);
- if (ret) {
- dev_err(dev, failed to start usbhs with err %d\n, ret);
- goto err_enable;
- }
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
/*
* An undocumented feature in the OMAP3 EHCI controller,
@@ -240,11 +238,8 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
return 0;
err_add_hcd:
- omap_usbhs_disable(dev);
-
-err_enable:
disable_put_regulator(pdata);
- usb_put_hcd(hcd);
+ pm_runtime_put_sync(dev);
err_io:
iounmap(regs);
@@ -266,10 +261,12 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
usb_remove_hcd(hcd);
- omap_usbhs_disable(dev);
disable_put_regulator(dev-platform_data);
iounmap(hcd-regs);
usb_put_hcd(hcd);
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+
return 0;
}
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
index 6048f2f..6cfedaf 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -31,6 +31,7 @@
#include linux/platform_device.h
#include plat/usb.h
+#include linux/pm_runtime.h
/*-*/
@@ -134,7 +135,7 @@ static int __devinit ohci_hcd_omap3_probe(struct
platform_device *pdev)
int irq;
if (usb_disabled())
- goto err_end;
+ return -ENODEV;
if (!dev-parent) {
dev_err(dev, Missing parent device\n);
@@ -172,11 +173,8 @@ static int __devinit ohci_hcd_omap3_probe(struct
platform_device *pdev)
hcd-rsrc_len = resource_size(res);
hcd-regs = regs;
- ret = omap_usbhs_enable(dev);
- if (ret) {
- dev_dbg(dev, failed to start ohci\n);
- goto err_end;
- }
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
ohci_hcd_init(hcd_to_ohci(hcd));
@@ -189,9 +187,7 @@ static int __devinit ohci_hcd_omap3_probe(struct
platform_device *pdev)
return 0;
err_add_hcd:
- omap_usbhs_disable(dev);
-
-err_end:
+ pm_runtime_put_sync(dev);
usb_put_hcd(hcd);
err_io:
@@ -220,9 +216,9 @@ static int __devexit ohci_hcd_omap3_remove(struct
platform_device *pdev)
iounmap(hcd-regs);
usb_remove_hcd(hcd);
- omap_usbhs_disable(dev);
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
usb_put_hcd(hcd);
-
return 0;
}
--
1.6.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 v13 v14] mfd: omap: usb: Runtime PM support
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the interface and
functional clocks directly, These clocks are handled by runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the optional clocks and port clocks are handled by
the usbhs core.
Dependency:
This patch is dependent on this series:
[PATCH 0/5 v13 or latest version] omap: usb: host: Runtime PM preparation
for EHCI and OHCI drivers.
Validation performed:
The global suspend/resume of EHCI and OHCI is validated on
OMAP3430 sdp board with this patch combined with the series:
[PATCH 0/5 v13 or latest version] omap: usb: host: Runtime PM preparation
for EHCI and OHCI drivers.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
drivers/mfd/omap-usb-host.c | 753 +--
1 files changed, 303 insertions(+), 450 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9c2da29..8fb8cfc 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -26,6 +26,7 @@
#include linux/spinlock.h
#include linux/gpio.h
#include plat/usb.h
+#include linux/pm_runtime.h
#define USBHS_DRIVER_NAME usbhs_omap
#define OMAP_EHCI_DEVICE ehci-omap
@@ -146,9 +147,6 @@
struct usbhs_hcd_omap {
- struct clk *usbhost_ick;
- struct clk *usbhost_hs_fck;
- struct clk *usbhost_fs_fck;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -158,8 +156,7 @@ struct usbhs_hcd_omap {
struct clk *usbhost_p2_fck;
struct clk *usbtll_p2_fck;
struct clk *init_60m_fclk;
- struct clk *usbtll_fck;
- struct clk *usbtll_ick;
+ struct clk *ehci_logic_fck;
void __iomem*uhh_base;
void __iomem*tll_base;
@@ -168,7 +165,6 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
- int count;
};
/*-*/
@@ -318,269 +314,6 @@ err_end:
return ret;
}
-/**
- * usbhs_omap_probe - initialize TI-based HCDs
- *
- * Allocates basic resources for this USB host controller.
- */
-static int __devinit usbhs_omap_probe(struct platform_device *pdev)
-{
- struct device *dev = pdev-dev;
- struct usbhs_omap_platform_data *pdata = dev-platform_data;
- struct usbhs_hcd_omap *omap;
- struct resource *res;
- int ret = 0;
- int i;
-
- if (!pdata) {
- dev_err(dev, Missing platform data\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
- if (!omap) {
- dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- spin_lock_init(omap-lock);
-
- for (i = 0; i OMAP3_HS_USB_PORTS; i++)
- omap-platdata.port_mode[i] = pdata-port_mode[i];
-
- omap-platdata.ehci_data = pdata-ehci_data;
- omap-platdata.ohci_data = pdata-ohci_data;
-
- omap-usbhost_ick = clk_get(dev, usbhost_ick);
- if (IS_ERR(omap-usbhost_ick)) {
- ret = PTR_ERR(omap-usbhost_ick);
- dev_err(dev, usbhost_ick failed error:%d\n, ret);
- goto err_end;
- }
-
- omap-usbhost_hs_fck = clk_get(dev, hs_fck);
- if (IS_ERR(omap-usbhost_hs_fck)) {
- ret = PTR_ERR(omap-usbhost_hs_fck);
- dev_err(dev, usbhost_hs_fck failed error:%d\n, ret);
- goto err_usbhost_ick;
- }
-
- omap-usbhost_fs_fck = clk_get(dev, fs_fck);
- if (IS_ERR(omap-usbhost_fs_fck)) {
- ret = PTR_ERR(omap-usbhost_fs_fck);
- dev_err(dev, usbhost_fs_fck failed error:%d\n, ret);
- goto err_usbhost_hs_fck;
- }
-
- omap-usbtll_fck = clk_get(dev, usbtll_fck);
- if (IS_ERR(omap-usbtll_fck)) {
- ret = PTR_ERR(omap-usbtll_fck);
- dev_err(dev, usbtll_fck failed error:%d\n, ret);
- goto err_usbhost_fs_fck;
- }
-
- omap-usbtll_ick = clk_get(dev, usbtll_ick);
- if (IS_ERR(omap-usbtll_ick)) {
- ret = PTR_ERR(omap-usbtll_ick);
- dev_err(dev, usbtll_ick failed error:%d\n, ret);
- goto err_usbtll_fck;
- }
-
[PATCH v14] mfd: omap: usb: Runtime PM support
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the interface and
functional clocks directly, These clocks are handled by runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the optional clocks and port clocks are handled by
the usbhs core.
Dependency:
This patch is dependent on this series:
[PATCH 0/5 v13 or latest version] omap: usb: host: Runtime PM preparation
for EHCI and OHCI drivers.
Validation performed:
The global suspend/resume of EHCI and OHCI is validated on
OMAP3430 sdp board with this patch combined with the series:
[PATCH 0/5 v13 or latest version] omap: usb: host: Runtime PM preparation
for EHCI and OHCI drivers.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
drivers/mfd/omap-usb-host.c | 753 +--
1 files changed, 303 insertions(+), 450 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9c2da29..8fb8cfc 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -26,6 +26,7 @@
#include linux/spinlock.h
#include linux/gpio.h
#include plat/usb.h
+#include linux/pm_runtime.h
#define USBHS_DRIVER_NAME usbhs_omap
#define OMAP_EHCI_DEVICE ehci-omap
@@ -146,9 +147,6 @@
struct usbhs_hcd_omap {
- struct clk *usbhost_ick;
- struct clk *usbhost_hs_fck;
- struct clk *usbhost_fs_fck;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -158,8 +156,7 @@ struct usbhs_hcd_omap {
struct clk *usbhost_p2_fck;
struct clk *usbtll_p2_fck;
struct clk *init_60m_fclk;
- struct clk *usbtll_fck;
- struct clk *usbtll_ick;
+ struct clk *ehci_logic_fck;
void __iomem*uhh_base;
void __iomem*tll_base;
@@ -168,7 +165,6 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
- int count;
};
/*-*/
@@ -318,269 +314,6 @@ err_end:
return ret;
}
-/**
- * usbhs_omap_probe - initialize TI-based HCDs
- *
- * Allocates basic resources for this USB host controller.
- */
-static int __devinit usbhs_omap_probe(struct platform_device *pdev)
-{
- struct device *dev = pdev-dev;
- struct usbhs_omap_platform_data *pdata = dev-platform_data;
- struct usbhs_hcd_omap *omap;
- struct resource *res;
- int ret = 0;
- int i;
-
- if (!pdata) {
- dev_err(dev, Missing platform data\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
- if (!omap) {
- dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- spin_lock_init(omap-lock);
-
- for (i = 0; i OMAP3_HS_USB_PORTS; i++)
- omap-platdata.port_mode[i] = pdata-port_mode[i];
-
- omap-platdata.ehci_data = pdata-ehci_data;
- omap-platdata.ohci_data = pdata-ohci_data;
-
- omap-usbhost_ick = clk_get(dev, usbhost_ick);
- if (IS_ERR(omap-usbhost_ick)) {
- ret = PTR_ERR(omap-usbhost_ick);
- dev_err(dev, usbhost_ick failed error:%d\n, ret);
- goto err_end;
- }
-
- omap-usbhost_hs_fck = clk_get(dev, hs_fck);
- if (IS_ERR(omap-usbhost_hs_fck)) {
- ret = PTR_ERR(omap-usbhost_hs_fck);
- dev_err(dev, usbhost_hs_fck failed error:%d\n, ret);
- goto err_usbhost_ick;
- }
-
- omap-usbhost_fs_fck = clk_get(dev, fs_fck);
- if (IS_ERR(omap-usbhost_fs_fck)) {
- ret = PTR_ERR(omap-usbhost_fs_fck);
- dev_err(dev, usbhost_fs_fck failed error:%d\n, ret);
- goto err_usbhost_hs_fck;
- }
-
- omap-usbtll_fck = clk_get(dev, usbtll_fck);
- if (IS_ERR(omap-usbtll_fck)) {
- ret = PTR_ERR(omap-usbtll_fck);
- dev_err(dev, usbtll_fck failed error:%d\n, ret);
- goto err_usbhost_fs_fck;
- }
-
- omap-usbtll_ick = clk_get(dev, usbtll_ick);
- if (IS_ERR(omap-usbtll_ick)) {
- ret = PTR_ERR(omap-usbtll_ick);
- dev_err(dev, usbtll_ick failed error:%d\n, ret);
- goto err_usbtll_fck;
- }
-
Re: [PATCH 2/5 v14] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Tue, Oct 11, 2011 at 1:21 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 230
1 files changed, 230 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..c06b4a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3198,229 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk = core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = ohci,
+ .pa_start = 0x48064400,
+ .pa_end = 0x480647ff,
+ },
+ {
+ .name = ehci,
+ .pa_start = 0x48064800,
+ .pa_end = 0x48064cff,
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__ick = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk = usbhost_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_usb_host_hs__ick,
+};
+
+static struct omap_hwmod_opt_clk omap34xx_usb_host_hs_opt_clks[] = {
+ { .role = ehci_logic_fck, .clk = usbhost_120m_fck, },
+};
+
+static struct omap_hwmod_irq_info omap34xx_usb_host_hs_irqs[] = {
+ { .name = ohci-irq, .irq = 76 },
+ { .name = ehci-irq, .irq = 77 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap34xx_usb_host_hs_irqs,
+ .main_clk = usbhost_48m_fck,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430ES2_EN_USBHOST1_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430ES2_ST_USBHOST_IDLE_SHIFT,
+ .idlest_stdby_bit =
OMAP3430ES2_ST_USBHOST_STDBY_SHIFT,
+ },
+ },
+ .opt_clks = omap34xx_usb_host_hs_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_opt_clks),
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt =
RE: [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
hi Kevin,
Apologies for the delayed response, I was on vacation.
On October 01, 2011 4:57 AM, Hilman, Kevin wrote:
Abhilash,
Kevin Hilman khil...@ti.com writes:
Abhilash K V abhilash...@ti.com writes:
From: Abhilash K V abhilash...@ti.com
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it. So omap3_twl_init() is now not called
when the processor does not support SR.
This still isn't right.
The reason to skip the TWL PMIC init is not because SR is not available
(TWL PMICs are quite usable without SR). The reason to skip TWL PMIC
init is because the PMIC is not present.
[Abhilash K V] yes, I understand now.
Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
only registered if a TWL driver is registered.
Below is a test patch that is a first pass at implementing what I
suggested above. I tested this (along with your patch 3/3) on a
3430/n900 after removing the omap_pmic_init() call frome the board file.
[Abhilash K V] I'll re-submit the patch with this change (i,e. if you've not
already
pulled it into your branch).
Can you let me know if this solves the problem you're seeing on
platforms that don't have TWL PMICs?
[Abhilash K V] It should, I have validated on am3517_evm
After digging into this more, I'm increasingly aware that the way we're
managing the init of PMIC stuff is a mess. Guess I need another round
of voltage layer cleanups to fix that up.
[Abhilash K V] True, and to add to this, the changes required to support only
ONE voltage-domain for am35xx would be too many, I believe.
Kevin
From 1cd49077829a262155b96f8fdcdcdd6c54d83ed5 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Fri, 30 Sep 2011 11:24:04 -0700
Subject: [PATCH] ARM: OMAP2+: PM: only register TWL with voltage layer when
device is present
Current code registers voltage layer details for TWL PMIC even when a TWL
has not been registered. Fix this to only register the TWL with voltage
layer when the TWL PMIC is initialized by board-level code.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c |6 ++
arch/arm/mach-omap2/twl-common.c | 11 +++
arch/arm/mach-omap2/twl-common.h |3 +++
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d34fc52..602fc66 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -23,6 +23,7 @@
#include powerdomain.h
#include clockdomain.h
#include pm.h
+#include twl-common.h
static struct omap_device_pm_latency *pm_lats;
@@ -251,11 +252,8 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
- /* Init the OMAP TWL parameters */
- omap3_twl_init();
- omap4_twl_init();
-
/* Init the voltage layer */
+ omap_pmic_late_init();
omap_voltage_late_init();
/* Initialize the voltages */
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index daa056e..47133fa 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -30,6 +30,7 @@
#include plat/usb.h
#include twl-common.h
+#include pm.h
static struct i2c_board_info __initdata pmic_i2c_board_info = {
.addr = 0x48,
@@ -48,6 +49,16 @@ void __init omap_pmic_init(int bus, u32 clkrate,
omap_register_i2c_bus(bus, clkrate, pmic_i2c_board_info, 1);
}
+void __init omap_pmic_late_init(void)
+{
+ /* Init the OMAP TWL parameters (if PMIC has been registerd) */
+ if (!pmic_i2c_board_info.irq)
+ return;
+
+ omap3_twl_init();
+ omap4_twl_init();
+}
+
#if defined(CONFIG_ARCH_OMAP3)
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
diff --git a/arch/arm/mach-omap2/twl-common.h
b/arch/arm/mach-omap2/twl-common.h
index 5e83a5b..275dde8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -1,6 +1,8 @@
#ifndef __OMAP_PMIC_COMMON__
#define __OMAP_PMIC_COMMON__
+#include plat/irqs.h
+
#define TWL_COMMON_PDATA_USB (1 0)
#define TWL_COMMON_PDATA_BCI (1 1)
#define TWL_COMMON_PDATA_MADC (1 2)
@@ -30,6 +32,7 @@ struct twl4030_platform_data;
void omap_pmic_init(int bus, u32 clkrate, const char *pmic_type, int
pmic_irq,
struct twl4030_platform_data *pmic_data);
+void omap_pmic_late_init(void);
static inline void omap2_pmic_init(const char *pmic_type,
struct twl4030_platform_data *pmic_data)
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Tue, Oct 11, 2011 at 11:18 AM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Oct 11, 2011 at 6:08 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
so I just noticed another problem with these hwmods:
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 227
1 files changed, 227 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..b8ca690 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
...
+static struct omap_hwmod_ocp_if omap34xx_ick_cfg__usb_tll_hs = {
This interface is missing a .master and .slave. It must have both. So,
dropping this patch until it's fixed.
Clearly we also need to modify the hwmod code needs to reject any
instances where either .master or .slave is NULL.
- Paul
Hi Paul
I will fix it today only and I will send the updated
patches in couple of hours.
please help me to make it in this merge window.
Hi Paul
I have posted v14 of the patches; please do review
if it is OK, please merge to your branch for 3.2 version
please let me know if you have any comments here.
Thanks and Regards
keshava
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi Paul,
On 10/11/2011 2:40 AM, Paul Walmsley wrote:
Hi
and some comments on this one ...
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
[...]
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_tll_hs = {
+ .master =omap44xx_l4_cfg_hwmod,
+ .slave =omap44xx_usb_tll_hs_hwmod,
+ .addr = omap44xx_usb_tll_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
This one has the .master pointing to something reasonable, but is missing
a .clk entry.
In that case, there is only an interface clock and a couple of optional
clocks, that why I did not populate the main_clk.
IIRC, we decided to not duplicate the iclk into the main_clk in case of
module that are using only the interface clock as their functional clock.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi,
On Mon, Oct 10, 2011 at 08:15:29PM -0400, Alan Stern wrote:
In fact we do already have sibling lists. They are maintained as
part
of the device_private structure. What we are missing is a
device_for_each_sibling() routine. It could be added pretty easily;
it
would be similar to device_for_each_child().
care to point out where is ?
68 struct device_private {
69 struct klist klist_children;
70 struct klist_node knode_parent;
-^ Here. The parent in the name refers to where the
head of the list is stored.
71 struct klist_node knode_driver;
72 struct klist_node knode_bus;
73 void *driver_data;
74 struct device *device;
75 };
From device_add():
if (parent)
klist_add_tail(dev-p-knode_parent,
parent-p-klist_children);
that's a parent - child relationship. What we have on this case is:
-----
| | | | |\
| UHH| clocks, etc |USBTLL | | |
| | == | | == | | ports
| --- | | (Transceiver- | | |
|| EHCI | | | less Link)| |/
| --- | | | Port MUX
| | | |
| --- | | |
|| OHCI | | | |
| --- | | |
| | | |
-----
It doesn't shown here, but the TLL link is completely optional. It's
mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI
and OHCI will depend on a clock provided by the USBTLL block.
Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI
blocks. We can, from a code perspective, make USBTLL into a parent of
UHH to make things simpler, but this will mean that calling
pm_runtime_get() will also unconditionaly turn on TLL clock, unless we
add some nasty hacks to allow TLL know if *HCI port is in TLL mode.
That's why I decided for making TLL and UHH siblings, because that's a
closer relationship than parent-child.
Can you see the problem now ?
Okay, now I understand better. The word sibling implies that the two
objects have the same parent, so a different word would describe this
relationship better. Something like friend or associate.
Or maybe, following Paul's suggestion, the driver core doesn't have to
be changed at all.
I see... I just thought that if there are other similar cases, it might
make sense to have a more generic way to make those two devices talk to
each other. But if you all agree that an EXPORT_SYMBOL_GPL() is enough,
then it's ok ;-)
thanks
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx
Hi, On Mon, Oct 10, 2011 at 10:40:55AM +0530, Gupta, Ajay Kumar wrote: Hi, On Mon, Sep 26, 2011 at 03:21:07PM +0530, Gupta, Ajay Kumar wrote: To: linux-omap@vger.kernel.org Cc: linux-...@vger.kernel.org; Balbi, Felipe; t...@atomide.com; B, Ravi; Cousson, Benoit; Gupta, Ajay Kumar Subject: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx Felipe, I am planning to send patch 1/6 along with next revision of ti81xx hwmod baseport patch from Hemant so that all hwmod data gets reviewed at one place. So now only rest 5 (2/6 to 6/6) patches needs to be queued for usb. I hope this will be fine with you. Let me know if you want me to post Same 5 patches separately. I guess it's better to queue them separately. I will only take whatever lies in drivers/usb/musb Ok fine so usb hwmod patch will come from Hemant in his hwmod baseport Series. I will resubmit the one patch fixing your comment. ok cool, tks. For you platform_data stuff (if you have any), you can add a header to include/linux/platform_data/musb-dsps.h I need to access struct omap_musb_board_data and so would add #include plat/usb.h in new file drivers/usb/musb/musb_dsps.h. Any comment ? Ajay Or something similar. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx
Hi, On Tue, Oct 11, 2011 at 02:13:07PM +0530, Gupta, Ajay Kumar wrote: Hi, On Mon, Oct 10, 2011 at 10:40:55AM +0530, Gupta, Ajay Kumar wrote: Hi, On Mon, Sep 26, 2011 at 03:21:07PM +0530, Gupta, Ajay Kumar wrote: To: linux-omap@vger.kernel.org Cc: linux-...@vger.kernel.org; Balbi, Felipe; t...@atomide.com; B, Ravi; Cousson, Benoit; Gupta, Ajay Kumar Subject: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx Felipe, I am planning to send patch 1/6 along with next revision of ti81xx hwmod baseport patch from Hemant so that all hwmod data gets reviewed at one place. So now only rest 5 (2/6 to 6/6) patches needs to be queued for usb. I hope this will be fine with you. Let me know if you want me to post Same 5 patches separately. I guess it's better to queue them separately. I will only take whatever lies in drivers/usb/musb Ok fine so usb hwmod patch will come from Hemant in his hwmod baseport Series. I will resubmit the one patch fixing your comment. ok cool, tks. For you platform_data stuff (if you have any), you can add a header to include/linux/platform_data/musb-dsps.h I need to access struct omap_musb_board_data and so would add #include plat/usb.h in new file drivers/usb/musb/musb_dsps.h. Any comment ? It would be nice to move that platform_data from plat to linux/platform_data -- balbi signature.asc Description: Digital signature
RE: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx
Hi,
On Tue, Oct 11, 2011 at 02:13:07PM +0530, Gupta, Ajay Kumar wrote:
Hi,
On Mon, Oct 10, 2011 at 10:40:55AM +0530, Gupta, Ajay Kumar wrote:
Hi,
On Mon, Sep 26, 2011 at 03:21:07PM +0530, Gupta, Ajay Kumar
wrote:
To: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org; Balbi, Felipe;
t...@atomide.com; B, Ravi; Cousson, Benoit; Gupta, Ajay
Kumar
Subject: [PATCH 1/6 v3] omap: musb: Adding hwmod data for
ti81xx
Felipe,
I am planning to send patch 1/6 along with next revision of
ti81xx hwmod baseport patch from Hemant so that all hwmod data
gets reviewed at one place.
So now only rest 5 (2/6 to 6/6) patches needs to be queued for
usb.
I hope this will be fine with you. Let me know if you want me
to post Same 5 patches separately.
I guess it's better to queue them separately. I will only take
whatever lies in drivers/usb/musb
Ok fine so usb hwmod patch will come from Hemant in his hwmod
baseport Series. I will resubmit the one patch fixing your
comment.
ok cool, tks.
For you platform_data stuff (if you have any), you can add a header
to include/linux/platform_data/musb-dsps.h
I need to access struct omap_musb_board_data and so would add
#include plat/usb.h in new file drivers/usb/musb/musb_dsps.h.
Any comment ?
It would be nice to move that platform_data from plat to
linux/platform_data
Yes, correct. But that would need change at below files.
arch/arm/mach-omap2/board-4430sdp.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-am3517evm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-omap3evm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-rx51.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-omap4panda.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-ti8168evm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-omap4pcm049.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/usb-musb.c:static void usb_musb_mux_init(struct
omap_musb_board_data *board_data)
arch/arm/mach-omap2/board-ti8148evm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-am335xevm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-ti8148evm.c.orig:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-omap3evm.c.orig:static struct omap_musb_board_data
musb_board_data = {
drivers/usb/musb/am35x.c:
drivers/usb/musb/musb_dsps.c
drivers/usb/musb/omap2430.c:
I think this can be done in a separate patch and let the ti81xx 6/6
Patch to remain same.
The separate patch will replace #include plat/usb.h to
#include platform_data/usb.h
Ajay
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx
Hi,
On Tue, Oct 11, 2011 at 03:07:46PM +0530, Gupta, Ajay Kumar wrote:
Hi,
On Tue, Oct 11, 2011 at 02:13:07PM +0530, Gupta, Ajay Kumar wrote:
Hi,
On Mon, Oct 10, 2011 at 10:40:55AM +0530, Gupta, Ajay Kumar wrote:
Hi,
On Mon, Sep 26, 2011 at 03:21:07PM +0530, Gupta, Ajay Kumar
wrote:
To: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org; Balbi, Felipe;
t...@atomide.com; B, Ravi; Cousson, Benoit; Gupta, Ajay
Kumar
Subject: [PATCH 1/6 v3] omap: musb: Adding hwmod data for
ti81xx
Felipe,
I am planning to send patch 1/6 along with next revision of
ti81xx hwmod baseport patch from Hemant so that all hwmod data
gets reviewed at one place.
So now only rest 5 (2/6 to 6/6) patches needs to be queued for
usb.
I hope this will be fine with you. Let me know if you want me
to post Same 5 patches separately.
I guess it's better to queue them separately. I will only take
whatever lies in drivers/usb/musb
Ok fine so usb hwmod patch will come from Hemant in his hwmod
baseport Series. I will resubmit the one patch fixing your
comment.
ok cool, tks.
For you platform_data stuff (if you have any), you can add a header
to include/linux/platform_data/musb-dsps.h
I need to access struct omap_musb_board_data and so would add
#include plat/usb.h in new file drivers/usb/musb/musb_dsps.h.
Any comment ?
It would be nice to move that platform_data from plat to
linux/platform_data
Yes, correct. But that would need change at below files.
arch/arm/mach-omap2/board-4430sdp.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-am3517evm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-omap3evm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-rx51.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-omap4panda.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-ti8168evm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-omap4pcm049.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/usb-musb.c:static void usb_musb_mux_init(struct
omap_musb_board_data *board_data)
arch/arm/mach-omap2/board-ti8148evm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-am335xevm.c:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-ti8148evm.c.orig:static struct omap_musb_board_data
musb_board_data = {
arch/arm/mach-omap2/board-omap3evm.c.orig:static struct omap_musb_board_data
musb_board_data = {
drivers/usb/musb/am35x.c:
drivers/usb/musb/musb_dsps.c
drivers/usb/musb/omap2430.c:
I think this can be done in a separate patch and let the ti81xx 6/6
Patch to remain same.
The separate patch will replace #include plat/usb.h to
#include platform_data/usb.h
cool, that can be done with a sed script ;-)
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx
Hi,
On Tue, Oct 11, 2011 at 02:13:07PM +0530, Gupta, Ajay Kumar wrote:
Hi,
On Mon, Oct 10, 2011 at 10:40:55AM +0530, Gupta, Ajay Kumar
wrote:
Hi,
On Mon, Sep 26, 2011 at 03:21:07PM +0530, Gupta, Ajay Kumar
wrote:
To: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org; Balbi, Felipe;
t...@atomide.com; B, Ravi; Cousson, Benoit; Gupta, Ajay
Kumar
Subject: [PATCH 1/6 v3] omap: musb: Adding hwmod data
for ti81xx
Felipe,
I am planning to send patch 1/6 along with next revision
of ti81xx hwmod baseport patch from Hemant so that all
hwmod data gets reviewed at one place.
So now only rest 5 (2/6 to 6/6) patches needs to be queued
for
usb.
I hope this will be fine with you. Let me know if you want
me to post Same 5 patches separately.
I guess it's better to queue them separately. I will only
take whatever lies in drivers/usb/musb
Ok fine so usb hwmod patch will come from Hemant in his hwmod
baseport Series. I will resubmit the one patch fixing your
comment.
ok cool, tks.
For you platform_data stuff (if you have any), you can add a
header to include/linux/platform_data/musb-dsps.h
I need to access struct omap_musb_board_data and so would add
#include plat/usb.h in new file drivers/usb/musb/musb_dsps.h.
Any comment ?
It would be nice to move that platform_data from plat to
linux/platform_data
Yes, correct. But that would need change at below files.
arch/arm/mach-omap2/board-4430sdp.c:static struct omap_musb_board_data
musb_board_data = { arch/arm/mach-omap2/board-am3517evm.c:static
struct omap_musb_board_data musb_board_data = {
arch/arm/mach-omap2/board-omap3evm.c:static struct
omap_musb_board_data musb_board_data = {
arch/arm/mach-omap2/board-rx51.c:static struct omap_musb_board_data
musb_board_data = { arch/arm/mach-omap2/board-omap4panda.c:static
struct omap_musb_board_data musb_board_data = {
arch/arm/mach-omap2/board-ti8168evm.c:static struct
omap_musb_board_data musb_board_data = {
arch/arm/mach-omap2/board-omap4pcm049.c:static struct
omap_musb_board_data musb_board_data = {
arch/arm/mach-omap2/usb-musb.c:static void usb_musb_mux_init(struct
omap_musb_board_data *board_data)
arch/arm/mach-omap2/board-ti8148evm.c:static struct
omap_musb_board_data musb_board_data = {
arch/arm/mach-omap2/board-am335xevm.c:static struct
omap_musb_board_data musb_board_data = {
arch/arm/mach-omap2/board-ti8148evm.c.orig:static struct
omap_musb_board_data musb_board_data = {
arch/arm/mach-omap2/board-omap3evm.c.orig:static struct
omap_musb_board_data musb_board_data = {
drivers/usb/musb/am35x.c:
drivers/usb/musb/musb_dsps.c
drivers/usb/musb/omap2430.c:
I think this can be done in a separate patch and let the ti81xx 6/6
Patch to remain same.
The separate patch will replace #include plat/usb.h to #include
platform_data/usb.h
cool, that can be done with a sed script ;-)
Ok fine then I will send the refreshed 5 patch set for ti81xx and 3 patch set
for am335x correcting your comments.
Thanks,
Ajay
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
Hi Ohad, On Mon, Oct 10, 2011 at 01:02:46PM -0400, Ohad Ben-Cohen wrote: On Mon, Oct 10, 2011 at 5:36 PM, Roedel, Joerg joerg.roe...@amd.com wrote: Yes, somthing like that. Probably the iommu_ops-unmap function should be turned into a unmap_page function call which only takes an iova and no size parameter. The iommu-driver unmaps the page pointing to that iova and returns the size of the page unmapped. This still allows the simple implementation for the unmap-call. Yes, exactly. It will take some time to migrate all drivers (today we have 4 drivers, each of which is implementing a slightly different -unmap() semantics), but at least let's not accept any new driver that doesn't adhere to this, otherwise it's going to be even harder for the API to evolve. Agreed. We should change the existing drivers one-by-one. We don't need to really enforce the calls to be symetric. But we can define that we only give the guarantee about what will be unmapped when the calls are symetric. Sounds good to me. I'll add this to the kernel doc patch (which I'll submit after this patch set materializes), and when/if we move to symmetric only, we will update it. Great. So if no one disagrees with this direction (this means all the other people on Cc :) ) it is the way to. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
On Mon, Oct 10, 2011 at 06:01:06PM -0400, Ohad Ben-Cohen wrote:
On Mon, Oct 10, 2011 at 5:36 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
The master branch is best to base your patches on for generic work.
It looks like the master branch is missing something like this:
From acb316aa4bcaf383e8cb1580e30c8635e0a34369 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@wizery.com
Date: Mon, 10 Oct 2011 23:55:51 +0200
Subject: [PATCH] iommu/core: fix build issue
Fix this:
drivers/iommu/iommu.c: In function 'iommu_commit':
drivers/iommu/iommu.c:291: error: 'iommu_ops' undeclared (first use in
this function)
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/iommu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 909b0d2..a5131f1 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -288,7 +288,7 @@ EXPORT_SYMBOL_GPL(iommu_unmap);
void iommu_commit(struct iommu_domain *domain)
{
- if (iommu_ops-commit)
- iommu_ops-commit(domain);
+ if (domain-ops-commit)
+ domain-ops-commit(domain);
}
EXPORT_SYMBOL_GPL(iommu_commit);
--
1.7.4.1
Whoops. This iommu_commit branch wasn't meant to be in master already.
I'll try to fix that.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
On Mon, Oct 10, 2011 at 06:49:32PM -0400, Ohad Ben-Cohen wrote:
-int iommu_unmap(struct iommu_domain *domain, unsigned long iova, int
gfp_order)
+int iommu_unmap(struct iommu_domain *domain, unsigned long iova, int size)
{
- size_t size;
+ int order, unmapped_size, unmapped_order, total_unmapped = 0;
if (unlikely(domain-ops-unmap == NULL))
return -ENODEV;
- size = PAGE_SIZE gfp_order;
+ /*
+* The virtual address, as well as the size of the mapping, must be
+* aligned (at least) to the size of the smallest page supported
+* by the hardware
+*/
+ if (!IS_ALIGNED(iova | size, domain-ops-min_pagesz)) {
+ pr_err(unaligned: iova 0x%lx size 0x%x min_pagesz 0x%x\n,
+ iova, size, domain-ops-min_pagesz);
+ return -EINVAL;
+ }
+
+ pr_debug(unmap this: iova 0x%lx size 0x%x\n, iova, size);
+
+ while (size total_unmapped) {
+ order = get_order(size - total_unmapped);
Hmm, this actually unmaps more than requested, even in the symetric
case. Imgine the user wants to unmap a 12kb region, then order
will be 4 and this code will tell the iommu-driver to unmap 16kb.
You need to make sure that you don;t pass larger regions then requested
to the low-level driver. Some logic like in the iommu_map function
should do it.
+
+ unmapped_order = domain-ops-unmap(domain, iova, order);
+ if (unmapped_order 0)
+ break;
+
+ pr_debug(unmapped: iova 0x%lx order %d\n, iova,
+ unmapped_order);
+
+ unmapped_size = 0x1000UL unmapped_order;
Please use PAGE_SIZE instead of 0x1000UL.
- BUG_ON(!IS_ALIGNED(iova, size));
+ iova += unmapped_size;
+ total_unmapped += unmapped_size;
+ }
- return domain-ops-unmap(domain, iova, gfp_order);
+ return total_unmapped;
}
EXPORT_SYMBOL_GPL(iommu_unmap);
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index e8fdb88..4a8f761 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -409,7 +409,6 @@ static int map_iovm_area(struct iommu_domain
*domain, struct iovm_struct *new,
unsigned int i, j;
struct scatterlist *sg;
u32 da = new-da_start;
- int order;
if (!domain || !sgt)
return -EINVAL;
@@ -428,12 +427,10 @@ static int map_iovm_area(struct iommu_domain
*domain, struct iovm_struct *new,
if (bytes_to_iopgsz(bytes) 0)
goto err_out;
- order = get_order(bytes);
-
pr_debug(%s: [%d] %08x %08x(%x)\n, __func__,
i, da, pa, bytes);
- err = iommu_map(domain, da, pa, order, flags);
+ err = iommu_map(domain, da, pa, bytes, flags);
if (err)
goto err_out;
@@ -448,10 +445,9 @@ err_out:
size_t bytes;
bytes = sg-length + sg-offset;
- order = get_order(bytes);
/* ignore failures.. we're already handling one */
- iommu_unmap(domain, da, order);
+ iommu_unmap(domain, da, bytes);
da += bytes;
}
@@ -474,13 +470,11 @@ static void unmap_iovm_area(struct iommu_domain
*domain, struct omap_iommu *obj,
start = area-da_start;
for_each_sg(sgt-sgl, sg, sgt-nents, i) {
size_t bytes;
- int order;
bytes = sg-length + sg-offset;
- order = get_order(bytes);
- err = iommu_unmap(domain, start, order);
- if (err 0)
+ err = iommu_unmap(domain, start, bytes);
+ if (err bytes)
break;
dev_dbg(obj-dev, %s: unmap %08x(%x) %08x\n,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 710291f..a10a86c 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -48,6 +48,22 @@ struct iommu_domain {
#ifdef CONFIG_IOMMU_API
+/**
+ * struct iommu_ops - iommu ops and capabilities
+ * @domain_init: init iommu domain
+ * @domain_destroy: destroy iommu domain
+ * @attach_dev: attach device to an iommu domain
+ * @detach_dev: detach device from an iommu domain
+ * @map: map a physically contiguous memory region to an iommu domain
+ * @unmap: unmap a physically contiguous memory region from an iommu domain
+ * @iova_to_phys: translate iova to physical address
+ * @domain_has_cap: domain capabilities query
+ * @commit: commit iommu domain
+ * @pgsize_bitmap: bitmap of supported page sizes
+ * @min_pagesz: smallest page size supported. note: this member is private
+ * to the IOMMU core, and
Re: [RFT/PATCH 7/7] arm: omap: smartreflex: micro-optimization for sanity check
Hello.
On 10-10-2011 16:26, Felipe Balbi wrote:
val (val != 1) == val 1
Signed-off-by: Felipe Balbiba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7bdabfa..4b0d6a8 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -866,7 +866,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
}
/* Sanity check */
- if (val (val != 1)) {
+ if (val 1) {
pr_warning(%s: Invalid argument %lld\n, __func__, val);
The format specified should be %llu?
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: [RFT/PATCH 6/7] arm: omap: smartreflex: fix IRQ handling bug
Hello. On 10-10-2011 16:26, Felipe Balbi wrote: fix a bug which has been on this driver since it was added by the original commit 984aa6db Please also specify that commit's summary in parens. which would never clear IRQSTATUS bits. Signed-off-by: Felipe Balbi ba...@ti.com 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
[PATCH 0/8 v4] usb: musb: Adding support for ti81xx and am335x
This patch set adds support for musb interface for TI81XX and AM33XX platforms and are dependent on recent patch series from Hemant Pedanekar at [1] and [2] and Vaibhav Hiremath at [3] TI81XX and AM33XX platform has dual musb instances, uses CPPI4.1 DMA and has built in usb PHY. The current set of patches supports only the first interface and in PIO mode. [1] http://marc.info/?l=linux-omapm=131411961308438w=2 [2] http://marc.info/?l=linux-omapm=131821081227729w=2 [3] http://marc.info/?l=linux-omapm=131652916305543w=2 Changes from v3 for TI81xx: - Dropped hwmod data patch as that will be submitted along with Hemant's hwmod baseport patches. - Added ioremap and iounmap for accessing SCM register Changes from v1 for AM33xx: - Used cpu_is_am33xx() instead of cpu_is_am335x() to cover wider wider range of devices. - Removed unneeded parens. Ajay Kumar Gupta (4): omap: musb: ti81xx: Add phy power function arm: omap: am335x: enable phy controls usb: musb: enable support for am335x am335xevm: Add support for musb interface Ravi Babu (4): omap: musb: Adding support for ti81xx ti816evm: Add support for musb interface ti814evm: Add support for musb interface usb: musb: Add support for ti81xx platform arch/arm/mach-omap2/board-am335xevm.c |9 + arch/arm/mach-omap2/board-ti8148evm.c |9 + arch/arm/mach-omap2/board-ti8168evm.c |9 + arch/arm/mach-omap2/omap_phy_internal.c | 42 ++ arch/arm/mach-omap2/usb-musb.c |3 + arch/arm/plat-omap/include/plat/usb.h | 32 ++ drivers/usb/musb/Kconfig|6 + drivers/usb/musb/Makefile |1 + drivers/usb/musb/musb_core.c|4 +- drivers/usb/musb/musb_dsps.c| 693 +++ 10 files changed, 807 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/musb/musb_dsps.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] omap: musb: Adding support for ti81xx
From: Ravi Babu ravib...@ti.com
Added musb support for ti81xx platform which has two instances of musb
interface and uses CPPI4.1 DMA. The current patch set adds support for
single instance and in PIO mode only.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index a65145b..8bceeca 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -143,6 +143,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
if (cpu_is_omap3517() || cpu_is_omap3505()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
+ } else if (cpu_is_ti81xx()) {
+ oh_name = usb_otg_hs;
+ name = musb-ti81xx;
} else {
oh_name = usb_otg_hs;
name = musb-omap2430;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] ti816evm: Add support for musb interface
From: Ravi Babu ravib...@ti.com
Adding musb support in ti816 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-ti8168evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index 2c243df..1f3d423 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
};
@@ -33,6 +41,7 @@ static void __init ti8168_evm_init(void)
omap_sdrc_init(NULL, NULL);
omap_board_config = ti8168_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init ti8168_evm_map_io(void)
--
1.6.2.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 7/8] arm: omap: am335x: enable phy controls
Switch on the phy for am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Changes from v1:
- Added ioremap for AM33x SCM base.
arch/arm/mach-omap2/omap_phy_internal.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..7129408 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -266,7 +266,11 @@ void ti81xx_musb_phy_power(u8 on)
void __iomem *scm_base = NULL;
u32 usbphycfg;
- scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
+ if (cpu_is_ti81xx())
+ scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
+ else if (cpu_is_am33xx())
+ scm_base = ioremap(AM33XX_SCM_BASE, SZ_2K);
+
if (!scm_base) {
pr_err(system control module ioremap failed\n);
return;
@@ -278,16 +282,19 @@ void ti81xx_musb_phy_power(u8 on)
if (cpu_is_ti816x()) {
usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
- } else if (cpu_is_ti814x()) {
- usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
+ } else if (cpu_is_ti814x() || cpu_is_am33xx()) {
+ usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
+ usbphycfg |= USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN;
+ if (cpu_is_ti814x()) {
+ usbphycfg = ~(USBPHY_DPINPUT | USBPHY_DMINPUT);
+ usbphycfg |= USBPHY_DPOPBUFCTL
+ | USBPHY_DMOPBUFCTL;
+ }
}
} else {
if (cpu_is_ti816x())
usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
- else if (cpu_is_ti814x())
+ else if (cpu_is_ti814x() || cpu_is_am33xx())
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
--
1.6.2.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 8/8] usb: musb: enable support for am335x
Enabled the flag so that musb_dsps glue file can be used for am335x Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- Changes from v1 - Removed unneeded parens. drivers/usb/musb/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index d6abdec..e3a863c 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -8,7 +8,7 @@ config USB_MUSB_HDRC depends on USB USB_GADGET depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) - select NOP_USB_XCEIV if SOC_OMAPTI81XX + select NOP_USB_XCEIV if (SOC_OMAPTI81XX || SOC_OMAPAM33XX) select TWL4030_USB if MACH_OMAP_3430SDP select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA select USB_OTG_UTILS @@ -57,7 +57,7 @@ config USB_MUSB_AM35X config USB_MUSB_DSPS tristate TI DSPS platforms - depends on SOC_OMAPTI81XX + depends on SOC_OMAPTI81XX || SOC_OMAPAM33XX config USB_MUSB_BLACKFIN tristate Blackfin @@ -73,7 +73,7 @@ config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X - default SOC_OMAPTI81XX + default SOC_OMAPTI81XX || SOC_OMAPAM33XX help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] omap: musb: ti81xx: Add phy power function
Adding ti81xx_musb_phy_power() which will be used by musb driver through
its function pointer in board_data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
Changes from v3:
- Added ioremap and inumap for SCM register access instead of using
omap_ctrl_read/write.
arch/arm/mach-omap2/omap_phy_internal.c | 35 +++
arch/arm/plat-omap/include/plat/usb.h | 32
2 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 58775e3..4c90477 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -260,3 +260,38 @@ void am35x_set_mode(u8 musb_mode)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
+
+void ti81xx_musb_phy_power(u8 on)
+{
+ void __iomem *scm_base = NULL;
+ u32 usbphycfg;
+
+ scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
+ if (!scm_base) {
+ pr_err(system control module ioremap failed\n);
+ return;
+ }
+
+ usbphycfg = __raw_readl(scm_base + USBCTRL0);
+
+ if (on) {
+ if (cpu_is_ti816x()) {
+ usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
+ usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
+ } else if (cpu_is_ti814x()) {
+ usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
+ | USBPHY_DPINPUT | USBPHY_DMINPUT);
+ usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
+ | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
+ }
+ } else {
+ if (cpu_is_ti816x())
+ usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
+ else if (cpu_is_ti814x())
+ usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
+
+ }
+ __raw_writel(usbphycfg, scm_base + USBCTRL0);
+
+ iounmap(scm_base);
+}
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..c616385 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -114,6 +114,7 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void am35x_set_mode(u8 musb_mode);
+extern void ti81xx_musb_phy_power(u8 on);
/*
* FIXME correct answer depends on hmc_mode,
@@ -273,6 +274,37 @@ static inline void omap2_usbfs_init(struct omap_usb_config
*pdata)
#define CONF2_OTGPWRDN (1 2)
#define CONF2_DATPOL (1 1)
+/* TI81XX specific definitions */
+#define USBCTRL0 0x620
+#define USBSTAT0 0x624
+
+/* TI816X PHY controls bits */
+#define TI816X_USBPHY0_NORMAL_MODE (1 0)
+#define TI816X_USBPHY_REFCLK_OSC (1 8)
+
+/* TI814X PHY controls bits */
+#define USBPHY_CM_PWRDN(1 0)
+#define USBPHY_OTG_PWRDN (1 1)
+#define USBPHY_CHGDET_DIS (1 2)
+#define USBPHY_CHGDET_RSTRT(1 3)
+#define USBPHY_SRCONDM (1 4)
+#define USBPHY_SINKONDP(1 5)
+#define USBPHY_CHGISINK_EN (1 6)
+#define USBPHY_CHGVSRC_EN (1 7)
+#define USBPHY_DMPULLUP(1 8)
+#define USBPHY_DPPULLUP(1 9)
+#define USBPHY_CDET_EXTCTL (1 10)
+#define USBPHY_GPIO_MODE (1 12)
+#define USBPHY_DPOPBUFCTL (1 13)
+#define USBPHY_DMOPBUFCTL (1 14)
+#define USBPHY_DPINPUT (1 15)
+#define USBPHY_DMINPUT (1 16)
+#define USBPHY_DPGPIO_PD (1 17)
+#define USBPHY_DMGPIO_PD (1 18)
+#define USBPHY_OTGVDET_EN (1 19)
+#define USBPHY_OTGSESSEND_EN (1 20)
+#define USBPHY_DATA_POLARITY (1 23)
+
#if defined(CONFIG_ARCH_OMAP1) defined(CONFIG_USB)
u32 omap1_usb0_init(unsigned nwires, unsigned is_device);
u32 omap1_usb1_init(unsigned nwires);
--
1.6.2.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 5/8] usb: musb: Add support for ti81xx platform
From: Ravi Babu ravib...@ti.com TI81XX platform has two musb interfaces and uses CPPI4.1 DMA engine. It has builtin USB PHYs as AM35x. The current set of patches adds support for one instance and only in PIO mode. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com --- Same as v3. dropping plat/usb.h will be done in a seperate patch as discussed in the list. drivers/usb/musb/Kconfig |6 + drivers/usb/musb/Makefile|1 + drivers/usb/musb/musb_core.c |4 +- drivers/usb/musb/musb_dsps.c | 693 ++ 4 files changed, 703 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/musb/musb_dsps.c diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index fc34b8b..d6abdec 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -8,6 +8,7 @@ config USB_MUSB_HDRC depends on USB USB_GADGET depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if SOC_OMAPTI81XX select TWL4030_USB if MACH_OMAP_3430SDP select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA select USB_OTG_UTILS @@ -54,6 +55,10 @@ config USB_MUSB_AM35X tristate AM35x depends on ARCH_OMAP +config USB_MUSB_DSPS + tristate TI DSPS platforms + depends on SOC_OMAPTI81XX + config USB_MUSB_BLACKFIN tristate Blackfin depends on (BF54x !BF544) || (BF52x ! BF522 !BF523) @@ -68,6 +73,7 @@ config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X + default SOC_OMAPTI81XX help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index d8fd9d0..d92d110 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -13,6 +13,7 @@ musb_hdrc-$(CONFIG_DEBUG_FS) += musb_debugfs.o # Hardware Glue Layer obj-$(CONFIG_USB_MUSB_OMAP2PLUS) += omap2430.o obj-$(CONFIG_USB_MUSB_AM35X) += am35x.o +obj-$(CONFIG_USB_MUSB_DSPS)+= musb_dsps.o obj-$(CONFIG_USB_MUSB_TUSB6010)+= tusb6010.o obj-$(CONFIG_USB_MUSB_DAVINCI) += davinci.o obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 20a2873..b04790d 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1014,7 +1014,9 @@ static void musb_shutdown(struct platform_device *pdev) || defined(CONFIG_USB_MUSB_OMAP2PLUS) \ || defined(CONFIG_USB_MUSB_OMAP2PLUS_MODULE)\ || defined(CONFIG_USB_MUSB_AM35X) \ - || defined(CONFIG_USB_MUSB_AM35X_MODULE) + || defined(CONFIG_USB_MUSB_AM35X_MODULE)\ + || defined(CONFIG_USB_MUSB_DSPS)\ + || defined(CONFIG_USB_MUSB_DSPS_MODULE) static ushort __initdata fifo_mode = 4; #elif defined(CONFIG_USB_MUSB_UX500) \ || defined(CONFIG_USB_MUSB_UX500_MODULE) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c new file mode 100644 index 000..fb59e34 --- /dev/null +++ b/drivers/usb/musb/musb_dsps.c @@ -0,0 +1,693 @@ +/* + * Texas Instruments DSPS platforms glue layer + * + * Copyright (C) 2011, by Texas Instruments + * + * Based on the am35x glue layer code. + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux is free software; you + * can redistribute it and/or modify it under the terms of the GNU + * General Public License version 2 as published by the Free Software + * Foundation. + * + * The Inventra Controller Driver for Linux 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. + * + * You should have received a copy of the GNU General Public License + * along with The Inventra Controller Driver for Linux ; if not, + * write to the Free Software Foundation, Inc., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + * musb_dsps.c will be a common file for all the TI DSPS platforms + * such as dm64x, dm36x, dm35x, da8x, am35x and ti81x. + * For now only ti81x is using this and in future davinci.c, am35x.c + * da8xx.c would be merged to this file after testing. + */ + +#include linux/init.h +#include linux/io.h +#include linux/platform_device.h +#include linux/dma-mapping.h +#include linux/pm_runtime.h + +#include plat/usb.h + +#include musb_core.h + +/** + * avoid using musb_readx()/musb_writex() as glue
[PATCH 6/8] am335xevm: Add support for musb interface
Adding musb support in am335x EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-am335xevm.c |9 +
arch/arm/mach-omap2/usb-musb.c|2 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am335xevm.c
b/arch/arm/mach-omap2/board-am335xevm.c
index a4102ef..298dc51 100644
--- a/arch/arm/mach-omap2/board-am335xevm.c
+++ b/arch/arm/mach-omap2/board-am335xevm.c
@@ -24,6 +24,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
#include mux.h
@@ -73,6 +81,7 @@ static void __init am335x_evm_init(void)
omap_sdrc_init(NULL, NULL);
omap_board_config = am335x_evm_config;
omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init am335x_evm_map_io(void)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8bceeca..5cd373e 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -143,7 +143,7 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
if (cpu_is_omap3517() || cpu_is_omap3505()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
- } else if (cpu_is_ti81xx()) {
+ } else if (cpu_is_ti81xx() || cpu_is_am33xx()) {
oh_name = usb_otg_hs;
name = musb-ti81xx;
} else {
--
1.6.2.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 4/8] ti814evm: Add support for musb interface
From: Ravi Babu ravib...@ti.com
Adding musb support in ti814 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-ti8148evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8148evm.c
b/arch/arm/mach-omap2/board-ti8148evm.c
index 5f0280e..03c85dd 100644
--- a/arch/arm/mach-omap2/board-ti8148evm.c
+++ b/arch/arm/mach-omap2/board-ti8148evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti8148_evm_config[] __initdata = {
};
@@ -38,6 +46,7 @@ static void __init ti8148_evm_init(void)
omap_sdrc_init(NULL, NULL);
omap_board_config = ti8148_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8148_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init ti8148_evm_map_io(void)
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/6] OMAP4: Clock: Correct the name of SLIMBUS interface clocks
On 10/10/2011 11:34 PM, Hunter, Jon wrote:
Hi Benoit,
On 10/10/2011 4:54, Cousson, Benoit wrote:
Hi Jon,
On 10/8/2011 12:46 AM, Hunter, Jon wrote:
Hi Benoit,
On 10/7/2011 3:23, Cousson, Benoit wrote:
Hi Paul Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
+ Benoît
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Currently the interface clocks for the two SLIMBUS peripherals are
named slimbus1_fck and slimbus2_fck. Rename these clocks to be
slimbus1_ick and slimbus2_ick so it is clear that these are
interface clocks and not functional clocks.
Signed-off-by: Jon Hunterjon-hun...@ti.com
This one, I don't quite understand. We should probably be removing
these
MODULEMODE-only clocks from the OMAP4 tree, and using their parent
clock
as the main_clk. That would be a good cleanup for 3.3...
Yes, but in order to remove that from the clock data we must ensure that
the hwmod entry is there.
I kept a lot of legacy MODULEMODE clocks just because of missing hwmod /
runtime_pm adaptation on some drivers.
In the case of slimbus, there is no main_clk but a bunch of optional
clocks. It looks similar to the DSS case. So we should not use the
parent clock as a main_clk.
We should probably promote one of the opt_clk as the main_clk. The
slimbus_clk seems to be the good candidate for both instances.
static struct omap_hwmod_opt_clk slimbus1_opt_clks[] = {
{ .role = fclk_1, .clk = slimbus1_fclk_1 },
{ .role = fclk_0, .clk = slimbus1_fclk_0 },
{ .role = fclk_2, .clk = slimbus1_fclk_2 },
{ .role = slimbus_clk, .clk = slimbus1_slimbus_clk },
};
static struct omap_hwmod_opt_clk slimbus2_opt_clks[] = {
{ .role = fclk_1, .clk = slimbus2_fclk_1 },
{ .role = fclk_0, .clk = slimbus2_fclk_0 },
{ .role = slimbus_clk, .clk = slimbus2_slimbus_clk },
};
Jon,
Do you know if that one is indeed mandatory to use the slimbus IP?
Sorry, are you asking about the clocks I was re-naming or the
slimbus_clk you are referring to above?
The clocks you are renaming should not exist at all, so I was referring
to the real clocks that are all listed as optional clocks.
These clocks are the interface clocks enabled via the module-mode. So
you are saying you want to remove the interface clocks from the list of
clocks?
Yes or No, dependeing of which clock you are talking about.
The real interface clock is already handled thanks to the ocp_if structure.
/* l4_abe - slimbus1 */
static struct omap_hwmod_ocp_if omap44xx_l4_abe__slimbus1 = {
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_slimbus1_hwmod,
.clk= ocp_abe_iclk,
.addr = omap44xx_slimbus1_addrs,
.user = OCP_USER_MPU,
};
And since the modulemodule is now handled by the hwmod core thanks to that:
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_SLIMBUS_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_ABE_SLIMBUS_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
There is no need to create a fake leaf clock to handle the module using the
clock fmwk.
So we can now remove these two clock nodes from the clock44xx_data.c file:
static struct clk slimbus1_fck = {
.name = slimbus1_fck,
.ops= clkops_omap2_dflt,
.enable_reg = OMAP4430_CM1_ABE_SLIMBUS_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
.clkdm_name = abe_clkdm,
.parent = ocp_abe_iclk,
.recalc = followparent_recalc,
};
static struct clk slimbus2_fck = {
.name = slimbus2_fck,
.ops= clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_L4PER_SLIMBUS2_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
.clkdm_name = l4_per_clkdm,
.parent = l4_div_ck,
.recalc = followparent_recalc,
};
Usually we do need to have a main_clk in order to access the IP
registers (at least the sysconfig). But for some IPs, the iclk can be
enough.
If the interface clock is enough, then potentially that main clock is
not mandatory. But if one functional clock is mandatory, then we have to
figured out which one from the various optional functional clocks can be
used as the main_clk.
Looking at the clock tree tool, the slimbus_clk is the actual external
slimbus clock that can be generated by OMAP or by an external device.
The TRM states ...
Most of the SLIMbus module runs off two main clocks: the L4 interface
clock for the data input and output registers, and the control and
status control registers; and the SLIMbus clock, taken from the serial
interface (CLK line) for the SLIMbus-side logic.
The SLIMbus controller operates as clock source component (active
framer), which drives the SLIMbus clock line CLK, or as clock receiver
component, which gets its clock from
Re: [PATCH 4/8] ti814evm: Add support for musb interface
Hi Ajay, On 10/11/11 13:26, Ajay Kumar Gupta wrote: From: Ravi Babu ravib...@ti.com Adding musb support in ti814 EVM board file. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/board-ti8148evm.c |9 + This file does not exist and probably will not exist in the future, see [1] and [2]. So this patch can be dropped. Your 3/8 patch provides the support for both boards. [1] - http://www.spinics.net/lists/linux-omap/msg58348.html [2] - http://www.spinics.net/lists/arm-kernel/msg143915.html -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] ti816evm: Add support for musb interface
Hi Ajay,
On 10/11/11 13:26, Ajay Kumar Gupta wrote:
From: Ravi Babu ravib...@ti.com
Adding musb support in ti816 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
This patch can result in a merge conflict, therefore I think
this one should be taken through Tony's tree.
Also you should work together with Hemant Pedanekar and
someone of you should rebase on top of the other otherwise
one of the patches (yours or Hemant's) possibly will not apply.
---
arch/arm/mach-omap2/board-ti8168evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index 2c243df..1f3d423 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
};
@@ -33,6 +41,7 @@ static void __init ti8168_evm_init(void)
omap_sdrc_init(NULL, NULL);
omap_board_config = ti8168_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init ti8168_evm_map_io(void)
--
Regards,
Igor.
--
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: [RFT/PATCH 7/7] arm: omap: smartreflex: micro-optimization for sanity check
On Tue, Oct 11, 2011 at 03:22:33PM +0400, Sergei Shtylyov wrote:
Hello.
On 10-10-2011 16:26, Felipe Balbi wrote:
val (val != 1) == val 1
Signed-off-by: Felipe Balbiba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7bdabfa..4b0d6a8 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -866,7 +866,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
}
/* Sanity check */
-if (val (val != 1)) {
+if (val 1) {
pr_warning(%s: Invalid argument %lld\n, __func__, val);
The format specified should be %llu?
and what does that have to do with $SUBJECT ??
--
balbi
signature.asc
Description: Digital signature
Re: [RFT/PATCH 6/7] arm: omap: smartreflex: fix IRQ handling bug
On Tue, Oct 11, 2011 at 03:23:52PM +0400, Sergei Shtylyov wrote: Hello. On 10-10-2011 16:26, Felipe Balbi wrote: fix a bug which has been on this driver since it was added by the original commit 984aa6db Please also specify that commit's summary in parens. sure, no problem -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
On Tue, Oct 11, 2011 at 1:37 AM, Andrei Warkentin awarken...@vmware.com wrote: Hi, - Original Message - From: Greg KH g...@kroah.com To: Josh Triplett j...@joshtriplett.org Cc: G, Manjunath Kondaiah manj...@ti.com, linux-arm-ker...@lists.infradead.org, Grant Likely grant.lik...@secretlab.ca, linux-omap@vger.kernel.org, linux-...@vger.kernel.org, linux-ker...@vger.kernel.org, Dilan Lee di...@nvidia.com, Mark Brown broo...@opensource.wolfsonmicro.com, manjun...@jasper.es Sent: Saturday, October 8, 2011 11:55:02 AM Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism I'm a bit of a fly on the wall here, but I'm curious how this impacts suspend/resume. device_initialize-device_pm_init are called from device_register, so certainly this patch doesn't also ensure that the PM ordering matches probe ordering, which is bound to break suspend, right? Was this ever tested with the OMAP target? Shouldn't the Inside device_add(), device_pm_add is called before bus_probe_device, so the patch can't change the device order in pm list, and just change the driver probe order. PM change be also part of this patch set? I don't see why you would want to have this in without the PM changes. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 08/16] OMAP2+: UART: Store certain reg values to port structure
On Tue, Oct 11, 2011 at 5:28 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: In preparation to runtime conversion add missing uart regs to port structure which can be used in context restore. Also ensuring all uart reg info's are part of port structure. Signed-off-by: Govindraj.R govindraj.r...@ti.com IMO, this should come later in the series to avoid adding bunch of code that gets moved in a subsequent patch. First, convert to runtime PM (current patch 9/16) Then, add a patch to move context save/restore into driver. Then, add this patch. Okay fine. -- Thanks, Govindraj.R -- 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: omap2+: stub out omap*_volt_data
On Monday 10 October 2011, Kevin Hilman wrote: I got this build error only now after pulling in the latest omap series, but I cannot tell what caused it. It's also not clear to me if this is the correct solution. Please ack or provide a better fix. This code was merged for v2.6.39, so not sure why this error is only showing up for you now. I just tried a !CONFIG_PM_OPP build on v2.6.39 and get the same errors, so it's been lingering. Maybe you haven't had a randconfig that disabled CONFIG_PM_OPP before? I don't know. The best explanation is that this is a very unlikely case. I've done many thousand randconfig builds now and have not seen it before. Of course, since the output of randconfig is random, it could indeed just be a coincidence. Anyways, the fix is fine with me. Thanks, Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Tue, 11 Oct 2011, Felipe Balbi wrote: It doesn't shown here, but the TLL link is completely optional. It's mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI and OHCI will depend on a clock provided by the USBTLL block. Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI blocks. We can, from a code perspective, make USBTLL into a parent of UHH to make things simpler, but this will mean that calling pm_runtime_get() will also unconditionaly turn on TLL clock, unless we add some nasty hacks to allow TLL know if *HCI port is in TLL mode. That's why I decided for making TLL and UHH siblings, because that's a closer relationship than parent-child. Can you see the problem now ? Okay, now I understand better. The word sibling implies that the two objects have the same parent, so a different word would describe this relationship better. Something like friend or associate. Or maybe, following Paul's suggestion, the driver core doesn't have to be changed at all. I see... I just thought that if there are other similar cases, it might make sense to have a more generic way to make those two devices talk to each other. But if you all agree that an EXPORT_SYMBOL_GPL() is enough, then it's ok ;-) At the moment, I can't see any way to set up a more generic mechanism that wouldn't be more complicated and have higher overhead than a simple EXPORT_SYMBOL_GPL. Can this be handled by adding another resource to a platform_device? That at least would make use of an already-existing mechanism. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi, On Tue, Oct 11, 2011 at 10:04:28AM -0400, Alan Stern wrote: On Tue, 11 Oct 2011, Felipe Balbi wrote: It doesn't shown here, but the TLL link is completely optional. It's mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI and OHCI will depend on a clock provided by the USBTLL block. Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI blocks. We can, from a code perspective, make USBTLL into a parent of UHH to make things simpler, but this will mean that calling pm_runtime_get() will also unconditionaly turn on TLL clock, unless we add some nasty hacks to allow TLL know if *HCI port is in TLL mode. That's why I decided for making TLL and UHH siblings, because that's a closer relationship than parent-child. Can you see the problem now ? Okay, now I understand better. The word sibling implies that the two objects have the same parent, so a different word would describe this relationship better. Something like friend or associate. Or maybe, following Paul's suggestion, the driver core doesn't have to be changed at all. I see... I just thought that if there are other similar cases, it might make sense to have a more generic way to make those two devices talk to each other. But if you all agree that an EXPORT_SYMBOL_GPL() is enough, then it's ok ;-) At the moment, I can't see any way to set up a more generic mechanism that wouldn't be more complicated and have higher overhead than a simple EXPORT_SYMBOL_GPL. Can this be handled by adding another resource to a platform_device? That at least would make use of an already-existing mechanism. maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that this IP comes from synopsys, and I'm not really keen on adding OMAP-specific, integration-related knowledge on a driver which was supposed to be reusable ;-) But at least for the time being, I guess that's what we need to do ;-) tks -- balbi signature.asc Description: Digital signature
RE: [PATCH 4/8] ti814evm: Add support for musb interface
Hi Igor, On 10/11/11 13:26, Ajay Kumar Gupta wrote: From: Ravi Babu ravib...@ti.com Adding musb support in ti814 EVM board file. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/board-ti8148evm.c |9 + This file does not exist and probably will not exist in the future, see [1] and [2]. So this patch can be dropped. Your 3/8 patch provides the support for both boards. Thanks for this. Felipe/Tony, Please drop this 4/8 patch. Ajay [1] - http://www.spinics.net/lists/linux-omap/msg58348.html [2] - http://www.spinics.net/lists/arm-kernel/msg143915.html -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
On Tue, Oct 11, 2011 at 7:49 AM, Ohad Ben-Cohen o...@wizery.com wrote:
int iommu_map(struct iommu_domain *domain, unsigned long iova,
- phys_addr_t paddr, int gfp_order, int prot)
+ phys_addr_t paddr, int size, int prot)
{
Even though it is not realistic that size becomes larger than 1
((sizeof(int) * 8) - 1),
I think the type of size should be size_t.
- size_t size;
+ unsigned long orig_iova = iova;
+ int ret = 0, orig_size = size;
if (unlikely(domain-ops-map == NULL))
return -ENODEV;
- size = PAGE_SIZE gfp_order;
+ /*
+ * both the virtual address and the physical one, as well as
+ * the size of the mapping, must be aligned (at least) to the
+ * size of the smallest page supported by the hardware
+ */
+ if (!IS_ALIGNED(iova | paddr | size, domain-ops-min_pagesz)) {
+ pr_err(unaligned: iova 0x%lx pa 0x%lx size 0x%x min_pagesz
+ 0x%x\n, iova, (unsigned long)paddr,
+ size, domain-ops-min_pagesz);
+ return -EINVAL;
+ }
+
+ pr_debug(map: iova 0x%lx pa 0x%lx size 0x%x\n, iova,
+ (unsigned long)paddr, size);
+
+ while (size) {
+ unsigned long pgsize, addr_merge = iova | paddr;
+ unsigned int pgsize_idx;
+
+ /* Max page size that still fits into 'size' */
+ pgsize_idx = __fls(size);
+
+ /* need to consider alignment requirements ? */
+ if (likely(addr_merge)) {
+ /* Max page size allowed by both iova and paddr */
+ unsigned int align_pgsize_idx = __ffs(addr_merge);
+
+ pgsize_idx = min(pgsize_idx, align_pgsize_idx);
+ }
+
+ /* build a mask of acceptable page sizes */
+ pgsize = (1UL (pgsize_idx + 1)) - 1;
+
+ /* throw away page sizes not supported by the hardware */
+ pgsize = domain-ops-pgsize_bitmap;
+
+ /* make sure we're still sane */
+ BUG_ON(!pgsize);
- BUG_ON(!IS_ALIGNED(iova | paddr, size));
+ /* pick the biggest page */
+ pgsize_idx = __fls(pgsize);
+ pgsize = 1UL pgsize_idx;
- return domain-ops-map(domain, iova, paddr, gfp_order, prot);
+ /* convert index to page order */
+ pgsize_idx -= PAGE_SHIFT;
+
+ pr_debug(mapping: iova 0x%lx pa 0x%lx order %u\n, iova,
+ (unsigned long)paddr, pgsize_idx);
+
+ ret = domain-ops-map(domain, iova, paddr, pgsize_idx, prot);
+ if (ret)
+ break;
+
+ iova += pgsize;
+ paddr += pgsize;
+ size -= pgsize;
+ }
+
+ /* unroll mapping in case something went wrong */
+ if (ret)
+ iommu_unmap(domain, orig_iova, orig_size);
+
domain-ops-map() might return error because a mapping already exists
in the range from iova until iova + size.
Thus, it should be
iommu_unmap(domain, orig_iova, orig_size - size)
Regards,
KyongHo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/8] ti816evm: Add support for musb interface
Hi,
On 10/11/11 13:26, Ajay Kumar Gupta wrote:
From: Ravi Babu ravib...@ti.com
Adding musb support in ti816 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
This patch can result in a merge conflict, therefore I think
this one should be taken through Tony's tree.
Also you should work together with Hemant Pedanekar and
someone of you should rebase on top of the other otherwise
one of the patches (yours or Hemant's) possibly will not apply.
Ok sure. I will submit the patches (v5) after creating it on top of
Hemant's and Vaibhav's patches.
Thanks,
Ajay
---
arch/arm/mach-omap2/board-ti8168evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c b/arch/arm/mach-
omap2/board-ti8168evm.c
index 2c243df..1f3d423 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti8168_evm_config[] __initdata
= {
};
@@ -33,6 +41,7 @@ static void __init ti8168_evm_init(void)
omap_sdrc_init(NULL, NULL);
omap_board_config = ti8168_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init ti8168_evm_map_io(void)
--
Regards,
Igor.
--
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 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
Santosh Shilimkar santosh.shilim...@ti.com writes: On Monday 10 October 2011 11:31 PM, Kevin Hilman wrote: Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: The series adds OMAP4 MPUSS (MPU SubSystem) power management support for suspend (S2R), CPU hotplug and CPUidle. There are a few more compile errors when doing OMAP1-only builds. You'll need a way to eliminate the secure calls for OMAP1. This series causes a couple build errors when doing OMAP1-only builds (I used omap1_defconfig): OK. Thanks for catching it. First: /work/kernel/omap/pm/arch/arm/plat-omap/common.c:24:30: fatal error: mach/omap-secure.h: No such file or directory And trying creating a dummy header to see if it would continue to build gives: /work/kernel/omap/pm/arch/arm/plat-omap/common.c: In function 'omap_reserve': /work/kernel/omap/pm/arch/arm/plat-omap/common.c:70:2: error: implicit declaration of function 'omap_secure_ram_reserve_memblock' make[2]: *** [arch/arm/plat-omap/common.o] Error 1 make[1]: *** [arch/arm/plat-omap] Error 2 For OMAP1 build, omap_secure_ram_reserve_memblock() definition is needed since common.c is built for OMAP1 as well. The trivial change in the end of this email fixes the omap1 build. Looks good. Have folded that change in original patch and updated the OMAP4 PM branch - for_3_2/omap4-mpuss-pm_2 Thanks. Regards Santosh P.S : Even with this fix, omap1_defconfig build breaks because of USB. I removed USB from build to check rest of the build and it was fine then. OK. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
On Tue, Oct 11, 2011 at 12:38 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
You need to make sure that you don;t pass larger regions then requested
to the low-level driver. Some logic like in the iommu_map function
should do it.
You're right. But the solution IMHO should be getting rid of that size
- order - size conversion which we do back and forth, as it's kinda
pointless.
Please use PAGE_SIZE instead of 0x1000UL.
This one would go away too if we remove the size - order - size
conversions. In fact, iommu_unmap() just becomes so much simpler when
we do that.
I'm attaching two patches: first one that removes the
size-order-size conversions we have, and then the usual pgsize patch
rebased to it.
Please take a look,
Thanks,
Ohad.
From 7102bda53a425872591f14f850ab031b1ca5dae1 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@wizery.com
Date: Tue, 11 Oct 2011 16:50:38 +0200
Subject: [PATCH 1/2] iommu/core: stop converting bytes to page order
back and forth
Express sizes in bytes rather than in page order, to eliminate the
size-order-size conversions we have whenever the IOMMU API is calling
the low level drivers' map/unmap methods.
Adopt all existing drivers.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/amd_iommu.c | 13 +
drivers/iommu/intel-iommu.c | 11 ---
drivers/iommu/iommu.c |8 +---
drivers/iommu/msm_iommu.c | 19 +++
drivers/iommu/omap-iommu.c | 14 +-
include/linux/iommu.h |6 +++---
6 files changed, 29 insertions(+), 42 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 764e3da..32d502e 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2702,9 +2702,8 @@ static int amd_iommu_attach_device(struct
iommu_domain *dom,
}
static int amd_iommu_map(struct iommu_domain *dom, unsigned long iova,
-phys_addr_t paddr, int gfp_order, int iommu_prot)
+phys_addr_t paddr, size_t page_size, int iommu_prot)
{
- unsigned long page_size = 0x1000UL gfp_order;
struct protection_domain *domain = dom-priv;
int prot = 0;
int ret;
@@ -2721,13 +2720,11 @@ static int amd_iommu_map(struct iommu_domain
*dom, unsigned long iova,
return ret;
}
-static int amd_iommu_unmap(struct iommu_domain *dom, unsigned long iova,
- int gfp_order)
+static size_t amd_iommu_unmap(struct iommu_domain *dom, unsigned long iova,
+ size_t page_size)
{
struct protection_domain *domain = dom-priv;
- unsigned long page_size, unmap_size;
-
- page_size = 0x1000UL gfp_order;
+ size_t unmap_size;
mutex_lock(domain-api_lock);
unmap_size = iommu_unmap_page(domain, iova, page_size);
@@ -2735,7 +2732,7 @@ static int amd_iommu_unmap(struct iommu_domain
*dom, unsigned long iova,
domain_flush_tlb_pde(domain);
- return get_order(unmap_size);
+ return unmap_size;
}
static phys_addr_t amd_iommu_iova_to_phys(struct iommu_domain *dom,
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 2d53c3d..96a9bd4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3821,12 +3821,11 @@ static void intel_iommu_detach_device(struct
iommu_domain *domain,
static int intel_iommu_map(struct iommu_domain *domain,
unsigned long iova, phys_addr_t hpa,
- int gfp_order, int iommu_prot)
+ size_t size, int iommu_prot)
{
struct dmar_domain *dmar_domain = domain-priv;
u64 max_addr;
int prot = 0;
- size_t size;
int ret;
if (iommu_prot IOMMU_READ)
@@ -3836,7 +3835,6 @@ static int intel_iommu_map(struct iommu_domain *domain,
if ((iommu_prot IOMMU_CACHE) dmar_domain-iommu_snooping)
prot |= DMA_PTE_SNP;
- size = PAGE_SIZE gfp_order;
max_addr = iova + size;
if (dmar_domain-max_addr max_addr) {
u64 end;
@@ -3859,11 +3857,10 @@ static int intel_iommu_map(struct iommu_domain *domain,
return ret;
}
-static int intel_iommu_unmap(struct iommu_domain *domain,
-unsigned long iova, int gfp_order)
+static size_t intel_iommu_unmap(struct iommu_domain *domain,
+unsigned long iova, size_t size)
{
struct dmar_domain *dmar_domain = domain-priv;
- size_t size = PAGE_SIZE gfp_order;
dma_pte_clear_range(dmar_domain, iova VTD_PAGE_SHIFT,
(iova + size - 1) VTD_PAGE_SHIFT);
@@ -3871,7 +3868,7 @@ static int intel_iommu_unmap(struct iommu_domain *domain,
if (dmar_domain-max_addr == iova + size)
dmar_domain-max_addr = iova;
- return gfp_order;
+ return size;
}
static phys_addr_t intel_iommu_iova_to_phys(struct iommu_domain *domain,
diff
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
Hi KyongHo, On Tue, Oct 11, 2011 at 4:59 PM, KyongHo Cho pullip@samsung.com wrote: I think the type of size should be size_t. .. Thus, it should be iommu_unmap(domain, orig_iova, orig_size - size) Agree with both suggestions, thanks ! P.S - please only keep the parts of my email which you are replying to, otherwise it's a bit hard to find your comments. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/8] ti816evm: Add support for musb interface
Hi,
Adding musb support in ti816 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
This patch can result in a merge conflict, therefore I think
this one should be taken through Tony's tree.
Also you should work together with Hemant Pedanekar and
someone of you should rebase on top of the other otherwise
one of the patches (yours or Hemant's) possibly will not apply.
Ok sure. I will submit the patches (v5) after creating it on top of
Hemant's and Vaibhav's patches.
Here is the v5 of this patch created against latest Hemant's patch set.
From 3006845992157acc4a2b44d0be119e22bb34d1f4 Mon Sep 17 00:00:00 2001
From: Ravi Babu ravib...@ti.com
Date: Wed, 17 Aug 2011 17:58:02 +0530
Subject: [PATCH 3/8 v5] ti816evm: Add support for musb interface
Adding musb support in ti816 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-ti8168evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index b858921..cab909f 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti81xx_evm_config[] __initdata = {
};
@@ -33,6 +41,7 @@ static void __init ti81xx_evm_init(void)
omap_sdrc_init(NULL, NULL);
omap_board_config = ti81xx_evm_config;
omap_board_config_size = ARRAY_SIZE(ti81xx_evm_config);
+ usb_musb_init(musb_board_data);
}
MACHINE_START(TI8168EVM, ti8168evm)
--
1.6.2.4
Thanks,
Ajay
---
arch/arm/mach-omap2/board-ti8168evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c b/arch/arm/mach-
omap2/board-ti8168evm.c
index 2c243df..1f3d423 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti8168_evm_config[]
__initdata
= {
};
@@ -33,6 +41,7 @@ static void __init ti8168_evm_init(void)
omap_sdrc_init(NULL, NULL);
omap_board_config = ti8168_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init ti8168_evm_map_io(void)
--
Regards,
Igor.
--
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
Re: [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
Koyamangalath, Abhilash abhilash...@ti.com writes: hi Kevin, Apologies for the delayed response, I was on vacation. On October 01, 2011 4:57 AM, Hilman, Kevin wrote: Abhilash, Kevin Hilman khil...@ti.com writes: Abhilash K V abhilash...@ti.com writes: From: Abhilash K V abhilash...@ti.com In case of AM3517 AM3505, SmartReflex is not applicable so we must not enable it. So omap3_twl_init() is now not called when the processor does not support SR. This still isn't right. The reason to skip the TWL PMIC init is not because SR is not available (TWL PMICs are quite usable without SR). The reason to skip TWL PMIC init is because the PMIC is not present. [Abhilash K V] yes, I understand now. Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are only registered if a TWL driver is registered. Below is a test patch that is a first pass at implementing what I suggested above. I tested this (along with your patch 3/3) on a 3430/n900 after removing the omap_pmic_init() call frome the board file. [Abhilash K V] I'll re-submit the patch with this change (i,e. if you've not already pulled it into your branch). I haven't posted/merged this yet, but I will now that you've tested it. Thanks. Can you let me know if this solves the problem you're seeing on platforms that don't have TWL PMICs? [Abhilash K V] It should, I have validated on am3517_evm Thanks, will add a Tested-by from you. After digging into this more, I'm increasingly aware that the way we're managing the init of PMIC stuff is a mess. Guess I need another round of voltage layer cleanups to fix that up. [Abhilash K V] True, and to add to this, the changes required to support only ONE voltage-domain for am35xx would be too many, I believe. I don't see that part to be an obstacle. Let's just be sure to use the clock, clockdomain, powerdomain voltagedomain data files to describe the hardware. That is the only scalable and maintainable way to support these devices. Any core code changes to fix assumption's we've made that are now wrong need to be raised and addressed. Stated differently, we know we have assumptions in the PM core code that may now be mistaken in light of these new AM3xxx devices. Rather than try to trick the core PM code into thinking these devices are normal OMAP3/4 devices, let's fix those assumptions so we can properly support the new devices. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 10/16] OMAP2+: UART: Modify omap_uart_can_sleep function
Govindraj.R govindraj.r...@ti.com writes:
Modify the omap_uart_can_sleep function to check uart is active
or not to be used by pm code to enter low power states.
Doesn't the driver now control when the UART clocks are gated (using
runtime PM autosuspend)?
IMO, this check should be completely removed and the driver should
be managing this with the autosuspend timeout.
Removing this check can cause console response little sluggish.
Sluggish in what way?
If the driver is runtime suspended, it should only be sluggish for the
first character. After that, the autosuspend timeout should prevent it
from feeling sluggish.
However no characters will be lost until uart clocks are gated
and woken up using rx-pad. UART interface clocks can be auto gated
this can make response on uart slower. This behaviour was observed
only on some of OMAP3 boards(beagleboard xm rev c).
Reported-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 6725caf..ccf3550 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -156,23 +156,20 @@ static void omap_uart_smart_idle_enable(struct
omap_uart_state *uart,
int omap_uart_can_sleep(void)
{
- struct omap_uart_state *uart;
- int can_sleep = 1;
-
- list_for_each_entry(uart, uart_list, node) {
- if (!uart-clocked)
- continue;
+ struct omap_hwmod *oh;
+ u8 i, ret = true;
- if (!uart-can_sleep) {
- can_sleep = 0;
+ for (i = 0; i num_uarts; i++) {
+ oh = omap_uart_hwmod_lookup(i);
This is a heavy operation to add for *every* entry into idle.
+ if (!oh)
continue;
- }
- /* This UART can now safely sleep. */
- omap_uart_allow_sleep(uart);
+ if (oh-od oh-od-pdev
+ !pm_runtime_suspended(oh-od-pdev-dev))
+ return false;
}
- return can_sleep;
+ return ret;
}
#ifdef CONFIG_OMAP_MUX
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi Felipe On Tue, 11 Oct 2011, Felipe Balbi wrote: maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that this IP comes from synopsys, and I'm not really keen on adding OMAP-specific, integration-related knowledge on a driver which was supposed to be reusable ;-) But at least for the time being, I guess that's what we need to do ;-) Which IP is coming from Synopsys - the TLL ? The EXPORT_SYMBOL approach shouldn't add anything OMAP-specific to the TLL driver. So the exported symbols should still be usable by drivers on other SoCs. But perhaps I am misunderstanding your point? - 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 v6 12/16] OMAP2+: UART: Allow UART parameters to be configured from board file.
Govindraj.R govindraj.r...@ti.com writes:
From: Deepak K deepa...@ti.com
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is received.
4). The auto suspend delay that will be passed for pm_runtime_autosuspend
where uart will be disabled after timeout
Different UARTs may be used for different purpose such as the console,
for interfacing bluetooth chip, for interfacing to a modem chip, etc.
Therefore, it is necessary to be able to customize the above settings
for a given board on a per UART basis.
This change allows these parameters to be configured from the board file
and allows the parameters to be configured for each UART independently.
If a board does not define its own custom parameters for the UARTs, then
use the default parameters in the structure omap_serial_default_info.
The default parameters are defined to be the same as the current settings
in the UART driver to avoid breaking the UART for any cuurnelty supported
boards. By default, make all boards use the default UART parameters.
Signed-off-by: Deepak K deepa...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
A couple minor comments below...
---
This patch is derived and reworked from a custom 2.6.35 kernel
Available here:
http://git.omapzoom.org/?p=kernel/omap.git;
a=commitdiff;h=584ef316542f77312be7ba96a0f3013c8f64852b;
hp=7233a76cb362c0fc603f773274159adff91d3513
arch/arm/mach-omap2/board-n8x0.c |6 +-
arch/arm/mach-omap2/serial.c | 56
arch/arm/plat-omap/include/plat/omap-serial.h |7 ++-
arch/arm/plat-omap/include/plat/serial.h |5 ++-
drivers/tty/serial/omap-serial.c |8 +--
5 files changed, 61 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c
b/arch/arm/mach-omap2/board-n8x0.c
index e11f0c5..3408726 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -656,15 +656,15 @@ static inline void board_serial_init(void)
bdata.pads_cnt = 0;
bdata.id = 0;
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
bdata.id = 1;
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
bdata.id = 2;
bdata.pads = serial2_pads;
bdata.pads_cnt = ARRAY_SIZE(serial2_pads);
- omap_serial_init_port(bdata);
+ omap_serial_init_port(bdata, NULL);
}
#else
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0731575..78f7051 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -43,17 +43,29 @@
#include mux.h
/*
- * NOTE: By default the serial timeout is disabled as it causes lost
characters
- * over the serial ports. This means that the UART clocks will stay on until
- * disabled via sysfs. This also causes that any deeper omap sleep states are
- * blocked.
+ * NOTE: By default the serial auto_suspend timeout is disabled as it causes
+ * lost characters over the serial ports. This means that the UART clocks
will
+ * stay on until power/autosuspend_delay is set for the uart from sysfs.
+ * This also causes that any deeper omap sleep states are blocked.
*/
-#define DEFAULT_TIMEOUT 0
+#define DEFAULT_AUTOSUSPEND_DELAY-1
#define MAX_UART_HWMOD_NAME_LEN 16
static u8 num_uarts;
+#define DEFAULT_RXDMA_TIMEOUT1 /* RX DMA polling rate
(us) */
+#define DEFAULT_RXDMA_BUFSIZE4096/* RX DMA buffer size */
+
+static struct omap_uart_port_info omap_serial_default_info[] = {
This could be __initdata
+ {
+ .dma_enabled= 0,
This field is a bool, use 'false' instead of 0.
+ .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
+ .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
+ .autosuspend_timeout = DEFAULT_AUTOSUSPEND_DELAY,
+ },
+};
+
static int uart_idle_hwmod(struct omap_device *od)
{
omap_hwmod_idle(od-hwmods[0]);
@@ -298,6 +310,7 @@ core_initcall(omap_serial_early_init);
/**
* omap_serial_init_port() - initialize single serial port
* @bdata: port specific board data pointer
+ * @info: platform specific data pointer
*
* This function initialies serial driver for given port only.
* Platforms can call this function instead of omap_serial_init()
@@ -306,7 +319,8 @@ core_initcall(omap_serial_early_init);
* Don't mix calls to omap_serial_init_port() and omap_serial_init(),
* use only one of the two.
*/
-void __init omap_serial_init_port(struct omap_board_data *bdata)
+void __init omap_serial_init_port(struct omap_board_data *bdata,
+ struct
Re: [PATCH v6 14/16] OMAP2+: UART: Take console_lock in suspend path if not taken
Govindraj.R govindraj.r...@ti.com writes: In suspend path the console_lock is taken by uart_port_suspend however when no_console_suspend is used console_lock is not taken. During system wide suspend omap_pwr_domain hooks cut all clocks that are left enabled. So its unsafe to proceed printing after clocks are cut by pwr_domain hooks. As I've mentioned in previous reviews, when no_console_suspend is enabled, the user has explicitly requested console output during suspend. In order to support that, we should not be cutting clocks at all in that mode. One way to address this would be to just disable runtime PM in the -prepare method of the driver if no_console_suspend is enabled. Also pm_runtime will be disabled after dpm_suspend devices happens. Not sure why this is relevant. So buffer all prints in suspend path by taking console_lock and print them back safely after power domain hooks re-enable clocks back. Use CONFIG_SERIAL_OMAP_CONSOLE macro check to take console_lock since console ops are available only if omap console is defined. omap-serial can be built as module without console support. Please revisit use of #ifdefs. (c.f. #ifdefs are ugly in Documentation/SubmittingPatches) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Tue, Oct 11, 2011 at 12:52:05PM -0600, Paul Walmsley wrote: Hi Felipe On Tue, 11 Oct 2011, Felipe Balbi wrote: maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that this IP comes from synopsys, and I'm not really keen on adding OMAP-specific, integration-related knowledge on a driver which was supposed to be reusable ;-) But at least for the time being, I guess that's what we need to do ;-) Which IP is coming from Synopsys - the TLL ? The EXPORT_SYMBOL approach TLL and UHH are OMAP-only wrappers. EHCI and OHCI are Synopsys IPs for all I know. shouldn't add anything OMAP-specific to the TLL driver. So the exported symbols should still be usable by drivers on other SoCs. But perhaps I am misunderstanding your point? A bit :-) EHCI/OHCI will need to ask TLL to enable TLL clock, because it's EHCI/OHCI who configure the port. Unless I misunderstood what Keshava did (and no, I didn't just read the code, too lazy :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi On Tue, 11 Oct 2011, Felipe Balbi wrote: On Tue, Oct 11, 2011 at 12:52:05PM -0600, Paul Walmsley wrote: On Tue, 11 Oct 2011, Felipe Balbi wrote: maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that this IP comes from synopsys, and I'm not really keen on adding OMAP-specific, integration-related knowledge on a driver which was supposed to be reusable ;-) But at least for the time being, I guess that's what we need to do ;-) Which IP is coming from Synopsys - the TLL ? The EXPORT_SYMBOL approach TLL and UHH are OMAP-only wrappers. EHCI and OHCI are Synopsys IPs for all I know. Ah, I see. shouldn't add anything OMAP-specific to the TLL driver. So the exported symbols should still be usable by drivers on other SoCs. But perhaps I am misunderstanding your point? A bit :-) EHCI/OHCI will need to ask TLL to enable TLL clock, because it's EHCI/OHCI who configure the port. Unless I misunderstood what Keshava did (and no, I didn't just read the code, too lazy :-) The calls to the TLL driver only need to go into the OMAP-specific ehci-omap.c and ohci-omap3.c wrappers, as far as I can see. So I don't think there's a need to modify the generic OHCI/EHCI drivers... - 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/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi, On Tue, Oct 11, 2011 at 01:17:03PM -0600, Paul Walmsley wrote: On Tue, 11 Oct 2011, Felipe Balbi wrote: maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that this IP comes from synopsys, and I'm not really keen on adding OMAP-specific, integration-related knowledge on a driver which was supposed to be reusable ;-) But at least for the time being, I guess that's what we need to do ;-) Which IP is coming from Synopsys - the TLL ? The EXPORT_SYMBOL approach TLL and UHH are OMAP-only wrappers. EHCI and OHCI are Synopsys IPs for all I know. Ah, I see. shouldn't add anything OMAP-specific to the TLL driver. So the exported symbols should still be usable by drivers on other SoCs. But perhaps I am misunderstanding your point? A bit :-) EHCI/OHCI will need to ask TLL to enable TLL clock, because it's EHCI/OHCI who configure the port. Unless I misunderstood what Keshava did (and no, I didn't just read the code, too lazy :-) The calls to the TLL driver only need to go into the OMAP-specific ehci-omap.c and ohci-omap3.c wrappers, as far as I can see. So I don't think there's a need to modify the generic OHCI/EHCI drivers... those where the ones I was talking about. That ehci-omap.c and ohci-omap3.c refer to Synopsys IPs, so (in theory at least) that same file can be used by any other SoC who uses a Synopsys IP. -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 11/16] OMAP2+: UART: Move errata handling from serial.c to omap-serial
Govindraj.R govindraj.r...@ti.com writes: Move the errata handling mechanism from serial.c to omap-serial file and utilise the same func in driver file. Errata i202, i291 are moved to be handled with omap-serial Moving the errata macro from serial.c file to driver header file as from on errata will be handled in driver file itself. Corrected errata id from chapter reference 2.15 to errata id i291. Acked-by: Alan Cox a...@linux.intel.com Signed-off-by: Govindraj.R govindraj.r...@ti.com The errata handling for i291 is moved from device code to driver code but it's functionality is also changed (but not described.) In the current mainline code, The workaround for i291 is done whenever UART clocks are about to be cut. When the clocks are (re)enabled, the device is put back into no-idle. This patch puts the device into force-idle just before the idle/suspend transistion, but never puts it back into no-idle. So after the first idle/suspend transition, the IP remains in force-idle forever. I don't think that's what we want. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 15/16] OMAP2+: UART: Enable back uart clocks with runtime API for early console
Govindraj.R govindraj.r...@ti.com writes: For the early console probing we had avoided hwmod reset and idling and uart was idled using hwmod API and enabled back using omap_device API after omap_device registration. Now since we are using runtime API's to enable back uart, move hwmod idling and use runtime API to enable back UART. Signed-off-by: Govindraj.R govindraj.r...@ti.com Now that the driver is using runtime PM. Why do we still need HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET? The comment in the code says: /* * During UART early init, device need to be probed * to determine SoC specific init before omap_device * is ready. Therefore, don't allow idle here */ This was true when using the 8250 driver because it was not using runtime PM so could not know how to (re)enable the device. However, since the driver is now runtime PM adapted, any device access should be contained within a runtime PM get/put block, so there should no longer be a reason not allow the IP blocks to be reset during boot. Kevin -- 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/7] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
On Fri, 07 Oct 2011 12:45:43 -0700
Tony Lindgren t...@atomide.com wrote:
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Acked-by: Andres Salomon dilin...@queued.net
Looks good to me, thanks for doing this. I only have one very minor
quibble below, which could be addressed in a later patch..
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/include/asm/io.h |1 +
arch/arm/mm/ioremap.c | 21 +
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d66605d..4ff152e 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -80,6 +80,7 @@ extern void __iomem *__arm_ioremap_caller(unsigned
long, size_t, unsigned int,
extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long,
size_t, unsigned int); extern void __iomem *__arm_ioremap(unsigned
long, size_t, unsigned int); +extern void __iomem
*__arm_ioremap_exec(unsigned long, size_t, int cached); extern void
__iounmap(volatile void __iomem *addr);
/*
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ab50627..a2d94ac 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -289,6 +289,27 @@ __arm_ioremap(unsigned long phys_addr, size_t
size, unsigned int mtype) }
EXPORT_SYMBOL(__arm_ioremap);
+/*
+ * Remap an arbitrary physical address space into the kernel virtual
+ * address space as memory. Needed when the kernel wants to execute
+ * code in external memory. This is needed for reprogramming source
+ * clocks that would affect normal memory for example. Please see
+ * CONFIG_GENERIC_ALLOCATOR for allocating external memory.
+ */
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
I'd rather see this as 'bool cached', so it's clear we're talking
about a simple boolean (rather than bits).
+{
+ unsigned int mtype;
+
+ if (cached)
+ mtype = MT_MEMORY;
+ else
+ mtype = MT_MEMORY_NONCACHED;
+
+ return __arm_ioremap_caller(phys_addr, size, mtype,
+ __builtin_return_address(0));
+}
+
void __iounmap(volatile void __iomem *io_addr)
{
void *addr = (void *)(PAGE_MASK (unsigned long)io_addr);
--
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
Re: [PATCH 1/7] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
* Andres Salomon dilin...@queued.net [111011 14:11]:
On Fri, 07 Oct 2011 12:45:43 -0700
Tony Lindgren t...@atomide.com wrote:
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Acked-by: Andres Salomon dilin...@queued.net
Looks good to me, thanks for doing this. I only have one very minor
quibble below, which could be addressed in a later patch..
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
I'd rather see this as 'bool cached', so it's clear we're talking
about a simple boolean (rather than bits).
Sure, thanks, updated version below. Will also update the patch in
Russell's patch system.
Tony
From: Tony Lindgren t...@atomide.com
Date: Wed, 5 Oct 2011 15:14:01 -0700
Subject: [PATCH] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Acked-by: Andres Salomon dilin...@queued.net
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -80,6 +80,7 @@ extern void __iomem *__arm_ioremap_caller(unsigned long, size_t, unsigned int,
extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long, size_t, unsigned int);
extern void __iomem *__arm_ioremap(unsigned long, size_t, unsigned int);
+extern void __iomem *__arm_ioremap_exec(unsigned long, size_t, bool cached);
extern void __iounmap(volatile void __iomem *addr);
/*
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -289,6 +289,27 @@ __arm_ioremap(unsigned long phys_addr, size_t size, unsigned int mtype)
}
EXPORT_SYMBOL(__arm_ioremap);
+/*
+ * Remap an arbitrary physical address space into the kernel virtual
+ * address space as memory. Needed when the kernel wants to execute
+ * code in external memory. This is needed for reprogramming source
+ * clocks that would affect normal memory for example. Please see
+ * CONFIG_GENERIC_ALLOCATOR for allocating external memory.
+ */
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, bool cached)
+{
+ unsigned int mtype;
+
+ if (cached)
+ mtype = MT_MEMORY;
+ else
+ mtype = MT_MEMORY_NONCACHED;
+
+ return __arm_ioremap_caller(phys_addr, size, mtype,
+ __builtin_return_address(0));
+}
+
void __iounmap(volatile void __iomem *io_addr)
{
void *addr = (void *)(PAGE_MASK (unsigned long)io_addr);
Re: [PATCH 7/8] OMAP3: update cpuidle latency and threshold figures
Hi,
On Thu, Sep 22, 2011 at 12:14 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
Update the data from the measurements performed at HW and SW levels.
Cf.
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers magically coming from.
ToDo:
- Measure the wake-up latencies for all power domains for OMAP3
- Correct some numbers when sys_clkreq and sys_offmode are supported
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 1b8e0da..4b3e994 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -44,20 +44,20 @@
* pass these details from the board file.
*/
static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 */
- {2 + 2, 5, 1},
- /* C2 */
- {10 + 10, 30, 1},
- /* C3 */
- {50 + 50, 300, 1},
- /* C4 */
- {1500 + 1800, 4000, 1},
- /* C5 */
- {2500 + 7500, 12000, 1},
- /* C6 */
- {3000 + 8500, 15000, 1},
- /* C7 */
- {1 + 3, 30, 1},
+ /* C1 . MPU WFI + Core active */
+ {73 + 78, 152, 1},
+ /* C2 . MPU WFI + Core inactive */
+ {165 + 88, 345, 1},
+ /* C3 . MPU CSWR + Core inactive */
+ {163 + 182, 345, 1},
+ /* C4 . MPU OFF + Core inactive */
+ {2852 + 605, 15, 1},
+ /* C5 . MPU RET + Core RET */
+ {800 + 366, 2120, 1},
C4 exit_latency is longer than C5's, not sure if it is correct?
+ /* C6 . MPU OFF + Core RET */
+ {4080 + 801, 215000, 1},
+ /* C7 . MPU OFF + Core OFF */
+ {4300 + 13000, 215000, 1},
};
#define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
--
1.7.4.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
thanks,
--
Ming Lei
--
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
