On Fri, 3 Dec 2010, Tony Lindgren wrote:
> Hi all,
>
> I've got some patches almost ready to go to merge the omap1
> configs into a single omap1_defconfig. While working on getting
> that done, I had to come up with a better solution for entry-armv.S
> macros to detect the soc we're running on.
>
Prepare OMAP2+ DMA to use hwmod infrastructure so that DMA can register
as platform device.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/dma.c | 74 +
1 files changed, 74 in
Implement OMAP1 DMA as platform device and add support for
registering through platform device layer using resource
structures.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap1/dma.c | 179 +
From: Benoit Cousson
Add OMAP4 DMA hwmod data
Signed-off-by: Benoit Cousson
Signed-off-by: G, Manjunath Kondaiah
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 101
1 files changed, 101 insertions(+), 0 deletions(-)
dif
Add OMAP3 DMA hwmod data
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 97
1 files changed, 97 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_
Add OMAP2430 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 87
arch/arm/plat-omap/include/plat/dma.h
Add OMAP2420 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 87
arch/arm/plat-omap/include/plat/dma.h
Prepare DMA library to get converted into DMA driver using platform
device model and hwmod infrastucture(for omap2+, resource structures
for omap1)
The low level read/write macros are replaced with static inline
functions and register offsets are handled through static register
offset tables mappe
Implement errata handling to use flags instead of cpu_is_* and
cpu_class_* in the code.
The errata flags are initialized at init time and during runtime we are
using the errata variable (via the IS_DMA_ERRATA macro) to execute the
required errata workaround.
Reused errata handling patch from: Pet
Patch series to convert DMA library into platform driver using platform
device model and adapting hwmod for omap2+.
The original patch series :
http://comments.gmane.org/gmane.linux.ports.arm.omap/46953
has been split into two patch series based on suggestion from Tony.
(https://patchwork.kernel.o
On Sat, Dec 4, 2010 at 2:29 AM, David Daney wrote:
> Does anything other than OMAP4 have one of these things?
I'm not aware of any, but David Brownell had some ideas about it in
our previous v2 discussion (see
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39413.html).
Btw, you might
Salut Jean
On Thu, 2 Dec 2010, Jean Pihet wrote:
> On Thu, Dec 2, 2010 at 8:23 AM, Paul Walmsley wrote:
> > On Thu, 25 Nov 2010, Jean Pihet wrote:
> >> On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley wrote:
> >> > On Thu, 25 Nov 2010, Jean Pihet wrote:
> >> >> On Thu, Nov 25, 2010 at 12:49 AM, P
On 12/03/2010 03:50 PM, Ohad Ben-Cohen wrote:
OMAP4 introduces a Hardware Spinlock device, which provides hardware
assistance for synchronization and mutual exclusion between heterogeneous
processors and those not operating under a single, shared operating system
(e.g. OMAP4 has dual Cortex-A9, d
This saves some cycles for multiple interrupts case.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap1/include/mach/entry-macro.S |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/include/mach/entry-macro.S
b/arch/arm/mach-omap1/include/mach/entry-
This way we can use the SoC specific code to detect what we're
running on.
Signed-off-by: Tony Lindgren
---
arch/arm/include/asm/irq.h |2 ++
arch/arm/kernel/entry-armv.S | 13 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/irq.h b/arch
This way we can use the generic omap SoC detection code instead.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/include/mach/entry-macro.S | 37 +++-
arch/arm/mach-omap2/io.c | 20 +
2 files changed, 25 insertions(+), 32 deletions(-
Initialize asm_irq_flags in omap_init_irq and use it in
get_irqnr_and_base to detect between omap7xx and omap15xx/16xx.
Note that both INT_1510_IH2_IRQ and INT_1510_IH2_IRQ are defined
as 0, so use INT_1510_IH2_IRQ for both of them.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap1/include/m
Hi all,
I've got some patches almost ready to go to merge the omap1
configs into a single omap1_defconfig. While working on getting
that done, I had to come up with a better solution for entry-armv.S
macros to detect the soc we're running on.
I suggest we add asm_irq_base and asm_irq_flags as in
Pedanekar, Hemant wrote on Wednesday, December 01, 2010 7:17 AM:
> Tony Lindgren wrote on Tuesday, November 30, 2010 12:59 AM:
>
>> * Pedanekar, Hemant [101129 09:07]:
>>> Tony Lindgren wrote on Saturday, November 06, 2010 2:30 AM:
>>>
>>> Though based on Cortex A8, TI816X series has difference
From: Simon Que
Build and register an hwspinlock platform device.
Although only OMAP4 supports the hardware spinlock module (for now),
it is still safe to run this initcall on all omaps, because hwmod lookup
will simply fail on hwspinlock-less platforms.
Signed-off-by: Simon Que
Signed-off-by:
Hi Rick
On Fri, 3 Dec 2010, Rick Bronson wrote:
> > This may be a stupid question, but are you using serial flow control? If
> > not, enabling wakeup on the RTS line isn't going to help.
>
> Not a stupid question at all. We are very pin constrained so we
> only have RX and TX, so no modem li
Add a platform-independent hwspinlock framework.
Hardware spinlock devices are needed, e.g., in order to access data
that is shared between remote processors, that otherwise have no
alternative mechanism to accomplish synchronization and mutual exclusion
operations.
Signed-off-by: Ohad Ben-Cohen
From: Benoit Cousson
Add hwspinlock hwmod data for OMAP4 chip
Signed-off-by: Cousson, Benoit
Signed-off-by: Hari Kanigeri
Signed-off-by: Ohad Ben-Cohen
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 64
1 files changed, 64 insertions(+), 0
From: Simon Que
Add hwspinlock support for the OMAP4 Hardware Spinlock device.
The Hardware Spinlock device on OMAP4 provides hardware assistance
for synchronization between the multiple processors in the system
(dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP).
[o...@wizery.com: adapt to hwspin
OMAP4 introduces a Hardware Spinlock device, which provides hardware
assistance for synchronization and mutual exclusion between heterogeneous
processors and those not operating under a single, shared operating system
(e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP).
The intention o
* G, Manjunath Kondaiah [101203 08:32]:
>
> I have done required changes to patch series and tested the same on
> omap2+ boards. Can you pls test OSK5912 board boot from the below
> git repo? If OSK5912 boots up(with LCD), I will post the 1st series to
> LO ML.
Yeah seems to boot OK now with tux
Hello List,
I am working with my Texas Instruments DM3730 EVM board running its default
Linux kernel 2.6.32 and default Linux distro Arago 2010.05. The cpu info is:
Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS: 998.84
Features: swp half thumb fastmult vfp edsp neon vfpv
Hi Paul,
Thanks again for all of the help.
> It's described in the 34xx TRM sections 4.11.2 "Device Off-Mode
> Configuration" and 4.11.3 "CORE Power Domain Off-Mode Sequences". All the
> references to off-mode just confuse things, since AFAIK, this wakeup
> mechanism also applies to the device
Hello.
Ajay Kumar Gupta wrote:
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
Signed-off-by: Ajay Kumar Gupta
[...]
diff --git a/arch/arm/mach-omap2/usb-
Patch "OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430"
in linux-next as of 20101203 introduced the following build
warning - fix this by removing the stray i2c_dev_attr.
arch/arm/mach-omap2/omap_hwmod_2430_data.c:483: warning: 'i2c_dev_attr' defined
but not used
Signed-o
Ajay Kumar Gupta wrote:
> As the control.h have been moved to new location and it's
> uses are not allowed to drivers directly so moving the phy
> control, interrupt clear and reset functionality to board
> files.
>
> Signed-off-by: Ajay Kumar Gupta
> ---
> Patch created against today's linus tree
Having CONFIG_SWP_EMULATE causes the build of omap2plus_defconfig
to fail as below:
CC arch/arm/kernel/swp_emulate.o
/tmp/ccCx8SX8.s: Assembler messages:
/tmp/ccCx8SX8.s:339: Error: selected processor does not support ARM mode
`ldrexb r7,[r6]'
/tmp/ccCx8SX8.s:340: Error: selected processor
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
Signed-off-by: Ajay Kumar Gupta
---
Patch created against today's linus tree.
arch/arm/mach-omap2/board-am3517evm
Commit f2ce62312650 (OMAP: WDT: Split OMAP1 and OMAP2PLUS device
registration) removed omap_init_wdt and related structures from
plat-omap/devices.c. However a subsequent commit or merge
seems to have reintroduced these by accident. The caller of
omap_init_wdt was also removed by that commit, and t
Hi,
as discussed in [1], here is step 2 - idle path errata fixes.
this is the next rev incorporating comments from V2 post
of this series.
V2: http://marc.info/?l=linux-omap&m=129106200408109&w=2
Major change in V3:
Erratas are now handled per silicon - it is much cleaner :)
no mo
From: Peter 'p2' De Schrijver
Erratum i581 impacts OMAP3 platforms.
PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing
the DPLL not to be locked at times.
IMPORTANT:
*) This is not a complete workaround implementation as recommended
by the silicon erratum. this is a support lo
Erratum id: i608
RTA (Retention Till Access) feature is not supported and leads to device
stability issues when enabled. This impacts modules with embedded memories
on OMAP3630
Workaround is to disable RTA on boot and coming out of core off.
For disabling rta coming out of off mode, we do this by
From: Eduardo Valentin
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 < ES1.2 is impacted as follows depending on the platform:
CS0: for 38.4M
From: Peter 'p2' De Schrijver
This disables L2 cache before invalidating it and reenables it afterwards.
This is be done according to ARM documentation. Currently this is identified
as being needed on OMAP3630 as the disable/enable is done from "public side"
while, on OMAP3430, this is done in th
From: Richard Woodruff
Analysis in TI kernel with ETM showed that using cache mapped flush
in kernel instead of SO mapped flush cost drops by 65% (3.39mS down
to 1.17mS) for clean_l2 which is used during sleep sequences.
Overall:
- speed up
- unfortunately there isn't a good alter
* David Woodhouse [101203 08:29]:
> On Fri, 2010-12-03 at 18:22 +0200, Artem Bityutskiy wrote:
> > On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote:
> > > * Sukumar Ghorai [101119 06:36]:
> > > > CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for
> > > > 2.6.36.
> > > > This
Hi Tony,
* Tony Lindgren [2010-12-02 12:52:19 -0800]:
> * G, Manjunath Kondaiah [101202 11:55]:
> >
> > >
> > > Note that even with these three fixes, 5912OSK still fails to
> > > boot to init. Maybe something wrong with the framebuffer DMA?
> >
> > Not sure. I don't have omap1 board for tes
On Fri, 2010-12-03 at 18:22 +0200, Artem Bityutskiy wrote:
> On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote:
> > * Sukumar Ghorai [101119 06:36]:
> > > CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36.
> > > This flag enables hw ecc by default. Boards like beagle an
On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote:
> * Sukumar Ghorai [101119 06:36]:
> > CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36.
> > This flag enables hw ecc by default. Boards like beagle and pandora uses
> > sw ecc for write (e.g. binary flushed from u-boo
On Fri, Dec 03, 2010 at 02:50:58PM +0100, Laurent Pinchart wrote:
> On Friday 03 December 2010 13:06:18 Hans Verkuil wrote:
> > > Just to confirm thinks, Mark's proposal is to replace 'connected' by
> > > 'linked' and 'active' by 'connected'. Are we on the same page here ?
> > Yes, but when I rea
Hi Hans,
Adding by the original CC list which was dropped by mistake.
On Friday 03 December 2010 13:06:18 Hans Verkuil wrote:
> On Friday, December 03, 2010 11:19:36 Laurent Pinchart wrote:
> > On Sunday 28 November 2010 16:57:00 you wrote:
> > > On Sunday, November 28, 2010 13:34:45 Laurent Pinc
> >We already have generic APIs so I think we can pass function pointers to
> >musb driver via "struct omap_musb_board_data",
> >
> > struct omap_musb_board_data {
> >+void(*phy_on) (void)
> >+void(*phy_off) (void)
> >+void (*intr_clr) (void)
> > }
> >
> >Reset part can be done
On Fri, Dec 3, 2010 at 3:07 PM, Russell King - ARM Linux
wrote:
> On Fri, Dec 03, 2010 at 02:10:23PM +0200, Felipe Contreras wrote:
>> On Fri, Dec 3, 2010 at 10:41 AM, Russell King - ARM Linux
>> wrote:
>> > On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
>> >> This has been fixed sin
On Fri, Dec 03, 2010 at 02:10:23PM +0200, Felipe Contreras wrote:
> On Fri, Dec 3, 2010 at 10:41 AM, Russell King - ARM Linux
> wrote:
> > On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
> >> This has been fixed since -rc2.
> >
> > So it is. However, the ioremap fix is wrong.
> >
> >
On Thu, Dec 02, 2010 at 02:27:36PM -0800, Tony Lindgren wrote:
Hi,
* Felipe Balbi [101202 03:38]:
Hi Tony,
I have a gigantic amount of patches on musb starting to move it to a
place where we can build am35x.c, omap2430.c and tusb6010.c together and
have a working binary.
There are a few chan
On Thu, Dec 02, 2010 at 04:13:50PM +0530, Gupta, Ajay Kumar wrote:
>> why don't you add a proper otg_transceiver driver for am35x ?
>> Is it like omap4's internal phy ? A separate block ?
>
>AM35x PHY is built inside the ip and we need to configure it through
>PHY control register.
>
>Additionall
On 12/3/2010 10:47 AM, G, Manjunath Kondaiah wrote:
* Cousson, Benoit [2010-12-03 09:38:35 +0100]:
[...]
v7: replaced mutex lock with spin lock. Added use count for controlling
access to sysconfig registers in case if overlapping request/release API's
are used.
I'm not sure it should be do
On Fri, Dec 3, 2010 at 10:41 AM, Russell King - ARM Linux
wrote:
> On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
>> This has been fixed since -rc2.
>
> So it is. However, the ioremap fix is wrong.
>
> } else {
> paddr = memblock_alloc(size, PAGE_SIZE);
>
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_mem_onst
.pwrdm_set_mem_retst
.pwrdm_read_mem_pwrst
.pwrdm_read_prev_mem_pwrst
.pwrdm_read_mem_retst
.pwrdm_clear_all_prev_pwrst
.pwrdm_enable_hdwr_sar
.pwrdm_disable_hdwr_sar
.pwrdm_wait_transition
.pwrdm_set_lowpwrstchan
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_next_pwrst
.pwrdm_read_next_pwrst
.pwrdm_read_pwrst
.pwrdm_read_prev_pwrst
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak
Cc: Paul Walmsley
Cc: Benoit Cousson
Cc: Kev
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_logic_retst
.pwrdm_read_logic_pwrst
.pwrdm_read_prev_logic_pwrst
.pwrdm_read_logic_retst
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak
Cc: Paul Walmsley
Cc: Benoit Co
Put infrastructure in place, so arch specific func pointers
can be hooked up to the platform-independent part of the
framework.
This is in preparation of splitting the powerdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
Signed-off-by: Rajendra Nayak
C
From: Rajendra Nayak
powerdomains.h header today has only static definitions.
Adding any function declarations into
it and including it in multiple source file is
expected to cause issues.
Hence move all the static definitions from powerdomains.h
file into powerdomains_data.c file.
Signed-off-by
OMAP4 powerdomains have some inherent differences as compared
to OMAP2/3 powerdomains, starting with register offsets being different
to clubbing of multiple controls into one register and in some cases
splitting of control into multiple registers.
There are also new features like lowpowerstatechan
From: Santosh Shilimkar
OMAP4430 ES2 has additional bitfields in PWRSTST register which help
identify the previous power state entered by the powerdomain.
Add pwrdm_clear_all_prev_pwrst api to support this.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Rajendra Nayak
Cc: Paul Walmsley
Cc: B
> -Original Message-
> From: Govindraj [mailto:govindraj...@gmail.com]
> Sent: Friday, December 03, 2010 4:51 PM
> To: Santosh Shilimkar
> Cc: Paul Walmsley; linux-omap@vger.kernel.org;
khil...@deeprootsystems.com
> Subject: Re: Unbalanced IRQ wake disable during resume from static
suspend
On Fri, Dec 3, 2010 at 4:38 PM, Santosh Shilimkar
wrote:
>> -Original Message-
>> From: Paul Walmsley [mailto:p...@pwsan.com]
>> Sent: Friday, December 03, 2010 3:53 PM
>> To: Santosh Shilimkar
>> Cc: linux-omap@vger.kernel.org; Govindraj; khil...@deeprootsystems.com
>> Subject: RE: Unbala
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Friday, December 03, 2010 3:53 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Govindraj; khil...@deeprootsystems.com
> Subject: RE: Unbalanced IRQ wake disable during resume from static
suspend
>
> Hell
By the way, if you're using a really recent kernel, you may want to see if
sending a few breaks down the line wakes it up:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39735.html
Based on your problem description, I doubt this will help, but it's worth
a try.
- Paul
--
To unsu
Hi Rick
On Thu, 2 Dec 2010, Rick Bronson wrote:
> > If the OMAP is in full-chip retention, the UART's asynchronous wakeup
> > mechanism won't work, which appears to be what you're trying to use.
> > That will only work when PER is fully powered, as far as I know. You'll
> > need to use the IO ch
Hello Santosh
On Thu, 2 Dec 2010, Santosh Shilimkar wrote:
> Just a wild guess here but is this because the 'set_wake' is
> not setup and then fw might be returning some error whenever
> driver invoke this API as part of enable_irq_wake() callback
>
> If that being the case, below patch might mi
Hi Kevin
On Thu, 2 Dec 2010, Kevin Hilman wrote:
> I guess this hasn't been seen before since we haven't tested the sysfs
> wakeup interface for the omap-serial driver. For on-chip OMAP UARTs,
> using the sysfs interface isn't needed as the serial core is already
> doing device_init_wakeup(dev,
* Cousson, Benoit [2010-12-03 09:38:35 +0100]:
> On 12/2/2010 2:59 PM, G, Manjunath Kondaiah wrote:
> >Certain errata in OMAP2+ processors will require forcing
> >master standby to "no standby" mode before completing on going
> >operation. Without this, the results will be unpredictable.
> >
> >S
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Thursday, December 02, 2010 7:03 PM
>>To: Gopinath, Thara
>>Cc: linux-omap@vger.kernel.org
>>Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init.
>>
>>Thara Gopinath writes:
>>
>>> o
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Friday, December 03, 2010 2:11 PM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; Benoit
Cousson
> Subject: RE: [PATCH v2 0/5] Split powerdomain framework into plat
specific/indepe
On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
> On Thu, Dec 02, 2010 at 02:32:08PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [101202 14:06]:
> > > On Thu, Dec 02, 2010 at 01:58:38PM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux [101202 13:04]:
> > >
Hi Rajendra,
On Thu, 2 Dec 2010, Rajendra Nayak wrote:
> This seems to be popping up with powerdomains.h file (which now
> has func declarations) being included in multiple source files. It earlier
> had only static structs and was included in one source file.
>
> I thought the right way to fix
On 12/2/2010 2:59 PM, G, Manjunath Kondaiah wrote:
Certain errata in OMAP2+ processors will require forcing
master standby to "no standby" mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not su
Hello Ben, Samu,
On Fri, 3 Dec 2010, samu.p.onk...@nokia.com wrote:
> >-Original Message-
> >From: ext Ben Dooks [mailto:ben-...@fluff.org]
> >Sent: 03 December, 2010 04:38
> >To: Onkalo Samu.P (Nokia-MS/Tampere)
> >Cc: ben-li...@fluff.org; linux-...@vger.kernel.org;
> >khil...@deeprootsy
74 matches
Mail list logo
