From: Peter 'p2' De Schrijver [EMAIL PROTECTED]
Kconfig and Makefile changes
Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED]
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/i2c/chips/Kconfig |4
drivers/i2c/chips/Makefile |3 ++-
2 files changed, 6
From: Peter 'p2' De Schrijver [EMAIL PROTECTED]
This patch adapts the existing driver to use the power IRQ handler. This
patch superseeds any previous version.
Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED]
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
On Thu, Apr 03, 2008 at 04:44:22PM +0300, Felipe Balbi wrote:
From: Peter 'p2' De Schrijver [EMAIL PROTECTED]
Missing d-handle_irq();
From 10b0fa72ded443a8d89ef3676f9ea08b3b87f8c0 Mon Sep 17 00:00:00 2001
From: Peter 'p2' De Schrijver [EMAIL PROTECTED]
Date: Wed, 2 Apr 2008 20:57:58 +0300
On Thu, Apr 03, 2008 at 06:56:01AM -0500, ext Felipe Balbi wrote:
On Thu, 3 Apr 2008 14:38:30 +0300, Felipe Balbi [EMAIL PROTECTED]
wrote:
The following is better as I'm also disabling the clock on suspend to
conserve power.
The spinlock wasn't needed, stupid brain-fart.
Sorry for
On Thu, Apr 03, 2008 at 04:57:33PM +0300, Peter 'p2' De Schrijver wrote:
Felipe,
+
+ for (module_irq = IH_TWL4030_PWRBASE; pwr_isr != 0;
+ module_irq++, pwr_isr = 1) {
+ if (pwr_isr 1) {
+ irq_desc_t *d =
On Thursday 03 April 2008, Felipe Balbi wrote:
+ * TWL4030 MADC module driver
What's a MADC? The driver should explain that much,
especially for chips where the documentation isn't being
made generally available.
I'm guessing it's some flavor of ADC... 8 bit? How
many channels? Any special
On Thursday 03 April 2008, Felipe Balbi wrote:
+config TWL4030_MADC
+ tristate TWL4030 MADC Driver
+ depends on TWL4030_CORE
+
Again, what's a MADC?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Thursday 03 April 2008, Felipe Balbi wrote:
+config TWL4030_MADC
+ tristate TWL4030 MADC Driver
+ depends on TWL4030_CORE
+
Again, what's a MADC?
It's an 'upset C' of course ;)
Really:
It's a 10-bit analog-to-digital converter combined with a 16-input analog
Again, what's a MADC?
It's an 'upset C' of course ;)
Better than obfuscated C, I guess. http://www.ioccc.org/ ... :)
Really:
It's a 10-bit analog-to-digital converter combined with a 16-input
analog multiplexer. Multiplexed-ADC I suppose. It is used by
processor groups, battery
This patch implements an idea from Igor Stoppa [EMAIL PROTECTED]
from last year. We use functions to modify PRM/CM register bits,
rather than open-coding those operations.
The patch provides functions that do read + AND + OR + write sequences
on CM and PRM registers: {cm,prm}_rmw_reg_bits(), and
Convert existing code that reads, modifies, and writes back CM/PRM
register values to use the rmw functions introduced in the previous
patch. This code should eventually disappear once clockdomain handling
is integrated into the 24xx clock framework.
Also restructure arch/arm/mach-omap2/prcm.c
From: Andrzej Zaborowski [EMAIL PROTECTED]
Prevent AIC23 driver Oopsing when no AIC23 is present by moving some of the
initialisation to after the chip is found. There seems to be more that
should be fixed in this driver but with this change it can at least be
compiled into a kernel safely.
On 02/04/2008, Tony Lindgren [EMAIL PROTECTED] wrote:
* Andrzej Zaborowski [EMAIL PROTECTED] [080329 18:30]:
From: Andrzej Zaborowski [EMAIL PROTECTED]
Prevent AIC23 driver Oopsing when no AIC23 is present by moving some of the
initialisation to after the chip is found. There seems
Hello,
this patch series adds DPLL autoidle control for OMAP3. It then adds
OMAP3 DPLL enable and disable support via clock framework clk_enable()
and clk_disable(). It also updates the clock34xx.h comments to credit
frequent contributors.
I personally have verified that DPLL disable has been
Ensure that people who have contributed several bug fixes to the
34xx clock framework are appropriately credited.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clock34xx.h | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
Index:
This patch adds support for DPLL autoidle control to the OMAP3 clock
framework. These functions will be used by the noncore DPLL enable
and disable code - this is because, according to the CDP code, the
DPLL autoidle status must be saved and restored across DPLL
lock/bypass/off transitions.
This patch implements enable/disable for non-CORE DPLLs (DPLLs 1, 2,
4, 5) in the OMAP34xx clock framework.
Enabling a DPLL in this context means taking the DPLL from off to
lock, off to bypass, or bypass to lock. If the clock's target rate is
set to the DPLL parent's clock rate, the DPLL will
In that variant I just added a load_start() function in addition to
the
load function and converted all the in tree callers to use this as
they
all called load() then start() in order anyway. This left the API
behavior the same but optimized all current users.
Can you send a patch
18 matches
Mail list logo