Re: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling
* Linus Walleij linus.wall...@linaro.org [130710 13:42]: On Thu, Jun 27, 2013 at 4:01 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: I think, In the future the OMAP pinctrl configurations would be manged in more flexible way then now (thanks to pinctrl PM helpers and you;)) - Idle state will be splitted to Idle/sleep - default state will be splitted to default/active OK so the first ones we already have so the discussion is now down to adding the active state (and pinctrl_pm* helper function). I think I have a patchset ready for pinctrl to allow multiple simulaneous states as discussed, need to test it first though. Should be able to post it on Friday hopefully. I guess we need a patch set prepared which adds the active state and helper function as the first patch, i.e. this: http://marc.info/?l=linux-kernelm=137094012703340w=2 Can I have your ACK on this patch? Hmm I have gone a bit further with the drivers/base/pinctrl.c in my set where if active state is defined then sleep and idle states must match active state for the pingroups to avoid constantly checking those sets during runtime. Then the pinctrl_pm_select_active_state() does not actually have anything to do with PM in the rx/tx case, so we should rename that. It's pretty close, but before we can apply that we need the changes I have to allow multiple simultaneous states. I suggest wait just few days on that patch. I do not want to add the state unless there is a clear consumer, so it needs to go in with the first patch to a device driver that uses pinctrl_pm_select_active_state() which will be a good demonstration on its use and utility. (And a point to object and suggest other ways to do the same thing...) Right, we have quite a few consumers with omaps for that as am33xx requires remuxing wake-up events for all drivers AFAIK. The MMC SDIO pin remuxing is probably closest one ready. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Boot hang regression 3.10.0-rc4 - 3.10.0
On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
* Kevin Hilman khil...@linaro.org [130710 01:29]:
Felipe Balbi ba...@ti.com writes:
Right, but calling serial_omap_restore_context() even when the context
is not lost, should not ideally cause an issue.
it does in one condition. If context hasn't been saved before. And that
can happen in the case of wrong pm runtime status for that device.
Imagine the device is marked as suspended even though it's fully enabled
(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
your context structure is all zeroes (context has never been saved
before) then when you call pm_runtime_get_sync() on probe() your
-runtime_resume() will get called, which will restore context,
essentially undoing anything which was configured by u-boot.
Am I missing something ?
You're right, the _set_active() is crucial in the case when we prevent
the console UART from idling during boot (though that shouldn't be
happening in mainline unless the fix for Issue 1 is done.)
Felipe is right, looks like all we need is to check if context is
initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
works for me.
On what platform? Like I said there are flags set statically in hmwod
data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
in mach-omap2/serial.c. But it won't work for am33xx.
We could also check for some combination of the context
save registers being NULL if somebody has a good idea which ones
should never be 0.
Regards,
Tony
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -161,6 +161,7 @@ struct uart_omap_port {
u32 calc_latency;
struct work_struct qos_work;
struct pinctrl *pins;
+ boolinitialized;
boolis_suspending;
};
@@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device
*pdev)
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
+ up-initialized = true;
This won't help as the context save for serial happens as part of set_termios()
and not
when the device is probed.
+
return 0;
err_add_port:
@@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct
uart_omap_port *up, u8 mdr1)
#ifdef CONFIG_PM_RUNTIME
static void serial_omap_restore_context(struct uart_omap_port *up)
{
+ if (!up-initialized)
+ return;
+
if (up-errata UART_ERRATA_i202_MDR1_ACCESS)
serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
else
--
To unsubscribe from this list: send the line unsubscribe 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: Boot hang regression 3.10.0-rc4 - 3.10.0
* Rajendra Nayak rna...@ti.com [130710 23:25]: On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote: Felipe is right, looks like all we need is to check if context is initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering. After that having DEBUG_LL and cmdline with earlyprintk console=ttyO.. works for me. On what platform? Like I said there are flags set statically in hmwod data for OMAP4 and OMAP5, which make it work without any hwmod tinkering in mach-omap2/serial.c. But it won't work for am33xx. For me omap4 sdp hangs during ttyO2 probe if earlyprintk is enabled for that port and console is enabled for that port. That's because we attempt to restore uninitialized context. It's possible that we have more than one bug here though. @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev) pm_runtime_mark_last_busy(up-dev); pm_runtime_put_autosuspend(up-dev); + up-initialized = true; This won't help as the context save for serial happens as part of set_termios() and not when the device is probed. The issue is that in serial probe we currently restore NULL context to the port which kills earlyprintk output until set_termios() is called. But as discussed, there are better ways for fixing this issue. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Boot hang regression 3.10.0-rc4 - 3.10.0
* Felipe Balbi ba...@ti.com [130710 09:18]: On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote: how about something like below ? It makes omap_device/hwmod and pm_runtime agree on the initial state of the device and will prevent -runtime_resume() from being called on first pm_runtime_get*() done during probe. This is similar to what PCI bus does (if you look at pci_pm_init()). commit 59108a500b4ab4b1a5102648a3360276dbf7df6f Author: Felipe Balbi ba...@ti.com Date: Wed Jul 10 18:50:16 2013 +0300 arm: omap2plus: unidle devices which are about to probe in order to make HWMOD and pm_runtime agree on the initial state of the device, we will unidle the device and call pm_runtime_set_active() to tell pm_runtime that the device is really active. By the time driver's probe() is reached, a call to pm_runtime_get_sync() will not cause driver's -runtime_resume() method to be called at first, only after a successful -runtime_suspend(). Signed-off-by: Felipe Balbi ba...@ti.com btw, this is RFC, haven't tested at all. Yes it does not compile, then removing the extra ; at the end of the functions, it oopses with a NULL pointer exception. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 00/13] ARM: OMAP2+: AM43x PRCM support
Hi, AM43x PRCM support (excluding clock tree) is being added with this series. AM43x reuses most of the IP's from AM335x, as that is the case, it was felt that reusing AM335x code as much as possible for AM43x is better - it also helps to keep LOC less. This RFC is being posted to get an early feedback on approach taken here mainly w.r.t reusing AM335x hwmod database for AM43x. Major reuse has been with hwmod database of AM335x, moving common elements to a new array and keeping separate arrays for elements that are specific only to either one of AM335x or AM43x. And in the cases where relevant IP is present in both that has difference in details like CLKCTRL register offsets, it is being updated at runtime based on the SoC detected. Powerdomain Clockdomain data has been added separately as it was not giving much advantage reusing AM335x ones (runtime updates required was getting too ugly). As AM43x PRCM is similar to OMAP4, OMAP4 power domain clock domain operations are being reused. This would have to be modified to have only the required domain operation fields, some thing like reusing Vaibhav Bedia's newly proposed domain operations for AM335x of [4] if [1] completely makes it to the mainline (that would require modifications to power and clock domain data fields of this series too), otherwise a similar domain operations would have to be added for AM43x. Also it has to be ensured that only relevant HWMOD operations are handled like in [4]. A single header file has been added to provide all AM43x PRCM defines. Here sequencewise, initially AM335x hwmod is modified to have it's fields get updated at runtime (wherever element is shared and has some difference with AM43x). Then power domain, clock domain for AM43x is added and finally AM335x hwmod database is updated with AM43x specifics. This series is being developed with additional clock tree changes that would be DT'fied. Additional DTS changes are also required for hwmod to get register target address space as most of AM335x hwmod address space details has been recently cleaned up and moved to DTS. Vaibhav Bedia's [2] [3] that are part of [1] has been used along with this series for validating. Regards Afzal [1] Consolidate AM335x and OMAP4 PRM/CM APIs - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg91511.html [2] [RFC 2/9] ARM: OMAP2+: CM code: Reintroduce SW_SLEEP for OMAP4 class of devices [3] [RFC 6/9] ARM: OMAP4: CM code: Remove the check for non-zero clkctrl_offs [4] [RFC 8/9] ARM: OMAP2+: AM335x: Migrate to OMAP4 PRM/CM APIs Afzal Mohammed (8): ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling ARM: OMAP2+: hwmod: AMx3: remove common static fields ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling ARM: OMAP2+: AM43x: PRCM kbuild ARM: OMAP2+: hwmod: type4 sysc ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x Ambresh K (4): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 arch/arm/mach-omap2/Makefile | 5 +- arch/arm/mach-omap2/clockdomain.h| 3 +- arch/arm/mach-omap2/clockdomains43xx_data.c | 199 +++ arch/arm/mach-omap2/cm33xx.c | 30 +- arch/arm/mach-omap2/cm33xx.h | 28 +- arch/arm/mach-omap2/cminst44xx.c | 29 +- arch/arm/mach-omap2/cminst44xx.h | 25 +- arch/arm/mach-omap2/io.c | 6 + arch/arm/mach-omap2/omap_hwmod.c | 2 +- arch/arm/mach-omap2/omap_hwmod.h | 5 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 850 --- arch/arm/mach-omap2/omap_hwmod_common_data.c | 6 + arch/arm/mach-omap2/powerdomain.h| 1 + arch/arm/mach-omap2/powerdomains43xx_data.c | 145 + arch/arm/mach-omap2/prcm43xx.h | 148 + 15 files changed, 1341 insertions(+), 141 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/prcm43xx.h -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 01/13] ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse
AM335x AM43x have most of the interconnects, IPs similar. Instead of
adding new hwmod data for AM43x, reuse AM335x hwmod data as much as
possible.
In the hwmod entries that could be reused on AM43x, major changes are
in register offsets and different ocpif clock for most of peripherals
that comes under l4_wkup interconnect.
To achieve reuse, as a first step, bring out ocpif's relevant for both
SoC's to a new array and handle appropriately.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 7a9b492..b0a38f0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -29,6 +29,7 @@
#include i2c.h
#include mmc.h
#include wd_timer.h
+#include soc.h
/*
* IP blocks
@@ -2458,6 +2459,13 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l3_main__emif,
+ am33xx_l4_hs__pruss,
+ am33xx_l3_main__lcdc,
+ am33xx_l3_s__usbss,
+ NULL,
+};
+
+static struct omap_hwmod_ocp_if *amx3xx_hwmod_ocp_ifs[] __initdata = {
am33xx_mpu__l3_main,
am33xx_mpu__prcm,
am33xx_l3_s__l4_ls,
@@ -2481,7 +2489,6 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
am33xx_l4_wkup__gpio0,
am33xx_l4_wkup__adc_tsc,
am33xx_l4_wkup__wd_timer1,
- am33xx_l4_hs__pruss,
am33xx_l4_per__dcan0,
am33xx_l4_per__dcan1,
am33xx_l4_per__gpio1,
@@ -2522,14 +2529,12 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
am33xx_epwmss2__eqep2,
am33xx_epwmss2__ehrpwm2,
am33xx_l3_s__gpmc,
- am33xx_l3_main__lcdc,
am33xx_l4_ls__mcspi0,
am33xx_l4_ls__mcspi1,
am33xx_l3_main__tptc0,
am33xx_l3_main__tptc1,
am33xx_l3_main__tptc2,
am33xx_l3_main__ocmc,
- am33xx_l3_s__usbss,
am33xx_l4_hs__cpgmac0,
am33xx_cpgmac0__mdio,
am33xx_l3_main__sha0,
@@ -2539,6 +2544,15 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
int __init am33xx_hwmod_init(void)
{
+ int ret;
+
omap_hwmod_init();
- return omap_hwmod_register_links(am33xx_hwmod_ocp_ifs);
+ ret = omap_hwmod_register_links(amx3xx_hwmod_ocp_ifs);
+ if (ret 0)
+ return ret;
+
+ if (soc_is_am33xx())
+ return omap_hwmod_register_links(am33xx_hwmod_ocp_ifs);
+
+ return 0;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 04/13] ARM: OMAP2+: CM: cm_inst offset s16-u16
From: Ankur Kishore a-kish...@ti.com
Most of the AM43x CM reg address offsets are with MSB bit '1' (on
16-bit value) leading to arithmetic miscalculations while calculating
CLOCK ENABLE register's address because cm_inst field was a type of
const s16, so make it const u16.
Also modify relevant functions so as to take care of the above.
Signed-off-by: Ankur Kishore a-kish...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/clockdomain.h | 2 +-
arch/arm/mach-omap2/cm33xx.c | 30 +++---
arch/arm/mach-omap2/cm33xx.h | 26 +-
arch/arm/mach-omap2/cminst44xx.c | 29 +++--
arch/arm/mach-omap2/cminst44xx.h | 25 +
5 files changed, 57 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index daeecf1..8c22ce6 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -132,7 +132,7 @@ struct clockdomain {
u8 _flags;
const u8 dep_bit;
const u8 prcm_partition;
- const s16 cm_inst;
+ const u16 cm_inst;
const u16 clkdm_offs;
struct clkdm_dep *wkdep_srcs;
struct clkdm_dep *sleepdep_srcs;
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 325a515..59f276d 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -48,13 +48,13 @@
/* Private functions */
/* Read a register in a CM instance */
-static inline u32 am33xx_cm_read_reg(s16 inst, u16 idx)
+static inline u32 am33xx_cm_read_reg(u16 inst, u16 idx)
{
return __raw_readl(cm_base + inst + idx);
}
/* Write into a register in a CM */
-static inline void am33xx_cm_write_reg(u32 val, s16 inst, u16 idx)
+static inline void am33xx_cm_write_reg(u32 val, u16 inst, u16 idx)
{
__raw_writel(val, cm_base + inst + idx);
}
@@ -82,7 +82,7 @@ static inline u32 am33xx_cm_clear_reg_bits(u32 bits, s16
inst, s16 idx)
return am33xx_cm_rmw_reg_bits(bits, 0x0, inst, idx);
}
-static inline u32 am33xx_cm_read_reg_bits(u16 inst, s16 idx, u32 mask)
+static inline u32 am33xx_cm_read_reg_bits(u16 inst, u16 idx, u32 mask)
{
u32 v;
@@ -102,7 +102,7 @@ static inline u32 am33xx_cm_read_reg_bits(u16 inst, s16
idx, u32 mask)
* Return the IDLEST bitfield of a CM_*_CLKCTRL register, shifted down to
* bit 0.
*/
-static u32 _clkctrl_idlest(u16 inst, s16 cdoffs, u16 clkctrl_offs)
+static u32 _clkctrl_idlest(u16 inst, u16 cdoffs, u16 clkctrl_offs)
{
u32 v = am33xx_cm_read_reg(inst, clkctrl_offs);
v = AM33XX_IDLEST_MASK;
@@ -119,7 +119,7 @@ static u32 _clkctrl_idlest(u16 inst, s16 cdoffs, u16
clkctrl_offs)
* Returns true if the module's CM_*_CLKCTRL.IDLEST bitfield is either
* *FUNCTIONAL or *INTERFACE_IDLE; false otherwise.
*/
-static bool _is_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
+static bool _is_module_ready(u16 inst, u16 cdoffs, u16 clkctrl_offs)
{
u32 v;
@@ -138,7 +138,7 @@ static bool _is_module_ready(u16 inst, s16 cdoffs, u16
clkctrl_offs)
* @c must be the unshifted value for CLKTRCTRL - i.e., this function
* will handle the shift itself.
*/
-static void _clktrctrl_write(u8 c, s16 inst, u16 cdoffs)
+static void _clktrctrl_write(u8 c, u16 inst, u16 cdoffs)
{
u32 v;
@@ -158,7 +158,7 @@ static void _clktrctrl_write(u8 c, s16 inst, u16 cdoffs)
* Returns true if the clockdomain referred to by (@inst, @cdoffs)
* is in hardware-supervised idle mode, or 0 otherwise.
*/
-bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs)
+bool am33xx_cm_is_clkdm_in_hwsup(u16 inst, u16 cdoffs)
{
u32 v;
@@ -177,7 +177,7 @@ bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs)
* Put a clockdomain referred to by (@inst, @cdoffs) into
* hardware-supervised idle mode. No return value.
*/
-void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_enable_hwsup(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_ENABLE_AUTO, inst, cdoffs);
}
@@ -191,7 +191,7 @@ void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs)
* software-supervised idle mode, i.e., controlled manually by the
* Linux OMAP clockdomain code. No return value.
*/
-void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, inst, cdoffs);
}
@@ -204,7 +204,7 @@ void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs)
* Put a clockdomain referred to by (@inst, @cdoffs) into idle
* No return value.
*/
-void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_SLEEP, inst, cdoffs);
}
@@ -217,7 +217,7 @@ void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs)
* Take a clockdomain referred to by (@inst, @cdoffs) out of
[PATCH RFC 02/13] ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling
Update AM335x CLKCTRL, RSTCTRL, RSTST offsets, clockdomain ocpif clk
that differ with AM43x at runtime. This is being done so that static
initialization of these details (which are different between AM335x
and AM43x) can be removed to aid in sharing of hwmod data between both
platforms as much as possible.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 118 +
1 file changed, 118 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index b0a38f0..57234a0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2457,6 +2457,115 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+#define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
+
+static void am33xx_hwmod_clkctrl(void)
+{
+ CLKCTRL(am33xx_uart2_hwmod, AM33XX_CM_PER_UART1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart3_hwmod, AM33XX_CM_PER_UART2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart4_hwmod, AM33XX_CM_PER_UART3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart5_hwmod, AM33XX_CM_PER_UART4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart6_hwmod, AM33XX_CM_PER_UART5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan0_hwmod, AM33XX_CM_PER_DCAN0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan1_hwmod, AM33XX_CM_PER_DCAN1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_elm_hwmod, AM33XX_CM_PER_ELM_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss0_hwmod, AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss1_hwmod, AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss2_hwmod, AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio1_hwmod, AM33XX_CM_PER_GPIO1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio2_hwmod, AM33XX_CM_PER_GPIO2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio3_hwmod, AM33XX_CM_PER_GPIO3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c2_hwmod, AM33XX_CM_PER_I2C1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c3_hwmod, AM33XX_CM_PER_I2C2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mailbox_hwmod, AM33XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp0_hwmod, AM33XX_CM_PER_MCASP0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp1_hwmod, AM33XX_CM_PER_MCASP1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc0_hwmod, AM33XX_CM_PER_MMC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc1_hwmod, AM33XX_CM_PER_MMC1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi0_hwmod, AM33XX_CM_PER_SPI0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi1_hwmod, AM33XX_CM_PER_SPI1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spinlock_hwmod, AM33XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer2_hwmod, AM33XX_CM_PER_TIMER2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer3_hwmod, AM33XX_CM_PER_TIMER3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer4_hwmod, AM33XX_CM_PER_TIMER4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer5_hwmod, AM33XX_CM_PER_TIMER5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer6_hwmod, AM33XX_CM_PER_TIMER6_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer7_hwmod, AM33XX_CM_PER_TIMER7_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_wkup_m3_hwmod, AM33XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_control_hwmod, AM33XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_smartreflex0_hwmod,
+ AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_smartreflex1_hwmod,
+ AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart1_hwmod, AM33XX_CM_WKUP_UART0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer1_hwmod, AM33XX_CM_WKUP_TIMER1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c1_hwmod, AM33XX_CM_WKUP_I2C0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio0_hwmod, AM33XX_CM_WKUP_GPIO0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_adc_tsc_hwmod, AM33XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_wd_timer1_hwmod, AM33XX_CM_WKUP_WDT1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_rtc_hwmod, AM33XX_CM_RTC_RTC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc2_hwmod, AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpmc_hwmod, AM33XX_CM_PER_GPMC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_ls_hwmod, AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_wkup_hwmod, AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l3_main_hwmod, AM33XX_CM_PER_L3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_tpcc_hwmod, AM33XX_CM_PER_TPCC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_tptc0_hwmod, AM33XX_CM_PER_TPTC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_tptc1_hwmod, AM33XX_CM_PER_TPTC1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_tptc2_hwmod, AM33XX_CM_PER_TPTC2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gfx_hwmod, AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_hs_hwmod, AM33XX_CM_PER_L4HS_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_cpgmac0_hwmod, AM33XX_CM_PER_CPGMAC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_pruss_hwmod,
[PATCH RFC 05/13] ARM: OMAP2+: PRCM: AM43x definitions
Add AM43x CMINST, CDOFFS, RM_RSTST RM_RSTCTRL definitions - minimal ones that would be used. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/prcm43xx.h | 148 + 1 file changed, 148 insertions(+) create mode 100644 arch/arm/mach-omap2/prcm43xx.h diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h new file mode 100644 index 000..0d05278 --- /dev/null +++ b/arch/arm/mach-omap2/prcm43xx.h @@ -0,0 +1,148 @@ +/* + * AM43x PRCM defines + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed as is without any warranty of any + * kind, whether express or implied. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRCM_43XX_H +#define __ARCH_ARM_MACH_OMAP2_PRCM_43XX_H + +#define AM43XX_PRM_PARTITION 1 +#define AM43XX_CM_PARTITION1 + +/* PRM instances */ +#define AM43XX_PRM_OCP_SOCKET_INST 0x +#define AM43XX_PRM_MPU_INST0x0300 +#define AM43XX_PRM_GFX_INST0x0400 +#define AM43XX_PRM_RTC_INST0x0500 +#define AM43XX_PRM_TAMPER_INST 0x0600 +#define AM43XX_PRM_CEFUSE_INST 0x0700 +#define AM43XX_PRM_PER_INST0x0800 +#define AM43XX_PRM_WKUP_INST 0x2000 +#define AM43XX_PRM_DEVICE_INST 0x4000 + +/* RM RSTCTRL offsets */ +#defineAM43XX_RM_PER_RSTCTRL_OFFSET0x0010 +#defineAM43XX_RM_GFX_RSTCTRL_OFFSET0x0010 +#defineAM43XX_RM_WKUP_RSTCTRL_OFFSET 0x0010 + +/* RM RSTST offsets */ +#defineAM43XX_RM_GFX_RSTST_OFFSET 0x0014 +#defineAM43XX_RM_WKUP_RSTST_OFFSET 0x0014 + +/* CM instances */ +#define AM43XX_CM_WKUP_INST0x2800 +#define AM43XX_CM_DEVICE_INST 0x4100 +#define AM43XX_CM_DPLL_INST0x4200 +#define AM43XX_CM_MPU_INST 0x8300 +#define AM43XX_CM_GFX_INST 0x8400 +#define AM43XX_CM_RTC_INST 0x8500 +#define AM43XX_CM_TAMPER_INST 0x8600 +#define AM43XX_CM_CEFUSE_INST 0x8700 +#define AM43XX_CM_PER_INST 0x8800 + +/* CD offsets */ +#define AM43XX_CM_WKUP_L3_AON_CDOFFS 0x +#define AM43XX_CM_WKUP_L3S_TSC_CDOFFS 0x0100 +#define AM43XX_CM_WKUP_L4_WKUP_AON_CDOFFS 0x0200 +#define AM43XX_CM_WKUP_WKUP_CDOFFS 0x0300 +#define AM43XX_CM_MPU_MPU_CDOFFS 0x +#define AM43XX_CM_GFX_GFX_L3_CDOFFS0x +#define AM43XX_CM_RTC_RTC_CDOFFS 0x +#define AM43XX_CM_TAMPER_TAMPER_CDOFFS 0x +#define AM43XX_CM_CEFUSE_CEFUSE_CDOFFS 0x +#define AM43XX_CM_PER_L3_CDOFFS0x +#define AM43XX_CM_PER_L3S_CDOFFS 0x0200 +#define AM43XX_CM_PER_ICSS_CDOFFS 0x0300 +#define AM43XX_CM_PER_L4LS_CDOFFS 0x0400 +#define AM43XX_CM_PER_EMIF_CDOFFS 0x0700 +#define AM43XX_CM_PER_LCDC_CDOFFS 0x0800 +#define AM43XX_CM_PER_DSS_CDOFFS 0x0a00 +#define AM43XX_CM_PER_CPSW_CDOFFS 0x0b00 +#define AM43XX_CM_PER_OCPWP_L3_CDOFFS 0x0c00 + +/* CLK CTRL offsets */ +#defineAM43XX_CM_PER_UART1_CLKCTRL_OFFSET 0x0580 +#defineAM43XX_CM_PER_UART2_CLKCTRL_OFFSET 0x0588 +#defineAM43XX_CM_PER_UART3_CLKCTRL_OFFSET 0x0590 +#defineAM43XX_CM_PER_UART4_CLKCTRL_OFFSET 0x0598 +#defineAM43XX_CM_PER_UART5_CLKCTRL_OFFSET 0x05a0 +#defineAM43XX_CM_PER_DCAN0_CLKCTRL_OFFSET 0x0428 +#defineAM43XX_CM_PER_DCAN1_CLKCTRL_OFFSET 0x0430 +#defineAM43XX_CM_PER_ELM_CLKCTRL_OFFSET0x0468 +#defineAM43XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET0x0438 +#defineAM43XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET0x0440 +#defineAM43XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET0x0448 +#defineAM43XX_CM_PER_GPIO1_CLKCTRL_OFFSET 0x0478 +#defineAM43XX_CM_PER_GPIO2_CLKCTRL_OFFSET 0x0480 +#defineAM43XX_CM_PER_GPIO3_CLKCTRL_OFFSET 0x0488 +#defineAM43XX_CM_PER_I2C1_CLKCTRL_OFFSET 0x04a8 +#defineAM43XX_CM_PER_I2C2_CLKCTRL_OFFSET 0x04b0 +#defineAM43XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET 0x04b8 +#defineAM43XX_CM_PER_MMC0_CLKCTRL_OFFSET 0x04c0 +#defineAM43XX_CM_PER_MMC1_CLKCTRL_OFFSET 0x04c8 +#defineAM43XX_CM_PER_SPI0_CLKCTRL_OFFSET 0x0500 +#defineAM43XX_CM_PER_SPI1_CLKCTRL_OFFSET 0x0508 +#defineAM43XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET 0x0528 +#defineAM43XX_CM_PER_TIMER2_CLKCTRL_OFFSET 0x0530 +#defineAM43XX_CM_PER_TIMER3_CLKCTRL_OFFSET 0x0538 +#defineAM43XX_CM_PER_TIMER4_CLKCTRL_OFFSET 0x0540 +#define
[PATCH RFC 03/13] ARM: OMAP2+: hwmod: AMx3: remove common static fields
Hwmod common to AM43x AM335x has some of fields different (CLKCTRL,
RSTCTRL, RSTST, ocpif clk and clockdomain). It is now updated based
on SoC detection at run time, hence remove statically initialized
entries.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 79 --
1 file changed, 79 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 57234a0..a61032d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -79,7 +79,6 @@ static struct omap_hwmod am33xx_l3_main_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L3_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -101,7 +100,6 @@ static struct omap_hwmod am33xx_l3_instr_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -124,7 +122,6 @@ static struct omap_hwmod am33xx_l4_ls_hwmod = {
.main_clk = l4ls_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -134,12 +131,10 @@ static struct omap_hwmod am33xx_l4_ls_hwmod = {
static struct omap_hwmod am33xx_l4_hs_hwmod = {
.name = l4_hs,
.class = am33xx_l4_hwmod_class,
- .clkdm_name = l4hs_clkdm,
.flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
.main_clk = l4hs_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L4HS_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -154,7 +149,6 @@ static struct omap_hwmod am33xx_l4_wkup_hwmod = {
.flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -175,7 +169,6 @@ static struct omap_hwmod am33xx_mpu_hwmod = {
.main_clk = dpll_mpu_m2_ck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_MPU_MPU_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -200,12 +193,8 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.clkdm_name = l4_wkup_aon_clkdm,
/* Keep hardreset asserted */
.flags = HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
- .main_clk = dpll_core_m4_div2_ck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET,
- .rstctrl_offs = AM33XX_RM_WKUP_RSTCTRL_OFFSET,
- .rstst_offs = AM33XX_RM_WKUP_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -234,8 +223,6 @@ static struct omap_hwmod am33xx_pruss_hwmod = {
.main_clk = pruss_ocp_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_PRUSS_CLKCTRL_OFFSET,
- .rstctrl_offs = AM33XX_RM_PER_RSTCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -260,9 +247,6 @@ static struct omap_hwmod am33xx_gfx_hwmod = {
.main_clk = gfx_fck_div_ck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET,
- .rstctrl_offs = AM33XX_RM_GFX_RSTCTRL_OFFSET,
- .rstst_offs = AM33XX_RM_GFX_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -306,11 +290,9 @@ static struct omap_hwmod_class am33xx_adc_tsc_hwmod_class
= {
static struct omap_hwmod am33xx_adc_tsc_hwmod = {
.name = adc_tsc,
.class = am33xx_adc_tsc_hwmod_class,
- .clkdm_name = l4_wkup_clkdm,
.main_clk = adc_tsc_fck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -432,7 +414,6 @@ static struct omap_hwmod am33xx_aes0_hwmod = {
.main_clk
[PATCH RFC 06/13] ARM: OMAP2+: PM: AM43x powerdomain data
From: Ambresh K ambr...@ti.com
Add the data file to describe all power domains in AM43x SoC.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Note: domain operations to be used would have to modified as mentioned in
the cover letter
arch/arm/mach-omap2/powerdomain.h | 1 +
arch/arm/mach-omap2/powerdomains43xx_data.c | 145
2 files changed, 146 insertions(+)
create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index e4d7bd6..56ad9f5 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -254,6 +254,7 @@ extern void omap242x_powerdomains_init(void);
extern void omap243x_powerdomains_init(void);
extern void omap3xxx_powerdomains_init(void);
extern void am33xx_powerdomains_init(void);
+extern void am43xx_powerdomains_init(void);
extern void omap44xx_powerdomains_init(void);
extern void omap54xx_powerdomains_init(void);
diff --git a/arch/arm/mach-omap2/powerdomains43xx_data.c
b/arch/arm/mach-omap2/powerdomains43xx_data.c
new file mode 100644
index 000..35d8dbb
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains43xx_data.c
@@ -0,0 +1,145 @@
+/*
+ * AM43xx Power domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This file is made by modifying the file generated automatically
+ * from the OMAP hardware databases.
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+
+#include powerdomain.h
+
+#include prcm-common.h
+#include prcm44xx.h
+#include prcm43xx.h
+
+static struct powerdomain gfx_43xx_pwrdm = {
+ .name = gfx_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_GFX_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_ON,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* gfx_mem */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* gfx_mem */
+ },
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain mpu_43xx_pwrdm = {
+ .name = mpu_pwrdm,
+ .voltdm = { .name = mpu },
+ .prcm_offs= AM43XX_PRM_MPU_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .banks= 3,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* mpu_l1 */
+ [1] = PWRSTS_OFF_RET, /* mpu_l2 */
+ [2] = PWRSTS_OFF_RET, /* mpu_ram */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* mpu_l1 */
+ [1] = PWRSTS_ON,/* mpu_l2 */
+ [2] = PWRSTS_ON,/* mpu_ram */
+ },
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain rtc_43xx_pwrdm = {
+ .name = rtc_pwrdm,
+ .voltdm = { .name = rtc },
+ .prcm_offs= AM43XX_PRM_RTC_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+};
+
+static struct powerdomain wkup_43xx_pwrdm = {
+ .name = wkup_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_WKUP_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF, /* debugss_mem */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* debugss_mem */
+ },
+};
+
+static struct powerdomain tamper_43xx_pwrdm = {
+ .name = tamper_pwrdm,
+ .voltdm = { .name = tamper },
+ .prcm_offs= AM43XX_PRM_TAMPER_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+};
+
+static struct powerdomain cefuse_43xx_pwrdm = {
+ .name = cefuse_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_CEFUSE_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_ON,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain per_43xx_pwrdm = {
+ .name = per_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_PER_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .banks= 4,
+ .pwrsts_mem_ret = {
+
[PATCH RFC 09/13] ARM: OMAP2+: hwmod: AM43x operations
From: Ambresh K ambr...@ti.com
Reuse OMAP4 operations on AM43x.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Note: This may have to modified as mentioned in the cover letter.
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 7f4db12..0df6353 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4113,7 +4113,7 @@ void __init omap_hwmod_init(void)
soc_ops.assert_hardreset = _omap2_assert_hardreset;
soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
- } else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+ } else if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_am43xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 08/13] ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling
Update AM43x CLKCTRL, RSTCTRL, RSTST offsets, clockdomain ocpif clk
that differ with AM335x at runtime. This helps in resuing much of the
AM335x hwmod data's for AM43x.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 110 +
1 file changed, 110 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index a61032d..7897fec 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -26,6 +26,7 @@
#include cm33xx.h
#include prm33xx.h
#include prm-regbits-33xx.h
+#include prcm43xx.h
#include i2c.h
#include mmc.h
#include wd_timer.h
@@ -2380,6 +2381,71 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
#define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
+static void am43xx_hwmod_clkctrl(void)
+{
+ CLKCTRL(am33xx_uart2_hwmod, AM43XX_CM_PER_UART1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart3_hwmod, AM43XX_CM_PER_UART2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart4_hwmod, AM43XX_CM_PER_UART3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart5_hwmod, AM43XX_CM_PER_UART4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart6_hwmod, AM43XX_CM_PER_UART5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan0_hwmod, AM43XX_CM_PER_DCAN0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan1_hwmod, AM43XX_CM_PER_DCAN1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_elm_hwmod, AM43XX_CM_PER_ELM_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss0_hwmod, AM43XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss1_hwmod, AM43XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss2_hwmod, AM43XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio1_hwmod, AM43XX_CM_PER_GPIO1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio2_hwmod, AM43XX_CM_PER_GPIO2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio3_hwmod, AM43XX_CM_PER_GPIO3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c2_hwmod, AM43XX_CM_PER_I2C1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c3_hwmod, AM43XX_CM_PER_I2C2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mailbox_hwmod, AM43XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc0_hwmod, AM43XX_CM_PER_MMC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc1_hwmod, AM43XX_CM_PER_MMC1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi0_hwmod, AM43XX_CM_PER_SPI0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi1_hwmod, AM43XX_CM_PER_SPI1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spinlock_hwmod, AM43XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer2_hwmod, AM43XX_CM_PER_TIMER2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer3_hwmod, AM43XX_CM_PER_TIMER3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer4_hwmod, AM43XX_CM_PER_TIMER4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer5_hwmod, AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer6_hwmod, AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer7_hwmod, AM43XX_CM_PER_TIMER7_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_wkup_m3_hwmod, AM43XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_control_hwmod, AM43XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_smartreflex0_hwmod,
+ AM43XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_smartreflex1_hwmod,
+ AM43XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart1_hwmod, AM43XX_CM_WKUP_UART0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer1_hwmod, AM43XX_CM_WKUP_TIMER1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c1_hwmod, AM43XX_CM_WKUP_I2C0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio0_hwmod, AM43XX_CM_WKUP_GPIO0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_adc_tsc_hwmod, AM43XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_wd_timer1_hwmod, AM43XX_CM_WKUP_WDT1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_wkup_hwmod, AM43XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_rtc_hwmod, AM43XX_CM_RTC_RTC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc2_hwmod, AM43XX_CM_PER_MMC2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpmc_hwmod, AM43XX_CM_PER_GPMC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp0_hwmod, AM43XX_CM_PER_MCASP0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp1_hwmod, AM43XX_CM_PER_MCASP1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_ls_hwmod, AM43XX_CM_PER_L4LS_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l3_main_hwmod, AM43XX_CM_PER_L3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_tpcc_hwmod, AM43XX_CM_PER_TPCC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_tptc0_hwmod, AM43XX_CM_PER_TPTC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_tptc1_hwmod, AM43XX_CM_PER_TPTC1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_tptc2_hwmod, AM43XX_CM_PER_TPTC2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_cpgmac0_hwmod, AM43XX_CM_PER_CPGMAC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_pruss_hwmod, AM43XX_CM_PER_PRUSS_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gfx_hwmod, AM43XX_CM_GFX_GFX_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_hs_hwmod, AM43XX_CM_PER_L4HS_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mpu_hwmod
[PATCH RFC 11/13] ARM: OMAP2+: AM43x PRCM init
From: Ambresh K ambr...@ti.com Initialise AM43x HWMOD, powerdomains and clockdomains. Signed-off-by: Ambresh K ambr...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/io.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 7325ba6..901acf6 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -594,8 +594,14 @@ void __init am43xx_init_early(void) NULL); omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE)); omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE), NULL); + omap_prm_base_init(); + omap_cm_base_init(); omap3xxx_check_revision(); am33xx_check_features(); + am43xx_powerdomains_init(); + am43xx_clockdomains_init(); + am33xx_hwmod_init(); + omap_hwmod_init_postsetup(); } #endif -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 07/13] ARM: OMAP2+: CM: AM43x clockdomain data
From: Ambresh K ambr...@ti.com
Add the data file to describe clock domains in AM43x SoC.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Note: domain operations to be used would have to modified as mentioned in
the cover letter
arch/arm/mach-omap2/clockdomain.h | 1 +
arch/arm/mach-omap2/clockdomains43xx_data.c | 199
2 files changed, 200 insertions(+)
create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 8c22ce6..3b61557 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -215,6 +215,7 @@ extern void __init omap242x_clockdomains_init(void);
extern void __init omap243x_clockdomains_init(void);
extern void __init omap3xxx_clockdomains_init(void);
extern void __init am33xx_clockdomains_init(void);
+extern void am43xx_clockdomains_init(void);
extern void __init omap44xx_clockdomains_init(void);
extern void __init omap54xx_clockdomains_init(void);
diff --git a/arch/arm/mach-omap2/clockdomains43xx_data.c
b/arch/arm/mach-omap2/clockdomains43xx_data.c
new file mode 100644
index 000..5ddc010
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains43xx_data.c
@@ -0,0 +1,199 @@
+/*
+ * AM43xx Clock domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This file is made by modifying the file generated automatically
+ * from the OMAP hardware databases.
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/io.h
+
+#include clockdomain.h
+#include prcm44xx.h
+#include prcm43xx.h
+
+static struct clockdomain l4_cefuse_43xx_clkdm = {
+ .name = l4_cefuse_clkdm,
+ .pwrdm= { .name = cefuse_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_CEFUSE_INST,
+ .clkdm_offs = AM43XX_CM_CEFUSE_CEFUSE_CDOFFS,
+ .flags= CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain mpu_43xx_clkdm = {
+ .name = mpu_clkdm,
+ .pwrdm= { .name = mpu_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_MPU_INST,
+ .clkdm_offs = AM43XX_CM_MPU_MPU_CDOFFS,
+ .flags= CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l4ls_43xx_clkdm = {
+ .name = l4ls_clkdm,
+ .pwrdm= { .name = per_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_PER_INST,
+ .clkdm_offs = AM43XX_CM_PER_L4LS_CDOFFS,
+ .flags= CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain tamper_43xx_clkdm = {
+ .name = tamper_clkdm,
+ .pwrdm= { .name = tamper_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_TAMPER_INST,
+ .clkdm_offs = AM43XX_CM_TAMPER_TAMPER_CDOFFS,
+ .flags= CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain l4_rtc_43xx_clkdm = {
+ .name = l4_rtc_clkdm,
+ .pwrdm= { .name = rtc_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_RTC_INST,
+ .clkdm_offs = AM43XX_CM_RTC_RTC_CDOFFS,
+ .flags= CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain pruss_ocp_43xx_clkdm = {
+ .name = pruss_ocp_clkdm,
+ .pwrdm= { .name = per_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_PER_INST,
+ .clkdm_offs = AM43XX_CM_PER_ICSS_CDOFFS,
+ .flags= CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain ocpwp_l3_43xx_clkdm = {
+ .name = ocpwp_l3_clkdm,
+ .pwrdm= { .name = per_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_PER_INST,
+ .clkdm_offs = AM43XX_CM_PER_OCPWP_L3_CDOFFS,
+ .flags= CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain l3s_tsc_43xx_clkdm = {
+ .name = l3s_tsc_clkdm,
+ .pwrdm= { .name = wkup_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_WKUP_INST,
+ .clkdm_offs = AM43XX_CM_WKUP_L3S_TSC_CDOFFS,
+ .flags= CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain dss_43xx_clkdm = {
+ .name = dss_clkdm,
+ .pwrdm= { .name = per_pwrdm },
[PATCH RFC 10/13] ARM: OMAP2+: AM43x: PRCM kbuild
Build AM43x power domain, clock domain and hwmod data. Many of AM43x IP's and interconnects are similar as that in AM335x, hence AM335x hwmod data is being reused with necessary changes. Earlier the plan was to reuse AM335x specific PRCM code, but as AM43x PRCM is much similar to OMAP4/5, AM335x PRCM is divorced and instead married with OMAP4/5 PRCM for AM43x. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/Makefile | 5 - arch/arm/mach-omap2/cm33xx.h | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index ea5a27f..647acae 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -112,12 +112,12 @@ obj-$(CONFIG_ARCH_OMAP2) += prm2xxx_3xxx.o prm2xxx.o cm2xxx.o obj-$(CONFIG_ARCH_OMAP3) += prm2xxx_3xxx.o prm3xxx.o cm3xxx.o obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o obj-$(CONFIG_SOC_AM33XX) += prm33xx.o cm33xx.o -obj-$(CONFIG_SOC_AM43XX) += prm33xx.o cm33xx.o omap-prcm-4-5-common = cminst44xx.o cm44xx.o prm44xx.o \ prcm_mpu44xx.o prminst44xx.o \ vc44xx_data.o vp44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common) +obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -145,6 +145,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= powerdomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common) obj-$(CONFIG_SOC_AM33XX) += powerdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(powerdomain-common) +obj-$(CONFIG_SOC_AM43XX) += powerdomains43xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(powerdomain-common) obj-$(CONFIG_SOC_OMAP5)+= powerdomains54xx_data.o @@ -162,6 +163,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= clockdomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common) obj-$(CONFIG_SOC_AM33XX) += clockdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(clockdomain-common) +obj-$(CONFIG_SOC_AM43XX) += clockdomains43xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clockdomain-common) obj-$(CONFIG_SOC_OMAP5)+= clockdomains54xx_data.o @@ -205,6 +207,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= omap_hwmod_2xxx_3xxx_ipblock_data.o obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_2xxx_3xxx_interconnect_data.o obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_data.o +obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_data.o obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h index 201e507..757b9a1 100644 --- a/arch/arm/mach-omap2/cm33xx.h +++ b/arch/arm/mach-omap2/cm33xx.h @@ -383,7 +383,7 @@ extern void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs); extern void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs); extern void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs); -#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX) +#ifdef CONFIG_SOC_AM33XX extern int am33xx_cm_wait_module_idle(u16 inst, u16 cdoffs, u16 clkctrl_offs); extern void am33xx_cm_module_enable(u8 mode, u16 inst, u16 cdoffs, -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 12/13] ARM: OMAP2+: hwmod: type4 sysc
AM43x PKA module has sysconfig bitmap different from that of the
existing available types, hence add a new one.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h | 5 +
arch/arm/mach-omap2/omap_hwmod_common_data.c | 6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 29f7687..a743358 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -41,6 +41,7 @@ struct omap_device;
extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type1;
extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2;
extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
+extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4;
/*
* OCP SYSCONFIG bit shifts/masks TYPE1. These are for IPs compliant
@@ -81,6 +82,10 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
#define SYSC_TYPE3_MIDLEMODE_SHIFT 2
#define SYSC_TYPE3_MIDLEMODE_MASK (0x3 SYSC_TYPE3_MIDLEMODE_SHIFT)
+#define SYSC_TYPE4_SIDLEMODE_SHIFT 4
+#define SYSC_TYPE4_SOFTRESET_SHIFT 1
+#define SYSC_TYPE4_AUTOIDLE_SHIFT 0
+
/* OCP SYSSTATUS bit shifts/masks */
#define SYSS_RESETDONE_SHIFT 0
#define SYSS_RESETDONE_MASK(1 SYSS_RESETDONE_SHIFT)
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c
b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 79d623b..238c2c1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -59,6 +59,12 @@ struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3 = {
.sidle_shift= SYSC_TYPE3_SIDLEMODE_SHIFT,
};
+struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4 = {
+ .sidle_shift= SYSC_TYPE4_SIDLEMODE_SHIFT,
+ .srst_shift = SYSC_TYPE4_SOFTRESET_SHIFT,
+ .autoidle_shift = SYSC_TYPE4_AUTOIDLE_SHIFT,
+};
+
struct omap_dss_dispc_dev_attr omap2_3_dss_dispc_dev_attr = {
.manager_count = 2,
.has_framedonetv_irq= 0
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 13/13] ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x
AM43x has a few IP's that are not present in AM335x,
1. qspi
2. hdq1w
3. vpfe (two instances)
4. pka
5. des
6. rng
7. synctimer
In addition it has a few new instances of existing IP's,
1. timer8-11
2. ehrpwm3-5
3. spi2-4
Also a different pruss interconnect.
Update hwmod with the above details and register 'ocpif' if platform
being run is AM43x.
TODO:
1. usb
2. dss
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 525 -
1 file changed, 523 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 7897fec..319780e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -30,6 +30,7 @@
#include i2c.h
#include mmc.h
#include wd_timer.h
+#include hdq1w.h
#include soc.h
/*
@@ -1595,6 +1596,346 @@ static struct omap_hwmod am33xx_usbss_hwmod = {
},
};
+static struct omap_hwmod_class_sysconfig am43xx_qspi_sysc = {
+ .sysc_offs = 0x10,
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class am43xx_qspi_hwmod_class = {
+ .name = qspi,
+ .sysc = am43xx_qspi_sysc,
+};
+
+static struct omap_hwmod am43xx_qspi_hwmod = {
+ .name = qspi,
+ .class = am43xx_qspi_hwmod_class,
+ .clkdm_name = l3s_clkdm,
+ .main_clk = dpll_per_m2_div4_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_QSPI_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_hdq1w_sysc = {
+ .sysc_offs = 0x14,
+ .syss_offs = 0x18,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_hdq1w_hwmod_class = {
+ .name = hdq1w,
+ .sysc = am43xx_hdq1w_sysc,
+ .reset = omap_hdq1w_reset,
+};
+
+static struct omap_hwmod am43xx_hdq1w_hwmod = {
+ .name = hdq1w,
+ .class = am43xx_hdq1w_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .main_clk = func_12m_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_vpfe_sysc = {
+ .sysc_offs = 0x104,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class am43xx_vpfe_hwmod_class = {
+ .name = vpfe,
+ .sysc = am43xx_vpfe_sysc,
+};
+
+static struct omap_hwmod am43xx_vpfe0_hwmod = {
+ .name = vpfe0,
+ .class = am43xx_vpfe_hwmod_class,
+ .clkdm_name = l3_clkdm,
+ .main_clk = sysclk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+static struct omap_hwmod am43xx_vpfe1_hwmod = {
+ .name = vpfe1,
+ .class = am43xx_vpfe_hwmod_class,
+ .clkdm_name = l3_clkdm,
+ .main_clk = sysclk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_pka_sysc = {
+ .rev_offs = 0x1fe0,
+ .sysc_offs = 0x1ff0,
+ .syss_offs = 0x1ff4,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO),
+ .sysc_fields= omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class am43xx_pka_hwmod_class = {
+ .name = pka,
+ .sysc = am43xx_pka_sysc,
+};
+
+static struct omap_hwmod am43xx_pka_hwmod = {
+ .name = pka,
+ .class = am43xx_pka_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
RE: [PATCH RFC 13/13] ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x
4. pka 5. des 6. Rng Needs some re-wording.. PKA, DES, RNG are there on AM335x silicon. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] USB: Support wakeup IRQ for suspended controllers
On 07/10/2013 09:45 PM, Alan Stern wrote:
On Wed, 10 Jul 2013, Roger Quadros wrote:
Some platforms e.g. ehci-omap can generate an interrupt
(i.e. remote wakeup) even when the controller is suspended i.e.
HW_ACCESSIBLE is cleared.
Introduce a flag has_wakeup_irq in struct usb_hcd to indicate
such cases.
We tackle this case by disabling the IRQ, scheduling a
hub resume and enabling back the IRQ after the controller has
resumed. This ensures that the IRQ handler runs only after the
controller is accessible.
@@ -2248,7 +2253,21 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
*/
local_irq_save(flags);
-if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
+if (unlikely(HCD_DEAD(hcd)))
+rc = IRQ_NONE;
+else if (unlikely(!HCD_HW_ACCESSIBLE(hcd) hcd-has_wakeup_irq)) {
+/*
+ * We got a wakeup interrupt while the controller was
+ * suspending or suspended. We can't handle it now, so
+ * disable the IRQ and resume the root hub (and hence
+ * the controller too).
+ */
+disable_irq_nosync(hcd-irq);
+set_bit(HCD_FLAG_IRQ_DISABLED, hcd-flags);
+usb_hcd_resume_root_hub(hcd);
+
+rc = IRQ_HANDLED;
+} else if (unlikely(!HCD_HW_ACCESSIBLE(hcd)))
rc = IRQ_NONE;
In the interest of minimizing the amount of work needed in the most
common case, this should be written as:
else if (unlikely(!HCD_HW_ACCESSIBLE(hcd))) {
if (hcd-has_wakeup_irq) {
...
} else
rc = IRQ_NONE;
OK.
else if (hcd-driver-irq(hcd) == IRQ_NONE)
rc = IRQ_NONE;
Apart from that, the patch is okay. When you rearrange the logic, you
can add my Acked-by.
Thanks.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] USB: Support wakeup IRQ for suspended controllers
On 07/10/2013 10:08 PM, Alan Stern wrote:
On Wed, 10 Jul 2013, Roger Quadros wrote:
Some platforms e.g. ehci-omap can generate an interrupt
(i.e. remote wakeup) even when the controller is suspended i.e.
HW_ACCESSIBLE is cleared.
Introduce a flag has_wakeup_irq in struct usb_hcd to indicate
such cases.
We tackle this case by disabling the IRQ, scheduling a
hub resume and enabling back the IRQ after the controller has
resumed. This ensures that the IRQ handler runs only after the
controller is accessible.
Oh yes, one more thing...
@@ -132,6 +134,7 @@ struct usb_hcd {
unsignedwireless:1; /* Wireless USB HCD */
unsignedauthorized_default:1;
unsignedhas_tt:1; /* Integrated TT in root hub */
+unsignedhas_wakeup_irq:1; /* Can IRQ when suspended */
Please add a highly visible comment here, warning that has_wakeup_irq
should never be set on systems with shared IRQs. Having both would ...
well, it would indicate a really bad system design.
OK, will do.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe 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] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet
Hi,
On Wednesday 10 July 2013 06:38 PM, Pali Rohár wrote:
* On RX-51 probing for acx565akm driver is later then for omapfb which cause
that omapfb probe fail and framebuffer is not working
* EPROBE_DEFER causing that kernel try to probe for omapfb later again which
fixing this problem
* Without this patch display on Nokia RX-51 (N900) phone not working
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
drivers/video/omap2/omapfb/omapfb-main.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 856917b..93e7c84 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2419,6 +2419,15 @@ static int omapfb_probe(struct platform_device *pdev)
if (omapdss_is_initialized() == false)
return -EPROBE_DEFER;
+ dssdev = NULL;
+ for_each_dss_dev(dssdev) {
+ if (!dssdev-driver) {
+ dev_warn(pdev-dev, no driver for display: %s\n,
+ dssdev-name);
+ return -EPROBE_DEFER;
This will make omapfb probe defer till the time every panel has a
driver. It's possible that all the panel driver modules are never
interested by userspace. This will lead to the panels having drivers
also not work.
I think Tomi was working on this, it was something like making omapfb
defer only if the default display doesn't have a driver. We can wait for
his comment.
Archit
+ }
+ }
+
if (pdev-num_resources != 0) {
dev_err(pdev-dev, probed for an unknown device\n);
r = -ENODEV;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
On 07/10/2013 10:04 PM, Alan Stern wrote:
On Wed, 10 Jul 2013, Roger Quadros wrote:
Call ehci_suspend/resume() during runtime suspend/resume
as well as system suspend/resume.
Use a flag bound to indicate that the HCD structures are valid.
This is only true between usb_add_hcd() and usb_remove_hcd() calls.
The flag can be used by omap_ehci_runtime_suspend/resume() handlers
to avoid calling ehci_suspend/resume() when we are no longer bound
to the HCD e.g. during probe() and remove();
@@ -293,15 +301,67 @@ static const struct of_device_id omap_ehci_dt_ids[] = {
MODULE_DEVICE_TABLE(of, omap_ehci_dt_ids);
+static int omap_ehci_suspend(struct device *dev)
+{
+struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+dev_dbg(dev, %s\n, __func__);
+
+return ehci_suspend(hcd, true);
+}
+
+static int omap_ehci_resume(struct device *dev)
+{
+struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+dev_dbg(dev, %s\n, __func__);
+
+return ehci_resume(hcd, false);
+}
There are three problems here. The first is very simple: the wakeup
settings are messed up. Wakeup is supposed to be enabled always for
runtime suspend, whereas it is controlled by device_may_wakeup() for
system suspend. You reversed them.
Indeed. I'll fix that up.
However, even if wakeup is disabled during system suspend, the OMAP will
still wakeup on any activity on the USB pins.
The only way to disable that is to disable IO pad wakeup. This can
only be done in mfd/omap-usb-host.c
I suppose I can use device_may_wakeup() there and configure the IO pad
wakeup accordingly.
The other two problems are both related to the interaction between
system PM and runtime PM. Suppose the controller is already runtime
suspended when the system goes to sleep. Because it is runtime
suspended, it is enabled for wakeup. But device_may_wakeup() could
return false; if this happens then you have to do a runtime-resume in
omap_ehci_suspend() before calling ehci_suspend(), so that the
controller can be suspended again with wakeups disabled. (Or you could
choose an alternative method for accomplishing the same result, such as
disabling the wakeup signal from the pad without going through a whole
EHCI resume/suspend cycle.) Conversely, if device_may_wakeup() returns
true then you shouldn't do anything at all, because the controller is
already suspended with the correct wakeup setting.
I think this case is taken care of by the Runtime PM core at least for the OMAP
platform according to the documentation
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/runtime_pm.txt#n647
At the end of this mail is the log during system suspend/resume
You can notice the following sequence
-ehci runtime suspends
-system suspend triggered
-ehci runtime resumes
-ehci suspends (uses new wakeup settings)
-system wakeup triggered
-ehci resumes
-ehci runtime suspends
For the third problem, suppose the controller was runtime suspended
when the system went to sleep. When the system wakes up, the
controller will become active, so you have to inform the runtime PM
core about its change of state. Basically, if omap_ehci_resume() sees
that ehci_resume() returned 0 then it must do:
pm_runtime_disable(dev);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
All of these issues are discussed (among lots of other material) in
Documentation/power/runtime_pm.txt.
Is this still applicable? Documentation claims
During system resume it calls pm_runtime_enable() and pm_runtime_put_sync()
for every device right after executing the subsystem-level .resume_early()
callback and right after executing the subsystem-level .resume() callback
for it, respectively.
cheers,
-roger
---
[ 13.256286] smsc95xx 1-2.1:1.0 eth0: entering SUSPEND2 mode
[ 13.264648] usb 1-2.1: usb auto-suspend, wakeup 0
[ 13.281677] hub 1-2:1.0: hub_suspend
[ 13.285858] usb 1-2: unlink qh256-0001/dd443880 start 1 [1/0 us]
/
/ # [ 13.296386] usb 1-2: usb auto-suspend, wakeup 1
[ 13.321411] hub 1-0:1.0: hub_suspend
[ 13.325225] usb usb1: bus auto-suspend, wakeup 1
[ 13.330139] ehci-omap 48064800.ehci: suspend root hub
[ 13.336395] ehci-omap 48064800.ehci: omap_ehci_runtime_suspend
/ #
/ # echo mem /sys/power/state
[ 26.821838] PM: Syncing filesystems ... done.
[ 26.828491] PM: Preparing system for mem sleep
[ 26.841796] Freezing user space processes ... (elapsed 0.000 seconds) done.
[ 26.849426] Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
done.
[ 26.860046] PM: Entering mem sleep
[ 26.863769] Suspending console(s) (use no_console_suspend to debug)
[ 26.878234] ehci-omap 48064800.ehci: omap_ehci_runtime_resume
[ 26.878295] usb usb1: usb auto-resume
[ 26.878326] ehci-omap 48064800.ehci: resume root hub
[ 26.878417] hub 1-0:1.0: hub_resume
[ 26.878570] hub 1-0:1.0: port 2: status 0507 change
[ 26.879089] hub 1-0:1.0:
Re: Boot hang regression 3.10.0-rc4 - 3.10.0
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first pm_runtime_get*() done
during probe.
This is similar to what PCI bus does (if you look at pci_pm_init()).
I tried something similar [1] but what I found is that the serial
runtime resume was called despite it being marked as active using
pm_runtime_set_active().
That seems to be because of the pm_runtime_set_autosuspend_delay()
because we have the autosuspend_delay = -1
-
static void update_autosuspend(struct device *dev, int old_delay, int old_use)
{
int delay = dev-power.autosuspend_delay;
/* Should runtime suspend be prevented now? */
if (dev-power.use_autosuspend delay 0) {
/* If it used to be allowed then prevent it. */
if (!old_use || old_delay = 0) {
atomic_inc(dev-power.usage_count);
rpm_resume(dev, 0); ---
calls serial runtime resume.
}
}
-
So we end up with the same issue with serial resume being called before
set_termios()
[1]
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..c71d47d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
struct device_node *node = pdev-dev.of_node;
const char *oh_name;
int oh_cnt, i, ret = 0;
+ bool device_active = false;
oh_cnt = of_property_count_strings(node, ti,hwmods);
if (oh_cnt = 0) {
@@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
goto odbfd_exit1;
}
hwmods[i] = oh;
+ if (oh-flags HWMOD_INIT_NO_IDLE)
+ device_active = true;
+
}
od = omap_device_alloc(pdev, hwmods, oh_cnt);
@@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
pdev-dev.pm_domain = omap_device_pm_domain;
+ if (device_active) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
odbfd_exit1:
kfree(hwmods);
odbfd_exit:
--
To unsubscribe from this list: send the line unsubscribe 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 2/3] drivers: spi: Add qspi flash controller
On Monday 08 July 2013 08:02 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 08, 2013 at 07:12:59PM +0530, Sourav Poddar wrote:
+static inline unsigned long dra7xxx_readl(struct dra7xxx_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi-base + reg);
+}
+
+static inline void dra7xxx_writel(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg)
+{
+ writel(val, qspi-base + reg);
+}
+
+static inline unsigned long dra7xxx_readl_data(struct dra7xxx_qspi *qspi,
+ unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ return readw(qspi-base + reg);
+ break;
+ case 16:
+ return readb(qspi-base + reg);
+ break;
+ case 32:
+ return readl(qspi-base + reg);
+ break;
+ default:
+ return -1;
return -EINVAL ? or some other error code ?
+ }
+}
+
+static inline void dra7xxx_writel_data(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ writew(val, qspi-base + reg);
+ break;
+ case 16:
+ writeb(val, qspi-base + reg);
+ break;
+ case 32:
+ writeb(val, qspi-base + reg);
+ break;
+ default:
+ dev_dbg(qspi-dev, word lenght out of range);
+ break;
+ }
+}
+
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(spi-master);
+ int clk_div = 0;
+ u32 clk_ctrl_reg, clk_rate;
+
+ clk_rate = clk_get_rate(qspi-fclk);
+
+ if (!qspi-spi_max_frequency) {
+ dev_err(qspi-dev, spi max frequency not defined\n);
+ return -1;
same here
+ } else
this needs to have curly braces too, per CodingStyle
+ clk_div = (clk_rate / qspi-spi_max_frequency) - 1;
+
+ dev_dbg(qspi-dev, %s: hz: %d, clock divider %d\n, __func__,
+ qspi-spi_max_frequency, clk_div);
+
+ pm_runtime_get_sync(qspi-dev);
+
+ clk_ctrl_reg = dra7xxx_readl(qspi, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ clk_ctrl_reg= ~QSPI_CLK_EN;
+
+ /* disable SCLK */
+ dra7xxx_writel(qspi, clk_ctrl_reg, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ if (clk_div 0) {
+ dev_dbg(qspi-dev, %s: clock divider 0, using /1 divider\n,
+ __func__);
+ clk_div = 1;
+ }
+
+ if (clk_div QSPI_CLK_DIV_MAX) {
+ dev_dbg(qspi-dev, %s: clock divider%d , using /%d divider\n,
+ __func__, QSPI_CLK_DIV_MAX, QSPI_CLK_DIV_MAX + 1);
+ clk_div = QSPI_CLK_DIV_MAX;
+ }
+
+ /* enable SCLK */
+ dra7xxx_writel(qspi, QSPI_CLK_EN | clk_div, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ pm_runtime_mark_last_busy(qspi-dev);
+ pm_runtime_put_autosuspend(qspi-dev);
+
+ return 0;
+}
+
+static int dra7xxx_qspi_prepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_get_sync(qspi-dev);
not going to check return value ?
+ return 0;
+}
+
+static int dra7xxx_qspi_unprepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_mark_last_busy(qspi-dev);
+ pm_runtime_put_autosuspend(qspi-dev);
what about on these two ?
Just realised this, pm_runtime_mark_last_busy does not need a check, it
returns nothing.
+ return 0;
+}
+
+static int qspi_write_msg(struct dra7xxx_qspi *qspi, struct spi_transfer *t)
+{
+ const u8 *txbuf;
+ int wlen, count;
+
+ count = t-len;
+ txbuf = t-tx_buf;
+ wlen = t-bits_per_word;
+
+ while (count--) {
+ dev_dbg(qspi-dev, tx cmd %08x dc %08x data %02x\n,
+ qspi-cmd | QSPI_WR_SNGL, qspi-dc, *txbuf);
+ dra7xxx_writel(qspi, QSPI_WC_INT_EN, QSPI_INTR_ENABLE_SET_REG);
you should enable the interrupt as the last step. Also, why aren't you
using frame interrupt ?
+ dra7xxx_writel_data(qspi, *txbuf++, QSPI_SPI_DATA_REG, wlen);
+ dra7xxx_writel(qspi, qspi-dc, QSPI_SPI_DC_REG);
+ dra7xxx_writel(qspi, qspi-cmd | QSPI_WR_SNGL,
+ QSPI_SPI_CMD_REG);
+ wait_for_completion(qspi-word_complete);
+ }
+
+ return 0;
+}
+
+static int qspi_read_msg(struct dra7xxx_qspi *qspi, struct spi_transfer *t)
+{
+ u8 *rxbuf;
+ int wlen, count;
+
+ count = t-len;
+ rxbuf = t-rx_buf;
+ wlen = t-bits_per_word;
+
+ while (count--) {
+ dev_dbg(qspi-dev, rx cmd %08x dc %08x\n,
+ qspi-cmd | QSPI_RD_SNGL, qspi-dc);
+ dra7xxx_writel(qspi, QSPI_WC_INT_EN, QSPI_INTR_ENABLE_SET_REG);
ditto
+
Re: Boot hang regression 3.10.0-rc4 - 3.10.0
On Thursday 11 July 2013 11:54 AM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [130710 23:25]: On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote: Felipe is right, looks like all we need is to check if context is initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering. After that having DEBUG_LL and cmdline with earlyprintk console=ttyO.. works for me. On what platform? Like I said there are flags set statically in hmwod data for OMAP4 and OMAP5, which make it work without any hwmod tinkering in mach-omap2/serial.c. But it won't work for am33xx. For me omap4 sdp hangs during ttyO2 probe if earlyprintk is enabled for that port and console is enabled for that port. That's because we attempt to restore uninitialized context. Right, so thats the Issue 2: that you see on the omap4 sdp. You never hit Issue 1: despite not doing any hwmod tinkering because of the static flags set for uart3 in hwmod data. It's possible that we have more than one bug here though. Right, we have 2 issues like I said earlier. Issue 1: is when hwmod _setup() does a console UART reset (Not seen if the flags are set either runtime or statically) Issue 2: Is when omap serial does a runtime resume before set_termios(). @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev) pm_runtime_mark_last_busy(up-dev); pm_runtime_put_autosuspend(up-dev); + up-initialized = true; This won't help as the context save for serial happens as part of set_termios() and not when the device is probed. The issue is that in serial probe we currently restore NULL context to the port which kills earlyprintk output until set_termios() is called. But as discussed, there are better ways for fixing this issue. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Boot hang regression 3.10.0-rc4 - 3.10.0
Hi,
On Thu, Jul 11, 2013 at 02:47:00PM +0530, Rajendra Nayak wrote:
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first pm_runtime_get*() done
during probe.
This is similar to what PCI bus does (if you look at pci_pm_init()).
I tried something similar [1] but what I found is that the serial
runtime resume was called despite it being marked as active using
pm_runtime_set_active().
That seems to be because of the pm_runtime_set_autosuspend_delay()
because we have the autosuspend_delay = -1
-
static void update_autosuspend(struct device *dev, int old_delay, int old_use)
{
int delay = dev-power.autosuspend_delay;
/* Should runtime suspend be prevented now? */
if (dev-power.use_autosuspend delay 0) {
/* If it used to be allowed then prevent it. */
if (!old_use || old_delay = 0) {
atomic_inc(dev-power.usage_count);
rpm_resume(dev, 0); ---
calls serial runtime resume.
}
}
-
So we end up with the same issue with serial resume being called before
set_termios()
yeah, that part I figured out after I started testing today. It seems
like my latest version is getting closer but I still see problems, diff
below:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index e6d2307..0cc2da9 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -181,6 +181,26 @@ odbfd_exit:
return ret;
}
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+ omap_device_enable(pdev);
+ pm_runtime_forbid(pdev-dev);
+ pm_runtime_set_active(pdev-dev);
+ device_enable_async_suspend(pdev-dev);
+}
+
+static void omap_device_pm_allow(struct platform_device *pdev)
+{
+ pm_runtime_allow(pdev-dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev)
+{
+ device_disable_async_suspend(pdev-dev);
+ pm_runtime_set_suspended(pdev-dev);
+ omap_device_idle(pdev);
+}
+
static int _omap_device_notifier_call(struct notifier_block *nb,
unsigned long event, void *dev)
{
@@ -192,16 +212,31 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
if (pdev-archdata.od)
omap_device_delete(pdev-archdata.od);
break;
+ case BUS_NOTIFY_BIND_DRIVER:
+ if (pdev-archdata.od)
+ omap_device_pm_init(pdev);
+ break;
+ case BUS_NOTIFY_BOUND_DRIVER:
+ if (pdev-archdata.od)
+ omap_device_pm_allow(pdev);
+ break;
+ case BUS_NOTIFY_UNBOUND_DRIVER:
+ if (pdev-archdata.od)
+ omap_device_pm_exit(pdev);
+ break;
case BUS_NOTIFY_ADD_DEVICE:
if (pdev-dev.of_node)
omap_device_build_from_dt(pdev);
- /* fall through */
+ break;
default:
- od = to_omap_device(pdev);
- if (od)
- od-_driver_status = event;
+ /* nothing */
+ break;
}
+ od = to_omap_device(pdev);
+ if (od)
+ od-_driver_status = event;
+
return NOTIFY_DONE;
}
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
Hello Grant, Hi Grant, Hello Grant, Could you pull this Please? A gentle ping on this. A gentle ping on this. Could you pull this one? Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com Why does Grant have to pull this? Do you know why Sam didn't take it? I'd be happy to, if it wasn't stepping on anyone's toes. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe 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: Boot hang regression 3.10.0-rc4 - 3.10.0
On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first pm_runtime_get*() done
during probe.
This is similar to what PCI bus does (if you look at pci_pm_init()).
I tried something similar [1] but what I found is that the serial
runtime resume was called despite it being marked as active using
pm_runtime_set_active().
That seems to be because of the pm_runtime_set_autosuspend_delay()
because we have the autosuspend_delay = -1
-
static void update_autosuspend(struct device *dev, int old_delay, int old_use)
{
int delay = dev-power.autosuspend_delay;
/* Should runtime suspend be prevented now? */
if (dev-power.use_autosuspend delay 0) {
/* If it used to be allowed then prevent it. */
if (!old_use || old_delay = 0) {
atomic_inc(dev-power.usage_count);
rpm_resume(dev, 0); ---
calls serial runtime resume.
It's strange - the check for status is inside rpm_resume()
if (dev-power.runtime_status == RPM_ACTIVE) {
retval = 1;
goto out;
}
So, if status is set to RPM_ACTIVE before first call to:
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev,
omap_up_info-autosuspend_timeout);
-- or --
pm_runtime_get*()
everything should be ok.
May be the problem is inside serial_omap_set_termios() where
pm_runtime_get_sync is called before context is initialized.
probe:
get - status is ACTIVE and serial resume is not called
put - status is IDLE
set_termios
get - status is IDLE and serial resume is called
}
}
-
So we end up with the same issue with serial resume being called before
set_termios()
[1]
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..c71d47d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
struct device_node *node = pdev-dev.of_node;
const char *oh_name;
int oh_cnt, i, ret = 0;
+ bool device_active = false;
oh_cnt = of_property_count_strings(node, ti,hwmods);
if (oh_cnt = 0) {
@@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
goto odbfd_exit1;
}
hwmods[i] = oh;
+ if (oh-flags HWMOD_INIT_NO_IDLE)
+ device_active = true;
+
}
od = omap_device_alloc(pdev, hwmods, oh_cnt);
@@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
pdev-dev.pm_domain = omap_device_pm_domain;
+ if (device_active) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
odbfd_exit1:
kfree(hwmods);
odbfd_exit:
--
To unsubscribe from this list: send the line unsubscribe 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: Boot hang regression 3.10.0-rc4 - 3.10.0
Hi, On 07/11/2013 09:32 AM, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [130710 09:18]: On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote: how about something like below ? It makes omap_device/hwmod and pm_runtime agree on the initial state of the device and will prevent -runtime_resume() from being called on first pm_runtime_get*() done during probe. This is similar to what PCI bus does (if you look at pci_pm_init()). commit 59108a500b4ab4b1a5102648a3360276dbf7df6f Author: Felipe Balbi ba...@ti.com Date: Wed Jul 10 18:50:16 2013 +0300 arm: omap2plus: unidle devices which are about to probe in order to make HWMOD and pm_runtime agree on the initial state of the device, we will unidle the device and call pm_runtime_set_active() to tell pm_runtime that the device is really active. Don't think that it's good idea ( I've checked some driver's and think this patch will enable some devices unpredictably: - hwspinlock - mailbox - iommu - ipu All above devices need to be enabled on demand only (no pm_runtime_get*() calls in probe). More over, some of them have very specific enabling sequence - like ipu). May be Summan can say more on that. By the time driver's probe() is reached, a call to pm_runtime_get_sync() will not cause driver's -runtime_resume() method to be called at first, only after a successful -runtime_suspend(). Signed-off-by: Felipe Balbi ba...@ti.com btw, this is RFC, haven't tested at all. Yes it does not compile, then removing the extra ; at the end of the functions, it oopses with a NULL pointer exception. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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: omap2plus: unidle devices which are about to probe
in order to make HWMOD and pm_runtime agree on the
initial state of the device, we will unidle the device
and call pm_runtime_set_active() to tell pm_runtime
that the device is really active.
By the time driver's probe() is reached, a call to
pm_runtime_get_sync() will not cause driver's
-runtime_resume() method to be called at first, only
after a successful -runtime_suspend().
Note that we must prevent pm_runtime transitions while
driver is probing otherwise drivers would be suspended
as soon as they call pm_runtime_use_autosuspend(). By
calling pm_runtime_forbid() before probe() and
pm_runtime_allow() after probe() we 'fix' that detail.
Note that this patch was inspired by PCI's pci_pm_init().
Signed-off-by: Felipe Balbi ba...@ti.com
---
boot tested on top of today's Linus master
6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
panda. Reached console prompt and, after setting a
proper autosuspend delay, consoles autosuspend just
fine.
It needs to be tested on other platforms.
ps: note that we also call pm_runtime_set_suspended(dev)
from our late_initcall() to disable devices so that pm_runtime
and HWMOD continue to aggree on device's state.
arch/arm/mach-omap2/omap_device.c | 44 +++
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..cb1fc1d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -178,6 +178,26 @@ odbfd_exit:
return ret;
}
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+ omap_device_enable(pdev);
+ pm_runtime_forbid(pdev-dev);
+ pm_runtime_set_active(pdev-dev);
+ device_enable_async_suspend(pdev-dev);
+}
+
+static void omap_device_pm_allow(struct platform_device *pdev)
+{
+ pm_runtime_allow(pdev-dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev)
+{
+ device_disable_async_suspend(pdev-dev);
+ pm_runtime_set_suspended(pdev-dev);
+ omap_device_idle(pdev);
+}
+
static int _omap_device_notifier_call(struct notifier_block *nb,
unsigned long event, void *dev)
{
@@ -189,16 +209,31 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
if (pdev-archdata.od)
omap_device_delete(pdev-archdata.od);
break;
+ case BUS_NOTIFY_BIND_DRIVER:
+ if (pdev-archdata.od)
+ omap_device_pm_init(pdev);
+ break;
+ case BUS_NOTIFY_BOUND_DRIVER:
+ if (pdev-archdata.od)
+ omap_device_pm_allow(pdev);
+ break;
+ case BUS_NOTIFY_UNBOUND_DRIVER:
+ if (pdev-archdata.od)
+ omap_device_pm_exit(pdev);
+ break;
case BUS_NOTIFY_ADD_DEVICE:
if (pdev-dev.of_node)
omap_device_build_from_dt(pdev);
- /* fall through */
+ break;
default:
- od = to_omap_device(pdev);
- if (od)
- od-_driver_status = event;
+ /* nothing */
+ break;
}
+ od = to_omap_device(pdev);
+ if (od)
+ od-_driver_status = event;
+
return NOTIFY_DONE;
}
@@ -855,6 +890,7 @@ static int __init omap_device_late_idle(struct device *dev,
void *data)
dev_warn(dev, %s: enabled but no driver. Idling\n,
__func__);
omap_device_idle(pdev);
+ pm_runtime_set_suspended(dev);
}
}
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On 07/09/2013 05:16 PM, Stefan Roese wrote: Hi Roger, I have been too lazy to setup NFS :). But I will give it a shot soon to see what's going wrong. Really appreciated. :) Please let me know if you need anything else from me to reproduce this issue. Stefan, I tried it out today and it worked 5/5 times. I used a bare bones debian root filesystem for the NFS root. Could it be possible that the boot scripts on your filesystem are somehow shutting down the ethernet interface? Might be worth checking on a fresh filesystem. My u-boot script is below and boot log is attached. setenv bootargs console=ttyO2,115200n8 root=/dev/nfs rw nfsroot=192.168.2.1:/srv/nfsroot/ ip=192.168.2.2 rootwait setenv usbethaddr A6:66:4D:B0:69:04 setenv netmask 255.255.255.0 setenv ipaddr 192.168.2.2 setenv serverip 192.168.2.1 usb start tftpboot 0x825f omap3-beagle.dtb tftpboot 0x8030 uImage set fdt_high 0x bootm 0x8030 - 0x825f cheers, -roger U-Boot SPL 2013.01-rc1-00080-gdfc050a (Apr 17 2013 - 15:06:06) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01-rc1-00080-gdfc050a (Apr 17 2013 - 15:06:06) OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment In:serial Out: serial Err: serial Beagle xM Rev C No EEPROM on expansion board Die ID #700a00229ff8016842c91300d00e Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 3 2 1 0 mmc0 is current device reading boot.scr 440 bytes read Running bootscript from mmc0 ... ## Executing script at 8200 (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Waiting for Ethernet connection... done. Using sms0 device TFTP from server 192.168.2.1; our IP address is 192.168.2.2 Filename 'omap3-beagle.dtb'. Load address: 0x825f Loading: *EHCI timed out on TD - token=0x8008d80 T # done Bytes transferred = 13169 (3371 hex) Waiting for Ethernet connection... done. Using sms0 device TFTP from server 192.168.2.1; our IP address is 192.168.2.2 Filename 'uImage'. Load address: 0x8030 Loading: *# # # # ### done Bytes transferred = 4088512 (3e62c0 hex) Unknown command 'set' - try 'help' ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux-3.10.0-08610-g8e1cacd Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4088448 Bytes = 3.9 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f Booting using the fdt blob at 0x825f Loading Kernel Image ... OK OK Using Device Tree in place at 825f, end 825f6370 Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.10.0-08610-g8e1cacd (roger@rockdesk) (gcc version 4.7.1 20120531 (prerelease) (crosstool-NG linaro-1.13.1-2012.06-20120625 - Linaro GCC 2012.06) ) #802 SMP Thu Jul 11 12:31:28 EEST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP3 (Flattened Device Tree), model: TI OMAP3 BeagleBoard xM [0.00] cma: CMA: reserved 16 MiB at 9e80 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] PERCPU: Embedded 9 pages/cpu @c1188000 s14208 r8192 d14464 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [0.00] Kernel command line: console=ttyO2,115200n8 root=/dev/nfs rw nfsroot=192.168.2.1:/srv/nfsroot/ ip=192.168.2.2 rootwait [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 488432K/523264K available (5305K kernel code, 611K rwdata, 1936K rodata, 381K init, 5522K bss, 34832K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [
Re: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
On Thu, 20 Jun 2013, J Keerthy wrote: Add TPS659038 documentation under Palmas. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 7bcd59c..89cb773 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs Applied. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
On Thursday 11 July 2013 04:13 PM, Lee Jones wrote: On Thu, 20 Jun 2013, J Keerthy wrote: Add TPS659038 documentation under Palmas. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 7bcd59c..89cb773 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs Applied. Thanks Lee Jones. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
Hi Roger, On 07/11/2013 12:24 PM, Roger Quadros wrote: Stefan, I tried it out today and it worked 5/5 times. I used a bare bones debian root filesystem for the NFS root. Thanks for testing. Could it be possible that the boot scripts on your filesystem are somehow shutting down the ethernet interface? Might be worth checking on a fresh filesystem. I'm pretty sure that its not a problem with the filesystem. I'm using exactly this filesystem for multiple other ARM based boards as well. And all other boards (most of them with buildin ethernet controller instead of USB connected) have no problem mounting/booting from it. BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install it yourself. From your log I can see, that you are using a slightly different board than I am (Beagle xM Rev C vs. Beagle Rev C1/C2/C3). So its a different OMAP variant. Could this perhaps make a difference? Do you by chance have the old Beagleboard (non-xM) at hand for another test? Thanks again, Stefan [1] http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.6. [2] ftp://ftp.denx.de/pub/eldk/5.3/targets/armv7a/core-image-sato-sdk-generic-armv7a.tar.gz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix omap serial early crash during hwmod _setup()
This series should fix the issue with the early serial crash seen during hwmod _setup() as reported by [1] The issue was reported on a am33xx device and was not seen on omap4 or omap5 devices as the hwmod data for both omap4 and omap5 had statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for uart3 which happens to be the debug console used on omap4 panda and omap5 uevm boards. The series reverts the patch which stubbed out omap_serial_early_init() for DT boot and gets rid of the static flags in omap4 and omap5 hwmod data. This series along with the patch posted by Felipe [2] should fix the issue reported by [1] completely and boot to prompt on a am33xx device with LL_DEBUG enabled. I have boot tested this series (along with [2]) on a omap4 panda es and a am335x boneblack. [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100628 [2] http://marc.info/?l=linux-omapm=137353783912736w=2 Rajendra Nayak (2): Revert ARM: OMAP2+: Fix serial init for device tree based booting ARM: OMAP4+: Get rid of the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags for uart arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +-- arch/arm/mach-omap2/omap_hwmod_54xx_data.c |1 - arch/arm/mach-omap2/serial.c |3 --- 3 files changed, 1 insertion(+), 6 deletions(-) -- 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 1/2] Revert ARM: OMAP2+: Fix serial init for device tree based booting
This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
The above commit stubbed out omap_serial_early_init() in case of
DT build thinking it was doing the serial port initializations.
omap_serial_early_init() however does not do the serial port
inits (its instead done by omap_serial_init_port()) instead
it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
for the console uart which causes hwmod to avoid doing a reset
followed by the idling of the console uart.
This is still needed even in the DT case.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Mark Jackson mpfj-l...@newflow.co.uk
Reported-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/serial.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3a674de..58d5b56 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -175,9 +175,6 @@ static char *cmdline_find_option(char *str)
static int __init omap_serial_early_init(void)
{
- if (of_have_populated_dt())
- return -ENODEV;
-
do {
char oh_name[MAX_UART_HWMOD_NAME_LEN];
struct omap_hwmod *oh;
--
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 2/2] ARM: OMAP4+: Get rid of the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags for uart
The HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags don't belong in the
SoC data but instead need to be set runtime based on the uart thats used
for debug console, so hwmod avoids doing a reset followed by a idling of
the device. This is already happening as part of the omap_serial_early_init()
so remove these flags from the static SoC data.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +--
arch/arm/mach-omap2/omap_hwmod_54xx_data.c |1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index d04b5e6..f80f120 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2858,8 +2858,7 @@ static struct omap_hwmod omap44xx_uart3_hwmod = {
.name = uart3,
.class = omap44xx_uart_hwmod_class,
.clkdm_name = l4_per_clkdm,
- .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
- HWMOD_SWSUP_SIDLE_ACT,
+ .flags = HWMOD_SWSUP_SIDLE_ACT,
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index f37ae96..e816edd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1375,7 +1375,6 @@ static struct omap_hwmod omap54xx_uart3_hwmod = {
.name = uart3,
.class = omap54xx_uart_hwmod_class,
.clkdm_name = l4per_clkdm,
- .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
.main_clk = func_48m_fclk,
.prcm = {
.omap4 = {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
On Wed, 19 Jun 2013, Keerthy wrote: From: J Keerthy j-keer...@ti.com Check if irq value obtained is valid. If it is not valid then skip the irq request step and go ahead with the probe. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) Applied with Stephen and Mark's RB. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
On Thu, 11 Jul 2013, Lee Jones wrote: On Wed, 19 Jun 2013, Keerthy wrote: From: J Keerthy j-keer...@ti.com Check if irq value obtained is valid. If it is not valid then skip the irq request step and go ahead with the probe. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) Applied with Stephen and Mark's RB. Scrap that, it appears to be applied already. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On 07/11/2013 01:45 PM, Stefan Roese wrote: Hi Roger, On 07/11/2013 12:24 PM, Roger Quadros wrote: Stefan, I tried it out today and it worked 5/5 times. I used a bare bones debian root filesystem for the NFS root. Thanks for testing. Could it be possible that the boot scripts on your filesystem are somehow shutting down the ethernet interface? Might be worth checking on a fresh filesystem. I'm pretty sure that its not a problem with the filesystem. I'm using exactly this filesystem for multiple other ARM based boards as well. And all other boards (most of them with buildin ethernet controller instead of USB connected) have no problem mounting/booting from it. OK, then it might be something to do with beagle. Is pandaboard working fine for you? BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install it yourself. OK. Will give it a try. From your log I can see, that you are using a slightly different board than I am (Beagle xM Rev C vs. Beagle Rev C1/C2/C3). So its a My board is a C2. different OMAP variant. Could this perhaps make a difference? Do you by chance have the old Beagleboard (non-xM) at hand for another test? Sure. I have the old beagleboard with me. Let me know what to test. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On 07/11/2013 02:00 PM, Roger Quadros wrote: Could it be possible that the boot scripts on your filesystem are somehow shutting down the ethernet interface? Might be worth checking on a fresh filesystem. I'm pretty sure that its not a problem with the filesystem. I'm using exactly this filesystem for multiple other ARM based boards as well. And all other boards (most of them with buildin ethernet controller instead of USB connected) have no problem mounting/booting from it. OK, then it might be something to do with beagle. Is pandaboard working fine for you? I don't have a pandaboard here. Sorry. Only a another OMAP3530-based board which also fails to boot via NFS. BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install it yourself. OK. Will give it a try. From your log I can see, that you are using a slightly different board than I am (Beagle xM Rev C vs. Beagle Rev C1/C2/C3). So its a My board is a C2. Mine too. different OMAP variant. Could this perhaps make a difference? Do you by chance have the old Beagleboard (non-xM) at hand for another test? Sure. I have the old beagleboard with me. Let me know what to test. Either your debian rootfs via NFS or the ELDK one. As you have done with the Beagle-xM. And then please repeat the NFS booting (if successful) again for at least 5 times. Or even better, setup the bootcmd to autoboot via NFS and tune your NFS rootfs to reboot automatically. So a hangup in NFS booting would be noticed after some time with this board automatically rebooting. Thanks, Stefan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On 07/11/2013 12:24 PM, Roger Quadros wrote: My u-boot script is below and boot log is attached. BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify. Do you have any patches locally applied to the kernel.org version that might be helpful with this USB issue I'm seeing? Thanks, Stefan -- To unsubscribe from this list: send the line unsubscribe 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] mmc: omap_hsmmc: use the generic config for omap2plus devices
On Wed, Jul 10, 2013 at 09:36:24PM +0530, a-bin...@ti.com wrote: From: Amarinder Bindra a-bin...@ti.com OMAP's hs_mmc driver is used for MMC controller operation on many omap2plus SoCs (OMAP2430, OMAP3, 4, 5 and AM335x). Considering that the device tree entries are already present for these, allow the driver to be built using the config ARCH_OMAP2PLUS rather than individually adding a config for each SoC to enable the support. Use COMPILE_TEST to enable the build for other platforms. Signed-off-by: Amarinder Bindra a-bin...@ti.com Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com Cc: Felipe Balbi ba...@ti.com Cc: Nishanth Menon n...@ti.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
[PATCH] mmc: omap_hsmmc: fix dependency on indirect header inclusion
omap_hsmmc.c depends on linux/sizes.h being included indirectly by another header. Once we enable COMPILE_TEST for this driver, we might compile under architectures which won't include linux/sizes.h for us. In fact, one such case is x86. In order to prevent compile breakages, let's explicitly include linux/sizes.h Signed-off-by: Felipe Balbi ba...@ti.com --- This should be applied before http://marc.info/?l=linux-omapm=137347241524118w=2 in order to maintain bisectability. cheers drivers/mmc/host/omap_hsmmc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 1865321..c937ffc 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -21,6 +21,7 @@ #include linux/debugfs.h #include linux/dmaengine.h #include linux/seq_file.h +#include linux/sizes.h #include linux/interrupt.h #include linux/delay.h #include linux/dma-mapping.h -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix omap serial early crash during hwmod _setup()
On Thu, Jul 11, 2013 at 04:23:03PM +0530, Rajendra Nayak wrote: This series should fix the issue with the early serial crash seen during hwmod _setup() as reported by [1] The issue was reported on a am33xx device and was not seen on omap4 or omap5 devices as the hwmod data for both omap4 and omap5 had statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for uart3 which happens to be the debug console used on omap4 panda and omap5 uevm boards. The series reverts the patch which stubbed out omap_serial_early_init() for DT boot and gets rid of the static flags in omap4 and omap5 hwmod data. This series along with the patch posted by Felipe [2] should fix the issue reported by [1] completely and boot to prompt on a am33xx device with LL_DEBUG enabled. I have boot tested this series (along with [2]) on a omap4 panda es and a am335x boneblack. [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100628 [2] http://marc.info/?l=linux-omapm=137353783912736w=2 Rajendra Nayak (2): Revert ARM: OMAP2+: Fix serial init for device tree based booting ARM: OMAP4+: Get rid of the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags for uart boot tested on omap4-panda rev a3. Console still works and it suspends and resumes fine after setting a proper timeout. Tested-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
[PATCH] ARM: OMAP2+: Remove legacy device creation for McPDM and DMIC
McPDM and DMIC only available on OMAP4/5 which no longer boots in legacy
mode.
The code to create the devices in legacy mode can be removed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c | 40
1 file changed, 40 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index aef96e4..dbcadcc 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -328,44 +328,6 @@ static void omap_init_audio(void)
static inline void omap_init_audio(void) {}
#endif
-#if defined(CONFIG_SND_OMAP_SOC_MCPDM) || \
- defined(CONFIG_SND_OMAP_SOC_MCPDM_MODULE)
-
-static void __init omap_init_mcpdm(void)
-{
- struct omap_hwmod *oh;
- struct platform_device *pdev;
-
- oh = omap_hwmod_lookup(mcpdm);
- if (!oh)
- return;
-
- pdev = omap_device_build(omap-mcpdm, -1, oh, NULL, 0);
- WARN(IS_ERR(pdev), Can't build omap_device for omap-mcpdm.\n);
-}
-#else
-static inline void omap_init_mcpdm(void) {}
-#endif
-
-#if defined(CONFIG_SND_OMAP_SOC_DMIC) || \
- defined(CONFIG_SND_OMAP_SOC_DMIC_MODULE)
-
-static void __init omap_init_dmic(void)
-{
- struct omap_hwmod *oh;
- struct platform_device *pdev;
-
- oh = omap_hwmod_lookup(dmic);
- if (!oh)
- return;
-
- pdev = omap_device_build(omap-dmic, -1, oh, NULL, 0);
- WARN(IS_ERR(pdev), Can't build omap_device for omap-dmic.\n);
-}
-#else
-static inline void omap_init_dmic(void) {}
-#endif
-
#if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
@@ -566,8 +528,6 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
- omap_init_dmic();
- omap_init_mcpdm();
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and twl6040 setup for legacy boot
OMAP4 no longer boots in legacy mode so the code here is no longer used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 332 ++-
arch/arm/mach-omap2/twl-common.h | 8 -
2 files changed, 12 insertions(+), 328 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index c05898f..932dea7 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -38,20 +38,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info
= {
.flags = I2C_CLIENT_WAKE,
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-static int twl_set_voltage(void *data, int target_uV)
-{
- struct voltagedomain *voltdm = (struct voltagedomain *)data;
- return voltdm_scale(voltdm, target_uV);
-}
-
-static int twl_get_voltage(void *data)
-{
- struct voltagedomain *voltdm = (struct voltagedomain *)data;
- return voltdm_get_voltage(voltdm);
-}
-#endif
-
void __init omap_pmic_init(int bus, u32 clkrate,
const char *pmic_type, int pmic_irq,
struct twl4030_platform_data *pmic_data)
@@ -65,20 +51,6 @@ void __init omap_pmic_init(int bus, u32 clkrate,
omap_register_i2c_bus(bus, clkrate, pmic_i2c_board_info, 1);
}
-void __init omap4_pmic_init(const char *pmic_type,
- struct twl4030_platform_data *pmic_data,
- struct i2c_board_info *devices, int nr_devices)
-{
- /* PMIC part*/
- omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
- omap_mux_init_signal(fref_clk0_out.sys_drm_msecure, OMAP_PIN_OUTPUT);
- omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START,
pmic_data);
-
- /* Register additional devices on i2c1 bus if needed */
- if (devices)
- i2c_register_board_info(1, devices, nr_devices);
-}
-
void __init omap_pmic_late_init(void)
{
/* Init the OMAP TWL parameters (if PMIC has been registerd) */
@@ -86,7 +58,6 @@ void __init omap_pmic_late_init(void)
return;
omap3_twl_init();
- omap4_twl_init();
}
#if defined(CONFIG_ARCH_OMAP3)
@@ -189,6 +160,18 @@ static struct regulator_init_data omap3_vdd2 = {
.consumer_supplies = omap3_vdd2_supply,
};
+static int twl_set_voltage(void *data, int target_uV)
+{
+ struct voltagedomain *voltdm = (struct voltagedomain *)data;
+ return voltdm_scale(voltdm, target_uV);
+}
+
+static int twl_get_voltage(void *data)
+{
+ struct voltagedomain *voltdm = (struct voltagedomain *)data;
+ return voltdm_get_voltage(voltdm);
+}
+
static struct twl_regulator_driver_data omap3_vdd1_drvdata = {
.get_voltage = twl_get_voltage,
.set_voltage = twl_set_voltage,
@@ -235,297 +218,6 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
#endif /* CONFIG_ARCH_OMAP3 */
-#if defined(CONFIG_ARCH_OMAP4)
-static struct twl4030_usb_data omap4_usb_pdata = {
-};
-
-static struct regulator_consumer_supply omap4_vdda_hdmi_dac_supplies[] = {
- REGULATOR_SUPPLY(vdda_hdmi_dac, omapdss_hdmi),
-};
-
-static struct regulator_init_data omap4_vdac_idata = {
- .constraints = {
- .min_uV = 180,
- .max_uV = 180,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_vdda_hdmi_dac_supplies),
- .consumer_supplies = omap4_vdda_hdmi_dac_supplies,
- .supply_regulator = V2V1,
-};
-
-static struct regulator_init_data omap4_vaux2_idata = {
- .constraints = {
- .min_uV = 120,
- .max_uV = 280,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-static struct regulator_init_data omap4_vaux3_idata = {
- .constraints = {
- .min_uV = 100,
- .max_uV = 300,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
-
[PATCH 2/2] pwm: Add PWM polarity flag macros for DT
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 6 +++---
Documentation/devicetree/bindings/pwm/pwm-samsung.txt | 5 +++--
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 5 +++--
Documentation/devicetree/bindings/pwm/pwm.txt | 8 +---
Documentation/devicetree/bindings/pwm/vt8500-pwm.txt| 5 +++--
arch/arm/boot/dts/am335x-evm.dts| 3 ++-
arch/arm/boot/dts/am335x-evmsk.dts | 3 ++-
arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++-
include/dt-bindings/pwm/pwm.h | 15 +++
include/linux/pwm.h | 4 ++--
10 files changed, 40 insertions(+), 17 deletions(-)
create mode 100644 include/dt-bindings/pwm/pwm.h
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
index de0eaed..be09be4 100644
--- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
@@ -4,9 +4,9 @@ Required properties:
- compatible: should be atmel,tcb-pwm
- #pwm-cells: Should be 3. The first cell specifies the per-chip index
of the PWM to use, the second cell is the period in nanoseconds and
- bit 0 in the third cell is used to encode the polarity of PWM output.
- Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity
- set to 0 for normal polarity.
+ the third cell is used to encode the polarity of PWM output. Set the
+ PWM_POLARITY_NORMAL flag for normal polarity or the PWM_POLARITY_INVERSED
+ flag for inverted polarity. PWM flags are defined in dt-bindings/pwm/pwm.h.
- tc-block: The Timer Counter block to use as a PWM chip.
Example:
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
index ac67c68..bece18b 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -24,8 +24,9 @@ Required properties:
- phandle to PWM controller node
- index of PWM channel (from 0 to 4)
- PWM signal period in nanoseconds
- - bitmask of optional PWM flags:
-0x1 - invert PWM signal
+ - bitmask of optional PWM flags as defined in dt-bindings/pwm/pwm.h:
+PWM_POLARITY_NORMAL - normal polarity
+ PWM_POLARITY_INVERSED - inverted polarity
Optional properties:
- samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 337c6fc..9007d92 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -7,8 +7,9 @@ Required properties:
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
- encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
- to 1 for inverse polarity set to 0 for normal polarity.
+ encode the polarity of PWM output. Set the PWM_POLARITY_NORMAL flag for
+ normal polarity or the PWM_POLARITY_INVERSED flag for inverted polarity.
+ PWM flags are defined in dt-bindings/pwm/pwm.h.
- reg: physical base address and size of the registers map.
Optional properties:
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt
b/Documentation/devicetree/bindings/pwm/pwm.txt
index 06e6724..38c357a 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -43,13 +43,15 @@ because the name backlight would be used as fallback
anyway.
pwm-specifier typically encodes the chip-relative PWM number and the PWM
period in nanoseconds.
-Optionally, the pwm-specifier can encode a number of flags in a third cell:
-- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
+Optionally, the pwm-specifier can encode a number of flags (defined in
+dt-bindings/gpio/gpio.h) in a third cell:
+- PWM_POLARITY_NORMAL: use the normal PWM signal polarity
+- PWM_POLARITY_INVERSED: invert the PWM signal polarity
Example with optional PWM specifier for inverse polarity
bl: backlight {
- pwms = pwm 0 500 1;
+ pwms = pwm 0 500 PWM_POLARITY_INVERSED;
pwm-names = backlight;
};
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
index d21d82d..5b1b21f 100644
--- a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
+++
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On 07/11/2013 03:41 PM, Stefan Roese wrote: On 07/11/2013 12:24 PM, Roger Quadros wrote: My u-boot script is below and boot log is attached. BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify. Do you have any patches locally applied to the kernel.org version that might be helpful with this USB issue I'm seeing? Yes I had tested it on a more recent kernel with some local patches applied that I've recently sent for review. But to cross check with your setup I've retested it with commit d2b4a646 with the 2 below patches on top https://lkml.org/lkml/2013/6/20/327 https://lkml.org/lkml/2013/6/20/339 I've tried it again with the ELDK 5.3 root but still can't get it to fail. I think we should match our u-boot as well. Could you please let me know your u-boot commit and uEnv.txt? My network setup is pretty simple, beagle-xm is connected directly to my laptop's ethernet port. No network switch in between. When you get the problem do you cold boot the board or warm boot it? I've been always cold booting it. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM i.MX53: mba53: Fix PWM backlight DT node
The i.MX53 PWM controller uses two cells to describe the PWM specifier.
Remove the extra unused values from the backlight DT node pwms property.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
arch/arm/boot/dts/imx53-mba53.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-mba53.dts
b/arch/arm/boot/dts/imx53-mba53.dts
index aaa33bc..a630902 100644
--- a/arch/arm/boot/dts/imx53-mba53.dts
+++ b/arch/arm/boot/dts/imx53-mba53.dts
@@ -27,7 +27,7 @@
backlight {
compatible = pwm-backlight;
- pwms = pwm2 0 5 0 0;
+ pwms = pwm2 0 5;
brightness-levels = 0 24 28 32 36 40 44 48 52 56 60 64 68 72
76 80 84 88 92 96 100;
default-brightness-level = 10;
enable-gpios = gpio7 7 0;
--
1.8.1.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 0/2] Add PWM polarity flag macros for DT
Hello, Here's a small patch set that replaces PWM polarity numerical constants with macros in DT. The series starts with a fix for an error in the i.MX53 mba53 DT, and the second patch then introduces the macros and update both bindings documentation and existing DT. Laurent Pinchart (2): ARM i.MX53: mba53: Fix PWM backlight DT node pwm: Add PWM polarity flag macros for DT Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 6 +++--- Documentation/devicetree/bindings/pwm/pwm-samsung.txt | 5 +++-- Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 5 +++-- Documentation/devicetree/bindings/pwm/pwm.txt | 8 +--- Documentation/devicetree/bindings/pwm/vt8500-pwm.txt| 5 +++-- arch/arm/boot/dts/am335x-evm.dts| 3 ++- arch/arm/boot/dts/am335x-evmsk.dts | 3 ++- arch/arm/boot/dts/imx53-mba53.dts | 2 +- arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++- include/dt-bindings/pwm/pwm.h | 15 +++ include/linux/pwm.h | 4 ++-- 11 files changed, 41 insertions(+), 18 deletions(-) create mode 100644 include/dt-bindings/pwm/pwm.h -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and twl6040 setup for legacy boot
On 16:23-20130711, Peter Ujfalusi wrote: OMAP4 no longer boots in legacy mode so the code here is no longer used. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap2/twl-common.c | 332 ++- arch/arm/mach-omap2/twl-common.h | 8 - 2 files changed, 12 insertions(+), 328 deletions(-) Could we modify the Makefile and build twl-common.o only for CONFIG_ARCH_OMAP3? We could get rid of all the #ifdef from the code that way. OMAP3 is the only platform that still depends on this - Further, with this change, commit 34a38440689b06a515104d668494e0ff8a4e1537 (regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators) will need a relook as well. currently part of the discussion with Mark in [1] [1] http://marc.info/?t=13718501633r=1w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
On Thu, 11 Jul 2013, Roger Quadros wrote: The other two problems are both related to the interaction between system PM and runtime PM. Suppose the controller is already runtime suspended when the system goes to sleep. Because it is runtime suspended, it is enabled for wakeup. But device_may_wakeup() could return false; if this happens then you have to do a runtime-resume in omap_ehci_suspend() before calling ehci_suspend(), so that the controller can be suspended again with wakeups disabled. (Or you could choose an alternative method for accomplishing the same result, such as disabling the wakeup signal from the pad without going through a whole EHCI resume/suspend cycle.) Conversely, if device_may_wakeup() returns true then you shouldn't do anything at all, because the controller is already suspended with the correct wakeup setting. I think this case is taken care of by the Runtime PM core at least for the OMAP platform according to the documentation http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/runtime_pm.txt#n647 No; that section refers only to races, not to wakeup settings. At the end of this mail is the log during system suspend/resume You can notice the following sequence -ehci runtime suspends -system suspend triggered -ehci runtime resumes -ehci suspends (uses new wakeup settings) -system wakeup triggered -ehci resumes -ehci runtime suspends This is because the root hub was runtime suspended with the wrong wakeup setting. The USB core, which is careful about these things, resumed and re-suspended it with the proper wakeup setting. In the process, the controller had to be runtime resumed as well. Try doing the test over again, but this time with the root hub enabled for wakeup and the controller disabled. (I know this is a bizarre combination, but try it anyway.) Also, after the system wakes up, see whether the root hub and controller get runtime suspended. For the third problem, suppose the controller was runtime suspended when the system went to sleep. When the system wakes up, the controller will become active, so you have to inform the runtime PM core about its change of state. Basically, if omap_ehci_resume() sees that ehci_resume() returned 0 then it must do: pm_runtime_disable(dev); pm_runtime_set_active(dev); pm_runtime_enable(dev); All of these issues are discussed (among lots of other material) in Documentation/power/runtime_pm.txt. Is this still applicable? Documentation claims During system resume it calls pm_runtime_enable() and pm_runtime_put_sync() for every device right after executing the subsystem-level .resume_early() callback and right after executing the subsystem-level .resume() callback for it, respectively. Yes, this is applicable, but it is irrelevant to the problem I described. You still have to tell the runtime PM core that the device is now active. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On 07/11/2013 04:35 PM, Roger Quadros wrote: BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify. Do you have any patches locally applied to the kernel.org version that might be helpful with this USB issue I'm seeing? Yes I had tested it on a more recent kernel with some local patches applied that I've recently sent for review. But to cross check with your setup I've retested it with commit d2b4a646 with the 2 below patches on top https://lkml.org/lkml/2013/6/20/327 https://lkml.org/lkml/2013/6/20/339 Thanks. I have exactly those 2 patches applies as well. But on a different git commit. And with some local (unrelated) patches as well. I'll revert to exactly your version tomorrow and test again. I've tried it again with the ELDK 5.3 root but still can't get it to fail. I think we should match our u-boot as well. Could you please let me know your u-boot commit and uEnv.txt? Good idea. I'm currently using a dirty local version. I'll try to switch to an officially available version tomorrow. And send you the version/git id. My network setup is pretty simple, beagle-xm is connected directly to my laptop's ethernet port. No network switch in between. I have a switch in between the target and my PC. But this network setup is also quite simple and works with all other boards as well. So this shouldn't be a problem. When you get the problem do you cold boot the board or warm boot it? I've been always cold booting it. I'm usually warm booting (pushbutton reset). As mentioned above, I have some homework now to move to a setup/configuration (official git commits) that you can reproduce on your version C2 beagleboard as well. Stay tuned... ;) Thanks, Stefan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote:
[...]
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
index de0eaed..be09be4 100644
--- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
@@ -4,9 +4,9 @@ Required properties:
- compatible: should be atmel,tcb-pwm
- #pwm-cells: Should be 3. The first cell specifies the per-chip index
of the PWM to use, the second cell is the period in nanoseconds and
- bit 0 in the third cell is used to encode the polarity of PWM output.
- Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity
- set to 0 for normal polarity.
+ the third cell is used to encode the polarity of PWM output. Set the
+ PWM_POLARITY_NORMAL flag for normal polarity or the PWM_POLARITY_INVERSED
+ flag for inverted polarity. PWM flags are defined in
dt-bindings/pwm/pwm.h.
- tc-block: The Timer Counter block to use as a PWM chip.
Example:
I'd prefer for the original text to stay in place and the reference to
the dt-bindings/pwm/pwm.h file to go below that block. The reason is
that perhaps somebody will look at an older version of a given DT (with
the numerical value) and not have access to the include and therefore
not know which flag was being set by just looking at the documentation.
I'm also not sure about what the plans are with respect to shipping
device trees in a separate repository and if they are, whether that
repository would ship the includes as well.
Another issue might be that people without access to recent versions of
DTC won't be able to use the new #include feature, so keeping the
documentation backwards compatible seems like a good idea.
Perhaps the include file should even only be mentioned in the general
PWM binding documentation.
Perhaps Grant and Rob (Cc'ed) can comment on how they want to handle
this.
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
index ac67c68..bece18b 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -24,8 +24,9 @@ Required properties:
- phandle to PWM controller node
- index of PWM channel (from 0 to 4)
- PWM signal period in nanoseconds
- - bitmask of optional PWM flags:
-0x1 - invert PWM signal
+ - bitmask of optional PWM flags as defined in dt-bindings/pwm/pwm.h:
+PWM_POLARITY_NORMAL - normal polarity
+ PWM_POLARITY_INVERSED - inverted polarity
This part mixes spaces and tabs for indentation. Please stick to spaces.
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt
b/Documentation/devicetree/bindings/pwm/pwm.txt
index 06e6724..38c357a 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -43,13 +43,15 @@ because the name backlight would be used as fallback
anyway.
pwm-specifier typically encodes the chip-relative PWM number and the PWM
period in nanoseconds.
-Optionally, the pwm-specifier can encode a number of flags in a third cell:
-- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
+Optionally, the pwm-specifier can encode a number of flags (defined in
+dt-bindings/gpio/gpio.h) in a third cell:
+- PWM_POLARITY_NORMAL: use the normal PWM signal polarity
+- PWM_POLARITY_INVERSED: invert the PWM signal polarity
You'd have a hard time finding those in the GPIO header. =)
diff --git a/include/dt-bindings/pwm/pwm.h b/include/dt-bindings/pwm/pwm.h
new file mode 100644
index 000..f82be30
--- /dev/null
+++ b/include/dt-bindings/pwm/pwm.h
@@ -0,0 +1,15 @@
+/*
+ * This header provides constants for most PWM bindings.
+ *
+ * Most PWM bindings can include a flags cell as part of the PWM specifier.
+ * In most cases, the format of the flags cell uses the standard values
+ * defined in this header.
+ */
+
+#ifndef _DT_BINDINGS_PWM_PWM_H
+#define _DT_BINDINGS_PWM_PWM_H
+
+#define PWM_POLARITY_NORMAL (0 0)
+#define PWM_POLARITY_INVERSED(1 0)
+
+#endif
I think this should go into a patch separate from the DT changes above
because they'll likely go in via different trees. Or maybe they won't,
but it'd still be good to introduce the header first and only then
change the DTS files.
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
[...]
enum pwm_polarity {
- PWM_POLARITY_NORMAL,
- PWM_POLARITY_INVERSED,
+ PWM_POLARITY_NORMAL = 0,
+ PWM_POLARITY_INVERSED = 1,
That's what the enum values will be by default, so there's no need to be
explicit here.
Thierry
signature.asc
Description: Digital signature
Re: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and twl6040 setup for legacy boot
On 07/11/2013 04:59 PM, Nishanth Menon wrote: On 16:23-20130711, Peter Ujfalusi wrote: OMAP4 no longer boots in legacy mode so the code here is no longer used. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap2/twl-common.c | 332 ++- arch/arm/mach-omap2/twl-common.h | 8 - 2 files changed, 12 insertions(+), 328 deletions(-) Could we modify the Makefile and build twl-common.o only for CONFIG_ARCH_OMAP3? We could get rid of all the #ifdef from the code that way. OMAP3 is the only platform that still depends on this - Further, with this change, Yep, I can do that. I'll send a separate patch to do this. commit 34a38440689b06a515104d668494e0ff8a4e1537 (regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators) will need a relook as well. currently part of the discussion with Mark in [1] [1] http://marc.info/?t=13718501633r=1w=2 I don't see anything touching twl-common.c/h in the series. But at the end we should get rid of the legacy support in all of the drivers aimed for OMAP4+ gradually since it is pointless to keep dead code. Emphasis on gradually ;) -- Péter -- To unsubscribe from this list: send the line unsubscribe 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+: twl-common: Remove code for twl6030 and twl6040 setup for legacy boot
On 17:45-20130711, Peter Ujfalusi wrote: On 07/11/2013 04:59 PM, Nishanth Menon wrote: On 16:23-20130711, Peter Ujfalusi wrote: OMAP4 no longer boots in legacy mode so the code here is no longer used. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap2/twl-common.c | 332 ++- arch/arm/mach-omap2/twl-common.h | 8 - 2 files changed, 12 insertions(+), 328 deletions(-) Could we modify the Makefile and build twl-common.o only for CONFIG_ARCH_OMAP3? We could get rid of all the #ifdef from the code that way. OMAP3 is the only platform that still depends on this - Further, with this change, Yep, I can do that. I'll send a separate patch to do this. commit 34a38440689b06a515104d668494e0ff8a4e1537 (regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators) will need a relook as well. currently part of the discussion with Mark in [1] [1] http://marc.info/?t=13718501633r=1w=2 I don't see anything touching twl-common.c/h in the series. But at the end we should get rid of the legacy support in all of the drivers aimed for OMAP4+ gradually since it is pointless to keep dead code. Emphasis on gradually ;) right - now that we removed the set_voltage/get_voltage custom code, there are no longer any way the code introduced in the commit can be exercised. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources.
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 6 +++---
Documentation/devicetree/bindings/pwm/pwm-samsung.txt | 5 +++--
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 5 +++--
Documentation/devicetree/bindings/pwm/pwm.txt | 8 +---
Documentation/devicetree/bindings/pwm/vt8500-pwm.txt| 5 +++--
arch/arm/boot/dts/am335x-evm.dts| 3 ++-
arch/arm/boot/dts/am335x-evmsk.dts | 3 ++-
arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++-
include/dt-bindings/pwm/pwm.h | 15 +++
include/linux/pwm.h | 4 ++--
I think this needs to be separate patches; at least the new pwm.h should
be introduced separately to the board-specific *.dts edits, and perhaps
further split up?
That way, the one patch that introduces dt-bindings/pwm.h would be
available to be merged into any other tree that wanted to take patches
to use the new defines.
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
enum pwm_polarity {
- PWM_POLARITY_NORMAL,
- PWM_POLARITY_INVERSED,
+ PWM_POLARITY_NORMAL = 0,
+ PWM_POLARITY_INVERSED = 1,
};
Rather than manually editing that to ensure the enum matches the DT
bindings header, the whole point of making a separate dt-bindings/...
directory was that drivers could include the binding header files
directly to avoid having to duplicate the constant definitions. Can't
linux/pwm.h include dt-bindings/pwm.h and remove that enum?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On 07/11/2013 09:36 AM, Thierry Reding wrote: On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote: [...] diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index de0eaed..be09be4 100644 --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt @@ -4,9 +4,9 @@ Required properties: - compatible: should be atmel,tcb-pwm - #pwm-cells: Should be 3. The first cell specifies the per-chip index of the PWM to use, the second cell is the period in nanoseconds and - bit 0 in the third cell is used to encode the polarity of PWM output. - Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity - set to 0 for normal polarity. + the third cell is used to encode the polarity of PWM output. Set the + PWM_POLARITY_NORMAL flag for normal polarity or the PWM_POLARITY_INVERSED + flag for inverted polarity. PWM flags are defined in dt-bindings/pwm/pwm.h. - tc-block: The Timer Counter block to use as a PWM chip. Example: I'd prefer for the original text to stay in place and the reference to the dt-bindings/pwm/pwm.h file to go below that block. I disagree here. The whole point of creating header files for the constants in binding definitions was so that you wouldn't have to duplicate all the values into the binding definitions. Rather, you'd simply say see dt-bindings/xxx.h. A comment on the original patch: You're creating dt-bindings/pwm/pwm.h. That filename sounds entirely generic, as if the values are defining something PWM-wide rather than specific to individual PWM bindings. As such, I think the text in each individual binding should simply say something like: - the third cell encodes standard PWM flags, as defined in dt-bindings/pwm/pwm.h. - Similarly, pwm.txt should mention that standard flags exist, and refer to that same file for definitions. The reason is that perhaps somebody will look at an older version of a given DT (with the numerical value) and not have access to the include and therefore not know which flag was being set by just looking at the documentation. It's pretty trivial to find the header that defines the values; just grab the latest source. If you're looking at an old version of the .dts file, it's almost certain that's within the context of an old Linux kernel soruce tree, in which case you trivially have access to the old version of the binding document that spelled out the values. I'm also not sure about what the plans are with respect to shipping device trees in a separate repository and if they are, whether that repository would ship the includes as well. It would have to. That separate repository would be upstream for dt-bindings/ files, which would be imported into the kernel periodically as drivers wanted to make use of any new headers/values defined there. Another issue might be that people without access to recent versions of DTC won't be able to use the new #include feature, so keeping the documentation backwards compatible seems like a good idea. The dtc source tree is duplicated into the kernel source tree, so that isn't an issue for now. Besides, the dtc version is an entirely unrelated issue to how the documentation is written. Perhaps the include file should even only be mentioned in the general PWM binding documentation. I wondered about that too. It's slightly indirect in that you'd read foo-pwm.txt which would say something like: - the third cell encodes standard PWM flags, as defined by the core PWM binding in pwm.txt in this directory. - and pwm.txt would say: - The PWM specifier should include a flags cell to contain standard PWM flags. Values for that cell are defined in dt-bindings/pwm/pwm.h. - Which is somewhat like following a lot of symlinks. Still, I agree that's arguably the correct thing to do. -- To unsubscribe from this list: send the line unsubscribe 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: How to keep DM37x GPIO_162 high during off-mode
On 07/09/2013 11:55 AM, Tony Lindgren wrote: * Peter Barada peter.bar...@logicpd.com [130709 08:14]: I'm working with a 3.0.8 kernel in Android ICS and have run into a problem using wl12xx bluetooth after a suspend/resume cycle. GPIO_162 in this design is connected to the BT_EN pin of the wl12xx and needs to be held high to keep the bluetooth core from resetting while the DM37x goes into off mode. I've tried muxing the pin using OMAP_PIN_OUTPUT | OMAP_PIN_OFF_OUTPUT_HIGH, but the pin goes low when the chip goes into off mode. If I disable off mode via echo 0 /sys/kernel/debug/pm_debug/enable_off_mode the pin remains high while the chip goes into retention and the bluetooth core works after resume. Any ideas why GPIO_162 would go low during suspend to off mode? Unless the GPIO is in a GPIO bank that's connected to the WKUP power domain, the GPIO bank context will be lost. So there's a short period where the GPIO bank is in an uninitialized state between waking from off-idle and before the context to the GPIO bank gets restored in omap_gpio_runtime_resume(). If there's a pull on the line, the period is long enough to change the line. Unless the TI people know some magic tricks that I'm not aware of, there's no way around it, except to use external pulls to keep the GPIO line in desired state, or move the GPIO somewhere else, like TWL. Unfortunately the hardware doesn't have an external pullup, and re-spinning it to route BT_EN to a GPIO pin that's in the WKUP domain isn't an option at this time... Unless there's some TI-magic to keep GPIO_162 high during OFF mode I'll have to solve this the hard way by reinitializing the BT/GPS core during resume using deferred work. Unfirtuantely I don't have a clear understanding of the userspace interaction to know if this is doable. Mechanically it doesn't look too difficult to use the guts of st_register/st_kim_start to reinitialize the GT/GPS core and download its firmware, but the userspace interactions (and the time it takes to load the firmware) is what makes coming up with a good solution difficult. Any suggestions on how to approach solving this are most appreciated! -- Peter Barada peter.bar...@logicpd.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote: On 07/11/2013 09:36 AM, Thierry Reding wrote: On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote: [...] diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index de0eaed..be09be4 100644 --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt @@ -4,9 +4,9 @@ Required properties: - compatible: should be atmel,tcb-pwm - #pwm-cells: Should be 3. The first cell specifies the per-chip index of the PWM to use, the second cell is the period in nanoseconds and - bit 0 in the third cell is used to encode the polarity of PWM output. - Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity - set to 0 for normal polarity. + the third cell is used to encode the polarity of PWM output. Set the + PWM_POLARITY_NORMAL flag for normal polarity or the PWM_POLARITY_INVERSED + flag for inverted polarity. PWM flags are defined in dt-bindings/pwm/pwm.h. - tc-block: The Timer Counter block to use as a PWM chip. Example: I'd prefer for the original text to stay in place and the reference to the dt-bindings/pwm/pwm.h file to go below that block. I disagree here. The whole point of creating header files for the constants in binding definitions was so that you wouldn't have to duplicate all the values into the binding definitions. Rather, you'd simply say see dt-bindings/xxx.h. But that's not something that this patch solves. And it could be solved even in the absence of the header file defining the symbolic constants. If all the standard flags that dt-bindings/pwm/pwm.txt now specifies were to be listed in pwm.txt (they actually are) then referring to that document as the canonical source works equally well. The reason is that perhaps somebody will look at an older version of a given DT (with the numerical value) and not have access to the include and therefore not know which flag was being set by just looking at the documentation. It's pretty trivial to find the header that defines the values; just grab the latest source. If you're looking at an old version of the .dts file, it's almost certain that's within the context of an old Linux kernel soruce tree, in which case you trivially have access to the old version of the binding document that spelled out the values. I'm also not sure about what the plans are with respect to shipping device trees in a separate repository and if they are, whether that repository would ship the includes as well. It would have to. That separate repository would be upstream for dt-bindings/ files, which would be imported into the kernel periodically as drivers wanted to make use of any new headers/values defined there. If we can take both of the above for granted, then sure, let's refer to the header from within the generic pwm.txt file and add a reference to that in bindings for drivers that use the standard flags. Another issue might be that people without access to recent versions of DTC won't be able to use the new #include feature, so keeping the documentation backwards compatible seems like a good idea. The dtc source tree is duplicated into the kernel source tree, so that isn't an issue for now. Besides, the dtc version is an entirely unrelated issue to how the documentation is written. Well, not really. If the documentation specifies the binding in a way that the DTC can't handle that's still a problem. People will end up with a DTS that their DTC can't compile. I guess that can be resolved by adding a note to the upstream device tree repository about the minimum required version of DTC. Perhaps the include file should even only be mentioned in the general PWM binding documentation. I wondered about that too. It's slightly indirect in that you'd read foo-pwm.txt which would say something like: - the third cell encodes standard PWM flags, as defined by the core PWM binding in pwm.txt in this directory. - and pwm.txt would say: - The PWM specifier should include a flags cell to contain standard PWM flags. Values for that cell are defined in dt-bindings/pwm/pwm.h. - Which is somewhat like following a lot of symlinks. Still, I agree that's arguably the correct thing to do. Yes, I like this a whole lot better than the current situation. It gets us almost automatic consistency, which is harder to do with the current approach. Thierry signature.asc Description: Digital signature
Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Сряда, 2013, Юли 10 20:45:26 EEST
On Wed, Jul 10, 2013 at 02:59:04PM +0200, Pali Rohár wrote:
Other secure functions omap_smc1() and omap_smc2() calling instruction smc
#0
but Nokia RX-51 board needs to call smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
arch/arm/mach-omap2/omap-secure.h |1 +
arch/arm/mach-omap2/omap-smc.S| 22 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..5c02b8d 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* 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
@@ -54,6 +56,24 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r12, lr}
You don't need to save/restore r12. The ABI allows it to be clobbered
across function calls.
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb
+ dmb
dsb synchronises a superset of what dmb synchronises, so the dmb here is
not useful.
In any case, any code calling this must flush the region addressed by
r3 beforehand anyway, which will include a dsb as part of its semantics
-- this is how you call it from rx51_secure_dispatcher().
So I think the dsb may not be needed here (?)
Cheers
---Dave
Could be, but I wonder why almost all the kernel code(I am aware of) that uses
SMC and is written by TI, is storing r12 and is using both DSB and DMB. See
arch/arm/mach-omap2/sleep34xx.S or arch/arm/mach-omap2/omap-smc.S for examples.
I'd rather play it safe and leave it that way, unless someone confirms the
other code using SMC has extra DSB/DMB instructions too. I wouldn't risk
passing invalid/stale data to the Secure Monitor to just save 8 bytes and
barriers in a performance non-critical code which will be called only a couple
of times during the boot-up process. r12 save/restore is a legacy from
omap_smc2 in omap-smc.S, so I guess it can go away without much of a trouble.
--
To unsubscribe from this list: send the line unsubscribe 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 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On Thursday 11 July 2013 03:43 PM, Ивайло Димитров wrote:
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Сряда, 2013, Юли 10 20:45:26 EEST
On Wed, Jul 10, 2013 at 02:59:04PM +0200, Pali Rohár wrote:
Other secure functions omap_smc1() and omap_smc2() calling instruction
smc #0
but Nokia RX-51 board needs to call smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
arch/arm/mach-omap2/omap-secure.h |1 +
arch/arm/mach-omap2/omap-smc.S| 22 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S
b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..5c02b8d 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* 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
@@ -54,6 +56,24 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r12, lr}
You don't need to save/restore r12. The ABI allows it to be clobbered
across function calls.
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb
+ dmb
dsb synchronises a superset of what dmb synchronises, so the dmb here is
not useful.
In any case, any code calling this must flush the region addressed by
r3 beforehand anyway, which will include a dsb as part of its semantics
-- this is how you call it from rx51_secure_dispatcher().
So I think the dsb may not be needed here (?)
Cheers
---Dave
Could be, but I wonder why almost all the kernel code(I am aware of) that
uses SMC and is written by TI, is storing r12 and is using both DSB and DMB.
See arch/arm/mach-omap2/sleep34xx.S or arch/arm/mach-omap2/omap-smc.S for
examples. I'd rather play it safe and leave it that way, unless someone
confirms the other code using SMC has extra DSB/DMB instructions too. I
wouldn't risk passing invalid/stale data to the Secure Monitor to just save 8
bytes and barriers in a performance non-critical code which will be called
only a couple of times during the boot-up process. r12 save/restore is a
legacy from omap_smc2 in omap-smc.S, so I guess it can go away without much
of a trouble.
Dave pointed out about the dsb and r12 to me in another thread. R12 can be
easily removed
but the DSB's were needed on OMAP for power sequencing. Without those, we have
seen
many issues. So you can leave the dsb's to be consistent with rest of the code.
Regards
Santosh
P.S: Please sensibly wrap your message while replying. You reply apears like
one single line and I needed to keep scrolling to read it.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On 07/11/2013 01:32 PM, Thierry Reding wrote: On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote: On 07/11/2013 09:36 AM, Thierry Reding wrote: On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote: [...] diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index de0eaed..be09be4 100644 --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt @@ -4,9 +4,9 @@ Required properties: - compatible: should be atmel,tcb-pwm - #pwm-cells: Should be 3. The first cell specifies the per-chip index of the PWM to use, the second cell is the period in nanoseconds and - bit 0 in the third cell is used to encode the polarity of PWM output. - Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity - set to 0 for normal polarity. + the third cell is used to encode the polarity of PWM output. Set the + PWM_POLARITY_NORMAL flag for normal polarity or the PWM_POLARITY_INVERSED + flag for inverted polarity. PWM flags are defined in dt-bindings/pwm/pwm.h. - tc-block: The Timer Counter block to use as a PWM chip. Example: I'd prefer for the original text to stay in place and the reference to the dt-bindings/pwm/pwm.h file to go below that block. I disagree here. The whole point of creating header files for the constants in binding definitions was so that you wouldn't have to duplicate all the values into the binding definitions. Rather, you'd simply say see dt-bindings/xxx.h. But that's not something that this patch solves. Well, if the comments I made on the patch re: that linux/pwm.h should simply #include dt-bindings/pwm/pwm.h instead of duplicating the constants, then yet this patch will solve that. There will be a single place where the constants are defined. And it could be solved even in the absence of the header file defining the symbolic constants. If all the standard flags that dt-bindings/pwm/pwm.txt now specifies were to be listed in pwm.txt (they actually are) then referring to that document as the canonical source works equally well. If that's all the happens, then there will still be duplication between pwm.txt and linux/pwm.h. If we can take both of the above for granted, then sure, let's refer to the header from within the generic pwm.txt file and add a reference to that in bindings for drivers that use the standard flags. Another issue might be that people without access to recent versions of DTC won't be able to use the new #include feature, so keeping the documentation backwards compatible seems like a good idea. The dtc source tree is duplicated into the kernel source tree, so that isn't an issue for now. Besides, the dtc version is an entirely unrelated issue to how the documentation is written. Well, not really. If the documentation specifies the binding in a way that the DTC can't handle that's still a problem. People will end up with a DTS that their DTC can't compile. I guess that can be resolved by adding a note to the upstream device tree repository about the minimum required version of DTC. Yes, the separate repository would obviously require a version of dtc that's able to compile the files there; i.e. a version equivalent to what's already in the kernel tree (upstream 1.4.0 specifically). Again, right now, all of the binding docs, the *.dts files, and the dtc required to use them are part of the kernel; a single package, so there's no scope for issues re: using dtc features that aren't supported. If those components get separated later, obviously there will be a requirement to install a specific version of dtc to use with the separated *.dts and binding files. -- To unsubscribe from this list: send the line unsubscribe 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: How to keep DM37x GPIO_162 high during off-mode
Hi Peter, On 07/11/2013 10:00 PM, Peter Barada wrote: On 07/09/2013 11:55 AM, Tony Lindgren wrote: * Peter Barada peter.bar...@logicpd.com [130709 08:14]: I'm working with a 3.0.8 kernel in Android ICS and have run into a problem using wl12xx bluetooth after a suspend/resume cycle. GPIO_162 in this design is connected to the BT_EN pin of the wl12xx and needs to be held high to keep the bluetooth core from resetting while the DM37x goes into off mode. I've tried muxing the pin using OMAP_PIN_OUTPUT | OMAP_PIN_OFF_OUTPUT_HIGH, but the pin goes low when the chip goes into off mode. If I disable off mode via echo 0 /sys/kernel/debug/pm_debug/enable_off_mode the pin remains high while the chip goes into retention and the bluetooth core works after resume. Any ideas why GPIO_162 would go low during suspend to off mode? Unless the GPIO is in a GPIO bank that's connected to the WKUP power domain, the GPIO bank context will be lost. So there's a short period where the GPIO bank is in an uninitialized state between waking from off-idle and before the context to the GPIO bank gets restored in omap_gpio_runtime_resume(). If there's a pull on the line, the period is long enough to change the line. Unless the TI people know some magic tricks that I'm not aware of, there's no way around it, except to use external pulls to keep the GPIO line in desired state, or move the GPIO somewhere else, like TWL. Unfortunately the hardware doesn't have an external pullup, and re-spinning it to route BT_EN to a GPIO pin that's in the WKUP domain isn't an option at this time... Unless there's some TI-magic to keep GPIO_162 high during OFF mode I'll have to solve this the hard way by reinitializing the BT/GPS core during resume using deferred work. Unfirtuantely I don't have a clear understanding of the userspace interaction to know if this is doable. Mechanically it doesn't look too difficult to use the guts of st_register/st_kim_start to reinitialize the GT/GPS core and download its firmware, but the userspace interactions (and the time it takes to load the firmware) is what makes coming up with a good solution difficult. Any suggestions on how to approach solving this are most appreciated! The recommended way is to configure it as INPUT + PULL_UP and don't use OFFMODE feature if the 1 value is needed on port during off-mode. You need to check if you have valid pin-cfg right before call to omap4_enter_lowpower() -omap4_cpu_suspend(cpu, save_state); I recommend you to ask you questions here: http://e2e.ti.com/support/omap/default.aspx Regards, - grygorii -- To unsubscribe from this list: send the line unsubscribe 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: How to keep DM37x GPIO_162 high during off-mode
On 07/11/2013 04:15 PM, Grygorii Strashko wrote: Hi Peter, On 07/11/2013 10:00 PM, Peter Barada wrote: On 07/09/2013 11:55 AM, Tony Lindgren wrote: * Peter Barada peter.bar...@logicpd.com [130709 08:14]: I'm working with a 3.0.8 kernel in Android ICS and have run into a problem using wl12xx bluetooth after a suspend/resume cycle. GPIO_162 in this design is connected to the BT_EN pin of the wl12xx and needs to be held high to keep the bluetooth core from resetting while the DM37x goes into off mode. I've tried muxing the pin using OMAP_PIN_OUTPUT | OMAP_PIN_OFF_OUTPUT_HIGH, but the pin goes low when the chip goes into off mode. If I disable off mode via echo 0 /sys/kernel/debug/pm_debug/enable_off_mode the pin remains high while the chip goes into retention and the bluetooth core works after resume. Any ideas why GPIO_162 would go low during suspend to off mode? Unless the GPIO is in a GPIO bank that's connected to the WKUP power domain, the GPIO bank context will be lost. So there's a short period where the GPIO bank is in an uninitialized state between waking from off-idle and before the context to the GPIO bank gets restored in omap_gpio_runtime_resume(). If there's a pull on the line, the period is long enough to change the line. Unless the TI people know some magic tricks that I'm not aware of, there's no way around it, except to use external pulls to keep the GPIO line in desired state, or move the GPIO somewhere else, like TWL. Unfortunately the hardware doesn't have an external pullup, and re-spinning it to route BT_EN to a GPIO pin that's in the WKUP domain isn't an option at this time... Unless there's some TI-magic to keep GPIO_162 high during OFF mode I'll have to solve this the hard way by reinitializing the BT/GPS core during resume using deferred work. Unfirtuantely I don't have a clear understanding of the userspace interaction to know if this is doable. Mechanically it doesn't look too difficult to use the guts of st_register/st_kim_start to reinitialize the GT/GPS core and download its firmware, but the userspace interactions (and the time it takes to load the firmware) is what makes coming up with a good solution difficult. Any suggestions on how to approach solving this are most appreciated! The recommended way is to configure it as INPUT + PULL_UP and don't use OFFMODE feature if the 1 value is needed on port during off-mode. You need to check if you have valid pin-cfg right before call to omap4_enter_lowpower() -omap4_cpu_suspend(cpu, save_state); I recommend you to ask you questions here: http://e2e.ti.com/support/omap/default.aspx Regards, - grygorii Grygoril, Part of our requirements is to go to OFFMODE during suspend. I believe the pin is properly muxed since if I disable OFFMODE then GPIO_162 does stay high. From the TRM (if I understand it correctly) the only pins that will retain OFF-mode state high are those pins that are located in the WKUP domain. Given the requirement of OFFMODE and that we can't spin the hardware to move BT_EN to a gpio pin in the WKUP domain I'm stuck trying to figure out how to reinit/reload the firmware during resume. Any suggestions (or gotchas) are appreciated! -- Peter Barada peter.bar...@logicpd.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: omap3-igep0020: add mux conf for GPIO LEDs
On Thu, Jun 20, 2013 at 4:42 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The IGEPv2 has a number of GPIO LED connected to OMAP
pins. Configure these pins as output GPIO.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep0020.dts | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..51c084e 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -16,7 +16,10 @@
compatible = isee,omap3-igep0020, ti,omap3;
leds {
+ pinctrl-names = default;
+ pinctrl-0 = leds_pins;
compatible = gpio-leds;
+
boot {
label = omap3:green:boot;
gpios = gpio1 26 GPIO_ACTIVE_HIGH;
@@ -54,6 +57,14 @@
};
};
+leds_pins {
+ pinctrl-single,pins =
+ 0x5c4 (PIN_OUTPUT | MUX_MODE4) /* etk_d12.gpio_26 */
+ 0x5c6 (PIN_OUTPUT | MUX_MODE4) /* etk_d13.gpio_27 */
+ 0x5c8 (PIN_OUTPUT | MUX_MODE4) /* etk_d14.gpio_28 */
+ ;
+};
+
i2c3 {
clock-frequency = 10;
--
1.7.7.6
--
Hi Benoit,
These patches are actually a fix since without setting the mux pin for
the GPIO makes the gpio led driver probe fails and the user leds are
not available. So, it would be possible to add these as part of the
3.11 -rc cycle fixes?
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Boot hang regression 3.10.0-rc4 - 3.10.0
On 07/11/2013 04:59 AM, Grygorii Strashko wrote: Hi, On 07/11/2013 09:32 AM, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [130710 09:18]: On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote: how about something like below ? It makes omap_device/hwmod and pm_runtime agree on the initial state of the device and will prevent -runtime_resume() from being called on first pm_runtime_get*() done during probe. This is similar to what PCI bus does (if you look at pci_pm_init()). commit 59108a500b4ab4b1a5102648a3360276dbf7df6f Author: Felipe Balbi ba...@ti.com Date: Wed Jul 10 18:50:16 2013 +0300 arm: omap2plus: unidle devices which are about to probe in order to make HWMOD and pm_runtime agree on the initial state of the device, we will unidle the device and call pm_runtime_set_active() to tell pm_runtime that the device is really active. Don't think that it's good idea ( I've checked some driver's and think this patch will enable some devices unpredictably: - hwspinlock - mailbox - iommu - ipu All above devices need to be enabled on demand only (no pm_runtime_get*() calls in probe). More over, some of them have very specific enabling sequence - like ipu). May be Summan can say more on that. Indeed, this is a problem for any of the slave processor devices. mailbox and iommu would be slaves to the remoteproc and the drivers have a specific sequence of bringing up a processor. The current hwmod/omap_device code is such that these devices will be left in reset and the driver code use the omap_device_(de)assert_hardreset API together with omap_device_enable code to bring up the devices. The remoteproc driver also needs to assert the resets (there are other problems associated with using omap_device_idle for remoteproc and iommu) for bringing up the devices after a suspend sequence. hwspinlock and mailbox may get away since they are in CORE domain, but definitely an issue for iommu and remoteproc. I would think that this would also affect other compute devices like IVAHD, ISS, SGX. regards Suman By the time driver's probe() is reached, a call to pm_runtime_get_sync() will not cause driver's -runtime_resume() method to be called at first, only after a successful -runtime_suspend(). Signed-off-by: Felipe Balbi ba...@ti.com btw, this is RFC, haven't tested at all. Yes it does not compile, then removing the extra ; at the end of the functions, it oopses with a NULL pointer exception. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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 04/12] drivers/mmc/host: don't use devm_pinctrl_get_select_default() in probe
2013/7/10 Wolfram Sang w...@the-dreams.de: Since commit ab78029 (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Compile tested only. Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13) Signed-off-by: Wolfram Sang w...@the-dreams.de --- drivers/mmc/host/mvsdio.c |6 -- drivers/mmc/host/mxs-mmc.c |8 drivers/mmc/host/omap_hsmmc.c |7 --- drivers/mmc/host/sdhci-esdhc-imx.c |8 drivers/mmc/host/sdhci-sirf.c |8 Wolfram, this has been done for sirf, which version are you based on? 5 files changed, 37 deletions(-) -barry -- To unsubscribe from this list: send the line unsubscribe 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: find real users and drivers of rpmsg
2013/7/10 Anna, Suman s-a...@ti.com: Barry, On Mon, Jul 8, 2013 at 10:31 AM, Barry Song 21cn...@gmail.com wrote: hi Ohad/all, i am trying to find some real users of rpmsg, here i only get samples/rpmsg/rpmsg_client_sample.c, does it mean other real drivers are out of mainline? Yes where could i get them? TI maintains them in internal trees, some of which might be public. I'm looping in Suman from TI who might be able to refer you to some You will find couple of rpmsg client drivers in our product kernels. Following is a kernel used towards our Android product, you can look in the drivers/rpmsg folder. http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p- linux-omap-3.4 yes. i have repmsg-resmgr and repmsg-omx now. and i also have sysbios-rpmsg and domx. thanks! i am also trying to find source codes running in Cortex-M3 which use rpmsg and hope to find some Linux userspace codes which use rpmsg too. Thanks barry Some information from the following wiki might also be handy (kinda old, but still useful) for you to find the equivalent code running on the Cortex-M3 http://omappedia.org/wiki/Category:RPMsg DOMX(Distributed OpenMAX for OMAP4 processors) on the page seems to be based on syslink and lose maintaince for 3 years, where can i get a new version based on rpmsg? Look through the following project, http://git.omapzoom.org/?p=platform/hardware/ti/domx.git;a=shortlog;h=refs/heads/p-jb-mr1-release thanks, Anna. regards Suman -barry -barry -- To unsubscribe from this list: send the line unsubscribe 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 RESEND] PM / AVS: SmartReflex: remove redundant dev_err call in omap_sr_probe()
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Nishanth Menon n...@ti.com
---
cc to linux-pm with Nishanth Menon's ACK
---
drivers/power/avs/smartreflex.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index db9973b..c26acfc 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -871,10 +871,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sr_info-base = devm_ioremap_resource(pdev-dev, mem);
- if (IS_ERR(sr_info-base)) {
- dev_err(pdev-dev, %s: ioremap fail\n, __func__);
+ if (IS_ERR(sr_info-base))
return PTR_ERR(sr_info-base);
- }
irq = platform_get_resource(pdev, IORESOURCE_IRQ, 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
