Question about OABI_COMPAT feature in do_signal() function
Hello Russell, It's an honor to mail you. I'm writing this mail to ask you about the OABI_COMPAT feature in do_signal() function. After freezing and thawing user processes for Suspend-To-Ram, I found that some user processes(e.g. daemon processes) make prefetch abort continuously. And finally, I found that the following code in do_signal() was the root cause: /* arch/arm/kernel/signal.c: near 677 line */ put_user(regs-ARM_pc, usp[0]); /* swi __NR_restart_syscall */ put_user(0xef00 | swival, usp[1]); /* ldr pc, [sp], #12 */ put_user(0xe49df00c, usp[2]); It seems that this code makes processes execute in stack area to re-enter kernel area. However, when PC is in stack area, I saw that it *continuously* make data abort exception. (Process stack area is in general non executable area) I'm using OMAP3430 board whose core is Cotex-A8 and with enabling both CONFIG_AEABI and CONFIG_OABI_COMPAT. Can I ask your comments or idea about this problem? Regards, Kyuwon (규원) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
ext Nayak, Rajendra wrote: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, April 25, 2009 4:21 AM To: Roger Quadros Cc: Nayak, Rajendra; linux-omap Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver Roger Quadros ext-roger.quad...@nokia.com writes: ext Kevin Hilman wrote: [...] Rajendra, This series seems to boot on SDP and Beagle but I recetly tried on RX51 and it hangs in omap3_sr_init(). Using Lauterbach, I tracked it to hang in sr_configure_vp() at this PRM write to the PRM_VP1_VLIMITTO register: prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX | PRM_VP1_VLIMITTO_VDDMIN | PRM_VP1_VLIMITTO_TIMEOUT, OMAP3430_GR_MOD, OMAP3_PRM_VP1_VLIMITTO_OFFSET); Should these min/max/timeout values be board specific? [...] It runs on rx51 if we set CONFIG_OMAP_PM_SRF instead of CONFIG_OMAP_PM_NOOP. Should Smartreflex option be dependent or independent of the CONFIG_OMAP_PM_??? setting? I see the same thing on SDP as well as RX51. It looks like the new SR code assumes a range of OPPs, but when OMAP_PM_NONE is enabled, the omap_pm_vddX_get_opp() calls always return zero. In the mpu_opps array, the first entry is all zeros, resulting in a zero VSEL which is then used to (re)program the VP. The SR code should probably be a bit smarter about checking for valid values. Kevin, I'll send in a patch to fix that. thanks, Rajendra I think the the X_get_opp() and X_get_freq() calls should be returning sane values irrespective of PM layer (i.e. OMAP_PM_NOOP or OMAP_PM_NONE). I have a patchset which does this with a little help from resource.c to get the current OPP/frequency. This fixes boot on RX51 for both PM_NOOP and PM_NONE with SMARTREFLEX enabled. I just want to know if this is the right way to do. I think it would be because Smartreflex or any other future driver will not have to worry about which PM layer is selected. I will send my patchset as an RFC. regards, -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: [RFC] [Patch 0/2] Proposal for changes to TWL4030/TWL5030 framework for integrating the new TWL6030 chip
On Tue, Apr 28, 2009 at 07:24:30AM +0200, ext Pakaravoor, Jagadeesh wrote:
Hi folks,
We have a new TWL6030 chip that is coming in. In brief, the following are
the changes w.r.t. TWL5030:
0. This is the companion chip for OMAP4430.
1. Unlike in TWL5030, audio and power chips are going to be separate chips as
TWL6030 and TWL6031.
2. Keypad and GPIO features are no more present in TWL6030 (the power
companion chip). They all move into OMAP.
4. Register and module base names/addresses changes (as expected from 2).
5. Changes in interrupt framework:
- No more PIH and SIH
- 3 ISRs INT_STS_A, INT_STS_B and INT_STS_C at 3 consecutive address
locations (that will allow an I2C burst read).
6. The modules that are inherited from TWL5030 to TWL6030 remain same (like
RTC, BCI) except MADC with some minor changes making it a General Purpose ADC
(GPADC).
I'd like to propose a new generic framework that will incorporate
TWL4030/TWL5030 and TWL6030 functionalities/changes seamlessly.
Proposal
1. Rename all registers/functions etc. from twl4030/TWL4030 to twl/TWL.
- This would allow unchanged modules (like RTC) to work in the same
way, transparent to whether it is part of TWL4030 or TWL6030.
2. Have a new twl.c file, that will define functions like
- twl_i2c_write
- twl_i2c_write_u8
- twl_i2c_read
- twl_i2c_read_u8
- twl_init
- twl_exit
- twl_probe
- twl_remove
These functions implement the functionalities common to both TWL4030 and
TWL6030, doing away with the need to have a copy of these functions in two
places.
3. twl4030-core.c and twl4030-irq.c files will define functions that changes
between TWL4030 and TWL6030, like:
- add_children(): We do not need keypad and GPIO; MADC changes to GPADC
in case of TWL6030.
- twl_irq_thread() twl4030-irq.c: We have new registers to read
interrupts from. No more PIH and SIH. So the core loop that dispatches the
interrupt changes. We can also use an I2C burst read to get 3 interrupt
registers in one shot for TWL6030.
4. New twl6030-core.c and twl6030-irq.c that implements the TWL6030 counter
parts of functions applicable in (3).
5. A config option will determine whether TWL4030 or TWL6030 will be compiled
as a part of the kernel.
NB:
==
Please note that the patches are for RFC, and they might not even compile
properly. These are draft patches to convey the idea across. So please ignore
styling and formatting errors.
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 769b34b..c6eec75 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -176,6 +176,7 @@
/* chip-specific feature flags, for i2c_device_id.driver_data */
#define TWL4030_VAUX2 BIT(0) /* pre-5030 voltage ranges */
#define TPS_SUBSET BIT(1) /* tps659[23]0 have fewer LDOs
*/
+#define TWL6030BIT(2) /* twl6030 doesn't have
gpio nor keypad */
/*--*/
@@ -496,7 +497,8 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
return PTR_ERR(child);
}
- if (twl_has_keypad() pdata-keypad) {
+ if (twl_has_keypad() pdata-keypad
+ !(features TLW6030)) {
child = add_child(2, twl4030_keypad,
pdata-keypad, sizeof(*pdata-keypad),
true, pdata-irq_base + 1, 0);
You'd probably only need to make changes to register defines but almost
everything else could remain as is. There shouldn't be any need for
creating separate files.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [Patch 0/2] Proposal for changes to TWL4030/TWL5030 framework for integrating the new TWL6030 chip
- if (twl_has_keypad() pdata-keypad) {
+ if (twl_has_keypad() pdata-keypad
+ !(features TLW6030)) {
child = add_child(2, twl4030_keypad,
pdata-keypad, sizeof(*pdata-keypad),
true, pdata-irq_base + 1, 0);
You'd probably only need to make changes to register defines but almost
everything else could remain as is. There shouldn't be any need for
creating separate files.
Patch 0, of the series explains the differences between TWL4030 and TWL6030.
Going the aforesaid way, we will need checks like this in almost every other
line of code. And I believe having a separate file would be more modular, and
hence readable (a twl.c which will bind with twl4030-core.c and twl4030-irq.c
if TWL4030 is selected, and twl6030-core.c and twl6030-irq.c if TWL6030 is
selected).
I am not sure how we can incorporate all the hardware changes by just changing
register addresses.
--
Jagadeesh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator core: fix double-free in regulator_register() error path
On Tuesday 28 April 2009, Mark Brown wrote: For the record, that incomplete constraints message is bogus. On that board, VAUX3 has a complete set of constraints: it may only emit 2.8V. It's not VAUX3 that it's saying has incomplete constraints, it's the board as a whole - if the constraints for the board were fully specified No; driver support != constraint. Only one of the issues is packaged as a constraint. (and the core had been told about it) then it would power off VAUX3 at that point. Mark and/or Liam ... you might want to fix that diagnostic, to avoid leading more developers astray! Probably shove a board has in there or something I guess. How about: VAUX3 board support is incomplete. That's accurate. A comment there might suggest constraints and driver support as two common issues ... I'd not be surprised to see a few more idioms pop up. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: PM: Fix boot with OMAP_SMARTREFLEX and OMAP_PM_NOOP
Return sane values for all *_get_opp() and *_get_freq() functions.
Other modules e.g. Smartreflex will be requiring sane values of OPP
and CPU Frequency irrespective of the PM layer being used.
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/plat-omap/Makefile |3 ++-
arch/arm/plat-omap/omap-pm-noop.c | 15 ++-
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c58bab4..b82df3f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX)+= smartreflex.o
obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o
obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o
obj-$(CONFIG_OMAP_PM_SRF) += resource34xx.o
+obj-$(CONFIG_OMAP_PM_NOOP) += resource34xx.o
# DSP
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 3d7b517..038cdaf 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -27,6 +27,7 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o \
+ resource.o
obj-$(CONFIG_OMAP_PM_SRF) += omap-pm-srf.o \
resource.o
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index 490bc8e..f384df3 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -23,7 +23,7 @@
/* Interface documentation is in mach/omap-pm.h */
#include mach/omap-pm.h
-
+#include mach/resource.h
#include mach/powerdomain.h
struct omap_opp *dsp_opps;
@@ -194,8 +194,7 @@ u8 omap_pm_dsp_get_opp(void)
* Call clk_get_rate() on the OPP custom clock, map that to an
* OPP ID using the tables defined in board-*.c/chip-*.c files.
*/
-
- return 0;
+ return resource_get_level(vdd1_opp);
}
u8 omap_pm_vdd1_get_opp(void)
@@ -205,8 +204,7 @@ u8 omap_pm_vdd1_get_opp(void)
/*
* For l-o call resource_get_level of vdd1_opp resource.
*/
-
- return 0;
+ return resource_get_level(vdd1_opp);
}
u8 omap_pm_vdd2_get_opp(void)
@@ -216,8 +214,7 @@ u8 omap_pm_vdd2_get_opp(void)
/*
* For l-o call resource_get_level of vdd2_opp resource.
*/
-
- return 0;
+ return resource_get_level(vdd2_opp);
}
/*
@@ -267,8 +264,7 @@ unsigned long omap_pm_cpu_get_freq(void)
/*
* Call clk_get_rate() on the mpu_ck.
*/
-
- return 0;
+ return resource_get_level(mpu_freq);
}
/*
@@ -345,6 +341,7 @@ int __init omap_pm_if_early_init(struct omap_opp
*mpu_opp_table,
/* Must be called after clock framework is initialized */
int __init omap_pm_if_init(void)
{
+ resource_init(resources_omap);
return 0;
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [Patch 0/2] Proposal for changes to TWL4030/TWL5030 framework for integrating the new TWL6030 chip
Jagadeesh,
We are also working on similar lines and I have already sent a RFC to
discuss it further in the community. Please have a look at the below
link and provide your comments:
http://marc.info/?l=linux-omapm=124083364321017w=2
Regards,
Anuj Aggarwal
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Pakaravoor, Jagadeesh
Sent: Tuesday, April 28, 2009 2:42 PM
To: felipe.ba...@nokia.com
Cc: linux-omap@vger.kernel.org
Subject: RE: [RFC] [Patch 0/2] Proposal for changes to TWL4030/TWL5030
framework for integrating the new TWL6030 chip
- if (twl_has_keypad() pdata-keypad) {
+ if (twl_has_keypad() pdata-keypad
+ !(features TLW6030)) {
child = add_child(2, twl4030_keypad,
pdata-keypad, sizeof(*pdata-keypad),
true, pdata-irq_base + 1, 0);
You'd probably only need to make changes to register defines but almost
everything else could remain as is. There shouldn't be any need for
creating separate files.
Patch 0, of the series explains the differences between TWL4030 and TWL6030.
Going the aforesaid way, we will need checks like this in almost every other
line of code. And I believe having a separate file would be more modular, and
hence readable (a twl.c which will bind with twl4030-core.c and twl4030-irq.c
if
TWL4030 is selected, and twl6030-core.c and twl6030-irq.c if TWL6030 is
selected).
I am not sure how we can incorporate all the hardware changes by just
changing register addresses.
--
Jagadeesh
--
To unsubscribe from this list: send the line unsubscribe 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] regulator core: fix double-free in regulator_register() error path
On Tue, Apr 28, 2009 at 02:32:56AM -0700, David Brownell wrote: On Tuesday 28 April 2009, Mark Brown wrote: It's not VAUX3 that it's saying has incomplete constraints, it's the board as a whole - if the constraints for the board were fully specified No; driver support != constraint. Only one of the issues is packaged as a constraint. Driver support isn't particularly relevant here. If there are devices that don't have drivers or don't have drivers with regulator support but need a regulator enabling then the board should mark the regulator as always_on when setting full constraints; the always_on flag can be removed when the required consumers are added. Mark and/or Liam ... you might want to fix that diagnostic, to avoid leading more developers astray! Probably shove a board has in there or something I guess. How about: VAUX3 board support is incomplete. That's accurate. No. The constraints being complete is a property of the board as a whole and not the particular regulator. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Allow disabling wakeup for serial ports, including during off mode.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Russ Dill
Sent: Tuesday, April 28, 2009 12:58 AM
To: linux-omap@vger.kernel.org
Cc: Russ Dill
Subject: [RFC] Allow disabling wakeup for serial ports,
including during off mode.
This patch causes the OMAP uarts to honor the sysfs
power/wakeup file for
IOPADs. Before the OMAP was always woken up from off mode on
a rs232 signal
change.
This patch also creates a different platform device for each serial
port so that the wakeup properties can be control per port.
The patch is not in a complete state, but for my testing it
was necessary
to disable rs232 wakeup as allowing the signals to float in
off mode by
powering off the level converters was causing a wakeup event.
---
arch/arm/mach-omap2/serial.c | 165
--
1 files changed, 126 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 0762165..95b047a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -49,6 +49,7 @@ struct omap_uart_state {
struct plat_serial8250_port *p;
struct list_head node;
+ struct platform_device pdev;
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
int context_valid;
@@ -63,10 +64,9 @@ struct omap_uart_state {
#endif
};
-static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS];
static LIST_HEAD(uart_list);
-static struct plat_serial8250_port serial_platform_data[] = {
+static struct plat_serial8250_port serial_platform_data0[] = {
[sp] Is it necessary to split the array?
{
.membase= IO_ADDRESS(OMAP_UART1_BASE),
.mapbase= OMAP_UART1_BASE,
@@ -76,6 +76,12 @@ static struct plat_serial8250_port
serial_platform_data[] = {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
+ .flags = 0
+ }
+};
+
+static struct plat_serial8250_port serial_platform_data1[] = {
+ {
.membase= IO_ADDRESS(OMAP_UART2_BASE),
.mapbase= OMAP_UART2_BASE,
.irq= 73,
@@ -84,6 +90,12 @@ static struct plat_serial8250_port
serial_platform_data[] = {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
+ .flags = 0
+ }
+};
+
+static struct plat_serial8250_port serial_platform_data2[] = {
+ {
.membase= IO_ADDRESS(OMAP_UART3_BASE),
.mapbase= OMAP_UART3_BASE,
.irq= 74,
@@ -197,6 +209,40 @@ static inline void
omap_uart_save_context(struct omap_uart_state *uart) {}
static inline void omap_uart_restore_context(struct
omap_uart_state *uart) {}
#endif /* CONFIG_ARCH_OMAP3 */
+static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
+{
+ /* Set wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v |= uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+
+ /* Ensure IOPAD wake-enables are set */
+ if (cpu_is_omap34xx() uart-padconf) {
+ u16 v = omap_ctrl_readw(uart-padconf);
+ v |= OMAP3_PADCONF_WAKEUPENABLE0;
+ omap_ctrl_writew(v, uart-padconf);
+ }
+}
+
+static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
+{
+ /* Clear wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v = ~uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+
+ /* Ensure IOPAD wake-enables are cleared */
+ if (cpu_is_omap34xx() uart-padconf) {
+ u16 v = omap_ctrl_readw(uart-padconf);
+ v = ~OMAP3_PADCONF_WAKEUPENABLE0;
+ omap_ctrl_writew(v, uart-padconf);
+ }
+}
+
static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
int enable)
{
@@ -220,6 +266,11 @@ static inline void
omap_uart_restore(struct omap_uart_state *uart)
static inline void omap_uart_disable_clocks(struct
omap_uart_state *uart)
{
+ if (device_may_wakeup(uart-pdev.dev))
+ omap_uart_enable_wakeup(uart);
+ else
+ omap_uart_disable_wakeup(uart);
+
if (!uart-clocked)
return;
@@ -290,6 +341,7 @@ void omap_uart_resume_idle(int num)
if (__raw_readl(uart-wk_st) uart-wk_mask)
omap_uart_block_sleep(uart);
+ omap_uart_enable_wakeup(uart);
return;
}
}
@@ -300,6 +352,7 @@ void omap_uart_prepare_suspend(void)
struct omap_uart_state *uart;
[RFC][PATCH 0/2] OMAP: PM: Fix boot with SMARTREFLEX and PM_NOOP/PM_NONE
Resending in the correct format. This series fixes booting when OMAP_SMARTREFLEX is enabled along with OMAP_PM_NOOP or OMAP_PM_NONE. Patches apply on top of pm branch of Kevin's pm tree. git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git regards, -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][DSPBRIDGE] Add the device after driver initialization
From: Ameya Palande ameya.pala...@nokia.com
This prevents a panic caused by an IOCTL call before driver
completes its initialization.
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/rmgr/drv_interface.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 9466409..b562513 100755
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -298,14 +298,6 @@ static int __devinit omap34xx_bridge_probe(struct
platform_device *pdev)
bridge_device-cdev.owner = THIS_MODULE;
bridge_device-cdev.ops = bridge_fops;
- status = cdev_add(bridge_device-cdev, dev, 1);
-
- if (status) {
- GT_0trace(driverTrace, GT_7CLASS,
- Failed to add the bridge device \n);
- return status;
- }
-
/* udev support */
bridge_class = class_create(THIS_MODULE, ti_bridge);
@@ -429,6 +421,12 @@ static int __devinit omap34xx_bridge_probe(struct
platform_device *pdev)
} else {
GT_0trace(driverTrace, GT_5CLASS,
DSP/BIOS Bridge driver loaded\n);
+ /* Announce to kernel that we are ready */
+ status = cdev_add(bridge_device-cdev, dev, 1);
+ if (status) {
+ GT_0trace(driverTrace, GT_7CLASS,
+ Failed to add the bridge device \n);
+ }
}
}
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 1/2] OMAP: PM: Fix boot with OMAP_SMARTREFLEX and OMAP_PM_NOOP
From: Roger Quadros ext-roger.quad...@nokia.com
Return sane values for all *_get_opp() and *_get_freq() functions.
Other modules e.g. Smartreflex will be requiring sane values of OPP
and CPU Frequency irrespective of the PM layer being used.
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/plat-omap/Makefile |3 ++-
arch/arm/plat-omap/omap-pm-noop.c | 15 ++-
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c58bab4..b82df3f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX)+= smartreflex.o
obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o
obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o
obj-$(CONFIG_OMAP_PM_SRF) += resource34xx.o
+obj-$(CONFIG_OMAP_PM_NOOP) += resource34xx.o
# DSP
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 3d7b517..038cdaf 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -27,6 +27,7 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o \
+ resource.o
obj-$(CONFIG_OMAP_PM_SRF) += omap-pm-srf.o \
resource.o
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index 490bc8e..f384df3 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -23,7 +23,7 @@
/* Interface documentation is in mach/omap-pm.h */
#include mach/omap-pm.h
-
+#include mach/resource.h
#include mach/powerdomain.h
struct omap_opp *dsp_opps;
@@ -194,8 +194,7 @@ u8 omap_pm_dsp_get_opp(void)
* Call clk_get_rate() on the OPP custom clock, map that to an
* OPP ID using the tables defined in board-*.c/chip-*.c files.
*/
-
- return 0;
+ return resource_get_level(vdd1_opp);
}
u8 omap_pm_vdd1_get_opp(void)
@@ -205,8 +204,7 @@ u8 omap_pm_vdd1_get_opp(void)
/*
* For l-o call resource_get_level of vdd1_opp resource.
*/
-
- return 0;
+ return resource_get_level(vdd1_opp);
}
u8 omap_pm_vdd2_get_opp(void)
@@ -216,8 +214,7 @@ u8 omap_pm_vdd2_get_opp(void)
/*
* For l-o call resource_get_level of vdd2_opp resource.
*/
-
- return 0;
+ return resource_get_level(vdd2_opp);
}
/*
@@ -267,8 +264,7 @@ unsigned long omap_pm_cpu_get_freq(void)
/*
* Call clk_get_rate() on the mpu_ck.
*/
-
- return 0;
+ return resource_get_level(mpu_freq);
}
/*
@@ -345,6 +341,7 @@ int __init omap_pm_if_early_init(struct omap_opp
*mpu_opp_table,
/* Must be called after clock framework is initialized */
int __init omap_pm_if_init(void)
{
+ resource_init(resources_omap);
return 0;
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator core: fix double-free in regulator_register() error path
On Tue, Apr 28, 2009 at 04:47:52AM -0700, David Brownell wrote: On Tuesday 28 April 2009, Mark Brown wrote: On Tue, Apr 28, 2009 at 02:32:56AM -0700, David Brownell wrote: What it lacks is something entirely different: ?driver support for the LCD which uses the regulator framework, It's not VAUX3 that it's saying has incomplete constraints, it's the board as a whole - if the constraints for the board were fully specified No; driver support != constraint. Only one of the issues is packaged as a constraint. Driver support isn't particularly relevant here. It's the *entire* point. The driver is talking directly to the regulator, bypassing this framework. The constraints on that regulator are fully defined ... and then bypassed. Ah, I see - I didn't realise that there was driver support that doesn't use the regulator API, that had been dropped out of context by that point in the discussion. I guess the LCD driver will be converted to use the API in due course, hopefully there aren't too many other such drivers. This is the sort of use case that made me not want to have the API disable unused regulators by default - there's stuff going on that the regulator API and the code using it doesn't know about (since it's going through some other interface to do the job in this case) so the API can't safely do anything to that regulator. How about: VAUX3 board support is incomplete. That's accurate. No. The constraints being complete is a property of the board as a whole and not the particular regulator. Except ... that constraint isn't the issue, it's unexpected driver behavior. And board is exactly This is sufficiently unexpected that it's the first time I've seen anything bypassing the regulator API; in any case, it's just a question of where you see the problem coming from. My terminology comes from the fact that as far as the core is concerned the issue is that the board didn't say it had given the core complete constraints allowing it to fully control the regulators that are visible to it. The reason the board didn't do that is that is that the LCD driver is bypassing the regulator API and the regulator API doesn't have any way to express that possibility. what I said, so I don't know why you're arguing. (For the fun of it?) David, that is really not necessary or constructive. This sort of disparaging remark has been a constant feature of your interactions on regulator API issues and it is not achieving anything useful. Board support includes full driver support, as well as board setup (constraints). That's the common way to factor it, at any rate -- a board support package addresses both, and they need to work together. s/board/machine driver/; in an ideal world for Linux there is no BSP, it's all mainline. -- To unsubscribe from this list: send the line unsubscribe 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][DSPBRIDGE][v2] Add the device after driver initialization
From: Ameya Palande ameya.pala...@nokia.com
This prevents a panic caused by an IOCTL call before driver completes its
initialization.
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/rmgr/drv_interface.c | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 9466409..79f75c9 100755
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -298,14 +298,6 @@ static int __devinit omap34xx_bridge_probe(struct
platform_device *pdev)
bridge_device-cdev.owner = THIS_MODULE;
bridge_device-cdev.ops = bridge_fops;
- status = cdev_add(bridge_device-cdev, dev, 1);
-
- if (status) {
- GT_0trace(driverTrace, GT_7CLASS,
- Failed to add the bridge device \n);
- return status;
- }
-
/* udev support */
bridge_class = class_create(THIS_MODULE, ti_bridge);
@@ -328,14 +320,6 @@ static int __devinit omap34xx_bridge_probe(struct
platform_device *pdev)
GT_0trace(driverTrace, GT_ENTER, - driver_init\n);
-#ifdef CONFIG_PM
- /* Initialize the wait queue */
- if (!status) {
- bridge_suspend_data.suspended = 0;
- init_waitqueue_head(bridge_suspend_data.suspend_wq);
- }
-#endif
-
SERVICES_Init();
/* Autostart flag. This should be set to true if the DSP image should
@@ -429,6 +413,19 @@ static int __devinit omap34xx_bridge_probe(struct
platform_device *pdev)
} else {
GT_0trace(driverTrace, GT_5CLASS,
DSP/BIOS Bridge driver loaded\n);
+ /* Announce to kernel that we are ready */
+ status = cdev_add(bridge_device-cdev, dev, 1);
+ if (status) {
+ GT_0trace(driverTrace, GT_7CLASS,
+ Failed to add the bridge device \n);
+ }
+ else {
+ #ifdef CONFIG_PM
+ /* Initialize the wait queue */
+ bridge_suspend_data.suspended = 0;
+
init_waitqueue_head(bridge_suspend_data.suspend_wq);
+ #endif
+ }
}
}
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP35x GP TIMER as a wakeup trigger
On Mon, Apr 27, 2009 at 6:17 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Ashwin Bihari abih...@gmail.com writes: I need to implement a timer as a wake up trigger while my custom board is in the suspended state. I read in the TRM that all of the GPTIMERs have the capability of generating a wake up interrupt. I'm using the 2.6.28-rc8 PM Kernel which contains the patch to enable all the GPTIMERS as wake up sources. Try the patch below on the current PM branch. I use this for debugging PM code when no other wakeup sources (keypad, UART, etc. are working.) Kevin Kevin. The patch worked like a charm, thank you very much. -- Ashwin -- To unsubscribe from this list: send the line unsubscribe 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][DSPBRIDGE] Add the device after driver initialization
Hi,
Ameya Palande wrote:
From: Ameya Palande ameya.pala...@nokia.com
This prevents a panic caused by an IOCTL call before driver completes its
initialization.
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/rmgr/drv_interface.c | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 9466409..79f75c9 100755
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -298,14 +298,6 @@ static int __devinit omap34xx_bridge_probe(struct
platform_device *pdev)
bridge_device-cdev.owner = THIS_MODULE;
bridge_device-cdev.ops = bridge_fops;
- status = cdev_add(bridge_device-cdev, dev, 1);
-
- if (status) {
- GT_0trace(driverTrace, GT_7CLASS,
- Failed to add the bridge device \n);
- return status;
- }
-
/* udev support */
bridge_class = class_create(THIS_MODULE, ti_bridge);
@@ -328,14 +320,6 @@ static int __devinit omap34xx_bridge_probe(struct
platform_device *pdev)
GT_0trace(driverTrace, GT_ENTER, - driver_init\n);
-#ifdef CONFIG_PM
- /* Initialize the wait queue */
- if (!status) {
- bridge_suspend_data.suspended = 0;
- init_waitqueue_head(bridge_suspend_data.suspend_wq);
- }
-#endif
-
SERVICES_Init();
/* Autostart flag. This should be set to true if the DSP image should
@@ -429,6 +413,19 @@ static int __devinit omap34xx_bridge_probe(struct
platform_device *pdev)
} else {
GT_0trace(driverTrace, GT_5CLASS,
DSP/BIOS Bridge driver loaded\n);
+ /* Announce to kernel that we are ready */
+ status = cdev_add(bridge_device-cdev, dev, 1);
+ if (status) {
+ GT_0trace(driverTrace, GT_7CLASS,
+ Failed to add the bridge device \n);
+ }
+ else {
Checkpatch: else should follow close brace '}'
+ #ifdef CONFIG_PM
Moving this #ifdef #endif to the start of the line will make it a bit easier
to read.
+ /* Initialize the wait queue */
+ bridge_suspend_data.suspended = 0;
+
init_waitqueue_head(bridge_suspend_data.suspend_wq);
+ #endif
+ }
Line over 80 characters.
What if you replace if (DSP_SUCCEEDED(initStatus)) { on line 403 for a goto
and a failure comment, then you can remove one level of indentation.
}
}
--
1.6.2.4
- omar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] [RFC] OMAP4: SMP: Patch series
Following is the patch series to enable SMP support for OMAP4430 development platform. This series is on top of the first series sent on the mailing list. The patches are generated against mainline version 2.6.30 -rc2. The kernel is validated on the OMAP4430 software simulator platform. SMP kernel is functional with debug UART. No additional drivers are supported yet. TI's OMAP4430 SOC is based on ARM Cortex-A9 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and SCU for cache coherency. The series contains: [PATCH 1/3][RFC]OMAP4: SMP: Add OMAP4430 SMP board files [PATCH 2/3][RFC]OMAP4: SMP: Add mpu timer support for OMAP4430 [PATCH 3/3][RFC]OMAP4: SMP: Enable SMP support for OMAP4430 Thanks in advance for the review !! Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3][RFC]OMAP4: SMP: Add OMAP4430 SMP board files
This patch adds SMP platform files support for OMAP4430SDP. TI's OMAP4430
SOC is based on ARM Cortex-A9 SMP architecture. It's a dual core SOC
with GIC used for interrupt handling and SCU for cache coherency.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-headsmp.S| 49 +++
arch/arm/mach-omap2/omap-smp.c| 238 +
arch/arm/plat-omap/include/mach/scu.h | 28
arch/arm/plat-omap/include/mach/smp.h | 56
4 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap-headsmp.S
create mode 100644 arch/arm/mach-omap2/omap-smp.c
create mode 100644 arch/arm/plat-omap/include/mach/scu.h
create mode 100644 arch/arm/plat-omap/include/mach/smp.h
diff --git a/arch/arm/mach-omap2/omap-headsmp.S
b/arch/arm/mach-omap2/omap-headsmp.S
new file mode 100644
index 000..0afe039
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -0,0 +1,49 @@
+/*
+ * Secondary CPU startup routine source file.
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Author:
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Interface functions needed for the SMP. This file is based on arm
+ * realview smp platform.
+ * Copyright (c) 2003 ARM Limited.
+ *
+ * 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/linkage.h
+#include linux/init.h
+
+ __INIT
+
+/*
+ * OMAP4 specific entry point for secondary CPU to jump from ROM
+ * code. This routine also provides a holding flag into which
+ * secondary core is held until we're ready for it to initialise.
+ * The primary core will update the this flag using a hardware
+ * register AuxCoreBoot1.
+ */
+ENTRY(omap_secondary_startup)
+ mrc p15, 0, r0, c0, c0, 5
+ and r0, r0, #15
+ adr r4, 1f
+ ldmia r4, {r5, r6}
+ sub r4, r4, r5
+ add r6, r6, r4
+hold: ldr r7, [r6] @ read from AuxCoreBoot1
+ cmp r7, r0
+ bne hold
+
+ /*
+* we've been released from the holding pen: secondary_stack
+* should now contain the SVC stack for this core
+*/
+ b secondary_startup
+
+1: .long .
+ .long cpu_release
+
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
new file mode 100644
index 000..1d18acb
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -0,0 +1,238 @@
+/*
+ * OMAP4 SMP source file. It contains platform specific fucntions
+ * needed for the linux smp kernel.
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Author:
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Platform file needed for the OMAP4 SMP. This file is based on arm
+ * realview smp platform.
+ * * Copyright (c) 2002 ARM Limited.
+ *
+ * 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/init.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/jiffies.h
+#include linux/smp.h
+#include linux/io.h
+
+#include asm/cacheflush.h
+#include mach/scu.h
+#include mach/hardware.h
+#include asm/mach-types.h
+
+/* Registers used for communicating startup information */
+#define OMAP4_AUXCOREBOOT_REG0 (OMAP44XX_VA_WKUPGEN_BASE + 0x800)
+#define OMAP4_AUXCOREBOOT_REG1 (OMAP44XX_VA_WKUPGEN_BASE + 0x804)
+
+/* FIXME: Move to a common header file */
+extern void omap_secondary_startup(void);
+
+/*
+ * Control for which core is the next to come out of the secondary
+ * boot Auxcontrol_register
+ */
+int __cpuinitdata cpu_release = -1;
+
+/*
+ * Setup the SCU
+ */
+static void scu_enable(void)
+{
+ u32 scu_ctrl;
+ void __iomem *scu_base = OMAP44XX_VA_SCU_BASE;
+
+ scu_ctrl = __raw_readl(scu_base + SCU_CTRL);
+ scu_ctrl |= 1;
+ __raw_writel(scu_ctrl, scu_base + SCU_CTRL);
+}
+
+/*
+ * Use SCU config register to count number of cores
+ */
+static unsigned int __init get_core_count(void)
+{
+ unsigned int ncores;
+ void __iomem *scu_base = OMAP44XX_VA_SCU_BASE;
+
+ if (scu_base) {
+ ncores = __raw_readl(scu_base + SCU_CONFIG);
+ ncores = (ncores 0x03) + 1;
+ } else {
+ ncores = 1;
+ }
+
+ return ncores;
+}
+
+static DEFINE_SPINLOCK(boot_lock);
+
+void __cpuinit platform_secondary_init(unsigned int cpu)
+{
+ trace_hardirqs_off();
+
+ /*
+* If any interrupts are already enabled for the primary
+* core (e.g. timer irq), then they will not have been enabled
+* for us: do so
+*/
+
+ gic_cpu_init(0, IO_ADDRESS(OMAP44XX_GIC_CPU_BASE));
+
+ /*
+* Let the primary processor
[PATCH 3/3][RFC]OMAP4: SMP: Enable SMP support for OMAP4430
This patch enables SMP on OMAP4430 SDP platform. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/Kconfig|4 ++-- arch/arm/configs/omap_4430sdp_defconfig |7 ++- arch/arm/mach-omap2/Makefile|3 +++ 3 files changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e02b893..dc9f9fd 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -807,7 +807,7 @@ source kernel/time/Kconfig config SMP bool Symmetric Multi-Processing (EXPERIMENTAL) - depends on EXPERIMENTAL (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP) + depends on EXPERIMENTAL (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || ARCH_OMAP4) select USE_GENERIC_SMP_HELPERS help This enables support for systems with more than one CPU. If you have @@ -864,7 +864,7 @@ config HOTPLUG_CPU config LOCAL_TIMERS bool Use local timer interrupts - depends on SMP (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || REALVIEW_EB_A9MP) + depends on SMP (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || REALVIEW_EB_A9MP || ARCH_OMAP4) default y help Enable support for local timers on SMP platforms, rather then the diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 43532bc..fe2690e 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -30,7 +30,7 @@ CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # General setup # CONFIG_EXPERIMENTAL=y -CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y @@ -104,6 +104,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set @@ -244,6 +245,9 @@ CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_LOCAL_TIMERS=y # CONFIG_PREEMPT is not set CONFIG_HZ=128 CONFIG_AEABI=y @@ -695,6 +699,7 @@ CONFIG_HAVE_FUNCTION_TRACER=y # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set +# CONFIG_ARM_UNWIND is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_ERRORS is not set # CONFIG_DEBUG_STACK_USAGE is not set diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index bfb21e0..8fbbb35 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -14,6 +14,9 @@ obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o +# SMP support ONLY available for OMAP4 +obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o \ + timer-mpu.o # Functions loaded to SRAM obj-$(CONFIG_ARCH_OMAP2420)+= sram242x.o obj-$(CONFIG_ARCH_OMAP2430)+= sram243x.o -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Previewer and resizer demo
Hiremath, Vaibhav wrote: [Hiremath, Vaibhav] From where you got these patches? Kernel version should be enough for me to understand the release package. What I know is that previewer is accessible via separate character device. [Hiremath, Vaibhav] Yes, very true. Irrespective of release package you are using Resizer and Previewer modules are exported to the user space as a stand-alone character driver. There are some changes in the IOCTL's (New Ioctl added), so I just wanted to make sure that I share buildable version of application. Thanks, Vaibhav Hiremath Hi, I hope you did not forget me. I just need some skeleton that shows how captured frame is forwarded to previewer. I can work out build problems if there are any. Thanks a lot. Felix. -- To unsubscribe from this list: send the line unsubscribe 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/3][RFC]OMAP4: SMP: Add mpu timer support for OMAP4430
This patch adds SMP platform specific parts for local(mpu) timer support
for OMAP4430 platform. Each Cortex-a9 core has it's own local timer in the
MPU domain. These timers are not in wakeup domain.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer-gp.c| 11 ++
arch/arm/mach-omap2/timer-mpu.c | 214 +
arch/arm/plat-omap/include/mach/common.h |3 +
arch/arm/plat-omap/include/mach/entry-macro.S | 28
arch/arm/plat-omap/include/mach/irqs.h|2 +
5 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/timer-mpu.c
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 080868d..08c6ded 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -36,6 +36,7 @@
#include asm/mach/time.h
#include mach/dmtimer.h
+#include mach/common.h
static struct omap_dm_timer *gptimer;
static struct clock_event_device clockevent_gpt;
@@ -187,6 +188,16 @@ static void __init omap2_gp_clocksource_init(void)
static void __init omap2_gp_timer_init(void)
{
+#ifdef CONFIG_LOCAL_TIMERS
+ twd_base = IO_ADDRESS(OMAP44XX_LOCAL_TWD_BASE);
+#endif
+#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
+ /*
+* The dummy clock device has to be registered before the main device
+* so that the latter will broadcast the clock events
+*/
+ local_timer_setup();
+#endif
omap_dm_timer_init();
omap2_gp_clockevent_init();
diff --git a/arch/arm/mach-omap2/timer-mpu.c b/arch/arm/mach-omap2/timer-mpu.c
new file mode 100644
index 000..bb91b24
--- /dev/null
+++ b/arch/arm/mach-omap2/timer-mpu.c
@@ -0,0 +1,214 @@
+/*
+ * The MPU local timer source file. In OMAP4, both cortex-a9 cores have
+ * own timer in it's MPU domain. These timers will be driving the
+ * linux kernel SMP tick framework when active. These timers are not
+ * part of the wake up domain.
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Author:
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * This file is based on arm realview smp platform file.
+ * Copyright (C) 2002 ARM Ltd.
+ *
+ * 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/init.h
+#include linux/kernel.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/smp.h
+#include linux/jiffies.h
+#include linux/percpu.h
+#include linux/clockchips.h
+#include linux/irq.h
+
+#include asm/hardware/arm_twd.h
+#include asm/hardware/gic.h
+#include asm/irq.h
+
+#include mach/hardware.h
+#include mach/common.h
+
+static DEFINE_PER_CPU(struct clock_event_device, local_clockevent);
+
+/*
+ * Used on SMP for either the local timer or IPI_TIMER
+ */
+void local_timer_interrupt(void)
+{
+ struct clock_event_device *clk = __get_cpu_var(local_clockevent);
+
+ clk-event_handler(clk);
+}
+
+#ifdef CONFIG_LOCAL_TIMERS
+
+/* set up by the platform code */
+void __iomem *twd_base;
+
+static unsigned long mpcore_timer_rate;
+
+static void local_timer_set_mode(enum clock_event_mode mode,
+struct clock_event_device *clk)
+{
+ unsigned long ctrl;
+
+ switch (mode) {
+ case CLOCK_EVT_MODE_PERIODIC:
+ /* timer load already set up */
+ ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
+ | TWD_TIMER_CONTROL_PERIODIC;
+ break;
+ case CLOCK_EVT_MODE_ONESHOT:
+ /* period set, and timer enabled in 'next_event' hook */
+ ctrl = TWD_TIMER_CONTROL_IT_ENABLE | TWD_TIMER_CONTROL_ONESHOT;
+ break;
+ case CLOCK_EVT_MODE_UNUSED:
+ case CLOCK_EVT_MODE_SHUTDOWN:
+ default:
+ ctrl = 0;
+ }
+
+ __raw_writel(ctrl, twd_base + TWD_TIMER_CONTROL);
+}
+
+static int local_timer_set_next_event(unsigned long evt,
+ struct clock_event_device *unused)
+{
+ unsigned long ctrl = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+
+ __raw_writel(evt, twd_base + TWD_TIMER_COUNTER);
+ __raw_writel(ctrl | TWD_TIMER_CONTROL_ENABLE,
+ twd_base + TWD_TIMER_CONTROL);
+
+ return 0;
+}
+
+/*
+ * local_timer_ack: checks for a local timer interrupt.
+ *
+ * If a local timer interrupt has occurred, acknowledge and return 1.
+ * Otherwise, return 0.
+ */
+int local_timer_ack(void)
+{
+ if (__raw_readl(twd_base + TWD_TIMER_INTSTAT)) {
+ __raw_writel(1, twd_base + TWD_TIMER_INTSTAT);
+ return 1;
+ }
+
+ return 0;
+}
+
+static void __cpuinit twd_calibrate_rate(void)
+{
+ unsigned long load, count;
+ u64 waitjiffies;
+
+ /*
+* If this is the first time round, we need to work
Issues with PM Branch
Hi, I am having some hangs using origin/pm branch. SDPs used to test, same behaviour: SDP3430 PROCESSOR BD, ES2.0 SDP3430 PROCESSOR BD III, OMAP3430 ES3.0 EMU(MT), TWL5030 ES1.0 The commit taken is latest: commit 9d76f46e79302058464b569dbad9af8c594dbe53 author Roger Quadros ext-roger.quad...@nokia.com PM: OMAP: Fix build with CONFIG_OMAP_PM_NONE set If default configuration is used (omap_3430sdp_defconfig) then a kernel panic will occur: 7Switched to high resolution mode on CPU 0 6musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 1Unhandled fault: external abort on non-linefetch (0x1028) at 0xd80ab404 Internal error: : 1028 [#1] Modules linked in: CPU: 0Not tainted (2.6.29-omap1-05686-g9d76f46 #1) PC is at musb_platform_init+0x5c/0xf8 LR is at omap2_clk_enable+0x114/0x184 pc : [c001f6d0]lr : [c003b84c]psr: 4013 sp : c7817d50 ip : 0001 fp : c7817d64 r10: r9 : c78281f0 r8 : c03ad128 r7 : c7831240 r6 : c78280d8 r5 : r4 : c78280d8 r3 : d80ab000 r2 : 0200 r1 : r0 : Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc78162e0) Stack: (0xc7817d50 to 0xc7818000) ... [c001f674] (musb_platform_init+0x0/0xf8) from [c001ecd0] (musb_probe+0x244/0xbe8) r5: r4:c0394db8 [c001ea8c] (musb_probe+0x0/0xbe8) from [c01c0930] (platform_drv_probe+0x20/0x24) [c01c0910] (platform_drv_probe+0x0/0x24) from [c01bfb20] (driver_probe_device+0xd4/0x180) If USB is disabled then a hang now will be present in Power Management for TI OMAP3 6RPC: Registered udp transport module. RPC: Registered udp transport module. 6RPC: Registered tcp transport module. RPC: Registered tcp transport module. 3Power Management for TI OMAP3. Power Management for TI OMAP3. ö To avoid this last hang going back to the previous commit is needed, after this, the boot is Ok commit 90c3bdfb394ff2ddd87a72defb49c2f2456dd621 Author: Rajendra Nayak rna...@ti.com OMAP3 clock: Update cpufreq driver If minimal defconfig (omap_3430sdp_min_defconfig) is used, boot will be ok. Has anyone faced same issue? Best Regards Abraham -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] OMAP: pandora: setup regulator framework for MMC
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 415f2c76e247f2e6a325621e54f0b1b5dc3669cd PatchWorks http://patchwork.kernel.org/patch/20035/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=415f2c76e247f2e6a325621e54f0b1b5dc3669cd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: HSMMC: Do not enable buffer ready interrupt if using DMA
Jarkko? Tony?
On Tue, 21 Apr 2009 13:09:22 +0530
Gadiyar, Anand gadi...@ti.com wrote:
From: Anand Gadiyar gadi...@ti.com
OMAP: HSMMC: Do not enable buffer ready interrupt if using DMA
This considerably reduces the number of interrupts during a transfer
and ought to result in some power saving.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e62a22a..2d83807 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -70,6 +70,8 @@
#define DTO_MASK 0x000F
#define DTO_SHIFT16
#define INT_EN_MASK 0x307F0033
+#define BWR_ENABLE (1 4)
+#define BRR_ENABLE (1 5)
#define INIT_STREAM (1 1)
#define DP_SELECT(1 21)
#define DDIR (1 4)
@@ -241,7 +243,12 @@ mmc_omap_start_command(struct mmc_omap_host *host,
struct mmc_command *cmd,
*/
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
- OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+
+ if (host-use_dma)
+ OMAP_HSMMC_WRITE(host-base, IE,
+ INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE));
+ else
+ OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
signature.asc
Description: PGP signature
Re: [PATCH v3] ARM: OMAP: board-ldp: add regulator info to get the microSD slot working again
Seeing that a similar change to the pandora board went in, can this
*please* get applied as well now?
Op 31 mrt 2009, om 10:53 heeft Koen Kooi het volgende geschreven:
The ldp board was left behind when other boards got updated. The ldp
info was copied from the beagleboard board file and s/beagle/ldp/g
Changes since v2:
* fixed email address
Changes since v1:
* dropped vsim portion since only 4 pins are hooked up
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-ldp.c | 32 ++
++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/
board-ldp.c
index 30926b0..19a5c15 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -22,6 +22,7 @@
#include linux/clk.h
#include linux/spi/spi.h
#include linux/spi/ads7846.h
+#include linux/regulator/machine.h
#include linux/i2c/twl4030.h
#include mach/hardware.h
@@ -450,7 +451,16 @@ static struct twl4030_script *twl4030_scripts[]
__initdata = {
wrst_script,
};
+static const struct twl4030_resconfig ldp_resconfig[] = {
+ /* disable regulators that u-boot left enabled; the
+* devices' drivers should be managing these.
+*/
+ { .resource = RES_VMMC1, },
+ { 0, },
+};
+
static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
+ .resource_config= ldp_resconfig,
.scripts= twl4030_scripts,
.size = ARRAY_SIZE(twl4030_scripts),
};
@@ -474,6 +484,25 @@ static struct twl4030_madc_platform_data
ldp_madc_data = {
.irq_line = 1,
};
+static struct regulator_consumer_supply ldp_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card ==
max 220 mA) */
+static struct regulator_init_data ldp_vmmc1 = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = ldp_vmmc1_supply,
+};
+
static struct twl4030_platform_data ldp_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -483,6 +512,7 @@ static struct twl4030_platform_data ldp_twldata
= {
.madc = ldp_madc_data,
.usb= ldp_usb_data,
.power = sdp3430_t2scripts_data,
+ .vmmc1 = ldp_vmmc1,
.gpio = ldp_gpio_data,
.keypad = ldp_kp_twl4030_data,
};
@@ -530,6 +560,8 @@ static void __init omap_ldp_init(void)
omap_serial_init();
usb_musb_init();
twl4030_mmc_init(mmc);
+ /* link regulators to MMC adapters */
+ ldp_vmmc1_supply.dev = mmc[0].dev;
}
static void __init omap_ldp_map_io(void)
--
1.6.2
--
To unsubscribe from this list: send the line unsubscribe linux-
omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PGP.sig
Description: Dit deel van het bericht is digitaal ondertekend
Re: [PATCH v3] ARM: OMAP: board-ldp: add regulator info to get the microSD slot working again
* Koen Kooi k...@beagleboard.org [090428 12:44]:
Seeing that a similar change to the pandora board went in, can this
*please* get applied as well now?
Should be there since 23rd, can you please verify?
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=c42e73b956f346cb9a0b3afb064f69afc4761d2a
Cheers,
Tony
Op 31 mrt 2009, om 10:53 heeft Koen Kooi het volgende geschreven:
The ldp board was left behind when other boards got updated. The ldp
info was copied from the beagleboard board file and s/beagle/ldp/g
Changes since v2:
* fixed email address
Changes since v1:
* dropped vsim portion since only 4 pins are hooked up
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-ldp.c | 32 ++
++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/
board-ldp.c
index 30926b0..19a5c15 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -22,6 +22,7 @@
#include linux/clk.h
#include linux/spi/spi.h
#include linux/spi/ads7846.h
+#include linux/regulator/machine.h
#include linux/i2c/twl4030.h
#include mach/hardware.h
@@ -450,7 +451,16 @@ static struct twl4030_script *twl4030_scripts[]
__initdata = {
wrst_script,
};
+static const struct twl4030_resconfig ldp_resconfig[] = {
+/* disable regulators that u-boot left enabled; the
+ * devices' drivers should be managing these.
+ */
+{ .resource = RES_VMMC1, },
+{ 0, },
+};
+
static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
+.resource_config= ldp_resconfig,
.scripts= twl4030_scripts,
.size = ARRAY_SIZE(twl4030_scripts),
};
@@ -474,6 +484,25 @@ static struct twl4030_madc_platform_data
ldp_madc_data = {
.irq_line = 1,
};
+static struct regulator_consumer_supply ldp_vmmc1_supply = {
+.supply = vmmc,
+};
+
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max
220 mA) */
+static struct regulator_init_data ldp_vmmc1 = {
+.constraints = {
+.min_uV = 185,
+.max_uV = 315,
+.valid_modes_mask = REGULATOR_MODE_NORMAL
+| REGULATOR_MODE_STANDBY,
+.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+| REGULATOR_CHANGE_MODE
+| REGULATOR_CHANGE_STATUS,
+},
+.num_consumer_supplies = 1,
+.consumer_supplies = ldp_vmmc1_supply,
+};
+
static struct twl4030_platform_data ldp_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -483,6 +512,7 @@ static struct twl4030_platform_data ldp_twldata = {
.madc = ldp_madc_data,
.usb= ldp_usb_data,
.power = sdp3430_t2scripts_data,
+.vmmc1 = ldp_vmmc1,
.gpio = ldp_gpio_data,
.keypad = ldp_kp_twl4030_data,
};
@@ -530,6 +560,8 @@ static void __init omap_ldp_init(void)
omap_serial_init();
usb_musb_init();
twl4030_mmc_init(mmc);
+/* link regulators to MMC adapters */
+ldp_vmmc1_supply.dev = mmc[0].dev;
}
static void __init omap_ldp_map_io(void)
--
1.6.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
LDP support
Tony, et.al., Any ideas when more LDP support will be pushed into mainline (such as the framebuffer support)? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LDP support
* Russell King - ARM Linux li...@arm.linux.org.uk [090428 15:07]: Tony, et.al., Any ideas when more LDP support will be pushed into mainline (such as the framebuffer support)? I'll be looking at the board-*.c patches for the next merge window hopefully this week or next week. Looks like LDP keyboard, touchscreen RTC are pretty much ready to go. Then the MMC has some regulator updates, but AFAIK the MMC should work OK already. For the framebuffer, Imre and Tomi know the status the best, so I've added them to Cc. Imre has been meaning to send a bunch of drivers/video/omap changes to the fbdev list for a while now and LDP framebuffer may depend on those. Imre, any news on the status of sending the fb patches upstream? Then there are the upcoming DSS patches from Tomi, but those still need some work before they're ready to go. 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: Issues with PM Branch
Abraham Arce abraham.arce.mor...@gmail.com writes: Hi, I am having some hangs using origin/pm branch. SDPs used to test, same behaviour: SDP3430 PROCESSOR BD, ES2.0 SDP3430 PROCESSOR BD III, OMAP3430 ES3.0 EMU(MT), TWL5030 ES1.0 The commit taken is latest: commit 9d76f46e79302058464b569dbad9af8c594dbe53 author Roger Quadros ext-roger.quad...@nokia.com PM: OMAP: Fix build with CONFIG_OMAP_PM_NONE set If default configuration is used (omap_3430sdp_defconfig) then a kernel panic will occur: 7Switched to high resolution mode on CPU 0 6musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 1Unhandled fault: external abort on non-linefetch (0x1028) at 0xd80ab404 Internal error: : 1028 [#1] Modules linked in: CPU: 0Not tainted (2.6.29-omap1-05686-g9d76f46 #1) PC is at musb_platform_init+0x5c/0xf8 LR is at omap2_clk_enable+0x114/0x184 pc : [c001f6d0]lr : [c003b84c]psr: 4013 sp : c7817d50 ip : 0001 fp : c7817d64 r10: r9 : c78281f0 r8 : c03ad128 r7 : c7831240 r6 : c78280d8 r5 : r4 : c78280d8 r3 : d80ab000 r2 : 0200 r1 : r0 : Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc78162e0) Stack: (0xc7817d50 to 0xc7818000) ... [c001f674] (musb_platform_init+0x0/0xf8) from [c001ecd0] (musb_probe+0x244/0xbe8) r5: r4:c0394db8 [c001ea8c] (musb_probe+0x0/0xbe8) from [c01c0930] (platform_drv_probe+0x20/0x24) [c01c0910] (platform_drv_probe+0x0/0x24) from [c01bfb20] (driver_probe_device+0xd4/0x180) If USB is disabled then a hang now will be present in Power Management for TI OMAP3 6RPC: Registered udp transport module. RPC: Registered udp transport module. 6RPC: Registered tcp transport module. RPC: Registered tcp transport module. 3Power Management for TI OMAP3. Power Management for TI OMAP3. ö To avoid this last hang going back to the previous commit is needed, after this, the boot is Ok commit 90c3bdfb394ff2ddd87a72defb49c2f2456dd621 Author: Rajendra Nayak rna...@ti.com OMAP3 clock: Update cpufreq driver If minimal defconfig (omap_3430sdp_min_defconfig) is used, boot will be ok. Has anyone faced same issue? The non-USB related hang looks like the problem when using smartreflex without SRF. If you disable smartreflex, or use smartreflex with SRF you should boot past that hang. For MUSB, it has not yet been validated on the PM branch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Allow disabling wakeup for serial ports, including during off mode.
On Tue, Apr 28, 2009 at 4:03 AM, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Russ Dill
Sent: Tuesday, April 28, 2009 12:58 AM
To: linux-omap@vger.kernel.org
Cc: Russ Dill
Subject: [RFC] Allow disabling wakeup for serial ports,
including during off mode.
This patch causes the OMAP uarts to honor the sysfs
power/wakeup file for
IOPADs. Before the OMAP was always woken up from off mode on
a rs232 signal
change.
This patch also creates a different platform device for each serial
port so that the wakeup properties can be control per port.
The patch is not in a complete state, but for my testing it
was necessary
to disable rs232 wakeup as allowing the signals to float in
off mode by
powering off the level converters was causing a wakeup event.
---
arch/arm/mach-omap2/serial.c | 165
--
1 files changed, 126 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 0762165..95b047a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -49,6 +49,7 @@ struct omap_uart_state {
struct plat_serial8250_port *p;
struct list_head node;
+ struct platform_device pdev;
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
int context_valid;
@@ -63,10 +64,9 @@ struct omap_uart_state {
#endif
};
-static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS];
static LIST_HEAD(uart_list);
-static struct plat_serial8250_port serial_platform_data[] = {
+static struct plat_serial8250_port serial_platform_data0[] = {
[sp] Is it necessary to split the array?
Not really, it should be a separate patch. It allows the wakeup and
timeout options to be set per port.
{
.membase = IO_ADDRESS(OMAP_UART1_BASE),
.mapbase = OMAP_UART1_BASE,
@@ -76,6 +76,12 @@ static struct plat_serial8250_port
serial_platform_data[] = {
.regshift = 2,
.uartclk = OMAP24XX_BASE_BAUD * 16,
}, {
+ .flags = 0
+ }
+};
+
+static struct plat_serial8250_port serial_platform_data1[] = {
+ {
.membase = IO_ADDRESS(OMAP_UART2_BASE),
.mapbase = OMAP_UART2_BASE,
.irq = 73,
@@ -84,6 +90,12 @@ static struct plat_serial8250_port
serial_platform_data[] = {
.regshift = 2,
.uartclk = OMAP24XX_BASE_BAUD * 16,
}, {
+ .flags = 0
+ }
+};
+
+static struct plat_serial8250_port serial_platform_data2[] = {
+ {
.membase = IO_ADDRESS(OMAP_UART3_BASE),
.mapbase = OMAP_UART3_BASE,
.irq = 74,
@@ -197,6 +209,40 @@ static inline void
omap_uart_save_context(struct omap_uart_state *uart) {}
static inline void omap_uart_restore_context(struct
omap_uart_state *uart) {}
#endif /* CONFIG_ARCH_OMAP3 */
+static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
+{
+ /* Set wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v |= uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+
+ /* Ensure IOPAD wake-enables are set */
+ if (cpu_is_omap34xx() uart-padconf) {
+ u16 v = omap_ctrl_readw(uart-padconf);
+ v |= OMAP3_PADCONF_WAKEUPENABLE0;
+ omap_ctrl_writew(v, uart-padconf);
+ }
+}
+
+static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
+{
+ /* Clear wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v = ~uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+
+ /* Ensure IOPAD wake-enables are cleared */
+ if (cpu_is_omap34xx() uart-padconf) {
+ u16 v = omap_ctrl_readw(uart-padconf);
+ v = ~OMAP3_PADCONF_WAKEUPENABLE0;
+ omap_ctrl_writew(v, uart-padconf);
+ }
+}
+
static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
int enable)
{
@@ -220,6 +266,11 @@ static inline void
omap_uart_restore(struct omap_uart_state *uart)
static inline void omap_uart_disable_clocks(struct
omap_uart_state *uart)
{
+ if (device_may_wakeup(uart-pdev.dev))
+ omap_uart_enable_wakeup(uart);
+ else
+ omap_uart_disable_wakeup(uart);
+
if (!uart-clocked)
return;
@@ -290,6 +341,7 @@ void omap_uart_resume_idle(int num)
if (__raw_readl(uart-wk_st) uart-wk_mask)
omap_uart_block_sleep(uart);
+ omap_uart_enable_wakeup(uart);
return;
