[PATCHv3 0/7] ARM: OMAP: core/hwmod: first set of fixes for 3.5-rc
Hi, Here is an initial set of fixes for power management and OMAP core infrastructure for 3.5-rc. Most of these patches address boot warnings and power management problems on OMAP4, although a few of them address more general issues. Thanks to (in alphabetical order) Benoît Cousson, Tero Kristo, Kevin Hilman, Vaibhav Hiremath, and Tony Lindgren for help with this series. Compile- and boot-test information is below. Note that on OMAP3, return from suspend when off-mode is enabled is via GPIO buttons due to: http://www.spinics.net/lists/arm-kernel/msg173688.html Boot logs are available from: http://www.pwsan.com/omap/bootlogs/20120617/omap_fixes_a_3.5rc__52a5ae406dadef781bfcf3a641dae2064e9697ff/ These patches are available via git from git://git.pwsan.com/linux-2.6 in the branch 'omap_fixes_a_3.5rc'. This third version adds a fix for a new sparse warning, and drops everything that is still being commented on or reviewed or which needs acks. Hopefully those will make it into a future 3.5-rc series. - Paul --- object size (delta in bytes from v3.5-rc3 (485802a6c524e62b5924849dd727ddbb1497cc71)): textdata bss total kernel 0 0 0 0 5912osk_testconfig/vmlinux +32 0 0 +32 n800_multi_omap2xxx/vmlinux +64 0 0 +64 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux +64 0 0 +64 omap2_4_testconfig/vmlinux +4160 0 0 +4160 omap2plus_defconfig/vmlinux 0 0 0 0 omap2plus_no_pm/vmlinux 0 0 0 0 omap3_4_testconfig/vmlinux 0 0 0 0 omap3_testconfig/vmlinux +64 0 0 +64 omap4_testconfig/vmlinux Djamil Elaidi (1): ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby Paul Walmsley (5): ARM: OMAP2+: hwmod code/data: fix 32K sync timer ARM: OMAP4: hwmod data: fix 32k sync timer idle modes ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks ARM: OMAP2+: CM: increase the module disable timeout ARM: OMAP2+: mux: fix sparse warning Todd Poynor (1): ARM: OMAP: PM: Lock clocks list while generating summary arch/arm/mach-omap2/clock44xx_data.c |5 + arch/arm/mach-omap2/cm.h | 11 ++ arch/arm/mach-omap2/cminst44xx.c |4 ++-- arch/arm/mach-omap2/mux.c|1 + arch/arm/mach-omap2/omap_hwmod.c | 28 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 +++--- arch/arm/plat-omap/clock.c |2 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h |9 9 files changed, 53 insertions(+), 15 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
[PATCHv3 4/7] ARM: OMAP4: hwmod data: fix 32k sync timer idle modes
The 32k sync timer IP block target idle modes in the hwmod data are
incorrect. The IP block does not support any smart-idle modes.
Update the data to reflect the correct modes.
This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson b-cous...@ti.com. A patch description
bug in the first version was also identified by Benoît.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 484..6b0aedc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -393,8 +393,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_counter_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0004,
.sysc_flags = SYSC_HAS_SIDLEMODE,
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
- SIDLE_SMART_WKUP),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO),
.sysc_fields= omap_hwmod_sysc_type1,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 7/7] ARM: OMAP2+: mux: fix sparse warning
Commit bbd707acee279a61177a604822db92e8164d00db (ARM: omap2: use machine specific hook for late init) resulted in the addition of this sparse warning: arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not declared. Should it be static? Fix by including the header file containing the prototype. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Shawn Guo shawn@linaro.org Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/mux.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index 80e55c5..d3ef99c 100644 --- a/arch/arm/mach-omap2/mux.c +++ b/arch/arm/mach-omap2/mux.c @@ -41,6 +41,7 @@ #include control.h #include mux.h #include prm.h +#include common.h #define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */ #define OMAP_MUX_BASE_SZ 0x5ca -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 6/7] ARM: OMAP2+: CM: increase the module disable timeout
Increase the timeout for disabling an IP block to five milliseconds. This is to handle the usb_host_fs idle latency, which takes almost four milliseconds after a host controller reset. This is the second of two patches needed to resolve the following boot warning: omap_hwmod: usb_host_fs: _wait_target_disable failed Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/cm.h | 11 +++ arch/arm/mach-omap2/cminst44xx.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 + 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index a7bc096..f24e3f7 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -22,4 +22,15 @@ */ #define MAX_MODULE_READY_TIME 2000 +/* + * MAX_MODULE_DISABLE_TIME: max duration in microseconds to wait for + * the PRCM to request that a module enter the inactive state in the + * case of OMAP2 3. In the case of OMAP4 this is the max duration + * in microseconds for the module to reach the inactive state from + * a functional state. + * XXX FSUSB on OMAP4430 takes ~4ms to idle after reset during + * kernel init. + */ +#define MAX_MODULE_DISABLE_TIME5000 + #endif diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c index 8c86d29..1a39945 100644 --- a/arch/arm/mach-omap2/cminst44xx.c +++ b/arch/arm/mach-omap2/cminst44xx.c @@ -313,9 +313,9 @@ int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_off omap_test_timeout((_clkctrl_idlest(part, inst, cdoffs, clkctrl_offs) == CLKCTRL_IDLEST_DISABLED), - MAX_MODULE_READY_TIME, i); + MAX_MODULE_DISABLE_TIME, i); - return (i MAX_MODULE_READY_TIME) ? 0 : -EBUSY; + return (i MAX_MODULE_DISABLE_TIME) ? 0 : -EBUSY; } /** diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 6b0aedc..a428305 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -30,6 +30,7 @@ #include plat/mmc.h #include plat/dmtimer.h #include plat/common.h +#include plat/usb.h #include omap_hwmod_common_data.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
[PATCHv3 1/7] ARM: OMAP: PM: Lock clocks list while generating summary
From: Todd Poynor toddpoy...@google.com Commit a53025724052b2b1edbc982a4a248784638f563d (OMAP: Add debugfs node to show the summary of all clocks) introduced clock summary, however, we are interested in seeing snapshot of the clock state, not in dynamically changing clock configurations as the data provided by clock summary will then be useless for debugging configuration issues. So, hold the common lock when dumping the clock summary. Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Todd Poynor toddpoy...@google.com [n...@ti.com: added commit message] Signed-off-by: Nishanth Menon n...@ti.com [p...@pwsan.com: minor edits to commit message] Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/plat-omap/clock.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index 62ec5c4..706b7e2 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c @@ -461,6 +461,7 @@ static int clk_dbg_show_summary(struct seq_file *s, void *unused) struct clk *c; struct clk *pa; + mutex_lock(clocks_mutex); seq_printf(s, %-30s %-30s %-10s %s\n, clock-name, parent-name, rate, use-count); @@ -469,6 +470,7 @@ static int clk_dbg_show_summary(struct seq_file *s, void *unused) seq_printf(s, %-30s %-30s %-10lu %d\n, c-name, pa ? pa-name : none, c-rate, c-usecount); } + mutex_unlock(clocks_mutex); return 0; } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 3/7] ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby
From: Djamil Elaidi d-ela...@ti.com If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup. Signed-off-by: Djamil Elaidi d-ela...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_hwmod.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index e174c2a..a6da0b3 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -530,7 +530,7 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v) if (oh-class-sysc-idlemodes SIDLE_SMART_WKUP) _set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART, v); if (oh-class-sysc-idlemodes MSTANDBY_SMART_WKUP) - _set_master_standbymode(oh, HWMOD_IDLEMODE_SMART_WKUP, v); + _set_master_standbymode(oh, HWMOD_IDLEMODE_SMART, v); /* XXX test pwrdm_get_wken for this hwmod's subsystem */ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 5/7] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it. This
patch populates some clock structure clockdomain names to resolve the
following warnings during kernel init:
omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..e2b701e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -84,6 +84,7 @@ static struct clk slimbus_clk = {
static struct clk sys_32k_ck = {
.name = sys_32k_ck,
+ .clkdm_name = prm_clkdm,
.rate = 32768,
.ops= clkops_null,
};
@@ -512,6 +513,7 @@ static struct clk ddrphy_ck = {
.name = ddrphy_ck,
.parent = dpll_core_m2_ck,
.ops= clkops_null,
+ .clkdm_name = l3_emif_clkdm,
.fixed_div = 2,
.recalc = omap_fixed_divisor_recalc,
};
@@ -769,6 +771,7 @@ static const struct clksel dpll_mpu_m2_div[] = {
static struct clk dpll_mpu_m2_ck = {
.name = dpll_mpu_m2_ck,
.parent = dpll_mpu_ck,
+ .clkdm_name = cm_clkdm,
.clksel = dpll_mpu_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_MPU,
.clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
@@ -1149,6 +1152,7 @@ static const struct clksel l3_div_div[] = {
static struct clk l3_div_ck = {
.name = l3_div_ck,
.parent = div_core_ck,
+ .clkdm_name = cm_clkdm,
.clksel = l3_div_div,
.clksel_reg = OMAP4430_CM_CLKSEL_CORE,
.clksel_mask= OMAP4430_CLKSEL_L3_MASK,
@@ -2824,6 +2828,7 @@ static const struct clksel trace_clk_div_div[] = {
static struct clk trace_clk_div_ck = {
.name = trace_clk_div_ck,
.parent = pmd_trace_clk_mux_ck,
+ .clkdm_name = emu_sys_clkdm,
.clksel = trace_clk_div_div,
.clksel_reg = OMAP4430_CM_EMU_DEBUGSS_CLKCTRL,
.clksel_mask= OMAP4430_CLKSEL_PMD_TRACE_CLK_MASK,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/7] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c (ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database) broke CORE idle on OMAP3. This prevents device low power states. The root cause is that the 32K sync timer IP block does not support smart-idle mode[1], and so the hwmod code keeps the IP block in no-idle mode while it is active. This in turn prevents the WKUP clockdomain from transitioning to idle. There is a hardcoded sleep dependency that prevents the CORE_L3 and CORE_CM clockdomains from transitioning to idle when the WKUP clockdomain is active[2], so the chip cannot enter any device low power states. It turns out that there is no need to take the 32k sync timer out of idle. The IP block itself probably does not have any native idle handling at all, due to its simplicity. Furthermore, the PRCM will never request target idle for this IP block while the kernel is running, due to the sleep dependency that prevents the WKUP clockdomain from idling while the CORE_L3 clockdomain is active. So we can safely leave the 32k sync timer in target-force-idle mode, even while we continue to access it. This workaround is implemented by defining a new hwmod flag, HWMOD_ALWAYS_FORCE_SIDLE, that places the IP block into target force-idle mode even when enabled. The 32k sync timer hwmods are marked with this flag for OMAP3 and OMAP4 SoCs. (On OMAP2xxx, no OCP header existed on the 32k sync timer.) Another theoretically clean fix for this problem would be to implement PM runtime-based control for 32k sync timer accesses. These PM runtime calls would need to located in a custom clocksource, since the 32k sync timer is currently used as an MMIO clocksource. But in practice, there would be little benefit to doing so; and there would be some cost, due to the addition of unnecessary lines of code and the additional CPU overhead of the PM runtime and hwmod code - unnecessary in this case. Another possible fix would have been to modify the pm34xx.c code to force the IP block idle before entering WFI. But this would not have been an acceptable approach: we are trying to remove this type of centralized IP block idle control from the PM code. This patch is effectively a workaround for a hardware problem. A better hardware approach would have been to implement a smart-idle target idle mode for this IP block. The smart-idle mode in this case would behave identically to the force-idle mode. We consider the force-idle and no-idle target idle mode settings to be intended for debugging and automatic idle management bug workarounds only[4]. This patch is a collaboration between Kevin Hilman khil...@ti.com and Paul Walmsley p...@pwsan.com. Thanks to Vaibhav Hiremath hvaib...@ti.com for providing comments on an earlier version of this patch. Thanks to Tero Kristo t-kri...@ti.com for identifying a bug in an earlier version of this patch. Thanks to Benoît Cousson b-cous...@ti.com for identifying some bugs in an earlier version of this patch and for implementation comments. References: 1. Table 16-96 REG_32KSYNCNT_SYSCONFIG of the OMAP34xx TRM Rev. ZU (SWPU223U), available from: http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip 2. Table 4-72 Sleep Dependencies of the OMAP34xx TRM Rev. ZU (SWPU223U) 3. ibid. 4. Section 3.1.1.1.2 Module-Level Clock Management of the OMAP4430 TRM Rev. vAA (SWPU231AA). Cc: Tony Lindgren t...@atomide.com Cc: Vaibhav Hiremath hvaib...@ti.com Cc: Benoît Cousson b-cous...@ti.com Cc: Tero Kristo t-kri...@ti.com Tested-by: Kevin Hilman khil...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_hwmod.c | 26 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |9 + 4 files changed, 29 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index bf86f7e..e174c2a 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1124,10 +1124,12 @@ static struct omap_hwmod_addr_space * __init _find_mpu_rt_addr_space(struct omap * _enable_sysc - try to bring a module out of idle via OCP_SYSCONFIG * @oh: struct omap_hwmod * * - * If module is marked as SWSUP_SIDLE, force the module out of slave - * idle; otherwise, configure it for smart-idle. If module is marked - * as SWSUP_MSUSPEND, force the module out of master standby; - * otherwise, configure it for smart-standby. No return value. + * Ensure that the OCP_SYSCONFIG register for the IP block represented + * by @oh is set to indicate to the PRCM that the IP block is active. + * Usually this means placing the module into smart-idle mode and + * smart-standby, but if there is a bug in the automatic idle handling + * for the IP block, it may need to be placed into the
Re: [CFT 07/11] spi: omap2-mcspi: add DMA engine support
On Thursday 14 June 2012 06:20 PM, Russell King - ARM Linux wrote: because, at the time when omap2_mcspi_setup() is called, spi-dev is not bound, and so is outside of the devres valid lifetime of that struct device. Agree, Apologies for breaking in the initial commit. -- To unsubscribe from this list: send the line unsubscribe 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: MFD USB host: prevents CORE retention in idle
On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. 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] OMAPDSS: HDMI: Discard phy_tx_enabled member
On Sat, 2012-06-16 at 03:31 +0530, jaswinder.si...@linaro.org wrote: From: Jassi Brar jaswinder.si...@linaro.org Explicitly maintaining HDMI phy power state using a flag is prone to race and un-necessary when we have a zero-cost alternative of checking the state before trying to set it. Why would reading the value from the register be any less racy than keeping it in memory? And reading from memory is probably much faster than reading from an HDMI register, so I'm not sure what you mean with zero-cost. But I guess it is simpler, so in that sense the patch is ok. But please revise the description. Tomi signature.asc Description: This is a digitally signed message part
RE: Current state of AM33xx patches
On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote: From: Daniel Mack zon...@gmail.com Hey, can anybody give me a quick wrap-up about the current state of AM33xx based SoCs in mainline? What are the next steps to get things merged? There is a wiki page [1] that is intended to provide a summary, but I'm confident it is not up-to-date. Page updated now... http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.
On Fri, Jun 15, 2012 at 12:36 AM, Sarashetti, Mantesh mant...@ti.com wrote:
'Acked-by: mant...@ti.com'
'Tested-by: mant...@ti.com'
Regards,
Mantesh
-Original Message-
From: Russ Dill [mailto:russ.d...@gmail.com] On Behalf Of Dill, Russ
Sent: Thursday, June 14, 2012 11:24 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: Balbi, Felipe; Munegowda, Keshava; Partha Basak; Igor Grinberg; Samuel
Ortiz; Sarashetti, Mantesh; Setty, Sapna; Russ Dill
Subject: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.
From: Russ Dill russ.d...@gmail.com
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
an issue where the ULPI PHYs were not held in reset while initializing
the EHCI controller. However, it also changes behavior in
omap-usb-host.c omap_usbhs_init by releasing reset while the
configuration in that function was done.
This change caused a regression on BB-xM where USB would not function
if 'usb start' had been run from u-boot before booting. A change was
made to release reset a little bit earlier which fixed the issue on
BB-xM and did not cause any regressions on 3430 sdp, the board for
which the fix was originally made.
This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle
before adding hcd.', (3aa2ae74) caused a regression on OMAP5.
The original fix to hold the EHCI controller in reset during
initialization was correct, however it appears that changing
omap_usbhs_init to not hold the PHYs in reset during it's
configuration was incorrect. This patch first reverts both fixes, and
then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in
reset as the original patch had done. It also is sure to incorporate
the _cansleep change that has been made in the meantime.
I've tested this on Beagleboard xM, I'd really like to get an ack from
the 3430 sdp and OMAP5 guys before getting this merged.
v3 - Brown paper bag its too early in the morning actually run
git commit amend fix
v2 - Put cansleep gpiolib call outside of spinlock
Signed-off-by: Russ Dill russ.d...@gmail.com
---
drivers/mfd/omap-usb-host.c | 48
+-
drivers/usb/host/ehci-omap.c | 18 +++-
2 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..41088ec 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -25,6 +25,7 @@
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/spinlock.h
+#include linux/gpio.h
#include plat/cpu.h
#include plat/usb.h
#include linux/pm_runtime.h
@@ -500,8 +501,21 @@ static void omap_usbhs_init(struct device *dev)
dev_dbg(dev, starting TI HSUSB Controller\n);
pm_runtime_get_sync(dev);
- spin_lock_irqsave(omap-lock, flags);
+ if (pdata-ehci_data-phy_reset) {
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
+ gpio_request_one(pdata-ehci_data-reset_gpio_port[0],
+ GPIOF_OUT_INIT_LOW, USB1 PHY
reset);
+
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
+ gpio_request_one(pdata-ehci_data-reset_gpio_port[1],
+ GPIOF_OUT_INIT_LOW, USB2 PHY
reset);
+
+ /* Hold the PHY in RESET for enough time till DIR is high */
+ udelay(10);
+ }
+
+ spin_lock_irqsave(omap-lock, flags);
omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
dev_dbg(dev, OMAP UHH_REVISION 0x%x\n, omap-usbhs_rev);
@@ -581,9 +595,39 @@ static void omap_usbhs_init(struct device *dev)
}
spin_unlock_irqrestore(omap-lock, flags);
+
+ if (pdata-ehci_data-phy_reset) {
+ /* Hold the PHY in RESET for enough time till
+ * PHY is settled and ready
+ */
+ udelay(10);
+
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
+ gpio_set_value_cansleep
+ (pdata-ehci_data-reset_gpio_port[0], 1);
+
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
+ gpio_set_value_cansleep
+ (pdata-ehci_data-reset_gpio_port[1], 1);
+ }
+
pm_runtime_put_sync(dev);
}
+static void omap_usbhs_deinit(struct device *dev)
+{
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ struct usbhs_omap_platform_data *pdata = omap-platdata;
+
+ if (pdata-ehci_data-phy_reset) {
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
+ gpio_free(pdata-ehci_data-reset_gpio_port[0]);
+
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
+
Bringing back gptimer_wakeup
The support for using a timer to wake from suspend was removed in: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864 I found an alternative patch (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47836.html) that claimed to keep it working using GPTIMER1 instead, but I haven't been able to make it work (likely because the timer code has changed a good deal since the patch was posted). Anyone got a) a patch that enables this feature on newer kernels, or b) an idea how the patch above can be made to work? Regards, Tasslehoff -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] omap: add ocp2scp as a misc driver
Hi Kevin, On Tue, Jun 12, 2012 at 10:37 PM, Kevin Hilman khil...@ti.com wrote: ABRAHAM, KISHON VIJAY kis...@ti.com writes: Hi Kevin, Benoit, Paul, On Fri, Jun 1, 2012 at 2:16 AM, Arnd Bergmann a...@arndb.de wrote: On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote: I would mark the multiplexed device compatible with simple-bus, which results in the child devices automatically getting added. hmm.. ocp2scp has a sysconfig register and it also has a module mode by which it can be enabled/disabled. I was making use of pm_runtime API's to control these registers (Apart from creating child devices, the driver also has a call to pm_runtime_enable). I see. I'm not sure if with simple-bus we'll be able to do those. I have to check on that. How about making it compatible with both simple-bus and something that handles the pm_runtime requirements? I don't understand enough of what needs to be done for pm_runtime across a lot of devices, but I'd hope that it should be possible to do that in a generic way based on the device definition. Is there already exists a generic way for handling pm_runtime requirements (as simple as doing a pm_runtime_enable on a device). As you've discovered, the runtime PM core handles the parent/child relationships already. So the actual problem is we have ocp2scp as parent and usb2phy and usb3phy as the child device. ocp2scp has the sysconfig register and it can be controlled using module mode bit (both of this can be controlled by pm_runtime). Whenever usb controller(dwc3/musb) wants to enable a phy, it calls an exported API in usb2/usb3 phy to enable it. These API's have pm_runtime_get_sync on usb2/usb3 device which in-turn calls pm_runtime_get_sync of ocp2scp because of parent-child relationship (For this both usb2/usb3 phy and ocp2scp devices should have called pm_runtime_enable). All I'm trying is to find a place to have pm_runtime_enable for ocp2scp. Maybe I'm not following, but why can't it be in the driver? Arnd feels it is pointless to have a driver that only does creation of child (and pm_runtime_enable of the device). He feels it would be better to have a generic way to do a runtime_enable of a device with dt. (Just like how there is a generic way to create child devices by giving .compatible as simple-bus). Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 5/7] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
Hi Paul,
On 6/18/2012 8:16 AM, Paul Walmsley wrote:
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it. This
patch populates some clock structure clockdomain names to resolve the
following warnings during kernel init:
omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..e2b701e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -84,6 +84,7 @@ static struct clk slimbus_clk = {
static struct clk sys_32k_ck = {
.name = sys_32k_ck,
+ .clkdm_name = prm_clkdm,
I guess that patch need to be revisited based on discussion we had and the
patch you proposed in [1].
Assuming Tony is OK, it should be probably part of the -rc, because this domain
should not have been introduced in 3.5-rc1 at all for OMAP4.
So it will be better to revert the patch that introduced that first before
adding any new fix that will rely on a code that will disappear.
In fact, I think the proper way to fix that while maintaining the OMAP23 way
of dealing with clkdm is to ensure that at least one clkdm is there in either
hwmod or the main_clk.
That will fix these issues and the one that will append when the fake main_clk
will be removed.
Here is a patch that is doing that.
Thanks,
Benoit
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70177.html
---
From e5ffe6533236125c3c0b5eff883bfc1cf3cbe9f4 Mon Sep 17 00:00:00 2001
From: Benoit Cousson b-cous...@ti.com
Date: Fri, 15 Jun 2012 11:26:49 +0200
Subject: [PATCH] ARM: OMAP2+: hwmod: Do not check clkdm for main_clk if oh does
have one
When a clkdm is handled directly at the hwmod level, there is no need to handle
it with the main_clk as well. It is thus useless to complain about the missing
clkdm for the main_clk in that case.
Warn only if the clkdm is missing in both main_clk and hwmod.
Init hwmod clkdm first to ensure it will be there when the main_clk
will be initialized.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 162f9c7..f33f4e2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -609,7 +609,7 @@ static int _init_main_clk(struct omap_hwmod *oh)
return -EINVAL;
}
- if (!oh-_clk-clkdm)
+ if (!oh-_clk-clkdm !oh-clkdm)
pr_warning(omap_hwmod: %s: missing clockdomain for %s.\n,
oh-main_clk, oh-_clk-name);
@@ -1339,10 +1339,10 @@ static int _init_clocks(struct omap_hwmod *oh, void
*data)
pr_debug(omap_hwmod: %s: looking up clocks\n, oh-name);
+ ret |= _init_clkdm(oh);
ret |= _init_main_clk(oh);
ret |= _init_interface_clks(oh);
ret |= _init_opt_clks(oh);
- ret |= _init_clkdm(oh);
if (!ret)
oh-_state = _HWMOD_STATE_CLKS_INITED;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4
The commit 503d0ea24d1d3dd3db95e5e0edd693da7a2a23eb
ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks
added a wrong prcm_clk alias for PRCM clock whereas the McBSP
driver and previous OMAPs are using prcm_fck.
It thus lead to the following warning.
[ 47.409729] omap-mcbsp: clks: could not clk_get() prcm_fck
Fix that by changing the opt_clk role to prcm_fck.
Reported-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..1527541 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1924,7 +1924,7 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp1_sdma_reqs[] = {
static struct omap_hwmod_opt_clk mcbsp1_opt_clks[] = {
{ .role = pad_fck, .clk = pad_clks_ck },
- { .role = prcm_clk, .clk = mcbsp1_sync_mux_ck },
+ { .role = prcm_fck, .clk = mcbsp1_sync_mux_ck },
};
static struct omap_hwmod omap44xx_mcbsp1_hwmod = {
@@ -1959,7 +1959,7 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp2_sdma_reqs[] = {
static struct omap_hwmod_opt_clk mcbsp2_opt_clks[] = {
{ .role = pad_fck, .clk = pad_clks_ck },
- { .role = prcm_clk, .clk = mcbsp2_sync_mux_ck },
+ { .role = prcm_fck, .clk = mcbsp2_sync_mux_ck },
};
static struct omap_hwmod omap44xx_mcbsp2_hwmod = {
@@ -1994,7 +1994,7 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp3_sdma_reqs[] = {
static struct omap_hwmod_opt_clk mcbsp3_opt_clks[] = {
{ .role = pad_fck, .clk = pad_clks_ck },
- { .role = prcm_clk, .clk = mcbsp3_sync_mux_ck },
+ { .role = prcm_fck, .clk = mcbsp3_sync_mux_ck },
};
static struct omap_hwmod omap44xx_mcbsp3_hwmod = {
@@ -2029,7 +2029,7 @@ static struct omap_hwmod_dma_info
omap44xx_mcbsp4_sdma_reqs[] = {
static struct omap_hwmod_opt_clk mcbsp4_opt_clks[] = {
{ .role = pad_fck, .clk = pad_clks_ck },
- { .role = prcm_clk, .clk = mcbsp4_sync_mux_ck },
+ { .role = prcm_fck, .clk = mcbsp4_sync_mux_ck },
};
static struct omap_hwmod omap44xx_mcbsp4_hwmod = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bringing back gptimer_wakeup
On Mon, Jun 18, 2012 at 2:48 PM, Tasslehoff Kjappfot
tasskj...@gmail.com wrote:
The support for using a timer to wake from suspend was removed in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864
I found an alternative patch
(http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47836.html) that
claimed to keep it working using GPTIMER1 instead, but I haven't been able
to make it work (likely because the timer code has changed a good deal since
the patch was posted).
Anyone got
a) a patch that enables this feature on newer kernels, or
b) an idea how the patch above can be made to work?
I had one working against 3.4. may be you can try this out and see it helps.
Regards
Santosh
---
arch/arm/mach-omap2/pm-debug.c |5 +
arch/arm/mach-omap2/timer.c| 12
2 files changed, 17 insertions(+)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..8f59a70 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -39,6 +39,7 @@
#include pm.h
u32 enable_off_mode;
+u32 wakeup_timer_seconds = 0;
#ifdef CONFIG_DEBUG_FS
#include linux/debugfs.h
@@ -276,6 +277,10 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file(enable_off_mode, S_IRUGO | S_IWUSR, d,
enable_off_mode, pm_dbg_option_fops);
+
+ (void) debugfs_create_file(wakeup_timer_seconds, S_IRUGO | S_IWUSR, d,
+ wakeup_timer_seconds, pm_dbg_option_fops);
+
pm_dbg_init_done = 1;
return 0;
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b28ea5e..31a0628 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -82,6 +82,9 @@
#define MAX_GPTIMER_ID 12
static u32 sys_timer_reserved;
+#ifdef CONFIG_PM_DEBUG
+extern u32 wakeup_timer_seconds;
+#endif
/* Clockevent code */
@@ -138,6 +141,15 @@ static void omap2_gp_timer_set_mode(enum
clock_event_mode mode,
break;
case CLOCK_EVT_MODE_UNUSED:
case CLOCK_EVT_MODE_SHUTDOWN:
+#ifdef CONFIG_PM_DEBUG
+ if (wakeup_timer_seconds) {
+ __omap_dm_timer_write(clkev, OMAP_TIMER_LOAD_REG,
+ 0x - (clkev.rate * wakeup_timer_seconds), 1);
+ __omap_dm_timer_load_start(clkev, OMAP_TIMER_CTRL_ST,
+ 0x - (clkev.rate * wakeup_timer_seconds), 1);
+ }
+#endif
+ break;
case CLOCK_EVT_MODE_RESUME:
break;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP7XX: Remove omap730.h and omap850.h
No file includes omap730.h or omap850.h. That's not surprising, as commit e6684f7132c6e6333e96407b06910bebaa4c1935 (OMAP7XX: Create omap7xx.h) created a header that was intended to replace omap730.h and omap850.h, while all values defined [in omap7xx.h] are identical to those in both the old files. So it seems it was just an oversight to keep both the old files after commit 7a8f48f8c611ac8c07023260258e2fec312b9242 (OMAP7XX: omap_uwire.c: Convert to omap7xx.h) converted the last file still including one of those two old files. Convert the last reference to omap730.h to a reference to omap7xx.h too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) Tested only by using various git commands on the (history of the) tree. 1) A related cleanup could be to remove cpu_is_omap730 and cpu_is_omap850, as both macros seem unused. arch/arm/plat-omap/include/plat/mux.h |2 +- arch/arm/plat-omap/include/plat/omap730.h | 102 - arch/arm/plat-omap/include/plat/omap850.h | 102 - 3 files changed, 1 insertions(+), 205 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/omap730.h delete mode 100644 arch/arm/plat-omap/include/plat/omap850.h diff --git a/arch/arm/plat-omap/include/plat/mux.h b/arch/arm/plat-omap/include/plat/mux.h index aeba717..3239489 100644 --- a/arch/arm/plat-omap/include/plat/mux.h +++ b/arch/arm/plat-omap/include/plat/mux.h @@ -99,7 +99,7 @@ /* * OMAP730/850 has a slightly different config for the pin mux. - * - config regs are the OMAP7XX_IO_CONF_x regs (see omap730.h) regs and + * - config regs are the OMAP7XX_IO_CONF_x regs (see omap7xx.h) regs and * not the FUNC_MUX_CTRL_x regs from hardware.h * - for pull-up/down, only has one enable bit which is is in the same register * as mux config diff --git a/arch/arm/plat-omap/include/plat/omap730.h b/arch/arm/plat-omap/include/plat/omap730.h deleted file mode 100644 index 14272bc..000 --- a/arch/arm/plat-omap/include/plat/omap730.h +++ /dev/null @@ -1,102 +0,0 @@ -/* arch/arm/plat-omap/include/mach/omap730.h - * - * Hardware definitions for TI OMAP730 processor. - * - * Cleanup for Linux-2.6 by Dirk Behme dirk.be...@de.bosch.com - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN - * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#ifndef __ASM_ARCH_OMAP730_H -#define __ASM_ARCH_OMAP730_H - -/* - * - * Base addresses - * - */ - -/* Syntax: XX_BASE = Virtual base address, XX_START = Physical base address */ - -#define OMAP730_DSP_BASE 0xE000 -#define OMAP730_DSP_SIZE 0x5 -#define OMAP730_DSP_START 0xE000 - -#define OMAP730_DSPREG_BASE0xE100 -#define OMAP730_DSPREG_SIZESZ_128K -#define OMAP730_DSPREG_START 0xE100 - -/* - * - * OMAP730 specific configuration registers - * - */ -#define OMAP730_CONFIG_BASE0xfffe1000 -#define OMAP730_IO_CONF_0 0xfffe1070 -#define OMAP730_IO_CONF_1 0xfffe1074 -#define OMAP730_IO_CONF_2 0xfffe1078 -#define OMAP730_IO_CONF_3 0xfffe107c -#define OMAP730_IO_CONF_4 0xfffe1080 -#define OMAP730_IO_CONF_5 0xfffe1084 -#define OMAP730_IO_CONF_6 0xfffe1088 -#define OMAP730_IO_CONF_7 0xfffe108c -#define OMAP730_IO_CONF_8 0xfffe1090 -#define OMAP730_IO_CONF_9 0xfffe1094 -#define OMAP730_IO_CONF_10 0xfffe1098 -#define OMAP730_IO_CONF_11 0xfffe109c -#define OMAP730_IO_CONF_12 0xfffe10a0 -#define OMAP730_IO_CONF_13 0xfffe10a4 - -#define OMAP730_MODE_1 0xfffe1010 -#define OMAP730_MODE_2 0xfffe1014 - -/* CSMI specials: in terms of
Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
On 18 June 2012 13:41, Tomi Valkeinen tomi.valkei...@ti.com wrote: Explicitly maintaining HDMI phy power state using a flag is prone to race and un-necessary when we have a zero-cost alternative of checking the state before trying to set it. Why would reading the value from the register be any less racy than keeping it in memory? Racy in the sense that h/w doesn't always hop states according to what a state variable would expect it to. Also in this case, phy_tx_enabled modification is unprotected in ti_hdmi_4xxx_phy_disable(). BTW, coming to think about it, I am not sure what we need the spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It can't control HPD gpio state change and hdmi_set_phy_pwr() seems too expensive and is already unprotected elsewhere. And reading from memory is probably much faster than reading from an HDMI register, so I'm not sure what you mean with zero-cost. Zero-cost in terms of space and bother :) But I guess it is simpler, so in that sense the patch is ok. But please revise the description. OK, will do. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.5-rc3: vdd_mpu_iva warnings
I have a GUMSTIX Overo AirSTORM module (AM3703-based). When booting the kernel the following features are listed: OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk ) After booting I get the following (repeating every few seconds): [ 81.122558] voltdm_scale: No voltage scale API registered for vdd_mpu_iva [ 81.130340] platform mpu.0: omap_target: unable to scale voltage up. I have SmartReflex enabled, and the same defconfig used to work on 3.4. CONFIG_OMAP_SMARTREFLEX=y CONFIG_OMAP_SMARTREFLEX_CLASS3=y I'm assuming this is because of changes to twl-common.c to add the IVA voltage domain, but on the OMAP I have there is no IVA - hence the warnings? Is there a known fix for this (disabling SmartReflex seems to make no difference)? Cheers, Joe Woodward -- To unsubscribe from this list: send the line unsubscribe 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] OMAPDSS: HDMI: Discard phy_tx_enabled member
On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote: On 18 June 2012 13:41, Tomi Valkeinen tomi.valkei...@ti.com wrote: Explicitly maintaining HDMI phy power state using a flag is prone to race and un-necessary when we have a zero-cost alternative of checking the state before trying to set it. Why would reading the value from the register be any less racy than keeping it in memory? Racy in the sense that h/w doesn't always hop states according to what a state variable would expect it to. But I don't think the status register is any better. If I'm not mistaken, when you set the phy pwr to, say, TXON, the status register will still show the old value. The status register will be right only after the HW is actually at TXON state. In this case the hdmi_set_phy_pwr() function will anyway wait until the HW has changed states, so both approaches should work just fine. Also in this case, phy_tx_enabled modification is unprotected in ti_hdmi_4xxx_phy_disable(). So is hdmi_set_phy_pwr(). Note that I'm not saying the current approach is not racy, but your patch doesn't make it any less racy. BTW, coming to think about it, I am not sure what we need the spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It can't control HPD gpio state change and hdmi_set_phy_pwr() seems too expensive and is already unprotected elsewhere. It's needed when enabling the hdmi output. In phy_enable() the irq is requested first, and then the phy_enable() runs hdmi_check_hpd_state(). So there's a chance to run hdmi_check_hpd_state() from both hpd-interrupt and phy_enable() at the same time. The hdmi_set_phy_pwr() is not called in many places, but I think there's indeed a problem there. It is called after free_irq(), but I think (guess) the irq handler could still be running after free_irq. So those should be protected by the same spinlock too. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
On Monday 18 June 2012 09:57 AM, Paul Walmsley wrote: On Thu, 14 Jun 2012, Rajendra Nayak wrote: OMAP3 has suspend broken in mainline, so I tested it on an older kernel (3.4-rc4 using my RFC series) Idle and OFF mode however seem to be broken for a long time, I wasn;t able to get it working even on 3.4 major. See my logs '3630 Beagle-Xm broken idle/off on 3.4' if I am doing anything wrong. I have CPUidle enabled in the kernel config. http://www.spinics.net/lists/arm-kernel/msg173688.html Thanks Paul. I re-tested my branch [1] after applying the 32K sync timer fix [2] and using timer based wakeup [3] instead of UART. Both retention and off work fine on my 3630 Beagle-Xm on my CCF conversion branch. Updated logs can be found here http://pastebin.com/u/rnayak regards, Rajendra [1] git://github.com/rrnayak/linux.git clk-next-omap-3.5-rc2 [2] http://marc.info/?l=linux-omapm=13453229888w=2 [3] http://marc.info/?l=linux-omapm=134001387702336w=2 - 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
[RFC PATCH v2 00/11] OMAP System Control Module
Hello. This is a next version of series of patches(based on Eduardo Valentin's patch set) adding a basic support for system control module, on OMAP4+ context. It is a working in progress. Main changes since previous patch set version: - Bandgap and usb phy: drivers are now independent from control module driver, they use their own API functions. Dependency was removed from Kconfig. - omap-control-core: driver is basically the same as arch/arm/mach-omap2/control.c, but resources aren't hardcoded, they are specified in dts file. - omap-control-core: Control module is a built-in driver - added control module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4. Probably, no configuration option is required! - omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows omap-control-core.c API to be called very early, for example from omap_type() - omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control module device. - Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers. - Bandgap: Check the type of bandgap dynamically in bandgap driver probe function by reading omap core control module revision register CONTROL_GEN_CORE_REVISION. TODO list for bandgap driver: - Currently, bandgap and usb phy are children of control module, but, in fact, the drivers are independent, so probably they should be independent entries in dts as well. - Reserve omap-control-core IOMEM window. - Improve thermal zone definition for OMAP4 - Introduce the thermal zones for OMAP5 Overall series has been tested only with panda board OMAP4430, so bandgap and usb phy drivers weren't tested at all. --- Documentation/devicetree/bindings/mfd/omap_control.txt | 44 Documentation/devicetree/bindings/thermal/omap_bandgap.txt | 27 arch/arm/boot/dts/omap4.dtsi | 17 arch/arm/mach-omap2/Kconfig |1 arch/arm/mach-omap2/am35xx-emac.c|2 arch/arm/mach-omap2/board-3430sdp.c |2 arch/arm/mach-omap2/board-4430sdp.c |2 arch/arm/mach-omap2/board-am3517crane.c |2 arch/arm/mach-omap2/board-am3517evm.c|2 arch/arm/mach-omap2/board-apollon.c |2 arch/arm/mach-omap2/board-cm-t3517.c |2 arch/arm/mach-omap2/board-h4.c |2 arch/arm/mach-omap2/board-igep0020.c |2 arch/arm/mach-omap2/board-ldp.c |2 arch/arm/mach-omap2/board-omap3logic.c |2 arch/arm/mach-omap2/board-omap4panda.c |2 arch/arm/mach-omap2/clock2420_data.c |2 arch/arm/mach-omap2/clock2430_data.c |2 arch/arm/mach-omap2/clock3xxx_data.c |2 arch/arm/mach-omap2/clock44xx_data.c |2 arch/arm/mach-omap2/common.c |2 arch/arm/mach-omap2/control.c|2 arch/arm/mach-omap2/control.h| 416 -- arch/arm/mach-omap2/cpuidle34xx.c|2 arch/arm/mach-omap2/devices.c|2 arch/arm/mach-omap2/display.c|2 arch/arm/mach-omap2/hsmmc.c |2 arch/arm/mach-omap2/id.c |7 arch/arm/mach-omap2/include/mach/control.h | 567 +++ arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h | 391 -- arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h | 1409 - arch/arm/mach-omap2/include/mach/ctrl_module_pad_wkup_44xx.h | 236 - arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h | 92 arch/arm/mach-omap2/mcbsp.c |2 arch/arm/mach-omap2/mux.c|2 arch/arm/mach-omap2/omap_phy_internal.c |2 arch/arm/mach-omap2/opp3xxx_data.c |2 arch/arm/mach-omap2/opp4xxx_data.c |2 arch/arm/mach-omap2/pm24xx.c |2 arch/arm/mach-omap2/pm34xx.c |2 arch/arm/mach-omap2/prcm.c |2 arch/arm/mach-omap2/serial.c |2 arch/arm/mach-omap2/sleep34xx.S |2 arch/arm/mach-omap2/sr_device.c |2 arch/arm/mach-omap2/usb-fs.c |2 arch/arm/mach-omap2/voltage.c|2
[RFC PATCH v2 02/11] ARM: OMAP: expose control.h to mach area
This patch exposes the definitions under control.h to
drivers outside the machine code.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/mach-omap2/am35xx-emac.c|2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/board-am3517crane.c |2 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap3logic.c |2 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-omap4pcm049.c |2 +-
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/clock44xx_data.c |2 +-
arch/arm/mach-omap2/common.c |2 +-
arch/arm/mach-omap2/control.c|2 +-
arch/arm/mach-omap2/cpuidle34xx.c|2 +-
arch/arm/mach-omap2/devices.c|2 +-
arch/arm/mach-omap2/display.c|2 +-
arch/arm/mach-omap2/hsmmc.c |2 +-
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/{ = include/mach}/control.h |2 +-
arch/arm/mach-omap2/mcbsp.c |2 +-
arch/arm/mach-omap2/mux.c|2 +-
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
arch/arm/mach-omap2/opp3xxx_data.c |2 +-
arch/arm/mach-omap2/opp4xxx_data.c |2 +-
arch/arm/mach-omap2/pm24xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 +-
arch/arm/mach-omap2/prcm.c |2 +-
arch/arm/mach-omap2/serial.c |2 +-
arch/arm/mach-omap2/sleep34xx.S |2 +-
arch/arm/mach-omap2/sr_device.c |2 +-
arch/arm/mach-omap2/usb-fs.c |2 +-
arch/arm/mach-omap2/voltage.c|2 +-
38 files changed, 38 insertions(+), 38 deletions(-)
rename arch/arm/mach-omap2/{ = include/mach}/control.h (99%)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 447682c..c3da28a 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -21,7 +21,7 @@
#include plat/irqs.h
#include mach/am35xx.h
-#include control.h
+#include mach/control.h
static struct mdio_platform_data am35xx_emac_mdio_pdata;
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 37abb0d..ad1132b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -46,7 +46,7 @@
#include sdram-qimonda-hyb18m512160af-6.h
#include hsmmc.h
#include pm.h
-#include control.h
+#include mach/control.h
#include common-board-devices.h
#define CONFIG_DISABLE_HFCLK 1
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 94af6cd..8f7f76b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -47,7 +47,7 @@
#include mux.h
#include hsmmc.h
-#include control.h
+#include mach/control.h
#include common-board-devices.h
#define ETH_KS8851_IRQ 34
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 3b8a53c..2ad514d 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -32,7 +32,7 @@
#include am35xx-emac.h
#include mux.h
-#include control.h
+#include mach/control.h
#define GPIO_USB_POWER 35
#define GPIO_USB_NRESET38
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 99790eb..bef6586 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -41,7 +41,7 @@
#include am35xx-emac.h
#include mux.h
-#include control.h
+#include mach/control.h
#include hsmmc.h
#define LCD_PANEL_PWR 176
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index 768ece2..bd04fe2 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -44,7 +44,7 @@
#include video/omap-panel-generic-dpi.h
#include mux.h
-#include control.h
+#include mach/control.h
/* LED Switch macros */
#define LED0_GPIO1313
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 9e66e16..1d2b7a3 100644
---
[RFC PATCH v2 03/11] mfd: omap: control: core system control driver
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device. It is
composed of two control submodules: general control
module and device (padconfiguration) control
module.
Changes since previous version:
- omap-control-core: driver is basically the same as
arch/arm/mach-omap2/control.c, but resources aren't hardcoded, they are
specified in dts file.
- omap-control-core: Control module is a built-in driver - added control module
select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4.
Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module IOMEM
window, this allows
omap-control-core.c API to be called very early, for example from omap_type()
- omap-control-core: Removed device pointer from omap-control-core API
arguments, becuase there can be only one instance control
module device.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/devicetree/bindings/mfd/omap_control.txt | 44 +
arch/arm/mach-omap2/Kconfig|1
arch/arm/plat-omap/Kconfig |4
drivers/mfd/Kconfig|9 +
drivers/mfd/Makefile |1
drivers/mfd/omap-control-core.c| 141 +
include/linux/mfd/omap_control.h | 70
7 files changed, 270 insertions(+)
Index: linux-2.6/Documentation/devicetree/bindings/mfd/omap_control.txt
===
--- /dev/null
+++ linux-2.6/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -0,0 +1,44 @@
+* Texas Instrument OMAP System Control Module (SCM) bindings
+
+The control module allows software control of various static modes supported by
+the device. The control module controls the settings of various device modules
+through register configuration and internal signals. It also controls the pad
+configuration, pin functional multiplexing, and the routing of internal signals
+(such as PRCM signals or DMA requests) to output pins configured for hardware
+observability.
+
+Required properties:
+- compatible : Should be:
+ - ti,omap3-control for OMAP3 support
+ - ti,omap4-control for OMAP4 support
+ - ti,omap5-control for OMAP5 support
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the control module:
+ Should be ctrl_module_core;
+
+Sub-nodes:
+- bandgap : contains the bandgap node
+
+ The bindings details of individual bandgap device can be found in:
+ Documentation/devicetree/bindings/thermal/omap_bandgap.txt
+
+- usb : contains the usb phy pin control node
+
+ The only required property for this child is:
+- compatible = ti,omap4-control-usb;
+
+Examples:
+
+ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = ti,omap4-control;
+ ti,hwmods = ctrl_module_core;
+ bandgap {
+ compatible = ti,omap4460-bandgap;
+ interrupts = 0 126 4; /* talert */
+ ti,tshut-gpio = 86; /* tshut */
+ };
+ usb {
+ compatible = ti,omap4-usb-phy;
+ };
+};
Index: linux-2.6/arch/arm/mach-omap2/Kconfig
===
--- linux-2.6.orig/arch/arm/mach-omap2/Kconfig
+++ linux-2.6/arch/arm/mach-omap2/Kconfig
@@ -52,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+ select ARCH_HAS_CONTROL_MODULE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
Index: linux-2.6/arch/arm/plat-omap/Kconfig
===
--- linux-2.6.orig/arch/arm/plat-omap/Kconfig
+++ linux-2.6/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,10 @@ menu TI OMAP Common Features
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+ bool
+ select MFD_OMAP_CONTROL
+
choice
prompt OMAP System Type
default ARCH_OMAP2PLUS
Index: linux-2.6/drivers/mfd/Kconfig
===
--- linux-2.6.orig/drivers/mfd/Kconfig
+++ linux-2.6/drivers/mfd/Kconfig
@@ -822,6 +822,15 @@ config MFD_WL1273_CORE
driver connects the radio-wl1273 V4L2 module and the wl1273
audio codec.
+config MFD_OMAP_CONTROL
+ bool Texas Instruments OMAP System control module
+ depends on ARCH_HAS_CONTROL_MODULE
+ help
+ This is the core driver for system control module. This driver
+ is responsible for creating the control module mfd child,
+ like USB-pin control, pin
[RFC PATCH v2 05/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
Changes since previous version:
- Bandgap and usb phy: drivers are now independent from control module driver,
they use their own API functions.
Dependency was removed from Kconfig.
- Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers.
(p.s. the mailbox for musb in omap4 is present in system control
module)
[kis...@ti.com: wrote the original API's related to USB functions]
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/usb/otg/Kconfig | 12 ++
drivers/usb/otg/Makefile |1
drivers/usb/otg/omap4-usb-phy.c | 167 ++
include/linux/usb/omap4_usb_phy.h | 53
4 files changed, 233 insertions(+)
Index: linux-2.6/drivers/usb/otg/Kconfig
===
--- linux-2.6.orig/drivers/usb/otg/Kconfig
+++ linux-2.6/drivers/usb/otg/Kconfig
@@ -78,6 +78,18 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP4_USB_PHY
+ tristate Texas Instruments OMAP4+ USB pin control driver
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4+ USB pin control driver. The register set is part of system
+ control module.
+
+ USB phy in OMAP configures control module register for powering on
+ the phy, configuring VBUSVALID, AVALID, IDDIG and SESSEND. For
+ performing the above mentioned configuration, API's are added in
+ by this children of the control module driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
Index: linux-2.6/drivers/usb/otg/Makefile
===
--- linux-2.6.orig/drivers/usb/otg/Makefile
+++ linux-2.6/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP4_USB_PHY)+= omap4-usb-phy.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
Index: linux-2.6/drivers/usb/otg/omap4-usb-phy.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/otg/omap4-usb-phy.c
@@ -0,0 +1,167 @@
+/*
+ * OMAP4 system control module driver, USB control children
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Contact:
+ *Kishon Vijay Abraham I kis...@ti.com
+ *Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This program 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/gpio.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/usb/omap4_usb_phy.h
+
+void __iomem *omap_usb_phy_base;
+spinlock_t omap_usb_phy_lock;
+
+static int omap_usb_phy_readl(u32 reg, u32 *val)
+{
+ if (!omap_usb_phy_base)
+ return -EINVAL;
+
+ *val = __raw_readl(omap_usb_phy_base + reg);
+ return 0;
+}
+
+/*
+ * TODO: Get rid from omap_usb_phy_writel() return value -
+ * It's useless.
+ */
+static int omap_usb_phy_writel(u32 val, u32 reg)
+{
+ unsigned long flags;
+
+ if (!omap_usb_phy_base)
+ return -EINVAL;
+
+ spin_lock_irqsave(omap_usb_phy_lock, flags);
+ __raw_writel(val, omap_usb_phy_base + reg);
+ spin_unlock_irqrestore(omap_usb_phy_lock, flags);
+ return 0;
+}
+
+/**
+ * omap4_usb_phy_power - power on/off the phy using control module reg
+ * @dev: struct device *
+ * @on: 0 or 1, based on powering on or off the PHY
+ *
+ * omap_usb2 can call this API to power on or off the PHY.
+ */
+int omap4_usb_phy_power(struct device *dev, int on)
+{
+ u32 val;
+ int ret;
+
+ if (on) {
+
[RFC PATCH v2 06/11] ARM: OMAP4+: Adding the temperature sensor register set bit fields
OMAP4460 specific temperature sensor register bit fields are added. Existing OMAP4 entries are renamed to OMAP4430. Signed-off-by: Keerthy j-keer...@ti.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/mach-omap2/include/mach/control.h | 116 1 files changed, 116 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/control.h b/arch/arm/mach-omap2/include/mach/control.h index cf42764..171b504 100644 --- a/arch/arm/mach-omap2/include/mach/control.h +++ b/arch/arm/mach-omap2/include/mach/control.h @@ -230,6 +230,122 @@ /* OMAP44xx control McBSP padconf */ #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP 0x061c +/* TEMP_SENSOR OMAP4430 */ +#define OMAP4430_BGAP_TEMPSOFF_SHIFT 12 +#define OMAP4430_BGAP_TEMPSOFF_MASK(1 12) +#define OMAP4430_BGAP_TSHUT_SHIFT 11 +#define OMAP4430_BGAP_TSHUT_MASK (1 11) +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_MASK(1 10) +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_SHIFT9 +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK (1 9) +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 8) +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff 0) + +/* TEMP_SENSOR OMAP4460 */ +#define OMAP4460_BGAP_TEMPSOFF_SHIFT 13 +#define OMAP4460_BGAP_TEMPSOFF_MASK(1 13) +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_SHIFT11 +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK (1 11) +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK(1 10) +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) + +/* BANDGAP_CTRL */ +#define OMAP4460_SINGLE_MODE_SHIFT 31 +#define OMAP4460_SINGLE_MODE_MASK (1 31) +#define OMAP4460_MASK_HOT_SHIFT1 +#define OMAP4460_MASK_HOT_MASK (1 1) +#define OMAP4460_MASK_COLD_SHIFT 0 +#define OMAP4460_MASK_COLD_MASK(1 0) + +/* BANDGAP_COUNTER */ +#define OMAP4460_COUNTER_SHIFT 0 +#define OMAP4460_COUNTER_MASK (0xff 0) + +/* BANDGAP_THRESHOLD */ +#define OMAP4460_T_HOT_SHIFT 16 +#define OMAP4460_T_HOT_MASK(0x3ff 16) +#define OMAP4460_T_COLD_SHIFT 0 +#define OMAP4460_T_COLD_MASK (0x3ff 0) + +/* TSHUT_THRESHOLD */ +#define OMAP4460_TSHUT_HOT_SHIFT 16 +#define OMAP4460_TSHUT_HOT_MASK(0x3ff 16) +#define OMAP4460_TSHUT_COLD_SHIFT 0 +#define OMAP4460_TSHUT_COLD_MASK (0x3ff 0) + +/* BANDGAP_STATUS */ +#define OMAP4460_CLEAN_STOP_SHIFT 3 +#define OMAP4460_CLEAN_STOP_MASK (1 3) +#define OMAP4460_BGAP_ALERT_SHIFT 2 +#define OMAP4460_BGAP_ALERT_MASK (1 2) +#define OMAP4460_HOT_FLAG_SHIFT1 +#define OMAP4460_HOT_FLAG_MASK (1 1) +#define OMAP4460_COLD_FLAG_SHIFT 0 +#define OMAP4460_COLD_FLAG_MASK(1 0) + +/* TEMP_SENSOR OMAP5430 */ +#define OMAP5430_BGAP_TEMP_SENSOR_SOC_SHIFT12 +#define OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK (1 12) +#define OMAP5430_BGAP_TEMPSOFF_SHIFT 11 +#define OMAP5430_BGAP_TEMPSOFF_MASK(1 11) +#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 10) +#define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) + +/* BANDGAP_CTRL */ +#define OMAP5430_MASK_HOT_CORE_SHIFT 5 +#define OMAP5430_MASK_HOT_CORE_MASK(1 5) +#define OMAP5430_MASK_COLD_CORE_SHIFT 4 +#define OMAP5430_MASK_COLD_CORE_MASK (1 4) +#define OMAP5430_MASK_HOT_MM_SHIFT 3 +#define OMAP5430_MASK_HOT_MM_MASK (1 3) +#define OMAP5430_MASK_COLD_MM_SHIFT2 +#define OMAP5430_MASK_COLD_MM_MASK (1 2) +#define OMAP5430_MASK_HOT_MPU_SHIFT1 +#define OMAP5430_MASK_HOT_MPU_MASK (1 1) +#define OMAP5430_MASK_COLD_MPU_SHIFT 0 +#define OMAP5430_MASK_COLD_MPU_MASK(1 0) + +/* BANDGAP_COUNTER */ +#define
[RFC PATCH v2 04/11] OMAP2+: use control module mfd driver in omap_type
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/mach-omap2/id.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/arm/mach-omap2/id.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/id.c
+++ linux-2.6/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/mfd/omap_control.h
#include asm/cputype.h
@@ -38,6 +39,8 @@ unsigned int omap_rev(void)
}
EXPORT_SYMBOL(omap_rev);
+u32 omap_control_readl(u16 offset);
+
int omap_type(void)
{
u32 val = 0;
@@ -49,7 +52,7 @@ int omap_type(void)
} else if (cpu_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
- val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ val = omap_control_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
} else {
pr_err(Cannot detect omap type!\n);
goto out;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 07/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor
In the System Control Module, OMAP supplies a voltage reference
and a temperature sensor feature that are gathered in the band
gap voltage and temperature sensor (VBGAPTS) module. The band
gap provides current and voltage reference for its internal
circuits and other analog IP blocks. The analog-to-digital
converter (ADC) produces an output value that is proportional
to the silicon temperature.
This patch provides a platform driver which expose this feature.
It is moduled as a MFD child of the System Control Module core
MFD driver.
This driver provides only APIs to access the device properties,
like temperature, thresholds and update rate.
Changes since previous version:
- Bandgap and usb phy: drivers are now independent from control module driver,
they use their own API functions.
- Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers.
- Bandgap: Check the type of bandgap dynamically in bandgap driver probe
function by reading
omap core control module revision register CONTROL_GEN_CORE_REVISION.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/thermal/omap_bandgap.txt | 27
drivers/thermal/Kconfig| 12
drivers/thermal/Makefile |4
drivers/thermal/omap-bandgap.c | 1654 +
drivers/thermal/omap-bandgap.h | 64
5 files changed, 1760 insertions(+), 1 deletion(-)
Index: linux-2.6/Documentation/devicetree/bindings/thermal/omap_bandgap.txt
===
--- /dev/null
+++ linux-2.6/Documentation/devicetree/bindings/thermal/omap_bandgap.txt
@@ -0,0 +1,27 @@
+* Texas Instrument OMAP SCM bandgap bindings
+
+In the System Control Module, OMAP supplies a voltage reference
+and a temperature sensor feature that are gathered in the band
+gap voltage and temperature sensor (VBGAPTS) module. The band
+gap provides current and voltage reference for its internal
+circuits and other analog IP blocks. The analog-to-digital
+converter (ADC) produces an output value that is proportional
+to the silicon temperature.
+
+Required properties:
+- compatible : Should be:
+ - ti,omap4460-control-bandgap : for OMAP4460 bandgap
+ - ti,omap5430-control-bandgap : for OMAP5430 bandgap
+- interrupts : this entry should indicate which interrupt line
+the talert signal is routed to;
+Specific:
+- ti,tshut-gpio : this entry should be used to inform which GPIO
+line the tshut signal is routed to;
+
+Example:
+
+bandgap {
+ compatible = ti,omap4460-control-bandgap;
+ interrupts = 0 126 4; /* talert */
+ ti,tshut-gpio = 86;
+};
Index: linux-2.6/drivers/thermal/Kconfig
===
--- linux-2.6.orig/drivers/thermal/Kconfig
+++ linux-2.6/drivers/thermal/Kconfig
@@ -26,3 +26,15 @@ config SPEAR_THERMAL
help
Enable this to plug the SPEAr thermal sensor driver into the Linux
thermal framework
+
+config OMAP_BANDGAP
+ tristate Texas Instruments OMAP4+ temperature sensor driver
+ depends on THERMAL
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4460+ on die bandgap temperature sensor support. The register
+ set is part of system control module.
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
+
Index: linux-2.6/drivers/thermal/Makefile
===
--- linux-2.6.orig/drivers/thermal/Makefile
+++ linux-2.6/drivers/thermal/Makefile
@@ -3,4 +3,6 @@
#
obj-$(CONFIG_THERMAL) += thermal_sys.o
-obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
\ No newline at end of file
+obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
+omap-thermal-y := omap-bandgap.o
Index: linux-2.6/drivers/thermal/omap-bandgap.c
===
--- /dev/null
+++ linux-2.6/drivers/thermal/omap-bandgap.c
@@ -0,0 +1,1654 @@
+/*
+ * OMAP4 Bandgap temperature sensor driver
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@ti.com
+ * Author: Moiz Sonasath m-sonas...@ti.com
+ * Couple of fixes, DT and MFD adaptation:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This program 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[RFC PATCH v2 08/11] omap4: thermal: add basic CPU thermal zone
This patch exposes OMAP4 thermal sensor as a thermal zone
named cpu. Only thermal creation is done here.
TODO:
- Add cooling bindings
- Add extrapolation rules
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/Kconfig | 12 ++
drivers/thermal/Makefile|1
drivers/thermal/omap-bandgap.c |1
drivers/thermal/omap-bandgap.h | 12 ++
drivers/thermal/omap4-thermal.c | 72
5 files changed, 98 insertions(+)
Index: linux-2.6/drivers/thermal/Kconfig
===
--- linux-2.6.orig/drivers/thermal/Kconfig
+++ linux-2.6/drivers/thermal/Kconfig
@@ -38,3 +38,15 @@ config OMAP_BANDGAP
This includes alert interrupts generation and also the TSHUT
support.
+config OMAP4_THERMAL
+ bool Texas Instruments OMAP4 thermal support
+ depends on OMAP_BANDGAP
+ depends on ARCH_OMAP4
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP4 SoC family. The current chip supported are:
+ - OMAP4460
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
+
Index: linux-2.6/drivers/thermal/Makefile
===
--- linux-2.6.orig/drivers/thermal/Makefile
+++ linux-2.6/drivers/thermal/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
+omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
Index: linux-2.6/drivers/thermal/omap-bandgap.c
===
--- linux-2.6.orig/drivers/thermal/omap-bandgap.c
+++ linux-2.6/drivers/thermal/omap-bandgap.c
@@ -1213,6 +1213,7 @@ static const struct omap_bandgap_data om
.fclock_name = bandgap_ts_fclk,
.div_ck_name = div_ts_ck,
.conv_table = omap4460_adc_to_temp,
+ .expose_sensor = omap4_thermal_expose_sensor,
.irq = 126,
.sensors = {
{
Index: linux-2.6/drivers/thermal/omap-bandgap.h
===
--- linux-2.6.orig/drivers/thermal/omap-bandgap.h
+++ linux-2.6/drivers/thermal/omap-bandgap.h
@@ -61,4 +61,16 @@ int omap_bandgap_write_update_interval(s
int omap_bandgap_read_temperature(struct omap_bandgap *bg_ptr, int id,
int *temperature);
+#ifdef CONFIG_OMAP4_THERMAL
+int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain);
+#else
+static inline int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr,
+ int id, char *domain)
+{
+ return 0;
+}
+
+#endif
+
#endif
Index: linux-2.6/drivers/thermal/omap4-thermal.c
===
--- /dev/null
+++ linux-2.6/drivers/thermal/omap4-thermal.c
@@ -0,0 +1,72 @@
+/*
+ * SPEAr thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+
+#include omap-bandgap.h
+
+struct omap4_thermal_data {
+ struct thermal_zone_device *omap4_thermal;
+ struct omap_bandgap *bg_ptr;
+ int sensor_id;
+};
+
+static inline int omap4_thermal_get_temp(struct thermal_zone_device *thermal,
+unsigned long *temp)
+{
+ struct omap4_thermal_data *data = thermal-devdata;
+ int ret, tmp;
+
+ ret = omap_bandgap_read_temperature(data-bg_ptr, data-sensor_id,
+ tmp);
+ if (!ret)
+ *temp = tmp;
+
+ return ret;
+}
+
+static struct thermal_zone_device_ops omap4_thermal_ops = {
+ .get_temp = omap4_thermal_get_temp,
+};
+
+int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain)
+{
+ struct omap4_thermal_data *data;
+
+ data = devm_kzalloc(bg_ptr-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(bg_ptr-dev, kzalloc fail\n);
+ return -ENOMEM;
+ }
+
[RFC PATCH v2 09/11] ARM: DT: Add support to system control module for OMAP4
This patch adds device tree entries on OMAP4 based boards
for System Control Module (SCM).
TODO:
The IOMEM windows of ctrl_module_core, bandgap, usbphy overlap, so
probably only specific registers should be specified in dts for
bandgap and usb phy entries.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 17 +
1 file changed, 17 insertions(+)
Index: linux-2.6/arch/arm/boot/dts/omap4.dtsi
===
--- linux-2.6.orig/arch/arm/boot/dts/omap4.dtsi
+++ linux-2.6/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,22 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = ti,omap4-control;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ctrl_module_core;
+ reg = 0x4a002000 0x1000;
+ bandgap@4a002000 {
+ compatible = ti,omap4-bandgap;
+ reg = 0x4a002000 0x1000;
+ };
+ usb@4a002000 {
+ compatible = ti,omap4-usb-phy;
+ reg = 0x4a002000 0x1000;
+ };
+ };
};
};
--
To unsubscribe from this list: send the line unsubscribe 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] OMAPDSS: HDMI: Discard phy_tx_enabled member
On 18 June 2012 16:24, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote: BTW, coming to think about it, I am not sure what we need the spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It can't control HPD gpio state change and hdmi_set_phy_pwr() seems too expensive and is already unprotected elsewhere. It's needed when enabling the hdmi output. In phy_enable() the irq is requested first, and then the phy_enable() runs hdmi_check_hpd_state(). So there's a chance to run hdmi_check_hpd_state() from both hpd-interrupt and phy_enable() at the same time. The hdmi_set_phy_pwr() is not called in many places, but I think there's indeed a problem there. It is called after free_irq(), but I think (guess) the irq handler could still be running after free_irq. So those should be protected by the same spinlock too. You know TI HDMI better than I do, so I assume your concerns are valid. So preferably I would move request_threaded_irq() to after hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the spin_lock_irqsave() in hdmi_check_hpd_state() to some mutex (we don't want irqs disabled so long as it takes for phy to power on/off). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 09/11] ARM: DT: Add support to system control module for OMAP4
Hello.
On 18-06-2012 15:32, Konstantin Baydarov wrote:
This patch adds device tree entries on OMAP4 based boards
for System Control Module (SCM).
TODO:
The IOMEM windows of ctrl_module_core, bandgap, usbphy overlap, so
probably only specific registers should be specified in dts for
bandgap and usb phy entries.
Signed-off-by: Konstantin Baydarovkbaida...@dev.rtsoft.ru
Signed-off-by: Eduardo Valentineduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 17 +
1 file changed, 17 insertions(+)
Index: linux-2.6/arch/arm/boot/dts/omap4.dtsi
===
--- linux-2.6.orig/arch/arm/boot/dts/omap4.dtsi
+++ linux-2.6/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,22 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = ti,omap4-control;
+ #address-cells =1;
+ #size-cells =1;
+ ranges;
+ ti,hwmods = ctrl_module_core;
+ reg =0x4a002000 0x1000;
+ bandgap@4a002000 {
+ compatible = ti,omap4-bandgap;
+ reg =0x4a002000 0x1000;
+ };
+ usb@4a002000 {
+ compatible = ti,omap4-usb-phy;
+ reg =0x4a002000 0x1000;
Two devices at the same address? Also, shouldn't values in the reg
property be relative to the value in the parent's reg property? Are they
needed at all here?
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote: On 18 June 2012 16:24, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote: BTW, coming to think about it, I am not sure what we need the spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It can't control HPD gpio state change and hdmi_set_phy_pwr() seems too expensive and is already unprotected elsewhere. It's needed when enabling the hdmi output. In phy_enable() the irq is requested first, and then the phy_enable() runs hdmi_check_hpd_state(). So there's a chance to run hdmi_check_hpd_state() from both hpd-interrupt and phy_enable() at the same time. The hdmi_set_phy_pwr() is not called in many places, but I think there's indeed a problem there. It is called after free_irq(), but I think (guess) the irq handler could still be running after free_irq. So those should be protected by the same spinlock too. You know TI HDMI better than I do, so I assume your concerns are valid. So preferably I would move request_threaded_irq() to after hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the No, you can't move the check. If you move it, the HPD state could change between the check and the request_irq, and we'd miss it. spin_lock_irqsave() in hdmi_check_hpd_state() to some mutex (we don't want irqs disabled so long as it takes for phy to power on/off). Yes, I guess a mutex is better. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
On 18 June 2012 17:54, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote: So preferably I would move request_threaded_irq() to after hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the No, you can't move the check. If you move it, the HPD state could change between the check and the request_irq, and we'd miss it. Wouldn't we then get an irq, and hence another hdmi_check_hpd_state(), for that? -- To unsubscribe from this list: send the line unsubscribe 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] OMAPDSS: HDMI: Discard phy_tx_enabled member
On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote: On 18 June 2012 17:54, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote: So preferably I would move request_threaded_irq() to after hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the No, you can't move the check. If you move it, the HPD state could change between the check and the request_irq, and we'd miss it. Wouldn't we then get an irq, and hence another hdmi_check_hpd_state(), for that? No, if we haven't requested the irq yet. So what could happen: - initially the cable is unplugged - ti_hdmi_4xxx_phy_enable() calls hdmi_check_hpd_state(), nothing is done as cable is unplugged - cable plugged in - ti_hdmi_4xxx_phy_enable() calls request_irq. No irq raised, as the cable's state doesn't change. We wouldn't know that cable is actually plugged in at that point. Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.
Thanks Keshava.
Regards
Sunil Matange
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, June 18, 2012 1:59 PM
To: Samuel Ortiz
Cc: Dill, Russ; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Balbi, Felipe; Partha Basak; Igor
Grinberg; Setty, Sapna; Russ Dill; Mantesh Sarashetti; Sunil Matange;
Nishant Kamat; Linux USB Devel
Subject: Re: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix
issues.
On Fri, Jun 15, 2012 at 12:36 AM, Sarashetti, Mantesh mant...@ti.com
wrote:
'Acked-by: mant...@ti.com'
'Tested-by: mant...@ti.com'
Regards,
Mantesh
-Original Message-
From: Russ Dill [mailto:russ.d...@gmail.com] On Behalf Of Dill, Russ
Sent: Thursday, June 14, 2012 11:24 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: Balbi, Felipe; Munegowda, Keshava; Partha Basak; Igor Grinberg;
Samuel Ortiz; Sarashetti, Mantesh; Setty, Sapna; Russ Dill
Subject: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix
issues.
From: Russ Dill russ.d...@gmail.com
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
an issue where the ULPI PHYs were not held in reset while initializing
the EHCI controller. However, it also changes behavior in
omap-usb-host.c omap_usbhs_init by releasing reset while the
configuration in that function was done.
This change caused a regression on BB-xM where USB would not function
if 'usb start' had been run from u-boot before booting. A change was
made to release reset a little bit earlier which fixed the issue on
BB-xM and did not cause any regressions on 3430 sdp, the board for
which the fix was originally made.
This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle
before adding hcd.', (3aa2ae74) caused a regression on OMAP5.
The original fix to hold the EHCI controller in reset during
initialization was correct, however it appears that changing
omap_usbhs_init to not hold the PHYs in reset during it's
configuration was incorrect. This patch first reverts both fixes, and
then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in
reset as the original patch had done. It also is sure to incorporate
the _cansleep change that has been made in the meantime.
I've tested this on Beagleboard xM, I'd really like to get an ack from
the 3430 sdp and OMAP5 guys before getting this merged.
v3 - Brown paper bag its too early in the morning actually run
git commit amend fix
v2 - Put cansleep gpiolib call outside of spinlock
Signed-off-by: Russ Dill russ.d...@gmail.com
---
drivers/mfd/omap-usb-host.c | 48
+-
drivers/usb/host/ehci-omap.c | 18 +++-
2 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..41088ec 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -25,6 +25,7 @@
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/spinlock.h
+#include linux/gpio.h
#include plat/cpu.h
#include plat/usb.h
#include linux/pm_runtime.h
@@ -500,8 +501,21 @@ static void omap_usbhs_init(struct device *dev)
dev_dbg(dev, starting TI HSUSB Controller\n);
pm_runtime_get_sync(dev);
- spin_lock_irqsave(omap-lock, flags);
+ if (pdata-ehci_data-phy_reset) {
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
+
gpio_request_one(pdata-ehci_data-reset_gpio_port[0],
+ GPIOF_OUT_INIT_LOW, USB1 PHY
reset);
+
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
+
gpio_request_one(pdata-ehci_data-reset_gpio_port[1],
+ GPIOF_OUT_INIT_LOW, USB2 PHY
reset);
+
+ /* Hold the PHY in RESET for enough time till DIR is
high */
+ udelay(10);
+ }
+
+ spin_lock_irqsave(omap-lock, flags);
omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
dev_dbg(dev, OMAP UHH_REVISION 0x%x\n, omap-usbhs_rev);
@@ -581,9 +595,39 @@ static void omap_usbhs_init(struct device *dev)
}
spin_unlock_irqrestore(omap-lock, flags);
+
+ if (pdata-ehci_data-phy_reset) {
+ /* Hold the PHY in RESET for enough time till
+ * PHY is settled and ready
+ */
+ udelay(10);
+
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
+ gpio_set_value_cansleep
+ (pdata-ehci_data-reset_gpio_port[0],
1);
+
+ if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
+ gpio_set_value_cansleep
+ (pdata-ehci_data-reset_gpio_port[1],
1);
+ }
+
pm_runtime_put_sync(dev);
}
+static void omap_usbhs_deinit(struct device *dev)
+{
+ struct
Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
On 18 June 2012 18:41, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote: On 18 June 2012 17:54, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote: So preferably I would move request_threaded_irq() to after hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the No, you can't move the check. If you move it, the HPD state could change between the check and the request_irq, and we'd miss it. Wouldn't we then get an irq, and hence another hdmi_check_hpd_state(), for that? No, if we haven't requested the irq yet. So what could happen: - initially the cable is unplugged - ti_hdmi_4xxx_phy_enable() calls hdmi_check_hpd_state(), nothing is done as cable is unplugged - cable plugged in - ti_hdmi_4xxx_phy_enable() calls request_irq. No irq raised, as the cable's state doesn't change. We wouldn't know that cable is actually plugged in at that point. I see, you mean physically (un)plugging the cable could race with phy_enable. OK, I'll revise the changelog for this patch and submit another patch converting the spinlock to mutex. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 03/13] I2C: OMAP: Remove reset at init
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
omap_i2c_reset is added in those places to effect the reset.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 38 +++---
1 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 838a0ae..5da91b5 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,15 +269,9 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static int omap_i2c_init(struct omap_i2c_dev *dev)
+static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
- u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
- unsigned long fclk_rate = 1200;
unsigned long timeout;
- unsigned long internal_clk = 0;
- struct clk *fclk;
-
if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -315,16 +309,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
dev-syscstate);
- /*
-* Enabling all wakup sources to stop I2C freezing on
-* WFI instruction.
-* REVISIT: Some wkup sources might not be needed.
-*/
- dev-westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- dev-westate);
}
}
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 1200;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
@@ -433,6 +429,16 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
OMAP_I2C_IE_AL) | ((dev-fifo_size) ?
(OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
+ /*
+* Enabling all wakup sources to stop I2C freezing on
+* WFI instruction.
+* REVISIT: Some wkup sources might not be needed.
+*/
+ dev-westate = OMAP_I2C_WE_ALL;
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ }
+
if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
dev-pscstate = psc;
dev-scllstate = scll;
@@ -541,6 +547,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
dev-buf_len = 0;
if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
+ omap_i2c_reset(dev);
omap_i2c_init(dev);
return -ETIMEDOUT;
}
@@ -551,6 +558,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
/* We have an error */
if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
+ omap_i2c_reset(dev);
omap_i2c_init(dev);
return -EIO;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 04/13] I2C: OMAP: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0.
I acknowledge the contributions and suggestions of Jon and Hemant.
A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and typically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5da91b5..7ab9fe1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -148,16 +148,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
@@ -311,6 +310,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
dev-syscstate);
}
}
+ return 0;
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -468,6 +468,31 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
}
/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, (OMAP_I2C_SYSTEST_ST_EN
+ | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_reset(dev);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
+
+/*
* Low level master read/write transaction.
*/
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
@@ -594,6 +619,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 02/13] I2C: OMAP: Remove the definition of SYSS_RESETDONE_MASK
Remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Also fixes the warning
CC drivers/i2c/busses/i2c-omap.o
drivers/i2c/busses/i2c-omap.c:163: warning: SYSS_RESETDONE_MASK redefined
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9a54e88..838a0ae 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -159,9 +159,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
#endif
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK(1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
#define SYSC_SIDLEMODE_MASK(0x3 3)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 07/13] I2C: OMAP: use devm_* functions
The various devm_* functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_and_ioremap for data
that is allocated in the probe function of a platform device and is only
freed in the remove function.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 33 +
1 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5c3a299..326b99c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -975,7 +975,7 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq, *ioarea;
+ struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
@@ -994,17 +994,16 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
- if (!ioarea) {
- dev_err(pdev-dev, I2C region already claimed\n);
- return -EBUSY;
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
- if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev-base = devm_request_and_ioremap(pdev-dev, mem);
+ if (!dev-base) {
+ dev_err(pdev-dev, I2C region already claimed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -1028,11 +1027,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq-start;
- dev-base = ioremap(mem-start, resource_size(mem));
- if (!dev-base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
platform_set_drvdata(pdev, dev);
@@ -1127,13 +1121,9 @@ err_free_irq:
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
- iounmap(dev-base);
pm_runtime_disable(pdev-dev);
err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem-start, resource_size(mem));
return r;
}
@@ -1141,7 +1131,6 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
int ret;
platform_set_drvdata(pdev, NULL);
@@ -1155,10 +1144,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 12/13] I2C: OMAP: add blank lines
From: Felipe Balbi ba...@ti.com
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0e0ab8f..6a79089 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -818,6 +818,7 @@ complete:
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
}
+
/*
* ProDB0017052: Clear ARDY bit twice
*/
@@ -830,6 +831,7 @@ complete:
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
+
if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
@@ -876,6 +878,7 @@ complete:
stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
continue;
}
+
if (stat (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
u8 num_bytes = 1;
if (dev-fifo_size) {
@@ -923,10 +926,12 @@ complete:
stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
continue;
}
+
if (stat OMAP_I2C_STAT_ROVR) {
dev_err(dev-dev, Receive overrun\n);
dev-cmd_err |= OMAP_I2C_STAT_ROVR;
}
+
if (stat OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
dev-cmd_err |= OMAP_I2C_STAT_XUDF;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 01/13] I2C: OMAP: I2C register restore only if context is lost
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost
or in case of error to be on the safe side.
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c |3 +++
drivers/i2c/busses/i2c-omap.c | 35 ++-
include/linux/i2c-omap.h |1 +
3 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index db071bc..4ccab07 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id)
*/
if (cpu_is_omap34xx())
pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
+
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9895fa7..9a54e88 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,6 +43,7 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
+#include plat/omap_device.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -185,6 +186,7 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*get_context_loss_count)(struct device *dev);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -207,6 +209,7 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
+ int dev_lost_count;
};
static const u8 reg_map_ip_v1[] = {
@@ -987,6 +990,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-speed = pdata-clkrate;
dev-flags = pdata-flags;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
+ dev-get_context_loss_count = pdata-get_context_loss_count;
dev-dtrev = pdata-rev;
}
@@ -1128,12 +1132,26 @@ omap_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_RUNTIME
+static void omap_i2c_restore(struct omap_i2c_dev *dev)
+{
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+
+}
static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
u16 iv;
+ if (_dev-get_context_loss_count)
+ _dev-dev_lost_count = _dev-get_context_loss_count(dev);
+
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
@@ -1154,16 +1172,15 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ int loss_cnt;
+
+ if (!(_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE))
+ return 0;
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ if (_dev-get_context_loss_count) {
+ loss_cnt = _dev-get_context_loss_count(dev);
+ if (_dev-dev_lost_count != loss_cnt)
+ omap_i2c_restore(_dev);
}
/*
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index 92a0dc7..c76cbc0 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@
[PATCHv8 06/13] I2C: OMAP: Correct I2C revision for OMAP3
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 691550a..5c3a299 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -50,8 +50,8 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
-#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_3530_4430 0x40
+#define OMAP_I2C_REV_ON_3430_3530 0x3C
+#define OMAP_I2C_REV_ON_3630_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
@@ -1055,7 +1055,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207)
dev-errata |= I2C_OMAP_ERRATA_I207;
- if (dev-rev = OMAP_I2C_REV_ON_3430)
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1073,7 +1073,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+ if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 13/13] I2C: OMAP: simplify omap_i2c_ack_stat()
From: Felipe Balbi ba...@ti.com
stat BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6a79089..bac6305 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -763,7 +763,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev, u16
*stat, int *err)
while (--timeout !(*stat OMAP_I2C_STAT_XUDF)) {
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
return -ETIMEDOUT;
}
@@ -824,10 +824,11 @@ complete:
*/
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, stat
- (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR |
+ OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -874,8 +875,8 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR));
continue;
}
@@ -922,8 +923,8 @@ complete:
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
continue;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 11/13] I2C: OMAP: decrease indentation level on data handling
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 63 -
1 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 080193a..0e0ab8f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -845,22 +845,7 @@ complete:
8) 0x3F;
}
while (num_bytes--) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev-buf_len) {
- *dev-buf++ = w;
- dev-buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
- }
- } else {
+ if (!dev-buf_len) {
if (stat OMAP_I2C_STAT_RRDY)
dev_err(dev-dev,
RRDY IRQ while no data
@@ -871,6 +856,21 @@ complete:
requested\n);
break;
}
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev-buf++ = w;
+ dev-buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
}
omap_i2c_ack_stat(dev,
stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
@@ -887,22 +887,7 @@ complete:
0x3F;
}
while (num_bytes--) {
- w = 0;
- if (dev-buf_len) {
- w = *dev-buf++;
- dev-buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- w |= *dev-buf++ 8;
- dev-buf_len--;
- }
- }
- } else {
+ if (!dev-buf_len) {
if (stat OMAP_I2C_STAT_XRDY)
dev_err(dev-dev,
XRDY IRQ while no
@@ -914,6 +899,20 @@ complete:
break;
}
+ w = *dev-buf++;
+ dev-buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ w |= *dev-buf++
[PATCHv8 08/13] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 326b99c..6f8e7d9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1147,6 +1147,7 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
#ifdef CONFIG_PM_RUNTIME
static void omap_i2c_restore(struct omap_i2c_dev *dev)
{
@@ -1208,15 +1209,16 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif /* CONFIG_PM_RUNTIME */
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
#else
#define OMAP_I2C_PM_OPS NULL
-#endif
+#endif /* CONFIG_PM */
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 10/13] I2C: OMAP: simplify num_bytes handling
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e24eb1f..080193a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -844,8 +844,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
8) 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
if (dev-buf_len) {
*dev-buf++ = w;
@@ -887,8 +886,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = 0;
if (dev-buf_len) {
w = *dev-buf++;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 05/13] I2C: OMAP: Optimise the remove code
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7ab9fe1..691550a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1138,8 +1138,7 @@ err_release_region:
return r;
}
-static int
-omap_i2c_remove(struct platform_device *pdev)
+static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
@@ -1236,7 +1235,7 @@ static struct dev_pm_ops omap_i2c_pm_ops = {
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
- .remove = omap_i2c_remove,
+ .remove = __devexit_p(omap_i2c_remove),
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 09/13] I2C: OMAP: Do not initialise the completion everytime
Use INIT_COMPLETION instead of init_completion in transfer. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 6f8e7d9..e24eb1f 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -521,7 +521,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, w |= OMAP_I2C_BUF_RXFIF_CLR | OMAP_I2C_BUF_TXFIF_CLR; omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, w); - init_completion(dev-cmd_complete); + INIT_COMPLETION(dev-cmd_complete); dev-cmd_err = 0; w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT; @@ -1029,6 +1029,7 @@ omap_i2c_probe(struct platform_device *pdev) dev-irq = irq-start; platform_set_drvdata(pdev, dev); + init_completion(dev-cmd_complete); dev-reg_shift = (dev-flags OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) 3; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: PATCH TI81xx fix MUSB software mode setting
Dear all,
when configuring our platform (DM8148 based) to work with USB0 as device
and USB1 as host I've found some problems.
It was fine if I configure both as device or both as host or enable only
one port, but configure both in different modes lead to a not working
configuration.
After a bit of debug I've found that probably the problem is inside
ti81xx_musb_set_mode() because this configure the controller but does
not set musb-board_mode. IIUC, without setting this structure the whole
musb generic state machine does not work correctly.
Attached you can find the patch that fixed the problem on our board. I
hope this can help others too and can be integrated inside the main tree.
Feel free to comment and tell me if I've done something wrong.
I hope the the patch format is quite correct for you.
Best Regards,
--
Andrea SCIAN
From d88b38b52d6561e8cee40cb7726fd4dc099fb07f Mon Sep 17 00:00:00 2001
From: Andrea Scian andrea.sc...@dave.eu
Date: Mon, 18 Jun 2012 16:17:28 +0200
Subject: [PATCH] set board_mode too when forcing musb mode, in this way musb is
initialized
properly
---
drivers/usb/musb/ti81xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/ti81xx.c b/drivers/usb/musb/ti81xx.c
index 22390e7..3656c74 100644
--- a/drivers/usb/musb/ti81xx.c
+++ b/drivers/usb/musb/ti81xx.c
@@ -1011,6 +1011,7 @@ int ti81xx_musb_set_mode(struct musb *musb, u8 musb_mode)
/* TODO: implement this using CONF0 */
if (musb_mode == MUSB_HOST) {
+ musb-board_mode = MUSB_HOST;
regval = musb_readl(reg_base, USB_MODE_REG);
regval = ~USBMODE_USBID_HIGH;
@@ -1023,6 +1024,7 @@ int ti81xx_musb_set_mode(struct musb *musb, u8 musb_mode)
musb_readl(reg_base, USB_MODE_REG), regval);
} else
if (musb_mode == MUSB_PERIPHERAL) {
+ musb-board_mode = MUSB_PERIPHERAL;
/* TODO commmented writing 8 to USB_MODE_REG device
mode is not working */
regval = musb_readl(reg_base, USB_MODE_REG);
--
1.6.5.GIT
Re: [PATCH 1/1] TPM: STMicroelectronics ST33 I2C/SPI ST19 I2C
Hi Mathias, On Fri, Jun 01, 2012 at 08:06:00PM +0200, Mathias Leblanc wrote: * STMicroelectronics version 1.2.0, Copyright (C) 2010 * STMicroelectronics comes with ABSOLUTELY NO WARRANTY. * This is free software, and you are welcome to redistribute it * under certain conditions. This is the driver for TPM chip from ST Microelectronics. Please go through Documentation/SubmitChecklist and make use of scripts/checkpatch.pl. This patch is far from meeting those standards. If you have a TPM security chip from STMicroelectronics working with an I2C/SPI, in menuconfig or .config choose the tpm driver on device -- tpm and activate the protocol of your choice before compiling the kernel. The driver will be accessible from within Linux. Tested on linux x86/x64 and beagleboard REV B XM REV C Signed-off-by: Mathias Leblanc mathias.lebl...@st.com --- arch/arm/mach-omap2/board-omap3beagle.c | 58 ++ drivers/char/tpm/Kconfig| 32 +- drivers/char/tpm/Makefile |2 + drivers/char/tpm/tpm_stm_st19_i2c.c | 560 ++ drivers/char/tpm/tpm_stm_st19_i2c.h | 52 ++ drivers/char/tpm/tpm_stm_st33_i2c.c | 1200 + drivers/char/tpm/tpm_stm_st33_i2c.h | 76 ++ drivers/char/tpm/tpm_stm_st33_spi.c | 1285 +++ drivers/char/tpm/tpm_stm_st33_spi.h | 80 ++ include/linux/i2c/tpm_stm_st19_i2c.h| 42 + include/linux/i2c/tpm_stm_st33_i2c.h| 48 ++ include/linux/spi/tpm_stm_st33_spi.h| 46 ++ 12 files changed, 3473 insertions(+), 8 deletions(-) create mode 100644 drivers/char/tpm/tpm_stm_st19_i2c.c create mode 100644 drivers/char/tpm/tpm_stm_st19_i2c.h create mode 100644 drivers/char/tpm/tpm_stm_st33_i2c.c create mode 100644 drivers/char/tpm/tpm_stm_st33_i2c.h create mode 100644 drivers/char/tpm/tpm_stm_st33_spi.c create mode 100644 drivers/char/tpm/tpm_stm_st33_spi.h create mode 100644 include/linux/i2c/tpm_stm_st19_i2c.h create mode 100644 include/linux/i2c/tpm_stm_st33_i2c.h create mode 100644 include/linux/spi/tpm_stm_st33_spi.h Please break up the patch into at least 4 patches, the spi driver, the i2c driver the build stuff and then the additions to the beagle board code. [cut] diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig index a048199..7384c93 100644 --- a/drivers/char/tpm/Kconfig +++ b/drivers/char/tpm/Kconfig @@ -5,6 +5,7 @@ menuconfig TCG_TPM tristate TPM Hardware Support depends on HAS_IOMEM + depends on EXPERIMENTAL This makes all TPM drivers experimental. Please move this into the config options for your drivers specifically so that only they are experimental. select SECURITYFS ---help--- If you have a TPM security chip in your system, which @@ -16,17 +17,14 @@ menuconfig TCG_TPM obtained at: http://sourceforge.net/projects/trousers. To compile this driver as a module, choose M here; the module will be called tpm. If unsure, say N. - Notes: - 1) For more TPM drivers enable CONFIG_PNP, CONFIG_ACPI + Note: For more TPM drivers enable CONFIG_PNP, CONFIG_ACPI and CONFIG_PNPACPI. - 2) Without ACPI enabled, the BIOS event log won't be accessible, - which is required to validate the PCR 0-7 values. if TCG_TPM config TCG_TIS tristate TPM Interface Specification 1.2 Interface - depends on X86 + depends on PNP I don't think this is correct, PNP is optional for tis. ---help--- If you have a TPM security chip that is compliant with the TCG TIS 1.2 TPM specification say Yes and it will be accessible @@ -35,7 +33,6 @@ config TCG_TIS config TCG_NSC tristate National Semiconductor TPM Interface - depends on X86 This needs to stay. Non-tis drivers are for 1.1 TPMs that have only been tested on their arch AFAIK. Unless you can provide a Tested-by: for this, I'll NACK it. ---help--- If you have a TPM security chip from National Semiconductor say Yes and it will be accessible from within Linux. To @@ -44,7 +41,6 @@ config TCG_NSC config TCG_ATMEL tristate Atmel TPM Interface - depends on PPC64 || HAS_IOPORT same as above. ---help--- If you have a TPM security chip from Atmel say Yes and it will be accessible from within Linux. To compile this driver @@ -60,6 +56,26 @@ config TCG_INFINEON To compile this driver as a module, choose M here; the module will be called tpm_infineon. Further information on this driver and the supported hardware - can be found at http://www.trust.rub.de/projects/linux-device-driver-infineon-tpm/ + can be found at http://www.prosec.rub.de/tpm + +config TCG_ST33_I2C +tristate STMicroelectronics ST33 I2C TPM with locality 0 4 Is with locality 0 4 relevent
Re: [PATCHv8 10/13] I2C: OMAP: simplify num_bytes handling
On Mon, Jun 18, 2012 at 08:00:25PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes
Wrong. This patch does change some behaviour, are you aware of that?
So, please check if the side-effect is affectong the code and adapt the
commit message, if everything is okay.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e24eb1f..080193a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -844,8 +844,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
8) 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
if (dev-buf_len) {
*dev-buf++ = w;
@@ -887,8 +886,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = 0;
if (dev-buf_len) {
w = *dev-buf++;
--
1.7.5.4
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCHv8 11/13] I2C: OMAP: decrease indentation level on data handling
On Mon, Jun 18, 2012 at 08:00:26PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes.
This patch seems to be correct, but it is not trivial. In fact, it is
pretty easy to miss a ! here which can cause subtle bugs.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 63
-
1 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 080193a..0e0ab8f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -845,22 +845,7 @@ complete:
8) 0x3F;
}
while (num_bytes--) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev-buf_len) {
- *dev-buf++ = w;
- dev-buf_len--;
- /*
- * Data reg in 2430, omap3 and
- * omap4 is 8 bit wide
- */
- if (dev-flags
- OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
- }
- } else {
+ if (!dev-buf_len) {
if (stat OMAP_I2C_STAT_RRDY)
dev_err(dev-dev,
RRDY IRQ while no data
@@ -871,6 +856,21 @@ complete:
requested\n);
break;
}
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev-buf++ = w;
+ dev-buf_len--;
+ /*
+ * Data reg in 2430, omap3 and
+ * omap4 is 8 bit wide
+ */
+ if (dev-flags
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
}
omap_i2c_ack_stat(dev,
stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
@@ -887,22 +887,7 @@ complete:
0x3F;
}
while (num_bytes--) {
- w = 0;
- if (dev-buf_len) {
- w = *dev-buf++;
- dev-buf_len--;
- /*
- * Data reg in 2430, omap3 and
- * omap4 is 8 bit wide
- */
- if (dev-flags
- OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- w |= *dev-buf++ 8;
- dev-buf_len--;
- }
- }
- } else {
+ if (!dev-buf_len) {
if (stat OMAP_I2C_STAT_XRDY)
dev_err(dev-dev,
XRDY IRQ while no
@@ -914,6 +899,20 @@ complete:
break;
}
+ w = *dev-buf++;
+ dev-buf_len--;
+ /*
+ * Data reg in 2430, omap3 and
+ * omap4 is 8 bit wide
+ */
+ if (dev-flags
+
Re: [PATCHv8 13/13] I2C: OMAP: simplify omap_i2c_ack_stat()
On Mon, Jun 18, 2012 at 08:00:28PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
stat BIT(1) is the same as BIT(1),
Not true. I'd guess you are missing some context in the patch
description.
so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6a79089..bac6305 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -763,7 +763,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev,
u16 *stat, int *err)
while (--timeout !(*stat OMAP_I2C_STAT_XUDF)) {
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
return -ETIMEDOUT;
}
@@ -824,10 +824,11 @@ complete:
*/
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, stat
- (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR |
+ OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -874,8 +875,8 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR));
continue;
}
@@ -922,8 +923,8 @@ complete:
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
continue;
}
--
1.7.5.4
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCHv8 00/13] I2C cleanups
On Mon, Jun 18, 2012 at 08:00:15PM +0530, Shubhrajyoti D wrote: The patch series does the following - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. - Adds a patch to use devm_* functions - Adds a pdata function pointer to do context save restore - Split the omap_i2c_isr to increase readability - Make the i2c use SET_RUNTIME_PM_OPS - Use INIT_COMPLETION instead of init_completion - Dropping a cleanup and taking few patchs Felipe's series as it may not be needed. Patches look mostly okay for me without knowing the platform too much. For that reason, I'd be really appreciating Tested-by or even Reviewed-by tags! This series mainly is the cleanups rebased on i2c-embedded/for-next branch. Thanks. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCHv3 5/7] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
Hi On Mon, 18 Jun 2012, Cousson, Benoit wrote: I guess that patch need to be revisited based on discussion we had and the patch you proposed in [1]. Assuming Tony is OK, it should be probably part of the -rc, because this domain should not have been introduced in 3.5-rc1 at all for OMAP4. Well as mentioned already on the lists, these clockdomains clearly exist; they are documented in the TRM and functional specification, and make sense from a chip perspective. For 3.6, I've already agreed to remove those clockdomains, even though it doesn't really match what's there on the chip. But I think 3.6 is the right time to do that. So it will be better to revert the patch that introduced that first before adding any new fix that will rely on a code that will disappear. In fact, I think the proper way to fix that while maintaining the OMAP23 way of dealing with clkdm is to ensure that at least one clkdm is there in either hwmod or the main_clk. That will fix these issues and the one that will append when the fake main_clk will be removed. Here is a patch that is doing that. Please document what systems this has been tested on. Thanks, Benoit [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70177.html --- From e5ffe6533236125c3c0b5eff883bfc1cf3cbe9f4 Mon Sep 17 00:00:00 2001 From: Benoit Cousson b-cous...@ti.com Date: Fri, 15 Jun 2012 11:26:49 +0200 Subject: [PATCH] ARM: OMAP2+: hwmod: Do not check clkdm for main_clk if oh does have one When a clkdm is handled directly at the hwmod level, there is no need to handle it with the main_clk as well. It is thus useless to complain about the missing clkdm for the main_clk in that case. Warn only if the clkdm is missing in both main_clk and hwmod. Init hwmod clkdm first to ensure it will be there when the main_clk will be initialized. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_hwmod.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 162f9c7..f33f4e2 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -609,7 +609,7 @@ static int _init_main_clk(struct omap_hwmod *oh) return -EINVAL; } - if (!oh-_clk-clkdm) + if (!oh-_clk-clkdm !oh-clkdm) pr_warning(omap_hwmod: %s: missing clockdomain for %s.\n, oh-main_clk, oh-_clk-name); @@ -1339,10 +1339,10 @@ static int _init_clocks(struct omap_hwmod *oh, void *data) pr_debug(omap_hwmod: %s: looking up clocks\n, oh-name); + ret |= _init_clkdm(oh); ret |= _init_main_clk(oh); ret |= _init_interface_clks(oh); ret |= _init_opt_clks(oh); - ret |= _init_clkdm(oh); if (!ret) oh-_state = _HWMOD_STATE_CLKS_INITED; -- 1.7.0.4 - 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] ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4
On Mon, 18 Jun 2012, Cousson, Benoit wrote: The commit 503d0ea24d1d3dd3db95e5e0edd693da7a2a23eb ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks added a wrong prcm_clk alias for PRCM clock whereas the McBSP driver and previous OMAPs are using prcm_fck. It thus lead to the following warning. [ 47.409729] omap-mcbsp: clks: could not clk_get() prcm_fck Fix that by changing the opt_clk role to prcm_fck. Reported-by: Misael Lopez Cruz misael.lo...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Peter Ujfalusi peter.ujfal...@ti.com Tested-by: Sebastien Guiriec s-guir...@ti.com Thanks, will queue this as part of the next 3.5-rc series. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Afzal,
Thanks for sending the update.
On 06/16/2012 03:03 AM, Afzal Mohammed wrote:
Reorganize gpmc-onenand initialization so that changes
required for gpmc driver migration can be made smooth.
Ensuring sync read/write are disabled in onenand cannot
be expected to work properly unless GPMC is setup, this
has been removed. And invocation of set_async has been
moved from set_sync to gpmc_onenand_init function; gpmc
for onenand needs to be initialized to async mode (even
for sync mode initially). Ensuring that onenand part
has been setup for async mode has been moved now to
setup function.
Thanks to Jon for his suggestions on improving this change.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: Move ensuring that async mode in OneNAND has been setup from
set_sync to setup function, improve commit message
arch/arm/mach-omap2/gpmc-onenand.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 71d7c07..975c1f9 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -38,10 +38,9 @@ static struct platform_device gpmc_onenand_device = {
.resource = gpmc_onenand_resource,
};
-static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
+static int omap2_onenand_set_async_mode(int cs)
{
struct gpmc_timings t;
- u32 reg;
int err;
const int t_cer = 15;
@@ -55,11 +54,6 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
const int t_wpl = 40;
const int t_wph = 30;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
memset(t, 0, sizeof(t));
t.sync_clk = 0;
t.cs_on = 0;
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
if (err)
return err;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
Sorry if I was not clear, but I was still thinking that we keep the
above instance of setting async mode.
return 0;
}
@@ -197,13 +187,10 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
sync_read = 1;
sync_write = 1;
} else
- return omap2_onenand_set_async_mode(cs, onenand_base);
+ return 0;
if (!freq) {
/* Very first call freq is not known */
- err = omap2_onenand_set_async_mode(cs, onenand_base);
- if (err)
- return err;
freq = omap2_onenand_get_freq(cfg, onenand_base, clk_dep);
first_time = 1;
}
@@ -385,6 +372,12 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
static int gpmc_onenand_setup(void __iomem *onenand_base, int *freq_ptr)
{
struct device *dev = gpmc_onenand_device.dev;
+ u32 reg;
+
+ /* Ensure sync read and sync write are disabled */
+ reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
+ reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
+ writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
... and here we should just call omap2_onenand_set_async_mode(), ...
/* Set sync timings in GPMC */
if (omap2_onenand_set_sync_mode(gpmc_onenand_data, onenand_base,
@@ -421,6 +414,8 @@ void __init gpmc_onenand_init(struct
omap_onenand_platform_data *_onenand_data)
gpmc_onenand_resource.end = gpmc_onenand_resource.start +
ONENAND_IO_SIZE - 1;
+ omap2_onenand_set_async_mode(gpmc_onenand_data-cs);
+
... then remove the above call.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: OMAP2/3: Move McBSP fck alias to hwmod data
Hi On Thu, 14 Jun 2012, Peter Ujfalusi wrote: To keep the McBSP fck alias handling in sync among OMAP versions. Change the legacy implementation for OMAP2/3 regarding to McBSP fck alias. OMAP4 (and OMAP5) uses the hwmod data to specify the aliases for the fcks and it is also needed for the coming McBSP DT support. Tested on OMAP3 BeagleBoard, compile tested it for OMAP2. Thanks, queued for 3.6. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API
Hi, On Fri, 20 Apr 2012, Tarun Kanti DebBarma wrote: Add an API to get main clock name associated with a given @oh. This will avoid the need to construct fclk names during early initialization in order to get fclk handle using clk_get(). Cc: Cousson, Benoit b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Thanks, queued for 3.6 with Benoît's ack. - Paul
Re: [PATCH 09/11] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
On Thu, 7 Jun 2012, Rajendra Nayak wrote: On Thursday 07 June 2012 11:43 AM, Paul Walmsley wrote: Until the OMAP4 code is converted to disable the use of the clock framework-based clockdomain enable/disable sequence, any clock used as a hwmod main_clk must have a clockdomain associated with it. This patch populates some clock structure clockdomain names to resolve the following warnings during kernel init: But these associations are useless if the clock is not a 'gate' clock, except for getting rid of these warnings. Maybe we should make hwmod understand that not all clocks need to have a clockdomain associated with it and stop complaining. In retrospect, I think I should have made clockdomains mandatory for all clocks for OMAP4 back then, rather than only allowing them for some clocks. As I understand it, that would have saved a lot of time and debugging frustration on the bug fixed by commit 6c4a057bffe9823221eab547e11fac181dc18a2b (ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock). Oh well. - 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: Bringing back gptimer_wakeup
Tasslehoff Kjappfot tasskj...@gmail.com writes: The support for using a timer to wake from suspend was removed in: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864 I found an alternative patch (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47836.html) that claimed to keep it working using GPTIMER1 instead, but I haven't been able to make it work (likely because the timer code has changed a good deal since the patch was posted). Anyone got a) a patch that enables this feature on newer kernels, or b) an idea how the patch above can be made to work? The branch below (based on v3.4) will work (at least on OMAP3) We've been holding off on putting this back becasue the timer interface has been going through some major cleanup/rework, but I would like to see this make it back in soonish. Kevin git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-wip/wakeup-timer -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 0/4] ARM: OMAP2+: am33xx: Add clocktree and hwmod data
Hi Vaibhav, On Thu, 14 Jun 2012, Hiremath, Vaibhav wrote: Leaving HWMOD data patch aside, both the above patches should be considered for acceptance, can you please review the same and if there are no review comments, can it be merged? I don't quite understand the part about leaving the hwmod data patch aside. Is that one not ready? Or does it need to be modified pending some other series? - 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 0/4] ARM: OMAP2+: am33xx: Add clocktree and hwmod data
On Mon, Jun 18, 2012 at 23:36:58, Paul Walmsley wrote: Hi Vaibhav, On Thu, 14 Jun 2012, Hiremath, Vaibhav wrote: Leaving HWMOD data patch aside, both the above patches should be considered for acceptance, can you please review the same and if there are no review comments, can it be merged? I don't quite understand the part about leaving the hwmod data patch aside. Is that one not ready? Or does it need to be modified pending some other series? It is ready, since I did not get your acked-by or reviewed-by on the patche- series, so I wanted to get trivial patches merged. Paul, I would really recommend you to look at the proposal of getting the clock- tree and hwmod patches to the linux-next until merge window, so that it will get tested for some time. Also, I am in the process of converting to common-clock framework on top of Rajendra's patch-series. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 0/4] ARM: OMAP2+: am33xx: Add clocktree and hwmod data
On Mon, 18 Jun 2012, Hiremath, Vaibhav wrote: I would really recommend you to look at the proposal of getting the clock- tree and hwmod patches to the linux-next until merge window, so that it will get tested for some time. I've thought about this, but I'm not sure it has much point unless Tony's tree goes to linux-next, since that's where the OMAP integration happens. - 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 0/4] ARM: OMAP2+: am33xx: Add clocktree and hwmod data
On Mon, Jun 18, 2012 at 23:58:36, Paul Walmsley wrote: On Mon, 18 Jun 2012, Hiremath, Vaibhav wrote: I would really recommend you to look at the proposal of getting the clock- tree and hwmod patches to the linux-next until merge window, so that it will get tested for some time. I've thought about this, but I'm not sure it has much point unless Tony's tree goes to linux-next, since that's where the OMAP integration happens. Yes, make sense. I also meant same thing, it should be along with Tony's pull request - Tony's Tree (for linux-next) + Your Branch (AM335x prm/cm/clkdm/pwrdm) + AM335x Clock Tree and HWMOD. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP AM33xx: add PRCM support (for 3.6)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit 08f3098928c991560408e8c71d4af8b1a3ff2d67: ARM: OMAP2+: am33xx: Add AM335XEVM machine support (2012-06-05 00:52:37 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-a-for-3.6 for you to fetch changes up to 9c80f3aa8b7828c89c5bae5c769955d1ac58630b: ARM: OMAP AM33xx: clockdomains: Add clockdomain data and respective operations (2012-06-18 12:08:06 -0600) - Adds AM33xx PRCM support - This branch is based on your devel-am33xx branch. object size (delta in bytes from tmlind_devel_am33xx (08f3098928c991560408e8c71d4af8b1a3ff2d67)): textdata bss total kernel 0 0 0 0 5912osk_testconfig/vmlinux +2364 +6976 0 +9340 am33xx_testconfig/vmlinux +4+568 0+572 n800_multi_omap2xxx/vmlinux +4+576 0+580 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux +4 +2104 0 +2108 omap2_4_testconfig/vmlinux +6216 +6944 0 +13160 omap2plus_defconfig/vmlinux +6276 +6720 0 +12996 omap2plus_no_pm/vmlinux +2120 +6560 0 +8680 omap3_4_testconfig/vmlinux +2136 +5048 0 +7184 omap3_testconfig/vmlinux +4 +1536 0 +1540 omap4_testconfig/vmlinux Vaibhav Hiremath (6): ARM: OMAP2+: control: Add AM33XX control reg sec clkctrl offset ARM: OMAP AM33xx: voltagedomain: Add voltage domain data ARM: OMAP AM33xx: PRM: add PRM support ARM: OMAP AM33xx: CM: Introduce AM33xx CM APIs and register level details ARM: OMAP AM33xx: powerdomains: add AM335x support ARM: OMAP AM33xx: clockdomains: Add clockdomain data and respective operations arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/clockdomain.h |2 + arch/arm/mach-omap2/clockdomain33xx.c | 74 +++ arch/arm/mach-omap2/clockdomains33xx_data.c | 196 +++ arch/arm/mach-omap2/cm-regbits-33xx.h | 687 + arch/arm/mach-omap2/cm33xx.c | 313 +++ arch/arm/mach-omap2/cm33xx.h | 420 +++ arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/control.h | 39 +- arch/arm/mach-omap2/io.c |3 + arch/arm/mach-omap2/powerdomain.h | 23 +- arch/arm/mach-omap2/powerdomain33xx.c | 229 + arch/arm/mach-omap2/powerdomains33xx_data.c | 185 +++ arch/arm/mach-omap2/prm-regbits-33xx.h| 357 + arch/arm/mach-omap2/prm33xx.c | 135 + arch/arm/mach-omap2/prm33xx.h | 129 + arch/arm/mach-omap2/voltage.h |1 + arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 ++ 18 files changed, 2825 insertions(+), 18 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomain33xx.c create mode 100644 arch/arm/mach-omap2/clockdomains33xx_data.c create mode 100644 arch/arm/mach-omap2/cm-regbits-33xx.h create mode 100644 arch/arm/mach-omap2/cm33xx.c create mode 100644 arch/arm/mach-omap2/cm33xx.h create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h create mode 100644 arch/arm/mach-omap2/prm33xx.c create mode 100644 arch/arm/mach-omap2/prm33xx.h create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJP338XAAoJEMePsQ0LvSpL09gQAIjd3cLj1IdNbu5JpstkFwfL zgyhH3/1VnMJ8zYtM0M+j4JGBYVtSQ8v7Mp6cbMTyGTpxzy0h+kAb3wL+Tf2f++f FpGGqO015n6aBAdWADcuf8ssYbgu5MmZTecfqMUuxMnNioXQkDbKREo9Srn9r/Et 987AXTaJFPMPu5JNbFDgaVi4axX+eMfHRk8vyMP5laBOOUWBVF7asq4SM2UyxAD8 s1dD8i/UX4tN7/sLDy6XHDVKLdOpR2aTitw+WQUBXwLaYObawNwVjnoZW7j+bby7 tUMaxbZTKZNE9utqYTdijYgnc3GsvjIp83jYVYfvjYcdYcc+LGoUSKpXa9ffvTj+ 0dh78Zua/7lRcfhJhlaK3SLGD9UDEfGSq7tMC6tCE2YuHZp71c2Vuf9lzzzywfuT LAzTrwkicMqPk3vDJxpgdmzxAyXCe5Qewh93Rgl9Y/Jei5sLmpMJYTGTBTV642cm F8ykWaL9KQslqSFLoZwZ9wUlPbz4wiNhSXk2/PvCV5S4A721sQ7J67EZy7SjDW6F gW0Mt6d0PdT7MwzqmHr+bYaeVMdgCLRbw9eC9Z6mIQ3Wyu+OTCn6b96tjrbymmy9 2PDvBXQhoCezRK6mZcrHfek7VoRd+otxvGfwakqPKj8FkAZpj6WfsnK4HSG2DF6e ID0oP4CQFmqy4/gvUWqV =zSRx -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe 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 01/29] clk: Add support for rate table based dividers
On 20120614-18:16, Rajendra Nayak wrote:
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index e548c43..e4911ee 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -32,30 +32,69 @@
#define div_mask(d) ((1 (d-width)) - 1)
#define is_power_of_two(i) !(i ~i)
+static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
+{
+ unsigned int maxdiv;
+ const struct clk_div_table *clkt;
+
+ for (clkt = table; clkt-div; clkt++)
+ if (clkt-div maxdiv)
+ maxdiv = clkt-div;
+ return maxdiv;
+}
+
Hi Rajendra,
During testing the compiler warns that maxdiv is uninitialized here.
Regards,
Mike
--
To unsubscribe from this list: send the line unsubscribe 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+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data
On Tue, 15 May 2012, Hiremath, Vaibhav wrote: Paul, Can you please add above statement, when you merge it into your repo? Added this, and added Santosh's ack, and queued for 3.6. - 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: [RFC] ARM: OMAP4470: Fix OMAP4470 boot failure
Hi Jon,
On Thu, 7 Jun 2012, Jon Hunter wrote:
The problem is that currently none of the clocks are being registered for
OMAP4470 devices and so on boot-up no clocks can be found and the kernel
panics.
This fix always the kernel to boot without failure using a simple RAMDISK file
system. However, I need some inputs from the clock guru's if this is the
correct fix :-)
Signed-off-by: Jon Hunter jon-hun...@ti.com
I guess Benoît should make the call on this, since he's got access to the
hardware data to use to autogenerate these clocks. If there aren't any
differences between the 4460 and 4470 clocks and dividers, then your
patch looks good to me.
If there are any differences between the 4460 and 4470 clocks and
dividers, we should probably wait until the common clock conversion is
complete, since that would presumably be a large change.
Just my 2 cents,
- Paul
---
arch/arm/mach-omap2/clock44xx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..19275e8 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3412,7 +3412,7 @@ int __init omap4xxx_clk_init(void)
if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
cpu_clkflg = CK_443X;
- } else if (cpu_is_omap446x()) {
+ } else if (cpu_is_omap446x() || cpu_is_omap447x()) {
cpu_mask = RATE_IN_4460 | RATE_IN_4430;
cpu_clkflg = CK_446X | CK_443X;
} else {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
Re: [RFC] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data
Hi On Sat, 16 Jun 2012, Ricardo Neri wrote: I would like to revive an old discussion regarding how to use a particular idle mode for a specific use-case[1]. As per the OMAP4 documentation, audio over HDMI should be transmitted in no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmode uses no-idle/force-idle settings instead of smart-idle. However, if this flag is used, smart-idle nor smart-idle wakeup-capable features could not be used. This would not be ideal if we want, for instance, to wake up using a HDMI cable connect event. Ideally, the HDMI module should be set to no-idle when transmitting audio and then go back to whatever mode it was (e.g., smart-idle) when audio transmission is over. I am not sure how to do that, though. In the past, it was suggested to use an integration function through platform_data[2], which didn't seem to be suitable from the device tree perspective; although there were no other alternatives[3]. It was also suggested to add functions to allow/block smart-idle momentarily[4], but how would the driver let know omap_hwmod when to allow/block smart-idle without using platform_data/integration function? Yep that's indeed a good summary of the situation. Since your patch fixes a functionality problem, maybe update the inline comment that you add to the data file to summarize what you wrote above: that this is simply a temporary workaround until the device driver has the ability to control the idle behavior. Also if you want this patch to go in during the 3.5-rc fixes cycle, please document further in the patch description what specific problem this fixes (e.g., choppy/broken audio, etc.) - 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: [PATCHv3 5/7] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
Hi Paul, On 6/18/2012 5:45 PM, Paul Walmsley wrote: Hi On Mon, 18 Jun 2012, Cousson, Benoit wrote: I guess that patch need to be revisited based on discussion we had and the patch you proposed in [1]. Assuming Tony is OK, it should be probably part of the -rc, because this domain should not have been introduced in 3.5-rc1 at all for OMAP4. Well as mentioned already on the lists, these clockdomains clearly exist; they are documented in the TRM and functional specification, and make sense from a chip perspective. OK, let's clarify: These are not clock domains for PRCM standpoint. These are the clock generators inside the PRCM, but they do not follow the functional clock domain mechanism at all. Because of that they do not have any regular clkdm registers and that's why it does not worth using the current clkdm infrastructure since there is no SW control for them. What is missing to make these domains valid is to extend the current definition to handle both the clock consumer domains and the clock generators. For 3.6, I've already agreed to remove those clockdomains, even though it doesn't really match what's there on the chip. But I think 3.6 is the right time to do that. OK, fair enough. I'll base the further cleanup series on that one. So it will be better to revert the patch that introduced that first before adding any new fix that will rely on a code that will disappear. In fact, I think the proper way to fix that while maintaining the OMAP23 way of dealing with clkdm is to ensure that at least one clkdm is there in either hwmod or the main_clk. That will fix these issues and the one that will append when the fake main_clk will be removed. Here is a patch that is doing that. Please document what systems this has been tested on. For the moment, Thunderbird 13.0.1 only since I do not have any board accessible :-(. 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
[PATCH] OMAP: beagle: Set USB Host Port 1 to OMAP_USBHS_PORT_MODE_UNUSED
The beagleboard USB Host Port that is used is Port 2. The platform driver sets
MODE_PHY for port 1 causing pin muxing to override the pins on the expansion
connector P17 when using board_mux[]. Since USBHS Port 1 is not connected
remove the case for muxing the USB Port1 pins by default.
Patch is based off of 3.5-rc2 from ASoC for-next branch
Tested with BeagleBoard xM revC and checked the userguides for Beagle xM and
revC to be sure USB Port2 is what is used.
Singed-off-by: Brian Austin brian.aus...@cirrus.com
---
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 79c6909..75eb88a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -435,7 +435,7 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
- .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
+ .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help! AM35xx mm/slab.c BUG
Hi Afzal,
I just wanted to follow back up. We are still trying to find this slab bug,
but so far we've not found any smoking guns. Less than stable power is our
current main suspect. As has been the custom however, the error was here 2
weeks ago nearly non-stop, and then as suddenly as it came it went nearly
silent. We've had a very hard time reproducing it since!
Anyway, we have advanced our kernel to today's latest l-o (3.5-rc2). Though we
are not considering the GPMC a likely source of the error at this moment, I'm
considering exploring this patchset. Unfortunately, the NAND is very critical
to our current efforts. So I'm trying to find a time where it would be OK to
disable it as you suggested to try this. Since these values are being set now
in Linux, do I need to rework my bootloaders as well? In my current case,
these settings are all done in u-boot. I do not believe Linux did anything with
them. Do I need to remove those in order to use your patches? If I do, do I
not lose access to those things while in the bootloaders?
Thanks
- Original Message -
From: Mohammed, Afzal af...@ti.com
To: CF Adad cfa...@rocketmail.com
Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org; Tony Lindgren
t...@atomide.com; Shilimkar, Santosh santosh.shilim...@ti.com
Sent: Tuesday, June 12, 2012 7:14 AM
Subject: RE: Please help! AM35xx mm/slab.c BUG
Hi,
On Fri, Jun 08, 2012 at 01:20:13, CF Adad wrote:
Thanks for your thoughts! I may try fiddling a bit just to see if that helps.
5 series of patches for gpmc modifications [1-5] has been posted,
In case it helps in resolving your issue, please let me know.
You will have to use the new interface to make use of runtime
calculation of smsc911x timing, [5.x] can be referred for how to
do board modifications for smsc911x (please comment out any other
gpmc peripheral initialization in your board code, seems you have
nand, comment out nand initialization, even nand can be made to
work with new changes, but avoiding it will probably reduce your
burden)
As your eth is 9221, either you can provide the timings based on it
from board file or apply [6] over [1-5] (base: 3.5-rc1)
Regards
Afzal
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html
[3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69891.html
[4] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69897.html
[5] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69917.html
[5.x] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69924.html
[6]
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 4bfe721..34816b9 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -105,12 +105,12 @@ static void gpmc_smsc911x_timing(struct gpmc_time_ctrl
*time_ctrl,
{
struct gpmc_timings t;
/* SMSC 9220 timings */
- unsigned tcycle_r = 165;
+ unsigned tcycle_r = 45;
unsigned tcsl_r = 32;
unsigned tcsh_r = 133;
unsigned tcsdv_r = 30;
unsigned tdoff_r = 9;
- unsigned tcycle_w = 165;
+ unsigned tcycle_w = 45;
unsigned tcsl_w = 32;
unsigned tcsh_w = 133;
unsigned tdsu_w = 7;
--
To unsubscribe from this list: send the line unsubscribe 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 09/29] ARM: omap: clk: Nuke plat/clock.c reuse struct clk as clk_hw_omap
On 20120614-18:16, Rajendra Nayak wrote: plat/clock.c which has most of usecounting/locking infrastructure will be used only for OMAP1 until that is moved to use COMMON clk. reuse most of what plat/clock.h has while we move to common clk, and move most of what 'struct clk' was as 'struct clk_hw_omap' which will then be used to define platform specific parameters. All usecounting/locking related variables from 'struct clk' are dropped as they will not be used with 'struct clk_hw_omap'. Based on the original changes from Mike Turquette. Signed-off-by: Rajendra Nayak rna...@ti.com Looks good to me Rajendra. Reviewed-by: Mike Turquette mturque...@linaro.org +unsigned long omap_fixed_divisor_recalc(struct clk_hw *hw, + unsigned long parent_rate); Would be nice to get rid of this. I think only iva1_mpu_int_ifck from OMAP2 uses it. If so it would be nice to convert that clock over to the fixed factor type (if possible) and drop this bit of glue code. Probably something for the future though, no reason to block this patch on it. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: beagle: Set USB Host Port 1 to OMAP_USBHS_PORT_MODE_UNUSED
On Mon, Jun 18, 2012 at 2:42 PM, Brian Austin brian.aus...@cirrus.com wrote:
The beagleboard USB Host Port that is used is Port 2. The platform driver
sets MODE_PHY for port 1 causing pin muxing to override the pins on the
expansion
connector P17 when using board_mux[]. Since USBHS Port 1 is not connected
remove the case for muxing the USB Port1 pins by default.
Patch is based off of 3.5-rc2 from ASoC for-next branch
Tested with BeagleBoard xM revC and checked the userguides for Beagle xM and
revC to be sure USB Port2 is what is used.
Singed-off-by: Brian Austin brian.aus...@cirrus.com
You'll probably have to fix your sing/sign typo, but otherwise it looks good
Acked-by: Russ Dill russ.d...@ti.com
Just for those that might get confused looking at schematics,
port_mode[0] refers to the HSUSB1_* pins, and port_mode[1] refers to
the HSUSB2_* pins.
---
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 79c6909..75eb88a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -435,7 +435,7 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
- .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
+ .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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 09/11] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
On Monday 18 June 2012 11:11 PM, Paul Walmsley wrote: On Thu, 7 Jun 2012, Rajendra Nayak wrote: On Thursday 07 June 2012 11:43 AM, Paul Walmsley wrote: Until the OMAP4 code is converted to disable the use of the clock framework-based clockdomain enable/disable sequence, any clock used as a hwmod main_clk must have a clockdomain associated with it. This patch populates some clock structure clockdomain names to resolve the following warnings during kernel init: But these associations are useless if the clock is not a 'gate' clock, except for getting rid of these warnings. Maybe we should make hwmod understand that not all clocks need to have a clockdomain associated with it and stop complaining. In retrospect, I think I should have made clockdomains mandatory for all clocks for OMAP4 back then, rather than only allowing them for some clocks. As I understand it, that would have saved a lot of time and debugging frustration on the bug fixed by commit 6c4a057bffe9823221eab547e11fac181dc18a2b (ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock). Oh well. We should certainly have a better way for PM code to WARN() users if some clocks which need clockdomains to be programmed together with the clocks, have the clockdomain information missing. One way to do that is make it mandatory for *all* clocks to have an associated clockdomain, but that would mean we populate dummy and unnecessary data atleast in some cases wherein it never gets used, just to get rid of the WARN(). That certainly does not seem right. The other way is really to make our frameworks understand and WARN() *intelligently*. Today we WARN() users only for main_clks used in hwmod. I feel this WARN() should instead come from the clock framework, because there are clearly clocks outside of what is handled by hwmod (like the one in the commit above) which need this information. We should also look at making the clock framework intelligent to identify which clocks really need a clockdomain associated instead of adding a WARN for every other clock. just my 2 cents.. - 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 01/29] clk: Add support for rate table based dividers
On Tuesday 19 June 2012 01:34 AM, Mike Turquette wrote:
On 20120614-18:16, Rajendra Nayak wrote:
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index e548c43..e4911ee 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -32,30 +32,69 @@
#define div_mask(d) ((1 (d-width)) - 1)
#define is_power_of_two(i)!(i ~i)
+static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
+{
+ unsigned int maxdiv;
+ const struct clk_div_table *clkt;
+
+ for (clkt = table; clkt-div; clkt++)
+ if (clkt-div maxdiv)
+ maxdiv = clkt-div;
+ return maxdiv;
+}
+
Hi Rajendra,
During testing the compiler warns that maxdiv is uninitialized here.
Thanks Mike, I'll fix that up.
Regards,
Mike
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Jon,
On Mon, Jun 18, 2012 at 21:31:46, Hunter, Jon wrote:
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
if (err)
return err;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
Sorry if I was not clear, but I was still thinking that we keep the
above instance of setting async mode.
:
static int gpmc_onenand_setup(void __iomem *onenand_base, int *freq_ptr)
{
struct device *dev = gpmc_onenand_device.dev;
+ u32 reg;
+
+ /* Ensure sync read and sync write are disabled */
+ reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
+ reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
+ writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
... and here we should just call omap2_onenand_set_async_mode(), ...
If omap2_onenand_set_async_mode is called from gpmc_onenand_setup removed
from gpmc_onenand_init, when using new gpmc driver interface, i.e. using
gpmc_onenand_update [1], we lost opportunity to provide gpmc driver with
configuration details for async mode causing a big warning about each
timings configurations that was left by bootloader (which is meant only
for cases where Kernel can't configure GPMC). Of course, we can put
omap2_onenand_set_async_mode in gpmc_onenand_update too, but then
unnecessarily, omap2_onenand_sey_async_mode would be called twice.
Please note that gpmc_onenand_setup is a callback by onenand driver.
Regards
Afzal
+ omap2_onenand_set_async_mode(gpmc_onenand_data-cs);
+
... then remove the above call.
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69919.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
