Tony Lindgren wrote:
* Adrian Hunter [EMAIL PROTECTED] [081121 01:16]:
Start idle timer only at the end of request or request like operation
such card detect, set_ios, probe, or resume. This will ensure the fclk is
disable quickly after the operation is done, but never too early.
From
Tony Lindgren wrote:
* Adrian Hunter [EMAIL PROTECTED] [081121 01:15]:
Add a timer that is kept active by MMC requests. FCLK is disabled on timeout
Let's keep these patches on hold until we have the hsmmc.c driver in
mainline, then get them integrated via LKML.
Meanwhile, maybe you want to
Op 27 nov 2008, om 01:05 heeft Kevin Hilman het volgende geschreven:
Various bootloaders have been known to leave modules in a state
which prevents full-chip retention. This series forces
MMC, IVA2 and D2D/modem into known reset/idle states so that
the OMAP3 can hit full-chip idle.
Tested on
ext Trilok Soni wrote:
Hi Hans,
Hello, Hans and Soni!
2) The Kconfig is probably missing a ARCH_OMAP dependency (sounds
reasonable, at least), so now it also compiles for the i686 but that
architecture doesn't have a clk_get function.
It *might* be possible that the same camera block would
Hi,
This patch set is a prototype video ram allocator for OMAP for review.
The reasons I made this are:
- The DMA_CONSISTENT memory area is only 14M, and that may not be enough.
1280*1024*4 framebuffer takes more than 5M. Three of those, and perhaps
double buffering, and we are easily over
Signed-off-by: Tomi Valkeinen [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-3430sdp.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index e2eed49..f3bb647 100644
---
The manager can be used to allocate large chucks of memory at boot time
for VRAM use. Drivers can then later allocate pieces of memory from the
manager.
Signed-off-by: Tomi Valkeinen [EMAIL PROTECTED]
---
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/fb-vram.c
Off mode is now using the omap2 retention fix code for scanning GPIOs
only during off-mode transitions. All the *non_wakeup_gpios variables
are now used for off-mode transition tracking on OMAP3. This patch fixes
cases where GPIO state changes are missed during off-mode.
Signed-off-by: Tero
On Thu, Nov 27, 2008 at 12:42:12PM +0200, Grazvydas Ignotas wrote:
Pandora board uses different master/slave configuration for McBSP bus,
compared to most other boards. It also has another audio path (in
addition to TWL4030) - another McBSP link connected to external DAC.
The DAC needs 256*Fs
On Thu, Nov 27, 2008 at 08:50:57PM +0800, Stanley.Miao wrote:
Add a shared omap_twl4030 driver to avoid reduplicate code among omap drivers.
This drive also provides a extended interface for some board specific
features.
As discussed in the thread following your initial submission it'd be
Pandora has some LEDs and backlights connected to OMAP
GPIOs and TWL4030/TPS65950 LED/PWM signals. This patch
registers them all with leds-gpio driver. TWL4030/TPS65950
controlled ones will be switched to PWM driver when it's ready.
Signed-off-by: Grazvydas Ignotas [EMAIL PROTECTED]
---
Changes from v1:
1, change the name from omap-general to omap_twl4030.
2, proune off board related defines.
3, add a extended interface omap_twl4030_specific_init() to support some board
specific features.
If some board specific features are added into a board, for example, omap3evm
board. we
Add a shared omap_twl4030 driver to avoid reduplicate code among omap drivers.
This drive also provides a extended interface for some board specific features.
Signed-off-by: Stanley.Miao [EMAIL PROTECTED]
---
sound/soc/omap/Kconfig| 33 -
sound/soc/omap/Makefile | 16
Signed-off-by: Tomi Valkeinen [EMAIL PROTECTED]
---
arch/arm/plat-omap/fb.c | 22 ++-
arch/arm/plat-omap/include/mach/omapfb.h |2 +
drivers/video/omap/dispc.c | 281 +++---
drivers/video/omap/omapfb_main.c | 11 +-
4 files
On Wed, 2008-11-26 at 21:16 +, Mark Brown wrote:
On Wed, Nov 26, 2008 at 12:33:12PM -0800, David Brownell wrote:
And maybe more; that's just me summarizing unconnected pins,
not the datasheet. There are also cost-reduced parts with
less audio capability.
...
I make no claim
Hi Tony,
From: ext Tony Lindgren [EMAIL PROTECTED]
Subject: Re: [PATCH 02/10] omap mailbox: add initial omap3 support
Date: Wed, 26 Nov 2008 10:36:14 -0800
snip
Thanks, since this is a large series, can you please send your series for
RMK to integrate to LAKML? Make sure it also applies
Add OMAP_LDP platform support.
Signed-off-by: Stanley.Miao [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-ldp.c | 477 ++-
arch/arm/plat-omap/include/mach/board-ldp.h |4 +
2 files changed, 479 insertions(+), 2 deletions(-)
diff --git
Add glue to control the OMAP_LDP LCD as a frame buffer device
using the existing dispc.c driver under omapfb.
Signed-off-by: Stanley.Miao [EMAIL PROTECTED]
---
drivers/video/omap/lcd_ldp.c | 198 ++
1 files changed, 198 insertions(+), 0 deletions(-)
On Wed, 2008-11-26 at 15:12 -0800, Tony Lindgren wrote:
* Stanley.Miao [EMAIL PROTECTED] [081120 23:45]:
Changes from v1:
1, change omap_request_gpio() to gpio_request() in gpio.patch.
One request: Since the LDP is in the mainline kernel, can you please
provide whatever applies as
On Thu, 2008-11-27 at 13:19 +, Mark Brown wrote:
On Thu, Nov 27, 2008 at 08:50:57PM +0800, Stanley.Miao wrote:
Add a shared omap_twl4030 driver to avoid reduplicate code among omap
drivers.
This drive also provides a extended interface for some board specific
features.
As
On Thu, Nov 27, 2008 at 11:56:05PM +0800, stanley.miao wrote:
On Thu, 2008-11-27 at 13:19 +, Mark Brown wrote:
As I said in response to your original posting I'd strongly urge you to
look at the s3c24xx_uda134x driver for an example of how something like
this can be implemented.
I
On Wednesday 26 November 2008, Kyungmin Park wrote:
Custom board powered by VAUX2 and VAUX4 for MMC instead of VMMC
Also it uses VMMC for MMC core power not voltage.
MMC1: uses VMMC1(voltage) and VMMC2(Vdd)
MMC2: uses VAUX2(voltage) and VAUX4(Vdd)
To address this issue, platform uses its
Hi Sakari,
It *might* be possible that the same camera block would be used in non-OMAP
CPUs as well but I guess it is safe to assume that it depends on ARCH_OMAP
now.
Right, better to keep ARCH_OMAP as dependancy.
Thanks for the review comments. I will resubmit the patch.
Is this
PR785 boards is a replacement for the Triton Power boards for OMAP3
EVM. It has a TPS62352 and TPS62353 device onboard for controlling the
CORE and MPU voltage for OMAP3 EVM. This patch provides the support
framework for PR785 boards. This patch series also helps in building
code without
This patch provides the support framework for PR785 boards.
More patches will follow that will allow complete programming
support for PR785 boards.
The board-omap3evm.c contains the I2C devices to be supported.
CONFIG_PR785 is configuration used for the PR784 boards.
Signed-off-by: Manikandan
Implements the basic driver for TPS6235x devices populated on the
PR785 board. tps6235x.c contains the driver code for TPS devices used on
PR785 boards. Driver code is added it to the build.
Signed-off-by: Manikandan Pillai [EMAIL PROTECTED]
---
drivers/i2c/chips/Makefile |1 +
MUSB on OMAP3EVM uses ISP1504 phy and doesn't need twl4030.
OMAP35xx Beagle board MUSB uses twl4030 phy thus uses it and
it also sets xceiv global field using otg_set_transceiver().
As OMAP3EVM MUSB doesn't require twl4030 so otg_set_transceiver()
part is being done in this patch.
This is a
Flash initialization has been modified to take care on NAND initialization
and creation of NAND partitions.
Signed-off-by: Manikandan Pillai [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap3evm-flash.c | 85 --
arch/arm/plat-omap/include/mach/board-omap3evm.h |
On Thursday 27 November 2008, Manikandan Pillai wrote:
Implements the basic driver for TPS6235x devices populated on the
PR785 board. tps6235x.c contains the driver code for TPS devices used on
PR785 boards. Driver code is added it to the build.
Signed-off-by: Manikandan Pillai [EMAIL
On Fri, Nov 28, 2008 at 10:58:24AM +0530, ext Manikandan Pillai wrote:
MUSB on OMAP3EVM uses ISP1504 phy and doesn't need twl4030.
OMAP35xx Beagle board MUSB uses twl4030 phy thus uses it and
it also sets xceiv global field using otg_set_transceiver().
As OMAP3EVM MUSB doesn't require twl4030
no.
I could even live with if (machine_is_xxx()) code, although I don't want
to. But ifdefs are an automatic NAK.
Felipe, this is temporary patch as described. I will submit the final one
later. twl4030 dependency is bottleneck for TPS work on OMAP3EVM.
--
balbi
--
To unsubscribe
On Fri, Nov 28, 2008 at 10:57:58AM +0530, ext Manikandan Pillai wrote:
This patch provides the support framework for PR785 boards.
More patches will follow that will allow complete programming
support for PR785 boards.
The board-omap3evm.c contains the I2C devices to be supported.
On Fri, Nov 28, 2008 at 10:58:10AM +0530, ext Manikandan Pillai wrote:
Implements the basic driver for TPS6235x devices populated on the
PR785 board. tps6235x.c contains the driver code for TPS devices used on
PR785 boards. Driver code is added it to the build.
Please, read
On Thursday 27 November 2008, Manikandan Pillai wrote:
#if defined(CONFIG_ARCH_OMAP2430)
omap_cfg_reg(AE5_2430_USB0HS_STP);
+ x = otg_get_transceiver();
+#elif defined(CONFIG_MACH_OMAP3EVM)
+ x = kzalloc(sizeof *x, GFP_KERNEL);
+ if (!x)
+ return 0;
On Fri, Nov 28, 2008 at 12:21:05PM +0530, Ajay Kumar Gupta wrote:
no.
I could even live with if (machine_is_xxx()) code, although I don't want
to. But ifdefs are an automatic NAK.
Felipe, this is temporary patch as described. I will submit the final one
later. twl4030 dependency is
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David
Brownell
Sent: Friday, November 28, 2008 12:33 PM
To: Pillai, Manikandan
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/3] musb: Remvoing twl4030 dependency for OMAP3EVM MUSB
On Thursday
36 matches
Mail list logo
