Tony,
Remove nand flash support
Remove legacy board support
Fix indent problem
Nand support would be added after omap3 nand problem was fixed.
From ad9cad8d67ea94b0db4b15da369741687f7280e5 Mon Sep 17 00:00:00 2001
From: Jason Lam l...@ema-tech.com
Date: Sun, 16
On Fri, 2010-05-14 at 21:09 +0200, ext Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@nokia.com [100512 01:54]:
Hi,
On Mon, 2010-05-10 at 22:20 +0200, ext Tony Lindgren wrote:
* Stephen Rothwell s...@canb.auug.org.au [100506 22:05]:
Hi Tomi,
Today's linux-next merge
si...@santesteban.eu wrote:
si...@santesteban.eu wrote:
Hi I am using a v4l2 usb video capturer (em28xx based), and it is
working
fine for around 5 minutes. However, it stops capturing after this
time.
There is no error message sent to kmsg ot the application, which
apparently waits
On Fri, May 14, 2010 at 1:16 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
because it also uses reserve_bootmem() in
drivers/video/omap2/vram.c and later ioremap on RAM. Perhaps LMB can
be used to fix that too?
WTF is reserve_bootmem doing in a driver?
IIRC Tony refused any new
On Mon, May 17, 2010 at 12:38:55PM +0300, Grazvydas Ignotas wrote:
On Fri, May 14, 2010 at 1:16 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
because it also uses reserve_bootmem() in
drivers/video/omap2/vram.c and later ioremap on RAM. Perhaps LMB can
be used to fix that too?
From: Felipe Balbi felipe.ba...@nokia.com
Few architectures, like OMAP, allow you to set
a debouncing time for the gpio before generating
the IRQ. Teach gpiolib about that.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/gpio/gpiolib.c | 43
From: Felipe Balbi felipe.ba...@nokia.com
OMAP support debouncing of gpio lines, implement
the method using gpiolib.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/plat-omap/gpio.c | 68 +
1 files changed, 68 insertions(+), 0
From: Felipe Balbi felipe.ba...@nokia.com
nobody uses that anymore, so remove and expect drivers
to use the gpiolib implementation.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/plat-omap/gpio.c | 73 -
1 files changed, 0
From: Felipe Balbi felipe.ba...@nokia.com
Hi all,
I'm resending this series since no-one has had any further
comments for quite some time.
Adding Andrew Morton to the loop also since David Brownell
didn't pick the patch neither comment to any version of it.
Felipe Balbi (5):
gpiolib:
From: Felipe Balbi felipe.ba...@nokia.com
move everything to a common location. No functional
changes.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/plat-omap/gpio.c | 143
arch/arm/plat-omap/include/plat/gpio.h | 143
From: Felipe Balbi felipe.ba...@nokia.com
stop using the omap-specific implementations for gpio
debouncing now that gpiolib provides its own support.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/board-3430sdp.c|4 +---
arch/arm/mach-omap2/board-ldp.c
On Mon, May 17, 2010 at 12:02:34PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
From: Felipe Balbi felipe.ba...@nokia.com
move everything to a common location. No functional
changes.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
sorry, this patch shouldn't be here... it was a broken
Hi,
On Mon, 2010-05-17 at 11:44 +0200, ext Russell King - ARM Linux wrote:
On Mon, May 17, 2010 at 12:38:55PM +0300, Grazvydas Ignotas wrote:
On Fri, May 14, 2010 at 1:16 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
because it also uses reserve_bootmem() in
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against linus'tree + all musb patches in Greg's queue
Changes from v2:
- fixed multipline comment style
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine.
It supports upto 500mA of power in host mode.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against linus'tree + all musb patches in Greg's queue
and patches available in linux-omap/for-next branch.
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode and there are on-going
discussions on location of CPPI4.1 DMA.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against linus'tree + all musb patches in Greg's queue
Changes from v2:
Hi,
Hi Peter,
The RES_TYPE field is same for all messages.
The resource which can go to low-power mode with clk_req sig de-asserting is
configured as RES_TYPE2 = '2'. And the resource which can go to low-power
mode with sys_off sig de-asserting is configured as RES_TYPE2 = '1'.
The
Use optimal values of transfer element based on buffer address in system
DMA programming. This would improve the performance.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musbhsdma.c | 29 ++---
1 files changed, 26 insertions(+), 3 deletions(-)
Current gadget Tx path always programs DMA in mode-1 if request length
is more than packet size. As system DMA can work only in mode-0 so
updating the DMA mode and transfer length for it.
Also fixed an issue in device Tx completion path where 'is_dma' is
getting set unconditionally. This would
OTG base physical address is required in calculating physical address
of endpoint FIFO which is needed by system dma.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against linus'tree + all musb patches in Greg's queue
drivers/usb/musb/musb_core.c |6 --
Added is_inventra_dma_enabled() funtion which would be required
for adding workaround for Inventra DMA issues. It can also be
used at other places instead of #ifdefs.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_dma.h |6 ++
1 files changed, 6
MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are
simultaneously enabled which results in DMA lockup.
Use system DMA for all RX channels as a workaround of this issue as this
will have minimal throughput overhead based on the fact that Rx transfers
are done in DMA mode-0
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA for unaligned buffers as a workaround of this issue.
Current patch set supports
If we are not able to register then it is better to have watchdog in disabled
state than noticing a system reboot.
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/watchdog/twl4030_wdt.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
On Mon, May 17, 2010 at 9:52 AM, Ghorai, Sukumar s-gho...@ti.com wrote:
[...]
@@ -108,11 +108,27 @@ static u32 gpmc_read_reg(int idx)
return __raw_readl(gpmc_base + idx);
}
+static void gpmc_cs_write_byte(int cs, int idx, u8 val)
+{
+ void __iomem *reg_addr;
+
+
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: 2010-05-17 19:57
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; artem.bityuts...@nokia.com;
t...@atomide.com; sako...@gmail.com; linux-...@lists.infradead.org
Subject: Re: [PATCH v2 1/2] omap3 nand:
Alan Stern st...@rowland.harvard.edu writes:
On Fri, 14 May 2010, Brian Swetland wrote:
In tickless mode, the time until next timer is a signed int, so the
longest the kernel will ever sleep is ~2 seconds at a go. In
practice, userspace entities often have polling behavior that can
trigger
On Mon, 2010-05-17 at 08:40 -0700, Kevin Hilman wrote:
Also, how does it handle the issue of ill-behaved apps?
For userspace, apps that have polling behavior or are ill-behaved must
be found and fixed. Thanks to tools like powertop, this is a farily
easy task.
That's a bit glib ...
* Tomi Valkeinen tomi.valkei...@nokia.com [100517 03:21]:
Hi,
On Mon, 2010-05-17 at 11:44 +0200, ext Russell King - ARM Linux wrote:
On Mon, May 17, 2010 at 12:38:55PM +0300, Grazvydas Ignotas wrote:
On Fri, May 14, 2010 at 1:16 PM, Russell King - ARM Linux
li...@arm.linux.org.uk
On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote:
For userspace, apps that have polling behavior or are ill-behaved must
be found and fixed. Thanks to tools like powertop, this is a farily
easy task.
That's a bit glib ... powertop can detect power consumption stats on a
On Mon, May 17, 2010 at 08:47:31PM +0300, Felipe Balbi wrote:
IMO the real fix would be on that particular poll(), changing the
timeout e.g. based on cpufreq notifications or even relying completely
on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a
crude example trying
On Mon, 2010-05-17 at 20:47 +0300, Felipe Balbi wrote:
On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote:
For userspace, apps that have polling behavior or are ill-behaved must
be found and fixed. Thanks to tools like powertop, this is a farily
easy task.
That's a bit
Hi,
On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote:
Have you actually tried this? On my N1 with CM5.0.6 just running
powertop requires me to keep the USB system up (debugging cable) and
paths into the usb console ... all of this produces significant wakeup
distortion, mostly
On Mon, May 17, 2010 at 11:12 AM, Felipe Balbi m...@felipebalbi.com wrote:
The technical reason for wanting suspend blockers (as has been stated
more times than I can be bothered to go back and count) is that no-one
can currently produce a working model for race free kernel to user work
Hi,
On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
We (Google) would like to allow completely open app distribution with
minimal hurdles, and avoid the walled garden approach. Toward this
goal we're not even requiring the use of a central app store for
distribution.
I
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi m...@felipebalbi.com wrote:
Hi,
On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
We (Google) would like to allow completely open app distribution with
minimal hurdles, and avoid the walled garden approach. Toward this
goal we're
On Mon, May 17, 2010 at 09:39:05PM +0300, Felipe Balbi wrote:
On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
For a large majority of apps, running in the background while the
device is asleep (screen off) is not essential, they don't request the
keep device awake
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi m...@felipebalbi.com wrote:
Hi,
On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
We (Google) would like to allow completely open app distribution with
minimal hurdles, and avoid the walled garden approach. Toward this
goal we're
James Bottomley james.bottom...@suse.de writes:
The technical reason for wanting suspend blockers (as has been stated
more times than I can be bothered to go back and count) is that no-one
can currently produce a working model for race free kernel to user work
handoff
At least I've never
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject:
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject: [PATCH
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject:
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject: [PATCH
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject: [PATCH
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject: [PATCH
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject: [PATCH
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject: [PATCH
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject: [PATCH
On Mon, 2010-05-17 at 21:12 +0300, Felipe Balbi wrote:
Hi,
On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote:
Have you actually tried this? On my N1 with CM5.0.6 just running
powertop requires me to keep the USB system up (debugging cable) and
paths into the usb console
Hi,
On Mon, May 17, 2010 at 03:24:27PM -0400, James Bottomley wrote:
Surely, depending on your UART FIFO depth, of course, a serial console
interrupts once every 16 characters or so ... how do you filter out that
storm of interrupts refreshing the powertop screen from the actual
application
hi,
On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote:
that's a whole other story. Hardware issues are things which in 99.999%
of the cases we can't change. We have to work around them. Software
bugs, on the other hand, can be fixed much more easily. I'm sure you
agree with that,
Fernando,
Thanks for forwarding the thread.
In wait_for_timer(), should return be used inside the loop? It will result in
omap_dm_timer_disable(timer) not being called. I believe it should be called
in all outcomes.
+ for (c = 0; c GPTIMER_IRQ_WAIT_MAX_CNT; c++)
+ if
On Mon, 2010-05-17 at 22:39 +0300, Felipe Balbi wrote:
hi,
On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote:
that's a whole other story. Hardware issues are things which in 99.999%
of the cases we can't change. We have to work around them. Software
bugs, on the other hand,
On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool vitalyw...@gmail.com wrote:
On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
and #2, the battery lifetime on the N770 and N800 (both of which I have)
is **appalling** **bad**.
Appalling bad compared to what?
move the documentation from header to c, cleanup missing function
documentation for the functions
Signed-off-by: Nishanth Menon n...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Jouni Hogander jouni.hogan...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley
The following cleanups are done for upstreaming OPP layer on top of the
current OPP layer in PM branch
Nishanth Menon (2):
omap: opp: make opp_get_opp_id robust
omap: opp: documentation update
Documentation/arm/OMAP/omap_pm| 66 +
arch/arm/plat-omap/include/plat/opp.h
opp_get_opp_id should handle the error cases that might hit it. check
parameters before using it
Signed-off-by: Nishanth Menon n...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Jouni Hogander jouni.hogan...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley
Add initial support for the OMAP4430 based Panda board.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/configs/omap4_panda_defconfig | 1094
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |1 +
On Mon, May 17, 2010 at 10:07 PM, Mike Chan m...@android.com wrote:
On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool vitalyw...@gmail.com wrote:
On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
and #2, the battery lifetime on the N770 and N800 (both of which I
On Monday 17 May 2010, Brian Swetland wrote:
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi m...@felipebalbi.com wrote:
...
but can anyone write an app that holds a suspend_blocker ?? If so, then
your goal is already broken, right ? I mean, if anyone can keep a
suspend_blocker held forever,
On 05/12/2010 09:16 PM, Xianghua Xiao wrote:
I'm unsure if the newest top (or /proc/PID/stat) reports the correct
cpu usage when CFS/BFS is used, as you mentioned it seems failed to do
that. I will try to stress the system and see who fails first under
same workload, maybe that's the only way
On Mon, May 17, 2010 at 1:17 PM, Vitaly Wool vitalyw...@gmail.com wrote:
On Mon, May 17, 2010 at 10:07 PM, Mike Chan m...@android.com wrote:
On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool vitalyw...@gmail.com wrote:
On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
khil...@deeprootsystems.com
Hi Cris,
On Mon, May 17, 2010 at 10:39 PM, Jansson, Cris cjans...@ti.com wrote:
Thanks for forwarding the thread.
In wait_for_timer(), should return be used inside the loop? It will result
in omap_dm_timer_disable(timer) not being called. I believe it should be
called in all outcomes.
The safe thing to do is disable the timer after the DSP has completed the dump.
During the dump processing, the DSP will clear the timer interrupt. I don't
know what would happen if the timer were disabled prior to that.
Best Regards,
Cris
-Original Message-
From: Felipe Contreras
If disable means cutting off the clock of the timer, then no.
The clock for the timer is needed so DSP can clear the timer IRQ status
register.
If it is to stop the timer from counting, then it is fine.
-Original Message-
From: Jansson, Cris
Sent: Monday, May 17, 2010 4:53 PM
To:
Mike Chan m...@android.com writes:
On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool vitalyw...@gmail.com wrote:
On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
and #2, the battery lifetime on the N770 and N800 (both of which I have)
is **appalling** **bad**.
On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
The fundamental problem is one of idleness. What we want is the
system to be idle in order to hit the lowest power states. We can't
get there because the system is not truly idle.
So, there are basically two
Update the irq mask so that is is clear that the MMU
interrupt is related to TWL fault.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/mach-omap2/iommu2.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c
The current iommu module doesn't provide the mechanism to get MMU fault on
TLB miss when working with locked TLB entries and TWL disabled.
To get the TLB miss interrupt, the TWL should be disabled.
This patch set provides the mechanism to disable TWL and enable TLB miss
interrupt.
Hari Kanigeri
In order to enable TLB miss interrupt, the TWL should be
disabled. This patch provides the functionality to get the
MMU fault interrupt for a TLB miss in the cases where the
users are working with the locked TLB entries and with TWL
disabled.
New interface is added to disable twl and enable TLB
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next
Initial commit ID (Likely to change): 97f84097ecdf7568d4d39e710cfda3e533441e1d
PatchWorks
http://patchwork.kernel.org/patch/96821/
Git (Likely to change, and takes a while to get
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next
Initial commit ID (Likely to change): 6ab41a6b4798817a99d79d9e23ca09702894b743
PatchWorks
http://patchwork.kernel.org/patch/99221/
Git (Likely to change, and takes a while to get
Hi all,
Here are few more patches for review. These
patches have been posted earlier to linux-omap list,
but have not quite been ready to go until now.
The series adds omap4 I2C and MMC support, and adds
a new omap3 board Stalker.
Please note that that the omap4 MMC support depends
on two other
Add separate omap_i2c_add_bus functions for mach-omap1
and mach-omap2. Make the mach-omap2 init set the interrupt
dynamically to support.
This is needed to add support for omap4 in a way that
works with multi-omap builds. This will eventually get
fixed with the omap hwmods.
Signed-off-by: Tony
Add support for i2c init for omap4.
This patch is based on and earlier patch by
Santosh Shilimkar santosh.shilim...@ti.com.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/i2c.c | 33 ++---
1 files changed, 26 insertions(+), 7 deletions(-)
From: Santosh Shilimkar santosh.shilim...@ti.com
This patch adds the i2c board support for OMAP4430 SDP platform.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
From: Balaji T K balaj...@ti.com
This patch adds i2c1 peripherals data to
omap4430 sdp board file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c | 177
From: Balaji T K balaj...@ti.com
This patch enables RTC and regulator support on omap4430 sdp
platform. Also sync up the defconfig with latest kernel
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
From: kishore kadiyala kishore.kadiy...@ti.com
Adding support for MMC1 MMC2 controllers of OMAP4430 SDP
to board file.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile|3 +-
From: kishore kadiyala kishore.kadiy...@ti.com
In OMAP4, MMC1 PBIAS and its associated IO is software-controlled
by CONTROL_PBIAS and CONTROL_MMC1 registers. This patch adds PBIAS
configuration for MMC1 Controller during power-ON and power-OFF
of regulator.
Signed-off-by: Kishore Kadiyala
From: kishore kadiyala kishore.kadiy...@ti.com
Enables HSMMC support for OMAP4430 defconfig
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/configs/omap_4430sdp_defconfig | 19 ++-
1 files changed, 18
From: kishore kadiyala kishore.kadiy...@ti.com
This patch adds dummy Interface clocks for MMC controllers
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/clock44xx_data.c |5
From: Jason l...@ema-tech.com
Add support for OMAP3Stalker boards
Signed-off-by: Jason Lam l...@ema-tech.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |6
arch/arm/mach-omap2/Makefile |2
From: Jason Lam l...@ema-tech.com
Add OMAP3 Stalker board LK-S defconfig.
Signed-off-by: Jason Lam l...@ema-tech.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/configs/omap3_stalker_lks_defconfig | 1691 ++
1 files changed, 1691 insertions(+), 0
From: Anand Gadiyar gadi...@ti.com
- Update the omap3_defconfig to sync up with the generated .config
- Increase CONFIG_LOG_BUF_SHIFT to 16 to allow the entire
boot log to be captured
(useful when using boot time tracer, for example)
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by:
Add stalker board to omap3_defconfig
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/configs/omap3_defconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig
index 0eb1bc9..94dfcf0 100644
---
Hi,
* kishore kadiyala kishore.kadiy...@ti.com [100515 11:15]:
Adding MMC1 and MMC2 controllers support for OMAP4
V4:
- Rebased to for_next branch[LO].
- The first 3 patches [1,2,3] in the series are Minimal set of changes
with which MMC1/MMC2 works [No card detect for MMC1]on OMAP4 but
* Santosh Shilimkar santosh.shilim...@ti.com [100512 01:22]:
This patch adds the i2c board support for OMAP4430 SDP platform. The
necessary drivers support patch is posted earlier.
https://patchwork.kernel.org/patch/80659/
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@
* kishore kadiyala kishore.kadiy...@ti.com [100515 11:16]:
Adding a flag to determine the card detect type which can be
either GPIO or NON-GPIO.MMC1 Controller of OMAP4 have NON-GPIO
interrupt line from twl6030 for card detect.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
* Tony Lindgren t...@atomide.com [100517 19:47]:
* Santosh Shilimkar santosh.shilim...@ti.com [100512 01:22]:
This patch adds the i2c board support for OMAP4430 SDP platform. The
necessary drivers support patch is posted earlier.
https://patchwork.kernel.org/patch/80659/
---
* Anders, David x0132...@ti.com [100517 13:13]:
Add initial support for the OMAP4430 based Panda board.
Signed-off-by: David Anders x0132...@ti.com
snip
+
+static void __init omap4_panda_init_irq(void)
+{
+ omap2_init_common_hw(NULL, NULL);
+#ifdef CONFIG_OMAP_32K_TIMER
+
Hi All,
I have been trying to find the reason for the problem I am facing with
CFS and process with SCHED_FIFO.
Here is a small program I wrote.
/* Lets call this V1 */
#include sys/types.h
#include sys/stat.h
/* There are other includes but for brevity I have not shown */
main ()
{
/* I have
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, May 18, 2010 8:23 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Krishnamoorthy, Balaji T
Subject: Re: [PATCH 1/3] omap4: Add i2c board support on omap4430 sdp platform
* Santosh Shilimkar
93 matches
Mail list logo
