From: Teerth Reddy tee...@ti.com
The UART clocks should not be turned on in resume idle path. The UART clocks
should be turned on only when there is a uart wakeup event. This optimization
will help save power.
Signed-off-by: Raja Govindraj govindraj.r...@ti.com
Signed-off-by: Teerth Reddy
From: Teerth Reddy tee...@ti.com
Currently UART context save is done in idle thread thru a call
to omap_uart_prepare_idle irrespective of what power state is
attained by the power domain to which the UART belongs to. This
patch allows omap_uart_prepare_idle to take power state as a
parameter
From: Teerth Reddy tee...@ti.com
This patch has the changes which adds power state parameter
for the omap_uart_prepare_idle idle function.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/pm24xx.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
snip
As per my email 5/5/10, I would suggest the only change to omap_hsmmc is:
Agreed and followed the changes mostly but made some more changes on top of it.
snip
And that the late init function is used to do the rest e.g.
On Tue, Jun 29, 2010 at 1:00 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
snip
As per my email 5/5/10, I would suggest the only change to omap_hsmmc is:
Agreed and followed the changes mostly but made some more
kishore kadiyala wrote:
On Tue, Jun 29, 2010 at 1:00 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
snip
As per my email 5/5/10, I would suggest the only change to omap_hsmmc is:
Agreed and followed the changes mostly but
Changes from V3:
1, Tested on AM3517EVM and OMAP3530EVM.
Stanley.
--
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
AM3505/3517 doesn't have IO wakeup capability, so we do not need to set
the bit OMAP3430_EN_IO and the bit OMAP3430_EN_IO_CHAIN in the register
PM_WKEN_WKUP when the system enters suspend state.
Tested on AM3517EVM and OMAP3530EVM.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
On Tue, Jun 29, 2010 at 1:48 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
kishore kadiyala wrote:
On Tue, Jun 29, 2010 at 1:00 PM, Adrian Hunter adrian.hun...@nokia.com
wrote:
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
snip
As per my email 5/5/10, I would
Hello.
Hema HK wrote:
From: Hema HK hem...@ti.com
I think the patch description has clarity issues...
Changed the musb driver to use omap_build_device api instead of
I don't see where are you changing the MUSB driver.
platform_device_registration.
Why underscores here?
The
Hi all,
Here are some Kconfig improvments to produce a mostly sane .config for
omap2/3/4 without a defconfig. This assumes that CONFIG_ARCH_OMAP is
selected, for example with:
$ echo CONFIG_ARCH_OMAP=y .config yes | ARCH=arm make oldconfig
or
$ rm .config; ARCH=arm make xconfig, then select
Otherwise we have to disable it manually to avoid compile errors.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/video/console/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/console/Kconfig
Use 32KiHZ timer by default as this is available on all omaps
except 15xx based systems.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
This will make Kconfig look nicer for selecting omap processor type
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/Kconfig |7 +++
arch/arm/mach-omap2/Kconfig |7 +++
arch/arm/plat-omap/Kconfig |2 +-
3 files changed, 15 insertions(+), 1 deletions(-)
Move omap2/3/4 specific Kconfig options to mach-omap2/Kconfig
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig | 18 ++
arch/arm/plat-omap/Kconfig | 18 --
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git
Select all omaps and boards by default
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index
This produces a sane config that's suitable for using as the
base for most omap2/3/4 boards.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig
* Kalliguddi, Hema hem...@ti.com [100628 16:52]:
Yes. The comment is being removed in the patch I posted. I will keep it.
Thanks.
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
Hi all,
Here are some FS USB platform init changes to allow further improvment
of the code for muxing, register access and hwmod.
This set mostly moves the code around to split it between mach-omap1
and mach-omap2.
Regards,
Tony
---
Tony Lindgren (4):
omap: Separate out omap2 FS USB
We want to split old FS USB platform init code and stop doing pin multiplexing
under plat-omap. First move 24xx specific init code into omap2_usb[012]_init
functions.
Cc: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/usb.c |
Move omap2 FS USB platform init code into mach-omap2/usb-fs.c. This will
allow further work later on to use omap hwmod for initializing the
device.
Cc: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile|2
Looks like this code was only working on boards that had
the usb_l4_ick enabled in the bootloader.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-fs.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-fs.c
Move omap1 FS USB platform init code into mach-omap1/usb.c
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/Makefile |3
arch/arm/mach-omap1/board-ams-delta.c |2
arch/arm/mach-omap1/board-generic.c |4
arch/arm/mach-omap1/board-h2.c|2
On Tue, Jun 29, 2010 at 02:47:20PM +0300, Tony Lindgren wrote:
Otherwise we have to disable it manually to avoid compile errors.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
We'll need this for mach-cns3xxx too. And doing that change for
every ARM subarch is
Tomi,
Would you please check if there are no further comments and can you please pull
the following patches in?
https://patchwork.kernel.org/patch/106498/
https://patchwork.kernel.org/patch/106670/
https://patchwork.kernel.org/patch/107547/
Regards,
Rajkumar N.--
To unsubscribe from this
Hello,
-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
Sent: Tuesday, June 29, 2010 4:35 PM
To: Kalliguddi, Hema
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Felipe Balbi; t...@atomide.com
Subject: Re: [PATCH 4/4]usb : musb:USB driver using
On Tue, Jun 29, 2010 at 02:20:36PM +0200, ext Nagarajan, Rajkumar wrote:
Tomi,
Would you please check if there are no further comments and can you please
pull the following patches in?
https://patchwork.kernel.org/patch/106498/
This one seems to have two separate changes in the same
Hi,
I am observing that image built using omap3_pm_defconfig on Kevin's pm branch
does not seem to boot on OMAP3430 SDP board. It just stops after printing
Uncompressing Linux... done, booting the kernel. I am using console=ttyS0 as
part of my bootargs. Any hints?
Vishwa
--
To unsubscribe
This is my attempt to make SDIO interfaced TI WL1251 wifi chip usable
on mainline kernels. It's driver has already been merged several releases
back, but the problem is current SDIO core can't detect the card because
it's not following SDIO standards and does not have any required SDIO
registers.
There are some chips (like TI WL12xx series) that can be interfaced
over SDIO but don't support the SDIO specification, meaning that they
are missing CIA (Common I/O Area) with all it's registers. Current
Linux SDIO implementation relies on those registers to identify and
configure the card, so
This will allow us to set up special cards in machine drivers just
after they are detected by MMC core.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
arch/arm/plat-omap/include/plat/mmc.h |2 ++
drivers/mmc/host/omap_hsmmc.c | 10 ++
2 files changed, 12
Pandora has TI WL1251 attached on MMC3, which is non-standard SDIO chip.
Make use MMC_QUIRK_NONSTD_SDIO to tell SDIO core about it.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
arch/arm/mach-omap2/board-omap3pandora.c | 16
arch/arm/mach-omap2/hsmmc.c |
Tony,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Tuesday, June 29, 2010 5:18 PM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 6/6] omap2/3/4: Add
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Thursday, June 24, 2010 4:21 PM
To: Nagarajan, Rajkumar
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP: DSS: Fix for dsi_pll to dpll4 clk switch
On Thu, 2010-06-17 at 07:12 +0200, ext
Here is the log from Early printk.
Bytes transferred = 2094808 (1ff6d8 hex)
## Booting image at 8030 ...
Image Name: Linux-2.6.35-rc3-10791-g305f453
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:2094744 Bytes = 2 MB
Load Address: 80008000
Entry Point:
* Jamie Lokier ja...@shareable.org [100623 16:30]:
Tony Lindgren wrote:
* Jamie Lokier ja...@shareable.org [100622 19:54]:
Tony Lindgren wrote:
__kuser_get_tls: @ 0x0fe0
-
-#if !defined(CONFIG_HAS_TLS_REG) !defined(CONFIG_TLS_REG_EMUL)
-
* Anton Vorontsov cbouatmai...@gmail.com [100629 15:04]:
On Tue, Jun 29, 2010 at 02:47:20PM +0300, Tony Lindgren wrote:
Otherwise we have to disable it manually to avoid compile errors.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
We'll need this for
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
Sent: Tuesday, June 29, 2010 7:23 PM
To: Tony Lindgren; linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH 6/6]
Reddy, Teerth tee...@ti.com writes:
From: Teerth Reddy tee...@ti.com
The UART clocks should not be turned on in resume idle path. The UART clocks
should be turned on only when there is a uart wakeup event.
No, UART clocks should be on whenever someone is accessing the UART.
Besides
Stanley.Miao stanley.m...@windriver.com writes:
AM3505/3517 doesn't have IO wakeup capability, so we do not need to set
the bit OMAP3430_EN_IO and the bit OMAP3430_EN_IO_CHAIN in the register
PM_WKEN_WKUP when the system enters suspend state.
Tested on AM3517EVM and OMAP3530EVM.
Reddy, Teerth tee...@ti.com writes:
From: Teerth Reddy tee...@ti.com
This patch has the changes which adds power state parameter
for the omap_uart_prepare_idle idle function.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/pm24xx.c |6 +++---
1 files changed, 3
Hi Vishwa,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
Sent: Tuesday, June 29, 2010 9:15 AM
To: linux-omap@vger.kernel.org
Subject: RE: Boot fail on OMAP3430SDP
Here is the log from Early
Aguirre, Sergio wrote:
Sripathy, Vishwanath wrote:
Here is the log from Early printk.
snip
Could not get gpios_ick
Could not get gpios_fck
Probably Tony will be the best to answer this, but... This
code shouldn't get executed I think (the one producing above prints)..
Above
Kevin Hilman khil...@deeprootsystems.com writes:
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.
So that these primary devices are available for
On Tue, 29 Jun 2010, Tony Lindgren wrote:
OK. Sorry for the delay again. Here's an updated version that sets
__kuser_get_tls instruction dynamically. Does this do what you were
thinking, or did I miss something?
See my comments below.
Also, can we detect somehow the hardware that uses
Hello,
Thanks for all your comments and feedback. I've updated the patch with changes
based on the feedback I've received:
- Switched to using hwmod. I enabled the hwmod entry for spinlock in
omap_hwmod_44xx_data.
- Removed reserved/unreserved distinction. Removed CONFIG option for number
The only difference between them is the physical address of the
uart4 port, which is only present in 36xx chips.
We don't really need to care about keeping these 2 functions, since
the decision to use uart4 is more cleanly done later when we do have
access to omap_revision variable.
Following commit missed to remove this:
commit 044d32ffbcb4a1d400088e3575508f46c0a9face
Author: Koen Kooi koen.k...@gmail.com
Date: Thu Apr 22 10:23:42 2010 +0200
board-omap3-beagle: add DSS2 support
Signed-off-by: Sergio Aguirre saagui...@ti.com
Cc: Koen Kooi koen.k...@gmail.com
Hi Simon,
From: Que, Simon
Sent: Tuesday, June 29, 2010 2:28 PM
To: linux-omap@vger.kernel.org; Kevin Hilman; Cousson, Benoit;
Hello,
Thanks for all your comments and feedback. I've updated the
patch with changes based on the feedback I've received:
- Switched to using hwmod. I enabled the
From: Que, Simon
Sent: Tuesday, June 29, 2010 2:28 PM
[snip]
+
+/* Spinlock count code */
+#define SPINLOCK_32_REGS 1
+#define SPINLOCK_64_REGS 2
+#define SPINLOCK_128_REGS 4
+#define SPINLOCK_256_REGS 8
+#define SPINLOCK_NUMLOCKS_OFFSET 24
Kevin Hilman khil...@deeprootsystems.com writes:
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
something doesn't make sense in this patch...
On Wed, 23 Jun 2010, Kevin Hilman wrote:
If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since
Sergio Aguirre saagui...@ti.com writes:
The only difference between them is the physical address of the
uart4 port, which is only present in 36xx chips.
We don't really need to care about keeping these 2 functions, since
the decision to use uart4 is more cleanly done later when we do have
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Tuesday, June 29, 2010 11:00 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com
Subject: Re: [PATCH v2 10/13] OMAP: create omap_devices for MPU, DSP, L3
Sergio Aguirre wrote:
The only difference between them is the physical address of the
uart4 port, which is only present in 36xx chips.
We don't really need to care about keeping these 2 functions, since
the decision to use uart4 is more cleanly done later when we do have
access to omap_revision
This patch contains the documentation for the API, termed the Virtual
Contiguous Memory Manager. Its use would allow all of the IOMMU to VM,
VM to device and device to IOMMU interoperation code to be refactored
into platform independent code.
Comments, suggestions and criticisms are welcome and
The Virtual Contiguous Memory Manager (VCMM) needs a physical pool to
allocate from. It breaks up the pool into sub-pools of same-sized
chunks. In particular, it breaks the pool it manages into sub-pools of
1 MB, 64 KB and 4 KB chunks.
When a user makes a request, this allocator satisfies that
56 matches
Mail list logo
