[PATCH] PM: Fix a bug with noncore dpll rate calculation
Noncore dpll can enter autoidle state, in which case the rate calculation
fails. Fixed by checking dpll mode instead of idle status.
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clock.c | 16 +++-
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 522ce6f..bbd3e82 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -212,9 +212,16 @@ u32 omap2_get_dpll_rate(struct clk *clk)
return 0;
/* Return bypass rate if DPLL is bypassed */
- v = cm_read_mod_reg(clk-prcm_mod, dd-idlest_reg);
- v = dd-idlest_mask;
- v = __ffs(dd-idlest_mask);
+ if (cpu_is_omap34xx()) {
+ v = cm_read_mod_reg(clk-prcm_mod, dd-control_reg);
+ v = dd-enable_mask;
+ v = __ffs(dd-enable_mask);
+ } else {
+ v = cm_read_mod_reg(clk-prcm_mod, dd-idlest_reg);
+ v = dd-idlest_mask;
+ v = __ffs(dd-idlest_mask);
+ }
+
if (cpu_is_omap24xx()) {
if (v == ST_CORE_CLK_REF)
@@ -224,9 +231,8 @@ u32 omap2_get_dpll_rate(struct clk *clk)
} else if (cpu_is_omap34xx()) {
- if (!v)
+ if (v == OMAP3430_EN_MPU_DPLL_BYPASS)
return dd-bypass_clk-rate;
-
}
v = cm_read_mod_reg(clk-prcm_mod, dd-mult_div1_reg);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6f3f5a3..9995353 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -112,6 +112,8 @@
#define OMAP3430_EN_MPU_DPLL_DRIFTGUARD_MASK (1 3)
#define OMAP3430_EN_MPU_DPLL_SHIFT 0
#define OMAP3430_EN_MPU_DPLL_MASK (0x7 0)
+#define OMAP3430_EN_MPU_DPLL_LOCK (0x7 0)
+#define OMAP3430_EN_MPU_DPLL_BYPASS(0x5 0)
/* CM_IDLEST_MPU */
#define OMAP3430_ST_MPU(1 0)
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PM: Added three PLL registers to the PRCM context save
These registers are now also saved:
CM_CLKSEL4
CM_CLKEN
CM_CLKEN2
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/prcm.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index d5a1e4b..c64b668 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -46,7 +46,10 @@ struct omap3_prcm_regs {
u32 emu_cm_clksel;
u32 emu_cm_clkstctrl;
u32 pll_cm_autoidle2;
+ u32 pll_cm_clksel4;
u32 pll_cm_clksel5;
+ u32 pll_cm_clken;
+ u32 pll_cm_clken2;
u32 cm_polctrl;
u32 iva2_cm_fclken;
u32 core_cm_fclken1;
@@ -233,8 +236,14 @@ void omap3_prcm_save_context(void)
cm_read_mod_reg(OMAP3430_EMU_MOD, CM_CLKSTCTRL);
prcm_context.pll_cm_autoidle2 =
cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
+ prcm_context.pll_cm_clksel4 =
+ cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4);
prcm_context.pll_cm_clksel5 =
cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5);
+ prcm_context.pll_cm_clken =
+ cm_read_mod_reg(PLL_MOD, CM_CLKEN);
+ prcm_context.pll_cm_clken2 =
+ cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
prcm_context.iva2_cm_fclken =
cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_FCLKEN);
@@ -380,8 +389,13 @@ void omap3_prcm_restore_context(void)
CM_CLKSTCTRL);
cm_write_mod_reg(prcm_context.pll_cm_autoidle2, PLL_MOD,
CM_AUTOIDLE2);
+ cm_write_mod_reg(prcm_context.pll_cm_clksel4, PLL_MOD,
+ OMAP3430ES2_CM_CLKSEL4);
cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
OMAP3430ES2_CM_CLKSEL5);
+ cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
+ cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
+ OMAP3430ES2_CM_CLKEN2);
__raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
cm_write_mod_reg(prcm_context.iva2_cm_fclken, OMAP3430_IVA2_MOD,
CM_FCLKEN);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH PM-20081106] OMAP: PM: Few fixes to uart clock handling
Omap3_can_sleep is not inside part of idle loop which is protected
with irg disable. If some irq handler is trying dump out something
after omap3_can_sleep and before irqs are disabled. It causes oops
because uart clocks are disabled.
Remove also some unused extra code from omap_uart_can_sleep
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/serial.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ef30d8d..b06b797 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -314,21 +314,13 @@ void omap_uart_check_wakeup(void)
int omap_uart_can_sleep(void)
{
struct omap_uart_state *uart;
- int can_sleep = 1;
list_for_each_entry(uart, uart_list, node) {
- if (!uart-clocked)
+ if (!uart-clocked || !uart-can_sleep)
continue;
- if (!uart-can_sleep) {
- can_sleep = 0;
- continue;
- }
-
/* This UART can now safely sleep. */
omap_uart_allow_sleep(uart);
- if (clocks_off_while_idle)
- omap_uart_disable_clocks(uart);
}
return 1;
@@ -435,7 +427,6 @@ static void omap_uart_pm(struct uart_port *port,
break;
case 3: /* suspend */
omap_uart_allow_sleep(uart);
- omap_uart_disable_clocks(uart);
break;
}
}
--
1.6.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] PM: Added three PLL registers to the PRCM context save
Hi,
Just an initial comment to this patch, this is somewhat experimental and
I think we should agree what registers will actually be saved here and
what should be left for drivers. CM_CLKSEL4 is for DPLL5 which is used
by USB. Two of the CLKEN registers are more interesting.
-Tero
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ext Tero Kristo
Sent: 19 November, 2008 11:32
To: linux-omap@vger.kernel.org
Subject: [PATCH] PM: Added three PLL registers to the PRCM context save
These registers are now also saved:
CM_CLKSEL4
CM_CLKEN
CM_CLKEN2
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/prcm.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c
b/arch/arm/mach-omap2/prcm.c index d5a1e4b..c64b668 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -46,7 +46,10 @@ struct omap3_prcm_regs {
u32 emu_cm_clksel;
u32 emu_cm_clkstctrl;
u32 pll_cm_autoidle2;
+ u32 pll_cm_clksel4;
u32 pll_cm_clksel5;
+ u32 pll_cm_clken;
+ u32 pll_cm_clken2;
u32 cm_polctrl;
u32 iva2_cm_fclken;
u32 core_cm_fclken1;
@@ -233,8 +236,14 @@ void omap3_prcm_save_context(void)
cm_read_mod_reg(OMAP3430_EMU_MOD,
CM_CLKSTCTRL);
prcm_context.pll_cm_autoidle2 =
cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
+ prcm_context.pll_cm_clksel4 =
+ cm_read_mod_reg(PLL_MOD,
OMAP3430ES2_CM_CLKSEL4);
prcm_context.pll_cm_clksel5 =
cm_read_mod_reg(PLL_MOD,
OMAP3430ES2_CM_CLKSEL5);
+ prcm_context.pll_cm_clken =
+ cm_read_mod_reg(PLL_MOD, CM_CLKEN);
+ prcm_context.pll_cm_clken2 =
+ cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
prcm_context.iva2_cm_fclken =
cm_read_mod_reg(OMAP3430_IVA2_MOD,
CM_FCLKEN); @@ -380,8 +389,13 @@ void omap3_prcm_restore_context(void)
CM_CLKSTCTRL);
cm_write_mod_reg(prcm_context.pll_cm_autoidle2, PLL_MOD,
CM_AUTOIDLE2);
+ cm_write_mod_reg(prcm_context.pll_cm_clksel4, PLL_MOD,
+ OMAP3430ES2_CM_CLKSEL4);
cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
OMAP3430ES2_CM_CLKSEL5);
+ cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
+ cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
+ OMAP3430ES2_CM_CLKEN2);
__raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
cm_write_mod_reg(prcm_context.iva2_cm_fclken, OMAP3430_IVA2_MOD,
CM_FCLKEN);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in the body of a message to
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Save sram context after changing MPU, DSP or core clocks
Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock34xx.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index d97d5a9..962ce56 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -911,6 +911,9 @@ printk(%s set to %luHz intended rate %luHz\n,dpll2_clk-name,clk_get_rate(dpll clk_set_rate(dpll3_clk, prcm_vdd-rate); curr_vdd2_prcm_set = prcm_vdd; } + + omap3_save_scratchpad_contents(); + return 0; } -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] Save sram context after changing MPU, DSP or core clocks
This patch saves the sram context again after a MPU,DSP or core clock frequency change. This is necessary so the rom code can restore the correct DPLL settings when resuming from off mode. Thanks to Rajendra Nayak for suggesting the problem and coming up with the same fix at about the same time. Peter 'p2' De Schrijver (1): Save sram context after changing MPU, DSP or core clocks arch/arm/mach-omap2/clock34xx.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: i2c-omap: Fix standard and fast mode prescalers
On Fri, 2008-11-14 at 11:45 -0800, ext David Brownell wrote: On Friday 14 November 2008, [EMAIL PROTECTED] wrote: The prescalers for 100 kHz and 400 kHz mode are wrong. The internal clock is the fclock divided by the prescaler. The PSC is an 8 bit field in omap3430. Moreover, the scll and sclh values should be adjusted properly. Having the correct prescaler is important in the process of getting a finite i2c clock. In addition, the prescaler is used in the process of activating the correct noise filter and thus, lets more error resilient i2c communications. Should this fix the bug causing the need for that recent ZOOM patch slowing down twl4030 communication to 400 MHz? And should it let at least some boards talk to their TWL chips at 3.4 MBit/sec (top speed for standard highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)? I've always wondered why all the boards configured those links to be seemingly slower than allowed ... - Dave Well, this should not affect the High speed I2C at all. Only fast and slow I2C (100 and 400 khz). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 1/1] ASoC: Add support for omap2evm board
On Wed, Nov 19, 2008 at 05:45:19PM +0530, Arun KS wrote: This patch adds twl4030 audio support on omap2evm Signed-off-by: Arun KS [EMAIL PROTECTED] Acked-by: Mark Brown [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] omap3evm asoc
On Wed, Nov 19, 2008 at 05:57:55PM +0530, naveen krishna ch wrote: Is there any previous work on audio ASOC for OMAP3EVM. I have started working on OMAP3EVM + TWL4030 combination and audio is working. Not that I'm aware of, though Arun just submitted a patch for the omap2evm. CCing in linux-omap who are more likely to know. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] omap3evm asoc
On Wed, Nov 19, 2008 at 6:07 PM, Mark Brown [EMAIL PROTECTED] wrote: On Wed, Nov 19, 2008 at 05:57:55PM +0530, naveen krishna ch wrote: Is there any previous work on audio ASOC for OMAP3EVM. I have started working on OMAP3EVM + TWL4030 combination and audio is working. Not that I'm aware of, though Arun just submitted a patch for the omap2evm. CCing in linux-omap who are more likely to know. Hi Naveen, See the link, http://marc.info/?l=linux-omapm=122690496617326w=2 ___ Alsa-devel mailing list [EMAIL PROTECTED] http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: new PM branch: pm-20081106
-Original Message- From: Kevin Hilman [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2008 10:51 PM To: Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: new PM branch: pm-20081106 Rajendra Nayak [EMAIL PROTECTED] writes: I am seeing a couple of issues on the 3430sdp with this latest pm branch. With the omap_3430sdp_min_defconfig I see a system freeze after bootup after the debug UART inactivity. Also system wide suspend seems to freeze. The system wide suspend freeze is seen even with the default (omap_3430sdp_defconfig) config. I ran into these issue while validating the DVFS patches and haven't really looked further into what might be causing these. I have a ES3.0 GP based SDP board. Rajendra, I just pushed another patch to pm-20081106 for you to try. This reverts a commit[1] from linux-omap which is causing problems coming out of retention. Could you update your PM branch, and also modify the 'enabled_uarts' settings in your board-3430sdp.c file so that only the console UART is enabled. Doing this would help me understand what's working on SDP. Until I get my SDP, I'll need to rely on you for this testing. Hi Kevin, Sorry for the delay in responding. The latest pm branch does seem to work fine on my SDP after taking in Jouni's patch [PATCH PM-20081106] OMAP3: UART: Make sure that uart clocks are enabled when needed and restricting the enabled_uarts to debug console. I however did not see the VCORE led blink while hitting OFF. regards, Rajendra [1] 2ac1da8c787f73f067e717408e631501ba60aabc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Hilman Sent: Friday, November 07, 2008 11:00 PM To: linux-omap@vger.kernel.org Subject: new PM branch: pm-20081106 For those who want to experiment with the latest PM branch, it is now available in OMAP git as branch pm-20081106 The shortlog is below[1], but the significant thing for now is a rework of how UART handles its clocks and allows idle. I also did quite a bit of reordering and some restructuring. I've tested this on Nokia HW and the basic retention-on-idle support on Beagle. I'm still waiting for my SDP to arrive, so haven't tested on SDP. Kevin [1] Amit Kucheria (2): OMAP: PM: Typo fix for clock_allow_idle HSMMC: Make driver support dynamic idle Jouni Hogander (5): OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle loop OMAP3: Do not set mpu, core, neon states if cpuidle is used OMAP3: PM: Do not set next states sw to control those is available OMAP3: PM: Always return value in pwrdms_setup OMAP3: PM: Fix wrong sequence in suspend. Kalle Jokiniemi (3): OMAP: PM: sysfs interface for enabling voltage off in idle OMAP3: PM: Fix cpu idle init sequencing OMAP: SRF: Fixes to shared resource framework (Ver.3) Kevin Hilman (10): OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X OMAP3: PM: Allow UARTs to be unclocked when inactive 8250: Allow platform to register PM hook 8250: when waking, PM hook should be called before accessing port OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume OMAP3: PM: UART save/restore support for OFF-mode OMAP2/3: HSMMC: Ensure HSMMC is fully reset on boot OMAP3: PM: CPUidle: obey enable_off_mode flag OMAP3: PM: CPUidle: restrict C-states on UART activity OMAP3: PM: decouple PER and CORE context save and restore Paul Walmsley (6): OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer. OMAP2/3 omapdev: add basic omapdev structure OMAP242x omapdev: add OMAP242x omapdev records OMAP243x omapdev: add OMAP243x omapdev records OMAP3xxx omapdev: add OMAP3xxx omapdev records OMAP2/3 omapdev: add code to walk the omapdev records Peter 'p2' De Schrijver (9): OMAP: PM counter infrastructure. OMAP: PM: Hook into PM counters OMAP: PM: Add closures to clkdm_for_each and pwrdm_for_each. OMAP: PM: Add pm-debug counters OMAP: PM debug: make powerdomains use PM-debug counters OMAP: PM: Add definitions for ETK pads and observability registers OMAP: Debug observability and ETK padconf implementation OMAP: Add debug observablity (debobs) Kconfig item OMAP: PM: Implement get_last_off_on_transaction_id() Rajendra Nayak (23): OMAP3: PM: GPMC context save/restore OMAP3: PM: GPIO context save/restore OMAP3: PM: I2C context save/restore OMAP3: PM: INTC context save/restore OMAP3: PM: PRCM context save/restore OMAP3: PM: Populate scratchpad contents OMAP3: PM: SCM context save/restore OMAP3: PM: SRAM restore function OMAP3:
Re: [PATCH] i2c: i2c-omap: Fix BUFSTAT_REG reading
On Fri, 2008-11-14 at 11:16 -0800, ext David Brownell wrote: On Friday 14 November 2008, [EMAIL PROTECTED] wrote: The amount of bytes to receive is read from wrong place. It is the 6 bits starting from the bit 8 from BUFSTAT_REG that indicate this amount. Not the 8 LSB:s. Only 6 LSB:s are used for the TX buffer. Also, with omap 3430, only the 6 LSB:s are relevant for XDR. So to summarize: 2430 and 3430 define this register differently? Lacking 2430 docs, I can't verify that. Agreed that 3430 has two 6-bit fields, RXSTAT at 8..13 and TXSTAT at 0..5, so this code is wrong for 3430. But if the issue is that the 2430 version of the FIFO support works differently, please say so in the patch commend and code... - Dave I checked against 2420, and there was no such register avaiable at all. (no 2430 TRM access) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix section mismatch warning.
This warning is observed when building for OMAP3EVM with pm-20081106.
WARNING: vmlinux.o(.data+0x89d4): Section mismatch in reference from the
variable omap3evm_twldata to the variable .init.data:generic3430_t2scripts_data
The variable omap3evm_twldata references
the variable __initdata generic3430_t2scripts_data
If the reference is valid then annotate the
variable with __init* (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Signed-off-by: Sanjeev Premi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a72772f..65e0bdc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -130,7 +130,7 @@ static struct twl4030_madc_platform_data omap3evm_madc_data
= {
.irq_line = 1,
};
-static struct twl4030_platform_data omap3evm_twldata = {
+static struct twl4030_platform_data __initdata omap3evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
--
1.5.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][OMAPZOOM] padconfig for NEC WVGA lcd
From: Leed Aguilar [EMAIL PROTECTED]
This patch sets the proper padconfig value for wvga spi chip select.
Also ensures that dvi output is disable.
LCD data lines has been changed to 24 for Zoom2
Signed-off-by: Leed Aguilar [EMAIL PROTECTED]
---
arch/arm/mach-omap2/mux.c | 15 ---
arch/arm/plat-omap/display.c |4 ++--
arch/arm/plat-omap/include/mach/mux.h |8
drivers/video/omap/omap_disp_out.c| 25 +
4 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 0e650a4..cd6de1d 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -25,10 +25,11 @@
*/
#include linux/module.h
#include linux/init.h
-#include asm/system.h
#include linux/io.h
#include linux/spinlock.h
+#include asm/system.h
+
#include mach/control.h
#include mach/mux.h
@@ -450,7 +451,7 @@ MUX_CFG_34XX(AD2_3430_USB3FS_PHY_MM3_TXDAT, 0x188,
MUX_CFG_34XX(AC1_3430_USB3FS_PHY_MM3_TXEN_N, 0x18a,
OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
- /* UART3 */
+/* UART3 */
MUX_CFG_34XX(R21_3430_UART3_CTS_RCTX,0x19a,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX(T21_3430_UART3_RTS_SD, 0x19c,
@@ -460,11 +461,15 @@ MUX_CFG_34XX(U21_3430_UART3_RX_IRRX, 0x19e,
MUX_CFG_34XX(V21_3430_UART3_TX_IRTX, 0x1a0,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
- /* GPIO */
+/* GPIO */
MUX_CFG_34XX(T21_3430_GPIO164, 0x19c,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLDOWN)
MUX_CFG_34XX(V21_3430_GPIO166, 0x1a0,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AF21_3430_GPIO8, 0xa16,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(B23_3430_GPIO167, 0x130,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
/* 34XX GPIO - bidirectional, unless the name has an _OUT suffix.
* No internal pullup/pulldown without _UP or _DOWN suffix.
@@ -473,6 +478,10 @@ MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(J25_34XX_GPIO170, 0x1c6,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+
+/* McSPI */
+MUX_CFG_34XX(AB1_3430_McSPI1_CS2, 0x1d2,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/display.c b/arch/arm/plat-omap/display.c
index 9ec7ff2..2fca7a9 100644
--- a/arch/arm/plat-omap/display.c
+++ b/arch/arm/plat-omap/display.c
@@ -1975,10 +1975,10 @@ omap2_disp_config_lcd(u32 clkdiv, u32 hbp, u32 hfp, u32
hsw,
#endif
dispc_reg_out(DISPC_DIVISOR, divisor);
control = dispc_reg_in(DISPC_CONTROL);
-#ifdef CONFIG_FB_OMAP_720P_STREAMING
+#if defined(CONFIG_FB_OMAP_720P_STREAMING) || defined(CONFIG_MACH_OMAP_ZOOM2)
control |= DISPC_CONTROL_TFTDATALINES_OALSB24B;
#else
-#if defined(CONFIG_MACH_OMAP_LDP) || defined(CONFIG_MACH_OMAP_ZOOM2)
+#ifdef CONFIG_MACH_OMAP_LDP
control |= DISPC_CONTROL_TFTDATALINES_OALSB18B;
#else
control |= DISPC_CONTROL_TFTDATALINES_OALSB16B;
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 0447a78..4055763 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -785,8 +785,13 @@ enum omap34xx_index {
T21_3430_UART3_RTS_SD,
U21_3430_UART3_RX_IRRX,
V21_3430_UART3_TX_IRTX,
+
+ /* GPIO */
T21_3430_GPIO164,
V21_3430_GPIO166,
+ AF21_3430_GPIO8,
+ B23_3430_GPIO167,
+
/* 34xx GPIO
* - normally these are bidirectional, no internal pullup/pulldown
* - _UP suffix (GPIO3_UP) if internal pullup is configured
@@ -795,6 +800,9 @@ enum omap34xx_index {
*/
AH8_34XX_GPIO29,
J25_34XX_GPIO170,
+
+ /* McSPI */
+ AB1_3430_McSPI1_CS2,
};
struct omap_mux_cfg {
diff --git a/drivers/video/omap/omap_disp_out.c
b/drivers/video/omap/omap_disp_out.c
index 62bf126..4dc818e 100755
--- a/drivers/video/omap/omap_disp_out.c
+++ b/drivers/video/omap/omap_disp_out.c
@@ -30,25 +30,29 @@
#include linux/fb.h
#include linux/delay.h
#include linux/device.h
-#include mach/hardware.h
+#include linux/delay.h
+#include linux/workqueue.h
+#include linux/platform_device.h
+
#include asm/uaccess.h
#include asm/delay.h
-#include linux/delay.h
-#include mach/display.h
+
#include mach/gpio.h
#include mach/clock.h
+#include mach/hardware.h
+#include mach/mux.h
+#include mach/power_companion.h
+#include mach/resource.h
+#include mach/display.h
+
#if defined(CONFIG_MACH_OMAP_2430SDP) || defined (CONFIG_MACH_OMAP_3430SDP) ||\
defined(CONFIG_MACH_OMAP_LDP) || defined(CONFIG_MACH_OMAP_ZOOM2)
#include linux/i2c/twl4030.h
#endif
-#include linux/workqueue.h
-#include mach/power_companion.h
-#include mach/resource.h
#ifdef CONFIG_PM
#include
Re: [PATCH] PM: Fix a bug with noncore dpll rate calculation
Tero Kristo [EMAIL PROTECTED] writes:
Noncore dpll can enter autoidle state, in which case the rate calculation
fails. Fixed by checking dpll mode instead of idle status.
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clock.c | 16 +++-
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 522ce6f..bbd3e82 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -212,9 +212,16 @@ u32 omap2_get_dpll_rate(struct clk *clk)
return 0;
/* Return bypass rate if DPLL is bypassed */
- v = cm_read_mod_reg(clk-prcm_mod, dd-idlest_reg);
- v = dd-idlest_mask;
- v = __ffs(dd-idlest_mask);
+ if (cpu_is_omap34xx()) {
+ v = cm_read_mod_reg(clk-prcm_mod, dd-control_reg);
+ v = dd-enable_mask;
+ v = __ffs(dd-enable_mask);
+ } else {
+ v = cm_read_mod_reg(clk-prcm_mod, dd-idlest_reg);
+ v = dd-idlest_mask;
+ v = __ffs(dd-idlest_mask);
+ }
+
if (cpu_is_omap24xx()) {
if (v == ST_CORE_CLK_REF)
@@ -224,9 +231,8 @@ u32 omap2_get_dpll_rate(struct clk *clk)
} else if (cpu_is_omap34xx()) {
- if (!v)
+ if (v == OMAP3430_EN_MPU_DPLL_BYPASS)
return dd-bypass_clk-rate;
-
}
v = cm_read_mod_reg(clk-prcm_mod, dd-mult_div1_reg);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6f3f5a3..9995353 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -112,6 +112,8 @@
#define OMAP3430_EN_MPU_DPLL_DRIFTGUARD_MASK (1 3)
#define OMAP3430_EN_MPU_DPLL_SHIFT 0
#define OMAP3430_EN_MPU_DPLL_MASK(0x7 0)
+#define OMAP3430_EN_MPU_DPLL_LOCK(0x7 0)
+#define OMAP3430_EN_MPU_DPLL_BYPASS (0x5 0)
/* CM_IDLEST_MPU */
#define OMAP3430_ST_MPU (1 0)
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: i2c-omap: Fix BUFSTAT_REG reading
On Wednesday 19 November 2008, Eero Nurkkala wrote: On Fri, 2008-11-14 at 11:16 -0800, ext David Brownell wrote: But if the issue is that the 2430 version of the FIFO support works differently, please say so in the patch commend and code... I checked against 2420, and there was no such register avaiable at all. (no 2430 TRM access) That code path couldn't be triggered on 2420; just 2430, which has the FIFO (as evidently needed for highspeed I2C). My default assumption would be that 2430 works just like OMAP3 here, but obviously someone should check the 2430 TRM to see its I2C BUFSTAT_REG really works differently. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH PM-20081106] OMAP: PM: Few fixes to uart clock handling
Jouni Hogander [EMAIL PROTECTED] writes:
Omap3_can_sleep is not inside part of idle loop which is protected
with irg disable. If some irq handler is trying dump out something
after omap3_can_sleep and before irqs are disabled. It causes oops
because uart clocks are disabled.
Remove also some unused extra code from omap_uart_can_sleep
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/serial.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ef30d8d..b06b797 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -314,21 +314,13 @@ void omap_uart_check_wakeup(void)
int omap_uart_can_sleep(void)
{
struct omap_uart_state *uart;
- int can_sleep = 1;
list_for_each_entry(uart, uart_list, node) {
- if (!uart-clocked)
+ if (!uart-clocked || !uart-can_sleep)
continue;
- if (!uart-can_sleep) {
- can_sleep = 0;
- continue;
- }
-
I don't think this part is quite right. I think this block should
stay, and the function should 'return can_sleep' instead of return 1;
I'll fix that, and incorporate your other changes here into
pm-20081118.
Kevin
/* This UART can now safely sleep. */
omap_uart_allow_sleep(uart);
- if (clocks_off_while_idle)
- omap_uart_disable_clocks(uart);
}
return 1;
@@ -435,7 +427,6 @@ static void omap_uart_pm(struct uart_port *port,
break;
case 3: /* suspend */
omap_uart_allow_sleep(uart);
- omap_uart_disable_clocks(uart);
break;
}
}
--
1.6.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Check in set_pwrdm_state that target state is supported by pwrdm v2
* Kevin Hilman [EMAIL PROTECTED] [081118 15:56]: Paul Walmsley [EMAIL PROTECTED] writes: On Mon, 17 Nov 2008, Jouni Hogander wrote: Check that wanted sleep state is supported by powerdomain. If it is not supported, then use next lowest supported state. Check also on suspend that state of pwrdm was lower or equal. Signed-off-by: Jouni Hogander [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] Signed-off-by: Kevin Hilman [EMAIL PROTECTED] Pushing this today. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] OMAP: Make OMAP LDP boot succussfuly
* Evgeniy Polyakov [EMAIL PROTECTED] [081114 03:29]: Hi Tony. On Thu, Nov 13, 2008 at 02:40:54PM -0800, Tony Lindgren ([EMAIL PROTECTED]) wrote: Evgeniy, can you please confirm you're adding the Stanley's 1w patch to your upstream queue? Or else let Stanley know if he needs to repost it to LKML. If w1 part does not depend on any upstream changes not yet in the tree, I will forward it for inclusing, but if it requires some external update to be pushed first, I would like to add w1 part into that merge. Yes, please include it into your queue, it does not have any other omap dependencies. And we are trying to move all the omap driver development to the appropriate driver lists to get in sync with the mainline tree. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] OMAP: Make OMAP LDP boot succussfuly
On Wed, Nov 19, 2008 at 10:13:08AM -0800, Tony Lindgren ([EMAIL PROTECTED]) wrote: If w1 part does not depend on any upstream changes not yet in the tree, I will forward it for inclusing, but if it requires some external update to be pushed first, I would like to add w1 part into that merge. Yes, please include it into your queue, it does not have any other omap dependencies. And we are trying to move all the omap driver development to the appropriate driver lists to get in sync with the mainline tree. Ok, I will push this patch series upstream. Thank you. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] OMAP: Make OMAP LDP boot succussfuly
* Evgeniy Polyakov [EMAIL PROTECTED] [081119 10:55]: On Wed, Nov 19, 2008 at 10:13:08AM -0800, Tony Lindgren ([EMAIL PROTECTED]) wrote: If w1 part does not depend on any upstream changes not yet in the tree, I will forward it for inclusing, but if it requires some external update to be pushed first, I would like to add w1 part into that merge. Yes, please include it into your queue, it does not have any other omap dependencies. And we are trying to move all the omap driver development to the appropriate driver lists to get in sync with the mainline tree. Ok, I will push this patch series upstream. Thank you. Thanks! The rest of the omap w1 patche should be coming to you via LKML then ;) Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] OMAP: Make OMAP LDP boot succussfuly
On Wed, Nov 19, 2008 at 11:14:20AM -0800, Tony Lindgren ([EMAIL PROTECTED]) wrote: Thanks! The rest of the omap w1 patche should be coming to you via LKML then ;) I've just pushed w1 patch (did I understand it right that there is only one in the given set, all others touch very different areas). -- Evgeniy Polyakov -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] OMAP: Make OMAP LDP boot succussfuly
* Evgeniy Polyakov [EMAIL PROTECTED] [081119 11:35]: On Wed, Nov 19, 2008 at 11:14:20AM -0800, Tony Lindgren ([EMAIL PROTECTED]) wrote: Thanks! The rest of the omap w1 patche should be coming to you via LKML then ;) I've just pushed w1 patch (did I understand it right that there is only one in the given set, all others touch very different areas). Yes, that's correct. The other patches are for LDP specific board support, and will be merged with the arm patches. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [FYI] Rebase: tidspbridge-20081118
* Hiroshi DOYU [EMAIL PROTECTED] [081117 05:37]: Hi, The following changes since commit f23f23fb6bfd8ce4669070df35ec9b320983ac0c: Grazvydas Ignotas (1): HSMMC: Add MMC configuration for pandora are available in the git repository at: http://git.gitorious.org/lk/mainline.git tidspbridge-20081118 Great, I'm now also mirroring tidspbridge-20081118 branch at: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary Tony Axel Haslam (1): BRIDGE: tiomap unmap fix Fernando Guzman Lugo (5): BRIDGE: Remove sparse warnings from wcd BRIDGE: Module ISR removed BRIDGE: PRCS wrappers removal BRIDGE: Chnl module cleanup BRIDGE: Sparse warnings cleanup Hari Kanigeri (4): BRIDGE Add preemption support to unprotected functions BRIDGE Resource cleanup node delete fix BRIDGE Memory leak fix BRIDGE Handle Node messaging when DSP crashed Hiroshi DOYU (23): BRIDGE: Kconfig Entry BRIDGE: Header files BRIDGE: Doff image dynamic loader BRIDGE: Generic Utilities BRIDGE: Hardware Interfaces BRIDGE: Platform Manager BRIDGE: Resource Manager BRIDGE: Services BRIDGE: Mini driver BRIDGE: README BRIDGE: Fix header path BRIDGE: Sync omapzoom bridge patches BRIDGE: set 0 for phys_mempool_* as default BRIDGE: Rename header file location BRIDGE: Fix header path name to arch/arm/plat-omap/include/dspbridge BRIDGE: Add 'dspbridge' dirname in header file inclusion BRIDGE: Fix incorrect pathname BRIDGE: Remove paths in header comment BRIDGE: fix build error BRIDGE: enable dspbridge in omap_3430sdp_defconfig BRIDGE: use more detail name for interrupt claiming device BRIDGE: Fix uninitialized spinlock BRIDGE: Fix memory leak in PROC_Init() Omar Ramirez Luna (11): BRIDGE: Ceanup GT sparse warnings BRIDGE: Cleanup static declarations warnings BRIDGE: Remove unused clk structs BRIDGE: Clean up unusedvariables BRIDGE: Cosmetic changes reported from checkpatch BRIDGE: Add wcd table end BRIDGE: Checkpatch Cleanup BRIDGE: OMAP CSL wrappers removed BRIDGE: Remove CDECL macro BRIDGE: GT mask for DSP traces BRIDGE: MMUfault infinite timeout fix Ramesh Gupta (4): BRIDGE: Power management changes BRIDGE: OMAP PM Bug softlockup fix BRIDGE Power Management cleanup BRIDGE Save mailbox settings for suspend-resume Suman Anna (1): BRIDGE: Fix bug in HW Mailbox messaging Tony Lindgren (1): DSPBRIDGE: Flush posted write when acking mailbox irq ext Ramirez Luna, Omar (1): BRIDGE: removing unnecesary OMAP3430 checks Documentation/tidspbridge/README | 70 + arch/arm/Kconfig |1 + arch/arm/configs/omap_3430sdp_defconfig|6 +- arch/arm/plat-omap/include/dspbridge/_chnl_sm.h| 212 ++ arch/arm/plat-omap/include/dspbridge/_dcd.h| 187 ++ arch/arm/plat-omap/include/dspbridge/brddefs.h | 54 + arch/arm/plat-omap/include/dspbridge/cfg.h | 339 ++ arch/arm/plat-omap/include/dspbridge/cfgdefs.h | 124 + arch/arm/plat-omap/include/dspbridge/chnl.h| 170 + arch/arm/plat-omap/include/dspbridge/chnl_sm.h | 210 ++ arch/arm/plat-omap/include/dspbridge/chnldefs.h| 92 + arch/arm/plat-omap/include/dspbridge/chnlpriv.h| 136 + arch/arm/plat-omap/include/dspbridge/clk.h | 155 + arch/arm/plat-omap/include/dspbridge/cmm.h | 420 +++ arch/arm/plat-omap/include/dspbridge/cmmdefs.h | 135 + arch/arm/plat-omap/include/dspbridge/cod.h | 433 +++ arch/arm/plat-omap/include/dspbridge/csl.h | 135 + arch/arm/plat-omap/include/dspbridge/dbc.h | 66 + arch/arm/plat-omap/include/dspbridge/dbdcd.h | 388 +++ arch/arm/plat-omap/include/dspbridge/dbdcddef.h| 94 + arch/arm/plat-omap/include/dspbridge/dbdefs.h | 577 arch/arm/plat-omap/include/dspbridge/dbg.h | 110 + arch/arm/plat-omap/include/dspbridge/dbl.h | 354 ++ arch/arm/plat-omap/include/dspbridge/dbldefs.h | 155 + arch/arm/plat-omap/include/dspbridge/dbll.h| 70 + arch/arm/plat-omap/include/dspbridge/dblldefs.h| 509 +++ arch/arm/plat-omap/include/dspbridge/dbof.h| 117 + arch/arm/plat-omap/include/dspbridge/dbreg.h | 113 + arch/arm/plat-omap/include/dspbridge/dbtype.h | 103 + arch/arm/plat-omap/include/dspbridge/dehdefs.h | 42 + arch/arm/plat-omap/include/dspbridge/dev.h | 785 + arch/arm/plat-omap/include/dspbridge/devdefs.h | 35 + arch/arm/plat-omap/include/dspbridge/disp.h| 236 ++ arch/arm/plat-omap/include/dspbridge/dispdefs.h| 45 +
Re: [PATCH] OMAP3 powerdomains: remove RET from SGX power states list
On Wed, Nov 12, 2008 at 11:07 AM, Paul Walmsley [EMAIL PROTECTED] wrote: Hi Jouni, Kevin, On Tue, 11 Nov 2008, Högander Jouni wrote: I wouldn't add any flags for this. The goal is finally to set all next_states as OFF until someone has set some constraint which prevents OFF usage. For now we need to use RET as default, because drivers are not supporting OFF mode. Do you agree this? Yes. Easiest way here would be to add own hook for SGX in pwrdms_setup? One more strcmp(*_pwrdm, pwrdm-name) :) What do you think? That is okay with me. This seems to be an unusual case - I guess it's due to an SGX firmware bug. So Kevin, if you have a strong opposition to that strcmp, maybe we should use a powerdomain flag for the SGX pwrdm. Otherwise, let's go with a strcmp as Jouni suggested. Thoughts? Has there been a final resolution on this? I am unable to boot reliably on Overo with 2.6.28-rc5 -- almost every boot attempt gives me: Power Management for TI OMAP3. Unable to set state of powerdomain: sgx_pwrdm Failed to setup powerdomains omap2|3_pm_init failed: -22 Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 powerdomains: remove RET from SGX power states list
Steve Sakoman [EMAIL PROTECTED] writes: On Wed, Nov 12, 2008 at 11:07 AM, Paul Walmsley [EMAIL PROTECTED] wrote: Hi Jouni, Kevin, On Tue, 11 Nov 2008, Högander Jouni wrote: I wouldn't add any flags for this. The goal is finally to set all next_states as OFF until someone has set some constraint which prevents OFF usage. For now we need to use RET as default, because drivers are not supporting OFF mode. Do you agree this? Yes. Easiest way here would be to add own hook for SGX in pwrdms_setup? One more strcmp(*_pwrdm, pwrdm-name) :) What do you think? That is okay with me. This seems to be an unusual case - I guess it's due to an SGX firmware bug. So Kevin, if you have a strong opposition to that strcmp, maybe we should use a powerdomain flag for the SGX pwrdm. Otherwise, let's go with a strcmp as Jouni suggested. Thoughts? Has there been a final resolution on this? I am unable to boot reliably on Overo with 2.6.28-rc5 -- almost every boot attempt gives me: Power Management for TI OMAP3. Unable to set state of powerdomain: sgx_pwrdm Failed to setup powerdomains omap2|3_pm_init failed: -22 Hi Steve, Tony just pushed the final version[1] of the fix for this issue. Please let me know if your problem still persists. Kevin [1] see commit 7a54b0f6f39ea1e5dbff6bb47314bea228bf6e44 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix section mismatch warning.
I know that Beagle and Overo get the same warnings, so this
isn't really a sufficient fix...
On Wednesday 19 November 2008, Sanjeev Premi wrote:
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -130,7 +130,7 @@ static struct twl4030_madc_platform_data
omap3evm_madc_data = {
.irq_line = 1,
};
-static struct twl4030_platform_data omap3evm_twldata = {
+static struct twl4030_platform_data __initdata omap3evm_twldata = {
... and that's incorrect in any case, since that data is used
by probe() code that's doesn't sit in an init section.
I have the following in my patchset, currently disabled since
it conflicts with other patches. And in any case, Beagle can't
reboot with these generic scripts for some TBD reason.
- Dave
= CUT HERE
---
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
arch/arm/mach-omap2/twl4030-generic-scripts.c |3 +++
arch/arm/mach-omap2/twl4030-generic-scripts.h |5 +
5 files changed, 11 insertions(+), 3 deletions(-)
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -188,7 +188,7 @@ static struct twl4030_platform_data beag
/* platform_data for children goes here */
.usb= beagle_usb_data,
.gpio = beagle_gpio_data,
- .power = generic3430_t2scripts_data,
+ .power = GENERIC3430_T2SCRIPTS_DATA,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -140,7 +140,7 @@ static struct twl4030_platform_data omap
.keypad = omap3evm_kp_data,
.madc = omap3evm_madc_data,
.usb= omap3evm_usb_data,
- .power = generic3430_t2scripts_data,
+ .power = GENERIC3430_T2SCRIPTS_DATA,
.gpio = omap3evm_gpio_data,
};
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -162,7 +162,7 @@ static struct twl4030_platform_data over
.irq_end= TWL4030_IRQ_END,
.gpio = overo_gpio_data,
.usb= overo_usb_data,
- .power = generic3430_t2scripts_data,
+ .power = GENERIC3430_T2SCRIPTS_DATA,
};
static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
--- a/arch/arm/mach-omap2/twl4030-generic-scripts.c
+++ b/arch/arm/mach-omap2/twl4030-generic-scripts.c
@@ -23,6 +23,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#ifdef CONFIG_TWL4030_POWER
+
#include linux/kernel.h
#include linux/device.h
#include linux/init.h
@@ -76,3 +78,4 @@ struct twl4030_power_data generic3430_t2
};
+#endif /* CONFIG_TWL4030_POWER */
--- a/arch/arm/mach-omap2/twl4030-generic-scripts.h
+++ b/arch/arm/mach-omap2/twl4030-generic-scripts.h
@@ -3,6 +3,11 @@
#include linux/i2c/twl4030.h
+#ifdef CONFIG_TWL4030_POWER
extern struct twl4030_power_data generic3430_t2scripts_data;
+#define GENERIC3430_T2SCRIPTS_DATA generic3430_t2scripts_data
+#else
+#define GENERIC3430_T2SCRIPTS_DATA NULL
+#endif /* CONFIG_TWL4030_POWER */
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] new PM branch: pm-20081119
Hello, A new PM branch is available named pm-20081119. This is mostly a new set of patches on top of the previous PM branch, rather than a rebase. We finally found the root cause of some DPLL relocking bugs. Special thanks to Paul Walmsley and Tero Kristo for debugging and fixing this problem. Now the DPLL fix that was reverted in the previous PM branch is re-applied as well as some fixes on top of it. It also has some additional UART fixes, so I think the UART idle work is ready to go to Tony. Special thanks to Jouni Hogander for the extra testing and fixes here. The shortlog is below[1] and the root of the tree is still v2.6.27-omap1 + T2 power patches from Peter. This has primarily been tested on custom HW since I'm _still_ waiting for my SDP to arrive. I have boot tested on Beagle, but I think there are still some problems with ES2 silicon. On my ES2 Beagle, neither DSS or IVA will leave the ON state, even when all clocks in their powerdomains are off. I have not debugged this further yet. Functionally, this tree is in pretty good shape, so I will do some bugfixes here when necessary, but will now spent some time focusing on getting the patches in this branch merged into linux-omap. Kevin [1] git shortlog: Amit Kucheria (2): OMAP: PM: Typo fix for clock_allow_idle HSMMC: Make driver support dynamic idle Jouni Hogander (11): OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle loop OMAP3: Do not set mpu, core, neon states if cpuidle is used OMAP3: PM: Do not set next states sw to control those is available OMAP3: PM: Always return value in pwrdms_setup OMAP3: PM: Fix wrong sequence in suspend. OMAP3: UART: Make sure that uart clocks are enabled when needed OMAP3: PM: Check in set_pwrdm_state that target state is supported by pwrdm v2 OMAP3: PM: Do not build suspend code if SUSPEND is not enabled OMAP: PM: Build fails if PM is not enabled OMAP2: PM: Fix omap2 build OMAP: MCSPI: Enable mcspi wake-up Kalle Jokiniemi (4): OMAP: PM: sysfs interface for enabling voltage off in idle OMAP3: PM: Fix cpu idle init sequencing OMAP: SRF: Fixes to shared resource framework (Ver.3) OMAP3: I2C: Enable I2C wakeups Kevin Hilman (16): OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X OMAP3: PM: Allow UARTs to be unclocked when inactive 8250: Allow platform to register PM hook 8250: when waking, PM hook should be called before accessing port OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume OMAP3: PM: UART save/restore support for OFF-mode OMAP2/3: HSMMC: Ensure HSMMC is fully reset on boot OMAP3: PM: CPUidle: obey enable_off_mode flag OMAP3: PM: CPUidle: restrict C-states on UART activity OMAP3: PM: decouple PER and CORE context save and restore Revert OMAP3 clock: fix non-CORE DPLL rate assignment bugs Revert OMAP3: PM: Do not set next states sw to control those is available Revert OMAP3: Do not set mpu, core, neon states if cpuidle is used OMAP: PM: UART: fix can_sleep hook to return correct value OMAP: PM: UART: Only disable clocks in prepare-idle hook OMAP3: PM: Check for UART wakeups in 'resume_idle' hook Paul Walmsley (14): OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer. OMAP2/3 omapdev: add basic omapdev structure OMAP242x omapdev: add OMAP242x omapdev records OMAP243x omapdev: add OMAP243x omapdev records OMAP3xxx omapdev: add OMAP3xxx omapdev records OMAP2/3 omapdev: add code to walk the omapdev records OMAP3 clock: fix non-CORE DPLL rate assignment bugs OMAP3 powerdomains: remove RET from SGX power states list OMAP3 powerdomains: remove RET from SGX power states list OMAP3 clock: remove unnecessary dpll_data dereferences OMAP3 clock: optimize DPLL rate rounding algorithm OMAP3 clock: avoid invalid FREQSEL values during DPLL rate rounding OMAP2/3 I2C: reprogram OCP_SYSCONFIG register after reset OMAP: I2C: convert 'rev1' flag to generic 'rev' u8 Peter 'p2' De Schrijver (9): OMAP: PM counter infrastructure. OMAP: PM: Hook into PM counters OMAP: PM: Add closures to clkdm_for_each and pwrdm_for_each. OMAP: PM: Add pm-debug counters OMAP: PM debug: make powerdomains use PM-debug counters OMAP: PM: Add definitions for ETK pads and observability registers OMAP: Debug observability and ETK padconf implementation OMAP: Add debug observablity (debobs) Kconfig item OMAP: PM: Implement get_last_off_on_transaction_id() Rajendra Nayak (23): OMAP3: PM: GPMC context save/restore OMAP3: PM: GPIO context save/restore OMAP3: PM: I2C context save/restore OMAP3: PM: INTC context save/restore OMAP3: PM: PRCM context save/restore OMAP3: PM: Populate scratchpad contents
[patch 2.6.28-rc5 0/5] twl4030 irq assignments
The following patches remove some needless dependencies from TWL4030 support, supporting non-OMAP builds and in some cases, non-SDP (etc) builds. - keypad driver ... use platform_get_irq(), no board dependencies - BCI driver ... likewise - MADC driver ... use platform_get_irq() - power button ... still pretty hacky, there's no device here - removes the now-dead symbols, and OMAP-dependency Build-tested. With this, I think the keypad driver becomes ready to go upstream, after related twl4030-core updates. At least, it's ready for review. (Including: Why pass the keypad module id to kpread/kpwrite, it's the only one ever used? Why does Kconfig mention GPIOs, since they aren't used?) The point of these patches is that last one, which lets non-OMAP folk do test builds and easily make updates when APIs change. Yeah, it's a strange notion, but not everyone does OMAP builds. ;) - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.28-rc5 1/5] twl4030 keypad irq dependencies
From: David Brownell [EMAIL PROTECTED]
Disable the TWL4030_MODIRQ_KEYPAD symbol and remove all its uses.
It's not needed any more now that platform_get_irq() works for
these keypad devices.
Also remove inappropriate board-specific Kconfig dependencies.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-2430sdp.c |1 -
arch/arm/mach-omap2/board-3430sdp.c |1 -
arch/arm/mach-omap2/board-ldp.c |1 -
arch/arm/mach-omap2/board-omap2evm.c|1 -
arch/arm/mach-omap2/board-omap3evm.c|1 -
drivers/input/keyboard/Kconfig |2 +-
drivers/input/keyboard/omap-twl4030keypad.c |2 +-
include/linux/i2c/twl4030.h |3 +--
8 files changed, 3 insertions(+), 9 deletions(-)
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -182,7 +182,6 @@ static struct twl4030_keypad_data sdp243
.keymap = sdp2430_keymap,
.keymapsize = ARRAY_SIZE(sdp2430_keymap),
.rep= 1,
- .irq= TWL4030_MODIRQ_KEYPAD,
};
static int __init msecure_init(void)
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -118,7 +118,6 @@ static struct twl4030_keypad_data sdp343
.keymap = sdp3430_keymap,
.keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep= 1,
- .irq= TWL4030_MODIRQ_KEYPAD,
};
static int ts_gpio;
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -101,7 +101,6 @@ static struct twl4030_keypad_data ldp_kp
.keymap = ldp_twl4030_keymap,
.keymapsize = ARRAY_SIZE(ldp_twl4030_keymap),
.rep= 1,
- .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct gpio_keys_button ldp_gpio_keys_buttons[] = {
--- a/arch/arm/mach-omap2/board-omap2evm.c
+++ b/arch/arm/mach-omap2/board-omap2evm.c
@@ -273,7 +273,6 @@ static struct twl4030_keypad_data omap2e
.keymap = omap2evm_keymap,
.keymapsize = ARRAY_SIZE(omap2evm_keymap),
.rep= 1,
- .irq= TWL4030_MODIRQ_KEYPAD,
};
static void __init omap2_evm_init_irq(void)
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -125,7 +125,6 @@ static struct twl4030_keypad_data omap3e
.keymap = omap3evm_keymap,
.keymapsize = ARRAY_SIZE(omap3evm_keymap),
.rep= 1,
- .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct twl4030_madc_platform_data omap3evm_madc_data = {
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -261,7 +261,7 @@ config KEYBOARD_OMAP
config KEYBOARD_TWL4030
tristate TI TWL4030 keypad support
- depends on TWL4030_CORE (MACH_OMAP_2430SDP || MACH_OMAP2EVM ||
MACH_OMAP_3430SDP || MACH_OMAP3EVM || MACH_OMAP_LDP)
+ depends on TWL4030_CORE
help
Say Y here if you want to use the OMAP TWL4030 keypad.
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -269,7 +269,7 @@ static int __init omap_kp_probe(struct p
kp-keymapsize = pdata-keymapsize;
kp-n_rows = pdata-rows;
kp-n_cols = pdata-cols;
- kp-irq = pdata-irq;
+ kp-irq = platform_get_irq(pdev, 0);
/* setup input device */
set_bit(EV_KEY, kp-omap_twl4030kp-evbit);
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -259,7 +259,6 @@ struct twl4030_keypad_data {
int rows;
int cols;
int *keymap;
- int irq;
unsigned int keymapsize;
unsigned int rep:1;
};
@@ -374,7 +373,7 @@ int twl4030_sih_setup(int module);
/* TWL4030 interrupts */
/* #define TWL4030_MODIRQ_GPIO (TWL4030_IRQ_BASE + 0) */
-#define TWL4030_MODIRQ_KEYPAD (TWL4030_IRQ_BASE + 1)
+/* #define TWL4030_MODIRQ_KEYPAD (TWL4030_IRQ_BASE + 1) */
#define TWL4030_MODIRQ_BCI (TWL4030_IRQ_BASE + 2)
#define TWL4030_MODIRQ_MADC(TWL4030_IRQ_BASE + 3)
/* #define TWL4030_MODIRQ_USB (TWL4030_IRQ_BASE + 4) */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.28-rc5 2/5] twl4030 BCI irq and dependencies
From: David Brownell [EMAIL PROTECTED]
Disable the TWL4030_MODIRQ_BCI symbol and remove all its uses.
It's not needed any more now that platform_get_irq() works for
these BCI devices.
Also remove inappropriate board-specific Kconfig dependencies.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/power/Kconfig |3 +--
drivers/power/twl4030_bci_battery.c | 18 +++---
include/linux/i2c/twl4030.h |2 +-
3 files changed, 13 insertions(+), 10 deletions(-)
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -58,8 +58,7 @@ config BATTERY_TOSA
config TWL4030_BCI_BATTERY
tristate OMAP TWL4030 BCI Battery driver
- depends on (MACH_OMAP_2430SDP || MACH_OMAP_3430SDP || MACH_OMAP_LDP)
TWL4030_MADC
- default y
+ depends on TWL4030_CORE TWL4030_MADC
help
Support for OMAP TWL4030 BCI Battery driver.
This driver can give support for TWL4030 Battery Charge Interface.
--- a/drivers/power/twl4030_bci_battery.c
+++ b/drivers/power/twl4030_bci_battery.c
@@ -958,17 +958,17 @@ static int __init twl4030_bci_battery_pr
/* REVISIT do we need to request both IRQs ?? */
/* request BCI interruption */
- ret = request_irq(TWL4030_MODIRQ_BCI, twl4030battery_interrupt,
+ irq = platform_get_irq(pdev, 1);
+ ret = request_irq(irq, twl4030battery_interrupt,
0, pdev-name, NULL);
if (ret) {
dev_dbg(pdev-dev, could not request irq %d, status %d\n,
- TWL4030_MODIRQ_BCI, ret);
+ irq, ret);
goto batt_irq_fail;
}
- irq = platform_get_irq(pdev, 0);
-
/* request Power interruption */
+ irq = platform_get_irq(pdev, 0);
ret = request_irq(irq, twl4030charger_interrupt,
0, pdev-name, di);
@@ -1005,7 +1005,8 @@ bk_batt_failed:
batt_failed:
free_irq(irq, di);
chg_irq_fail:
- free_irq(TWL4030_MODIRQ_BCI, NULL);
+ irq = platform_get_irq(pdev, 1);
+ free_irq(irq, NULL);
batt_irq_fail:
voltage_setup_fail:
temp_setup_fail:
@@ -1021,16 +1022,19 @@ temp_setup_fail:
static int __exit twl4030_bci_battery_remove(struct platform_device *pdev)
{
struct twl4030_bci_device_info *di = platform_get_drvdata(pdev);
- int irq = platform_get_irq(pdev, 0);
+ int irq;
twl4030charger_ac_en(DISABLE);
twl4030charger_usb_en(DISABLE);
twl4030battery_hw_level_en(DISABLE);
twl4030battery_hw_presence_en(DISABLE);
- free_irq(TWL4030_MODIRQ_BCI, NULL);
+ irq = platform_get_irq(pdev, 0);
free_irq(irq, di);
+ irq = platform_get_irq(pdev, 1);
+ free_irq(irq, NULL);
+
flush_scheduled_work();
power_supply_unregister(di-bat);
power_supply_unregister(di-bk_bat);
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -374,7 +374,7 @@ int twl4030_sih_setup(int module);
/* #define TWL4030_MODIRQ_GPIO (TWL4030_IRQ_BASE + 0) */
/* #define TWL4030_MODIRQ_KEYPAD (TWL4030_IRQ_BASE + 1) */
-#define TWL4030_MODIRQ_BCI (TWL4030_IRQ_BASE + 2)
+/* #define TWL4030_MODIRQ_BCI (TWL4030_IRQ_BASE + 2) */
#define TWL4030_MODIRQ_MADC(TWL4030_IRQ_BASE + 3)
/* #define TWL4030_MODIRQ_USB (TWL4030_IRQ_BASE + 4) */
/* #define TWL4030_MODIRQ_PWR (TWL4030_IRQ_BASE + 5) */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.28-rc5 3/5] twl4030 MADC irq
From: David Brownell [EMAIL PROTECTED]
Disable the TWL4030_MODIRQ_MADC symbol and remove all its uses.
It's not needed any more now that platform_get_irq() works for
these MADC devices.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-madc.c |4 ++--
include/linux/i2c/twl4030.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/i2c/chips/twl4030-madc.c
+++ b/drivers/i2c/chips/twl4030-madc.c
@@ -458,7 +458,7 @@ static int __init twl4030_madc_probe(str
ret = twl4030_i2c_write_u8(TWL4030_MODULE_MAIN_CHARGE,
regval, TWL4030_BCI_BCICTL1);
- ret = request_irq(TWL4030_MODIRQ_MADC, twl4030_madc_irq_handler,
+ ret = request_irq(platform_get_irq(pdev, 0), twl4030_madc_irq_handler,
0, twl4030_madc, madc);
if (ret) {
dev_dbg(pdev-dev, could not request irq\n);
@@ -489,7 +489,7 @@ static int __exit twl4030_madc_remove(st
twl4030_madc_set_power(madc, 0);
twl4030_madc_set_current_generator(madc, 0, 0);
- free_irq(TWL4030_MODIRQ_MADC, madc);
+ free_irq(platform_get_irq(pdev, 0), madc);
cancel_work_sync(madc-ws);
misc_deregister(twl4030_madc_device);
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -375,7 +375,7 @@ int twl4030_sih_setup(int module);
/* #define TWL4030_MODIRQ_GPIO (TWL4030_IRQ_BASE + 0) */
/* #define TWL4030_MODIRQ_KEYPAD (TWL4030_IRQ_BASE + 1) */
/* #define TWL4030_MODIRQ_BCI (TWL4030_IRQ_BASE + 2) */
-#define TWL4030_MODIRQ_MADC(TWL4030_IRQ_BASE + 3)
+/* #define TWL4030_MODIRQ_MADC (TWL4030_IRQ_BASE + 3) */
/* #define TWL4030_MODIRQ_USB (TWL4030_IRQ_BASE + 4) */
/* #define TWL4030_MODIRQ_PWR (TWL4030_IRQ_BASE + 5) */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.28-rc5 4/5] twl4030 power button irq
From: David Brownell [EMAIL PROTECTED]
Disable the TWL4030_PWRIRQ_PWRBTN symbol from the system headers;
initialization of the power button handler still needs work, so
an equivalent symbol is defined in its driver.
Power IRQs now properly handle trigger specs from request_irq();
stop goofing with registers reserved to the IRQ infrastructure.
Minor cleanup: switch several messages to pr_debug().
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-pwrbutton.c | 50
include/linux/i2c/twl4030.h |2 -
2 files changed, 15 insertions(+), 37 deletions(-)
--- a/drivers/i2c/chips/twl4030-pwrbutton.c
+++ b/drivers/i2c/chips/twl4030-pwrbutton.c
@@ -29,18 +29,16 @@
#include linux/interrupt.h
#include linux/i2c/twl4030.h
-#define PWR_ISR1 0
-#define PWR_IMR1 1
+
#define PWR_PWRON_IRQ (10)
-#define PWR_EDR1 5
-#define PWR_PWRON_RISING (11)
-#define PWR_PWRON_FALLING (10)
-#define PWR_PWRON_BOTH (PWR_PWRON_RISING | PWR_PWRON_FALLING)
+#define STS_HW_CONDITIONS 0xf
-#define PWR_SIH_CTRL 7
-#define STS_HW_CONDITIONS 0xf
+/* FIXME have this constant delivered to us as part of the
+ * twl4030-core setup ...
+ */
+#define TWL4030_PWRIRQ_PWRBTN (TWL4030_PWR_IRQ_BASE + 0)
static struct input_dev *powerbutton_dev;
@@ -73,20 +71,19 @@ static irqreturn_t powerbutton_irq(int i
static int __init twl4030_pwrbutton_init(void)
{
int err = 0;
- u8 value;
/* PWRBTN == PWRON */
- if (request_irq(TWL4030_PWRIRQ_PWRBTN, powerbutton_irq, 0,
- PwrButton, NULL) 0) {
- printk(KERN_ERR Unable to allocate IRQ for power button\n);
- err = -EBUSY;
+ err = request_irq(TWL4030_PWRIRQ_PWRBTN, powerbutton_irq,
+ IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
+ PwrButton, NULL);
+ if (err 0) {
+ pr_debug(Can't get IRQ for power button: %d\n, err);
goto out;
}
powerbutton_dev = input_allocate_device();
if (!powerbutton_dev) {
- printk(KERN_ERR
- Unable to allocate input device for power button\n);
+ pr_debug(Can't allocate power button\n);
err = -ENOMEM;
goto free_irq_and_out;
}
@@ -97,26 +94,7 @@ static int __init twl4030_pwrbutton_init
err = input_register_device(powerbutton_dev);
if (err) {
- input_free_device(powerbutton_dev);
- goto free_irq_and_out;
- }
-
- /* FIXME just pass IRQF_EDGE_FALLING | IRQF_EDGE_RISING
-* to request_irq(), once MODULE_INT supports them...
-*/
- err = twl4030_i2c_read_u8(TWL4030_MODULE_INT, value, PWR_EDR1);
- if (err) {
- printk(KERN_WARNING I2C error %d while reading TWL4030
-INT PWR_EDR1 register\n, err);
- goto free_input_dev;
- }
-
- err = twl4030_i2c_write_u8(TWL4030_MODULE_INT,
- value | PWR_PWRON_BOTH, PWR_EDR1);
-
- if (err) {
- printk(KERN_WARNING I2C error %d while writing TWL4030
-INT PWR_EDR1 register\n, err);
+ pr_debug(Can't register power button: %d\n, err);
goto free_input_dev;
}
@@ -126,7 +104,7 @@ static int __init twl4030_pwrbutton_init
free_input_dev:
- input_unregister_device(powerbutton_dev);
+ input_free_device(powerbutton_dev);
free_irq_and_out:
free_irq(TWL4030_PWRIRQ_PWRBTN, NULL);
out:
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -379,7 +379,7 @@ int twl4030_sih_setup(int module);
/* #define TWL4030_MODIRQ_USB (TWL4030_IRQ_BASE + 4) */
/* #define TWL4030_MODIRQ_PWR (TWL4030_IRQ_BASE + 5) */
-#define TWL4030_PWRIRQ_PWRBTN (TWL4030_PWR_IRQ_BASE + 0)
+/* #define TWL4030_PWRIRQ_PWRBTN (TWL4030_PWR_IRQ_BASE + 0) */
/* #define TWL4030_PWRIRQ_CHG_PRES (TWL4030_PWR_IRQ_BASE + 1) */
/* #define TWL4030_PWRIRQ_USB_PRES (TWL4030_PWR_IRQ_BASE + 2) */
/* #define TWL4030_PWRIRQ_RTC (TWL4030_PWR_IRQ_BASE + 3) */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.28-rc5 5/5] twl4030 cleanup symbols and OMAP dependency
From: David Brownell [EMAIL PROTECTED]
Finish removing dependency of TWL driver stack on platform-specific
IRQ definitions ... and remove the build dependency on OMAP.
This lets the TWL4030 code be included in test builds for most
platforms, and will make it easier for non-OMAP folk to update
most of this code for new APIs etc.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/mfd/Kconfig |2 +-
include/linux/i2c/twl4030.h | 32
2 files changed, 1 insertion(+), 33 deletions(-)
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -63,7 +63,7 @@ config UCB1400_CORE
config TWL4030_CORE
bool Texas Instruments TWL4030/TPS659x0 Support
- depends on I2C=y GENERIC_HARDIRQS (ARCH_OMAP2 || ARCH_OMAP3)
+ depends on I2C=y GENERIC_HARDIRQS
help
Say yes here if you have TWL4030 family chip on your board.
This core driver provides register access and IRQ handling
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -363,33 +363,6 @@ struct twl4030_platform_data {
int twl4030_sih_setup(int module);
-/*
- * FIXME completely stop using TWL4030_IRQ_BASE ... instead, pass the
- * IRQ data to subsidiary devices using platform device resources.
- */
-
-/* IRQ information-need base */
-#include mach/irqs.h
-/* TWL4030 interrupts */
-
-/* #define TWL4030_MODIRQ_GPIO (TWL4030_IRQ_BASE + 0) */
-/* #define TWL4030_MODIRQ_KEYPAD (TWL4030_IRQ_BASE + 1) */
-/* #define TWL4030_MODIRQ_BCI (TWL4030_IRQ_BASE + 2) */
-/* #define TWL4030_MODIRQ_MADC (TWL4030_IRQ_BASE + 3) */
-/* #define TWL4030_MODIRQ_USB (TWL4030_IRQ_BASE + 4) */
-/* #define TWL4030_MODIRQ_PWR (TWL4030_IRQ_BASE + 5) */
-
-/* #define TWL4030_PWRIRQ_PWRBTN (TWL4030_PWR_IRQ_BASE + 0) */
-/* #define TWL4030_PWRIRQ_CHG_PRES (TWL4030_PWR_IRQ_BASE + 1) */
-/* #define TWL4030_PWRIRQ_USB_PRES (TWL4030_PWR_IRQ_BASE + 2) */
-/* #define TWL4030_PWRIRQ_RTC (TWL4030_PWR_IRQ_BASE + 3) */
-/* #define TWL4030_PWRIRQ_HOT_DIE (TWL4030_PWR_IRQ_BASE + 4) */
-/* #define TWL4030_PWRIRQ_PWROK_TIMEOUT(TWL4030_PWR_IRQ_BASE + 5) */
-/* #define TWL4030_PWRIRQ_MBCHG(TWL4030_PWR_IRQ_BASE + 6) */
-/* #define TWL4030_PWRIRQ_SC_DETECT(TWL4030_PWR_IRQ_BASE + 7) */
-
-/* Rest are unsued currently*/
-
/* Offsets to Power Registers */
#define TWL4030_VDAC_DEV_GRP 0x3B
#define TWL4030_VDAC_DEDICATED 0x3E
@@ -400,11 +373,6 @@ int twl4030_sih_setup(int module);
#define TWL4030_VAUX3_DEV_GRP 0x1F
#define TWL4030_VAUX3_DEDICATED0x22
-/* TWL4030 GPIO interrupt definitions */
-
-#define TWL4030_GPIO_IRQ_NO(n) (TWL4030_GPIO_IRQ_BASE + (n))
-
-
#if defined(CONFIG_TWL4030_BCI_BATTERY) || \
defined(CONFIG_TWL4030_BCI_BATTERY_MODULE)
extern int twl4030charger_usb_en(int enable);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS in OMAP 1-wire driver
It has been fixed and the patch was added to -mm tree.
Stanley.
From: Stanley.Miao [EMAIL PROTECTED]
OMAP LDP boot crash. This is because w1 subsystem changed the search
interface, so update omap_hdq's search interface to follow the change.
Signed-off-by: Stanley.Miao [EMAIL PROTECTED]
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/w1/masters/omap_hdq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff -puN drivers/w1/masters/omap_hdq.c~w1-omap-fix-omap-ldp-boot-crash
drivers/w1/masters/omap_hdq.c
--- a/drivers/w1/masters/omap_hdq.c~w1-omap-fix-omap-ldp-boot-crash
+++ a/drivers/w1/masters/omap_hdq.c
@@ -86,8 +86,8 @@ static struct platform_driver omap_hdq_d
static u8 omap_w1_read_byte(void *_hdq);
static void omap_w1_write_byte(void *_hdq, u8 byte);
static u8 omap_w1_reset_bus(void *_hdq);
-static void omap_w1_search_bus(void *_hdq, u8 search_type,
- w1_slave_found_callback slave_found);
+static void omap_w1_search_bus(void *_hdq, struct w1_master
*master_dev,
+ u8 search_type, w1_slave_found_callback slave_found);
static struct w1_bus_master omap_w1_master = {
@@ -231,8 +231,8 @@ static u8 omap_w1_reset_bus(void *_hdq)
}
/* W1 search callback function */
-static void omap_w1_search_bus(void *_hdq, u8 search_type,
- w1_slave_found_callback slave_found)
+static void omap_w1_search_bus(void *_hdq, struct w1_master
*master_dev,
+ u8 search_type, w1_slave_found_callback slave_found)
{
u64 module_id, rn_le, cs, id;
@@ -249,7 +249,7 @@ static void omap_w1_search_bus(void *_hd
cs = w1_calc_crc8((u8 *)rn_le, 7);
id = (cs 56) | module_id;
- slave_found(_hdq, id);
+ slave_found(master_dev, id);
}
static int _omap_hdq_reset(struct hdq_data *hdq_data)
_
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: ARM: Change Some GPIO Funtions on LDP
0001-OMAP-ARM-Change-Some-GPIO-Funtions-on-LDP.patch Description: Binary data
Re: [PATCH] OMAP: ARM: Change Some GPIO Funtions on LDP
I think there are still a bunch of patches from Jarkko outstanding which solve this comprehensively ... - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
