Hi,
This patch set contains all workarounds that are needed to get omap3
to retention. Also patch from Tero Kristo to get PM to work if using
serial console is included in this set. Basically all patches in this
set should be reverted one by one as correct fixes are implemented and
applied.
This
There are drivers that are not disabling their clocks (gpio
uart). These clocks need to be disabled if retention/off state is
wanted when idling. Before disabling them in idle loop this option
needs to be checked.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm.c |
From: Tero Kristo [EMAIL PROTECTED]
UART usage (e.g. serial console) now denies sleep for 5 seconds. This
makes it possible to use serial console when dynamic idle is
enabled. Write 1 to /sys/power/clocks_off_while_sleep to enable uart
clock disable on idle. Without this omap won't enter
This workaround shouldn't be needed when all drivers are configuring
their sysconfig registers properly and using their clocks properly.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm34xx.c | 31 +++
1 files changed, 31 insertions(+), 0
In omap3 gpios 2-6 are in per domain. Functional clocks for these
should be disabled. This patch is needed until gpio driver disables
gpio clocks.
GPIO modules in PER domain are not able to act as a wake up source if
PER domain is in retention. PER domain sleep transition before MPU is
prevented
This workaround is needed until powerdomain code resets wkdeps.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm34xx.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
Hi Rajendra,
The patches still require some amount of cleaning, once Jouni posts his next
set of workaround patches
taking care of the sleep dependecy for PER, I will rework/clean these patches
and then send it to the
linux-omap list.
I am still seeing some issues with debug uart
On Mon, Jun 30, 2008 at 12:23 PM, David Brownell [EMAIL PROTECTED] wrote:
On Monday 02 June 2008, Bryan Wu wrote:
The DMA interrupt register is cleared on a read. I don't think you need
to explicitly clear it.
Maybe there some difference between Blackfin and OMAP implementation.
From the
Use platform_data to pass musb configuration-specific
details to musb driver.
It's easier to maintain in the sense that neither board
will affect the other.
For now tested on n800 only, wanna hear from everybody what
guys think before test on omap3430sdp
Signed-off-by: Felipe Balbi [EMAIL
Hi,
On Mon, 2008-06-30 at 07:45 -0500, ext Woodruff, Richard wrote:
For things like bluetooth or other the protocol should re-transmit.
That's avoided with an out of band irq.
That can work assuming that external device gives you a 'pre' interrupt before
it generates the real timing
Signed-off-by: Mikko Ylinen [EMAIL PROTECTED]
---
arch/arm/plat-omap/gpio-switch.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio-switch.c b/arch/arm/plat-omap/gpio-switch.c
index cd96c00..7a61d0e 100644
--- a/arch/arm/plat-omap/gpio-switch.c
Code changes for final rev of EHCI/OHCI USB expansion board 750-2099-001(C)
with h/w bug fixes to support ISP1504 PHY in input clocking mode
The board has 12-pin ULPI Port1 and Port2 EHCI pins connected to ISP1504's.
Port3 is connected to ISP1301 for connection to OHCI.
- This is
Try if pdata provides a cleanup function pointers. For
boards which don't provide it, driver will oops in
omap_remove.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/mmc/host/omap_hsmmc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
If by responsiveness it is meant slowness of output (tx path) that' likely
good news. It means your hitting interconnect clock stop often and thus
getting into first large active mode savings state. This is the biggest step
power drop for active states. If your UART looks good you
Hi all,
The following set of patches add ethernet support for omap2evm
I have incorporated the comments form Tony and Felipe.
* 0001-OMAP2EVM-Adding-ethernet-support.patch
This patch modifies the board files for supporting smc9115
*
net:smc911x Modify driver to also work with omap24xx
Signed-off-by: Arun KS [EMAIL PROTECTED]
---
drivers/net/Kconfig |2 +-
drivers/net/smc911x.h |5 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 61ecee7..ecda0b6
Added ethernet driver support in defconfig
Signed-off-by: Arun KS [EMAIL PROTECTED]
---
arch/arm/configs/omap2_evm_defconfig | 489 --
1 files changed, 349 insertions(+), 140 deletions(-)
diff --git a/arch/arm/configs/omap2_evm_defconfig
Hi all,
The following patch adds smc911x support for omap24xx platforms.
I had tested the driver on Mistral's OMAP2EVM board.
Please consider this for merging.
Best Regards,
Arun KS
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL
net:smc911x Modify driver to also work with omap24xx
Signed-off-by: Arun KS [EMAIL PROTECTED]
---
drivers/net/Kconfig |2 +-
drivers/net/smc911x.h |5 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 61ecee7..ecda0b6
Op 30 jun 2008, om 13:50 heeft Felipe Balbi het volgende geschreven:
Use platform_data to pass musb configuration-specific
details to musb driver.
It's easier to maintain in the sense that neither board
will affect the other.
For now tested on n800 only, wanna hear from everybody what
guys
Op 30 jun 2008, om 19:49 heeft Felipe Balbi het volgende geschreven:
On Mon, Jun 30, 2008 at 07:29:28PM +0200, Koen Kooi wrote:
Op 30 jun 2008, om 13:50 heeft Felipe Balbi het volgende geschreven:
Use platform_data to pass musb configuration-specific
details to musb driver.
It's easier to
On Mon, Jun 30, 2008 at 07:56:36PM +0200, Koen Kooi wrote:
I was wondering what would happen if I would test the patch on
beagleboard, now I know :)
The patch won't probe. But if you just copy what's added in board-omap3430sdp.c
should work.
afaict, they have the same configuration for
On Monday 30 June 2008, Felipe Balbi wrote:
The patch won't probe. But if you just copy what's added in
board-omap3430sdp.c
should work.
Better: that controller data should be provided by SOC glue
in those cases (omap2430, omap 3*, DaVinci, etc). If it's
not board-specific, it doesn't
On Mon, Jun 30, 2008 at 11:33:15AM -0700, David Brownell wrote:
On Monday 30 June 2008, Felipe Balbi wrote:
The patch won't probe. But if you just copy what's added in
board-omap3430sdp.c
should work.
Better: that controller data should be provided by SOC glue
in those cases
2008/6/30 David Brownell [EMAIL PROTECTED]:
On Monday 30 June 2008, Felipe Balbi wrote:
The patch won't probe. But if you just copy what's added in
board-omap3430sdp.c
should work.
Better: that controller data should be provided by SOC glue
in those cases (omap2430, omap 3*, DaVinci,
25 matches
Mail list logo
