> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Wednesday, June 30, 2010 11:47 AM
> To: Shilimkar, Santosh
> Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
> Subject: Re: [PATCH 6/6] omap2/3/4: Add Kconfig option to compile in
> typical oma
Op 29 jun 2010, om 22:32 heeft Sergio Aguirre het volgende geschreven:
> Following commit missed to remove this:
>
> commit 044d32ffbcb4a1d400088e3575508f46c0a9face
> Author: Koen Kooi
> Date: Thu Apr 22 10:23:42 2010 +0200
>
> board-omap3-beagle: add DSS2 support
>
> Signed-off-by:
* Mike Rapoport [100630 08:20]:
> 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 don
* Tony Lindgren [100629 17:15]:
> * Anton Vorontsov [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
> >
> >
* Shilimkar, Santosh [100629 17:40]:
> > >
> > With your series OMAP4 build breaks because of PM and SMP dependencies.
> > To ensure that build doesn't break on OMAP4, I needed below change. With
> > This change I tried your series and it boots OK on OMAP4430 SDP
Hmm the build does not break for
* Gadiyar, Anand [100629 19:07]:
> Aguirre, Sergio wrote:
> > Sripathy, Vishwanath wrote:
> > > Here is the log from Early printk.
> > >
> >
> >
> >
> > > Could not get gpios_ick
> > > Could not get gpios_fck
> >
> > Probably Tony will be the best to answer this, but... This
> > code shouldn
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 req
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 wa
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
>>-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 fo
Sergio Aguirre 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
> access to om
Kevin Hilman writes:
> Paul Walmsley 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 omap_hwmod_idle() requires th
>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
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 enab
Following commit missed to remove this:
commit 044d32ffbcb4a1d400088e3575508f46c0a9face
Author: Koen Kooi
Date: Thu Apr 22 10:23:42 2010 +0200
board-omap3-beagle: add DSS2 support
Signed-off-by: Sergio Aguirre
Cc: Koen Kooi
---
arch/arm/mach-omap2/board-omap3beagle.c |7 ++-
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.
Signed-off-by
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 of
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 CO
Kevin Hilman 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 early PM initialization,
Aguirre, Sergio wrote:
> Sripathy, Vishwanath wrote:
> > Here is the log from Early printk.
> >
>
>
>
> > 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)..
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
"Reddy, Teerth" writes:
> From: Teerth Reddy
>
> 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 s
"Reddy, Teerth" writes:
> From: Teerth Reddy
>
> This patch has the changes which adds power state parameter
> for the omap_uart_prepare_idle idle function.
>
> Signed-off-by: Teerth Reddy
> ---
> arch/arm/mach-omap2/pm24xx.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
S
"Stanley.Miao" 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.
>
> Signed-off-by: Stanley.Miao
"Reddy, Teerth" writes:
> From: Teerth Reddy
>
> 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 wakeups, applications can op
> -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
* Anton Vorontsov [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
>
> We'll need this for mach-cns3xxx too. And doing t
* Jamie Lokier [100623 16:30]:
> Tony Lindgren wrote:
> > * Jamie Lokier [100622 19:54]:
> > > Tony Lindgren wrote:
> > > > __kuser_get_tls: @ 0x0fe0
> > > > -
> > > > -#if !defined(CONFIG_HAS_TLS_REG) && !defined(CONFIG_TLS_REG_EMUL)
> > > > - ldr r0,
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: 800
> -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,
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: Ad
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
---
arch/arm/mach-omap2/board-omap3pandora.c | 16
arch/arm/mach-omap2/hsmmc.c |1 +
arch/arm/m
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
---
arch/arm/plat-omap/include/plat/mmc.h |2 ++
drivers/mmc/host/omap_hsmmc.c | 10 ++
2 files changed, 12 insertions(+), 0 deletions(-)
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 non
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. C
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 fr
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 sa
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
>
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 list:
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
We'll need this for mach-cns3xxx too. And doing that change for
every ARM subarch is going to prod
Move omap1 FS USB platform init code into mach-omap1/usb.c
Signed-off-by: Tony Lindgren
---
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
arch/arm/mach-om
Looks like this code was only working on boards that had
the usb_l4_ick enabled in the bootloader.
Signed-off-by: Tony Lindgren
---
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 b/arch/arm/mach-omap2/
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
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile|2
arch/arm/mach-omap2/board-2430sdp.c |2
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
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/usb.c | 252 +---
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 pla
* Kalliguddi, Hema [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 http://vger.kernel.o
This produces a sane config that's suitable for using as the
base for most omap2/3/4 boards.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Kconfig | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap
Select all omaps and boards by default
Signed-off-by: Tony Lindgren
---
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 d306aa1..4802988 100644
--- a/a
Move omap2/3/4 specific Kconfig options to mach-omap2/Kconfig
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Kconfig | 18 ++
arch/arm/plat-omap/Kconfig | 18 --
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfi
This will make Kconfig look nicer for selecting omap processor type
Signed-off-by: Tony Lindgren
---
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(-)
diff --git a/arch
Use 32KiHZ timer by default as this is available on all omaps
except 15xx based systems.
Signed-off-by: Tony Lindgren
---
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
index 78b49a6..3e
Otherwise we have to disable it manually to avoid compile errors.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Tony Lindgren
---
drivers/video/console/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
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
Hello.
Hema HK wrote:
From: Hema HK
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 device specif
On Tue, Jun 29, 2010 at 1:48 PM, Adrian Hunter wrote:
> kishore kadiyala wrote:
>>
>> On Tue, Jun 29, 2010 at 1:00 PM, Adrian Hunter
>> wrote:
>>>
>>> ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
>
> As per my email 5/5/10, I would sugges
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
---
arch/arm/mach-omap2/id.c
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
kishore kadiyala wrote:
On Tue, Jun 29, 2010 at 1:00 PM, Adrian Hunter wrote:
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
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 to
On Tue, Jun 29, 2010 at 1:00 PM, Adrian Hunter wrote:
> ext kishore kadiyala wrote:
>>
>> Adrian ,
>>
>> Sorry for the late response
>>
>>
>>>
>>> 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
ext kishore kadiyala wrote:
Adrian ,
Sorry for the late response
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.
And that the late init function is used to do the rest e.g.
find a h
60 matches
Mail list logo
