RE: linux-next: manual merge of the omap tree with the arm tree
> -Original Message- > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > Sent: Thursday, May 28, 2009 12:05 PM > To: Shilimkar, Santosh > Cc: Tony Lindgren; linux-omap@vger.kernel.org; > linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; Russell King > Subject: Re: linux-next: manual merge of the omap tree with > the arm tree > > Hi, > > On Thu, 28 May 2009 11:55:09 +0530 "Shilimkar, Santosh" > wrote: > > > > > +machine-$(CONFIG_ARCH_OMAP2):= omap2 > > > +machine-$(CONFIG_ARCH_OMAP3):= omap2 > > > ++machine-$(CONFIG_ARCH_OMAP4):= omap2 > > > > ++ Is this really ok ? > > Yeah, this is a diff of a git merge. The ++ just means it > was added on > neither side of the merge - I modified the change from the omap tree > slightly to fit in better with the cleanups from the arm tree. Ok. Thanks !! Regards, Santosh -- 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
Re: linux-next: manual merge of the omap tree with the arm tree
Hi, On Thu, 28 May 2009 11:55:09 +0530 "Shilimkar, Santosh" wrote: > > > +machine-$(CONFIG_ARCH_OMAP2) := omap2 > > +machine-$(CONFIG_ARCH_OMAP3) := omap2 > > ++machine-$(CONFIG_ARCH_OMAP4) := omap2 > > ++ Is this really ok ? Yeah, this is a diff of a git merge. The ++ just means it was added on neither side of the merge - I modified the change from the omap tree slightly to fit in better with the cleanups from the arm tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpppYO8L3Pvw.pgp Description: PGP signature
RE: linux-next: manual merge of the omap tree with the arm tree
> -Original Message- > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > Sent: Thursday, May 28, 2009 10:02 AM > To: Tony Lindgren; linux-omap@vger.kernel.org > Cc: linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; > Russell King; Shilimkar, Santosh > Subject: linux-next: manual merge of the omap tree with the arm tree > > Hi all, > > Today's linux-next merge of the omap tree got a conflict in > arch/arm/Makefile between commit > b4175b89921fefb2f352472fa6dccb0fc4fb37d9 > ("[ARM] sort machine- and plat- by CONFIG* name") from the > arm tree and > commit 68394eae0fc4e801fc2ae33055b24a9754669a7b ("ARM: OMAP4: > Add support > for 4430 SDP") from the omap tree. > > I fixed it up (see below) and can carry the fix as necessary. > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au > > diff --cc arch/arm/Makefile > index e97c21b,676d10d..000 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@@ -99,72 -99,65 +99,73 @@@ CHECKFLAGS += -D__arm_ > #Default value > head-y := arch/arm/kernel/head$(MMUEXT).o > arch/arm/kernel/init_task.o > textofs-y := 0x8000 - machine-$(CONFIG_ARCH_W90X900):= w90x900 > + > +# Machine directory name. This list is sorted alphanumerically > +# by CONFIG_* macro name. > +machine-$(CONFIG_ARCH_AAEC2000) := aaec2000 > +machine-$(CONFIG_ARCH_AT91) := at91 > +machine-$(CONFIG_ARCH_CLPS711X) := clps711x > +machine-$(CONFIG_ARCH_DAVINCI) := davinci > +machine-$(CONFIG_ARCH_EBSA110) := ebsa110 > +machine-$(CONFIG_ARCH_EP93XX) := ep93xx > +machine-$(CONFIG_ARCH_GEMINI) := gemini > +machine-$(CONFIG_ARCH_H720X):= h720x > +machine-$(CONFIG_ARCH_INTEGRATOR) := integrator > +machine-$(CONFIG_ARCH_IOP13XX) := iop13xx > +machine-$(CONFIG_ARCH_IOP32X) := iop32x > +machine-$(CONFIG_ARCH_IOP33X) := iop33x > +machine-$(CONFIG_ARCH_IXP2000) := ixp2000 > +machine-$(CONFIG_ARCH_IXP23XX) := ixp23xx > +machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx > +machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood > +machine-$(CONFIG_ARCH_KS8695) := ks8695 > +machine-$(CONFIG_ARCH_L7200):= l7200 > +machine-$(CONFIG_ARCH_LH7A40X) := lh7a40x > +machine-$(CONFIG_ARCH_LOKI) := loki > +machine-$(CONFIG_ARCH_MMP) := mmp > +machine-$(CONFIG_ARCH_MSM) := msm > +machine-$(CONFIG_ARCH_MV78XX0) := mv78xx0 > +machine-$(CONFIG_ARCH_MX1) := mx1 > +machine-$(CONFIG_ARCH_MX2) := mx2 > +machine-$(CONFIG_ARCH_MX3) := mx3 > +machine-$(CONFIG_ARCH_NETX) := netx > +machine-$(CONFIG_ARCH_NS9XXX) := ns9xxx > +machine-$(CONFIG_ARCH_OMAP1):= omap1 > +machine-$(CONFIG_ARCH_OMAP2):= omap2 > +machine-$(CONFIG_ARCH_OMAP3):= omap2 > ++machine-$(CONFIG_ARCH_OMAP4):= omap2 ++ Is this really ok ? > +machine-$(CONFIG_ARCH_ORION5X) := orion5x > +machine-$(CONFIG_ARCH_PNX4008) := pnx4008 > +machine-$(CONFIG_ARCH_PXA) := pxa -- 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
Re: [PATCH 1/4] ARM: OMAP4: SMP: Add OMAP4430 SMP board files
(Updated usage of NR_CPUS instead of num_possible_cpus() after Russell's remark) This patch adds SMP platform files support for OMAP4430SDP. TI's OMAP4430 SOC is based on ARM Cortex-A9 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and SCU for cache coherency. Signed-off-by: Santosh Shilimkar --- arch/arm/mach-omap2/omap-headsmp.S| 46 + arch/arm/mach-omap2/omap-smp.c| 178 + arch/arm/plat-omap/include/mach/smp.h | 51 ++ 3 files changed, 275 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/omap-headsmp.S create mode 100644 arch/arm/mach-omap2/omap-smp.c create mode 100644 arch/arm/plat-omap/include/mach/smp.h diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S new file mode 100644 index 000..4afadba --- /dev/null +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -0,0 +1,46 @@ +/* + * Secondary CPU startup routine source file. + * + * Copyright (C) 2009 Texas Instruments, Inc. + * + * Author: + * Santosh Shilimkar + * + * Interface functions needed for the SMP. This file is based on arm + * realview smp platform. + * Copyright (c) 2003 ARM Limited. + * + * This program is free software,you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include + +/* Physical address needed since MMU not enabled yet on secondary core */ +#define OMAP4_AUX_CORE_BOOT1_PA0x48281804 + + __INIT + +/* + * OMAP4 specific entry point for secondary CPU to jump from ROM + * code. This routine also provides a holding flag into which + * secondary core is held until we're ready for it to initialise. + * The primary core will update the this flag using a hardware + * register AuxCoreBoot1. + */ +ENTRY(omap_secondary_startup) + mrc p15, 0, r0, c0, c0, 5 + and r0, r0, #0x0f +hold: ldr r1, =OMAP4_AUX_CORE_BOOT1_PA@ read from AuxCoreBoot1 + ldr r2, [r1] + cmp r2, r0 + bne hold + + /* +* we've been released from the cpu_release,secondary_stack +* should now contain the SVC stack for this core +*/ + b secondary_startup + diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c new file mode 100644 index 000..e6a871f --- /dev/null +++ b/arch/arm/mach-omap2/omap-smp.c @@ -0,0 +1,178 @@ +/* + * OMAP4 SMP source file. It contains platform specific fucntions + * needed for the linux smp kernel. + * + * Copyright (C) 2009 Texas Instruments, Inc. + * + * Author: + * Santosh Shilimkar + * + * Platform file needed for the OMAP4 SMP. This file is based on arm + * realview smp platform. + * * Copyright (c) 2002 ARM Limited. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include + +#include +#include +#include + +/* Registers used for communicating startup information */ +#define OMAP4_AUXCOREBOOT_REG0 (OMAP44XX_VA_WKUPGEN_BASE + 0x800) +#define OMAP4_AUXCOREBOOT_REG1 (OMAP44XX_VA_WKUPGEN_BASE + 0x804) + +/* SCU base address */ +static void __iomem *scu_base = OMAP44XX_VA_SCU_BASE; + +/* + * Use SCU config register to count number of cores + */ +static inline unsigned int get_core_count(void) +{ + if (scu_base) + return scu_get_core_count(scu_base); + return 1; +} + +static DEFINE_SPINLOCK(boot_lock); + +void __cpuinit platform_secondary_init(unsigned int cpu) +{ + trace_hardirqs_off(); + + /* +* If any interrupts are already enabled for the primary +* core (e.g. timer irq), then they will not have been enabled +* for us: do so +*/ + + gic_cpu_init(0, IO_ADDRESS(OMAP44XX_GIC_CPU_BASE)); + + /* +* Synchronise with the boot thread. +*/ + spin_lock(&boot_lock); + spin_unlock(&boot_lock); +} + +int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle) +{ + unsigned long timeout; + + /* +* Set synchronisation state between this boot processor +* and the secondary one +*/ + spin_lock(&boot_lock); + + /* +* Update the AuxCoreBoot1 with boot state for secondary core. +* omap_secondary_startup() routine will hold the secondary core till +* the AuxCoreBoot1 register is updated with cpu state +* A barrier is added to ensure that write buffer is drained +*/ + __raw_writel(cpu, OMAP4_AUXCOREBOOT_REG1); + smp_wmb(); + + timeout = jiffies + (1 * HZ); + while (time_before(jiffies, timeout)) + ; + + /* +* Now the secondary core is starting up let it run its +
linux-next: manual merge of the omap tree with the arm tree
Hi all, Today's linux-next merge of the omap tree got a conflict in arch/arm/Makefile between commit b4175b89921fefb2f352472fa6dccb0fc4fb37d9 ("[ARM] sort machine- and plat- by CONFIG* name") from the arm tree and commit 68394eae0fc4e801fc2ae33055b24a9754669a7b ("ARM: OMAP4: Add support for 4430 SDP") from the omap tree. I fixed it up (see below) and can carry the fix as necessary. -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm/Makefile index e97c21b,676d10d..000 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@@ -99,72 -99,65 +99,73 @@@ CHECKFLAGS += -D__arm_ #Default value head-y:= arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o textofs-y := 0x8000 - - machine-$(CONFIG_ARCH_RPC) := rpc - machine-$(CONFIG_ARCH_EBSA110) := ebsa110 - machine-$(CONFIG_FOOTBRIDGE):= footbridge - machine-$(CONFIG_ARCH_SHARK):= shark - machine-$(CONFIG_ARCH_SA1100) := sa1100 -ifeq ($(CONFIG_ARCH_SA1100),y) +textofs-$(CONFIG_ARCH_CLPS711X) := 0x00028000 # SA DMA bug: we don't want the kernel to live in precious DMA-able memory - textofs-$(CONFIG_SA):= 0x00208000 +ifeq ($(CONFIG_ARCH_SA1100),y) +textofs-$(CONFIG_SA) := 0x00208000 endif - machine-$(CONFIG_ARCH_PXA) := pxa - machine-$(CONFIG_ARCH_MMP) := mmp -plat-$(CONFIG_PLAT_PXA) := pxa - machine-$(CONFIG_ARCH_L7200):= l7200 - machine-$(CONFIG_ARCH_INTEGRATOR) := integrator - machine-$(CONFIG_ARCH_GEMINI) := gemini - textofs-$(CONFIG_ARCH_CLPS711X) := 0x00028000 - machine-$(CONFIG_ARCH_CLPS711X) := clps711x - machine-$(CONFIG_ARCH_IOP32X) := iop32x - machine-$(CONFIG_ARCH_IOP33X) := iop33x - machine-$(CONFIG_ARCH_IOP13XX) := iop13xx -plat-$(CONFIG_PLAT_IOP) := iop - machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx - machine-$(CONFIG_ARCH_IXP2000):= ixp2000 - machine-$(CONFIG_ARCH_IXP23XX):= ixp23xx - machine-$(CONFIG_ARCH_OMAP1):= omap1 - machine-$(CONFIG_ARCH_OMAP2):= omap2 - machine-$(CONFIG_ARCH_OMAP3):= omap2 - machine-$(CONFIG_ARCH_OMAP4):= omap2 -plat-$(CONFIG_ARCH_OMAP) := omap - machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2400 s3c2412 s3c2440 s3c2442 s3c2443 - machine-$(CONFIG_ARCH_S3C24A0) := s3c24a0 -plat-$(CONFIG_PLAT_S3C24XX) := s3c24xx s3c - machine-$(CONFIG_ARCH_S3C64XX) := s3c6400 s3c6410 -plat-$(CONFIG_PLAT_S3C64XX) := s3c64xx s3c - machine-$(CONFIG_ARCH_LH7A40X) := lh7a40x - machine-$(CONFIG_ARCH_VERSATILE) := versatile - machine-$(CONFIG_ARCH_IMX) := imx - machine-$(CONFIG_ARCH_H720X):= h720x - machine-$(CONFIG_ARCH_AAEC2000) := aaec2000 - machine-$(CONFIG_ARCH_REALVIEW) := realview - machine-$(CONFIG_ARCH_AT91) := at91 - machine-$(CONFIG_ARCH_EP93XX) := ep93xx - machine-$(CONFIG_ARCH_PNX4008) := pnx4008 - machine-$(CONFIG_ARCH_NETX) := netx - machine-$(CONFIG_ARCH_NS9XXX) := ns9xxx - machine-$(CONFIG_ARCH_DAVINCI) := davinci - machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood - machine-$(CONFIG_ARCH_KS8695) := ks8695 -plat-$(CONFIG_ARCH_MXC) := mxc - machine-$(CONFIG_ARCH_MX2) := mx2 - machine-$(CONFIG_ARCH_MX3) := mx3 - machine-$(CONFIG_ARCH_MX1) := mx1 - machine-$(CONFIG_ARCH_ORION5X) := orion5x -plat-$(CONFIG_PLAT_ORION):= orion - machine-$(CONFIG_ARCH_MSM) := msm - machine-$(CONFIG_ARCH_LOKI) := loki - machine-$(CONFIG_ARCH_MV78XX0):= mv78xx0 - machine-$(CONFIG_ARCH_W90X900):= w90x900 + +# Machine directory name. This list is sorted alphanumerically +# by CONFIG_* macro name. +machine-$(CONFIG_ARCH_AAEC2000) := aaec2000 +machine-$(CONFIG_ARCH_AT91) := at91 +machine-$(CONFIG_ARCH_CLPS711X) := clps711x +machine-$(CONFIG_ARCH_DAVINCI):= davinci +machine-$(CONFIG_ARCH_EBSA110):= ebsa110 +machine-$(CONFIG_ARCH_EP93XX) := ep93xx +machine-$(CONFIG_ARCH_GEMINI) := gemini +machine-$(CONFIG_ARCH_H720X) := h720x +machine-$(CONFIG_ARCH_INTEGRATOR) := integrator +machine-$(CONFIG_ARCH_IOP13XX):= iop13xx +machine-$(CONFIG_ARCH_IOP32X) := iop32x +machine-$(CONFIG_ARCH_IOP33X) := iop33x +machine-$(CONFIG_ARCH_IXP2000):= ixp2000 +machine-$(CONFIG_ARCH_IXP23XX):= ixp23xx +machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx +machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood +machine-$(CONFIG_ARCH_KS8695) := ks8695 +machine-$(CONFIG_ARCH_L7200) := l7200 +machine-$(CONFIG_ARCH_LH7A40X):= lh7a40x +machine-$(CONFIG_ARCH_LOKI) := loki +machine-$(CONFIG_ARCH_MMP):= mmp +machine-$(CONFIG_ARCH_MSM):= msm +machine-$(CONFIG_ARCH_MV78XX0)
RE: [PATCH 1/4] ARM: OMAP4: Add minimal support for omap4
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Thursday, May 28, 2009 5:07 AM > To: Shilimkar, Santosh > Cc: li...@arm.linux.org.uk; > linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > Subject: Re: [PATCH 1/4] ARM: OMAP4: Add minimal support for omap4 > > * Santosh Shilimkar [090520 05:59]: > > This patch adds the support for OMAP4. The platform and > machine specific > > headers and sources updated for OMAP4430 SDP platform. > > > > OMAP4430 is Texas Instrument's SOC based on ARM Cortex-A9 > SMP architecture. > > It's a dual core SOC with GIC used for interrupt handling > and SCU for cache > > coherency. > > I've added these to omap for-next branch. Thanks Tony !! Regards, Santosh -- 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
Git pull request for omap patches for merge window after 2.6.30
Hi Russell, Assuming you have had a chance to look at all the patches posted, please pull them from the request below. Will refresh the patches as needed if you have more comments. I've merged all the omap patches, except Santosh' omap4 SMP set, and Paul's second clock updates. This should remove any dependencies for Santosh' SMP series. Merging this will cause a trivial merge conflict in arch/arm/Makefile with the omap4 line, so let me know if you want me to rebase on something else other than v2.6.30-rc7. Regards, Tony Summary of patch sets merged: [PATCH 0/5] More omap header clean-up for the merge window after 2.6.30 http://article.gmane.org/gmane.linux.ports.arm.omap/19727 [PATCH 0/4] OMAP: Cleanup series http://lists.arm.linux.org.uk/lurker/message/20090519.131647.c2c471ef.en.html [PATCH 00/10] OMAP clock/SDRC patches on v2.6.30-rc5 http://article.gmane.org/gmane.linux.ports.arm.omap/19589 [PATCH v2 00/13] OMAP2/3: PM sync-up http://article.gmane.org/gmane.linux.ports.arm.omap/20073 [PATCH 00/10] Omap updates for merge window after 2.6.30 http://article.gmane.org/gmane.linux.ports.arm.omap/19979 [PATCH 0/6] Updates for omap3 for merge window after 2.6.30 http://article.gmane.org/gmane.linux.ports.arm.omap/20123 PATCH 0/8] omap3 board updates for merge window after 2.6.30 http://article.gmane.org/gmane.linux.ports.arm.omap/20188 [PATCH 1/4] ARM: OMAP4: Add minimal support for omap4 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12819.html Pull request: The following changes since commit 59a3759d0fe8d969888c741bb33f4946e4d3750d: Linus Torvalds (1): Linux 2.6.30-rc7 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git for-next Adrian Hunter (1): ARM: OMAP3: RX51: Connect VAUX3 to MMC2 Artem Bityutskiy (1): OMAP3 clock: lessen amount of noisy messages David Brownell (2): ARM: OMAP3: mmc-twl4030 uses regulator framework ARM: OMAP3: Initialize regulators for Beagle and Overo Eero Nurkkala (1): ARM: OMAP: McBSP: Fix legacy interrupts to clear their status Grazvydas Ignotas (2): ARM: OMAP3: pandora: setup regulator framework for MMC ARM: OMAP3: pandora: add support for mode devices Imre Deak (2): ARM: OMAP2: 2430SDP: Add FB support to board file ARM: OMAP3: ZOOM MDK: Add FB support to board file Jarkko Nikula (1): ARM: OMAP: Update contact address of I2C registration helper Jouni Hogander (2): OMAP: Add new function to check wether there is irq pending OMAP: UART: Add sysfs interface for adjusting UART sleep timeout Juha Yrjola (1): ARM: OMAP2/3: Add generic onenand support when connected to GPMC Kevin Hilman (11): Revert "ARM: OMAP: Mask interrupts when disabling interrupts, v2" OMAP2/3: PM: push core PM code from linux-omap OMAP3: PM: Force IVA2 into idle during bootup OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X OMAP3: PM: UART: disable clocks when idle and off-mode support OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init OMAP3: PM: D2D clockdomain supports SW supervised transitions OMAP3: PM: Ensure PRCM interrupts are cleared at boot OMAP3: PM: Clear pending PRCM reset flags on init OMAP3: PM: prevent module wakeups from waking IVA2 OMAP1: PM: update and decouple from OMAP2/3 PM core Mans Rullgard (1): ARM: OMAP: Increase VMALLOC_END to allow 256MB RAM Paul Walmsley (11): OMAP3 SRAM: mark OCM RAM as Non-cacheable Normal memory OMAP3 SRAM: add ARM barriers to omap3_sram_configure_core_dpll OMAP3 clock: add interconnect barriers to CORE DPLL M2 change OMAP3 SRAM: clear the SDRC PWRENA bit during SDRC frequency change OMAP3 SDRC: initialize SDRC_POWER at boot OMAP3 SRAM: renumber registers to make space for argument passing OMAP3 clock: only unlock SDRC DLL if SDRC clk < 83MHz OMAP3 clock: use pr_debug() rather than pr_info() in some clock change code OMAP2xxx clock: rename clk_init_one() to clk_preinit() ARM: OMAP3: SDRC: add timing data for Micron MT46H32M32LF-6, v2 ARM: OMAP3: SDRC: add timing data for Qimonda HYB18M512160AF-6 Peter 'p2' De Schrijver (1): OMAP3: PM: Ensure MUSB block can idle when driver not loaded Santosh Shilimkar (11): ARM: OMAP: Remove unwanted type casts and fix the compiler warning. ARM: OMAP: Remove useless omap_sram_error function. ARM: OMAP: Remove unnecessary omap2_globals. ARM: OMAP2/3: sDMA: Correct omap_request_dma_chain(), v2 ARM: OMAP: Remove unwanted type casts and fix the compiler warning. ARM: OMAP: Remove useless omap_sram_error function. ARM: OMAP: Remove unnecessary omap2_globals. ARM: OMAP4: Add minimal support for omap4 ARM: OMAP4: Clock stubs since CLKDEV not in yet. ARM: OMAP4: Add support for 4430 SDP ARM: OMAP4: Add defconfig for 4430 S
Re: [PATCH 0/8] omap3 board updates for merge window after 2.6.30
* Tony Lindgren [090525 10:47]: > Hi all, > > Here are some omap3 board specific patches for the upcoming merge > window. It adds two new boards, and starts converting MMC to > use the regulator framework. Merged this series into omap for-next branch. > Regards, > > Tony > > --- > > Adrian Hunter (1): > ARM: OMAP3: RX51: Connect VAUX3 to MMC2 > > David Brownell (2): > ARM: OMAP3: Initialize regulators for Beagle and Overo > ARM: OMAP3: mmc-twl4030 uses regulator framework > > Grazvydas Ignotas (1): > ARM: OMAP3: pandora: setup regulator framework for MMC > > Syed Mohammed Khasim (2): > ARM: OMAP3: Add omap3 EVM defconfig > ARM: OMAP3: Add omap3 EVM support > > Vikram Pandita (2): > ARM: OMAP3: Defconfig for Zoom2 board > ARM: OMAP3: Add support for OMAP3 Zoom2 board > > > arch/arm/configs/omap3_evm_defconfig | 1528 > ++ > arch/arm/configs/omap_zoom2_defconfig| 1211 + > arch/arm/mach-omap2/Kconfig |8 > arch/arm/mach-omap2/Makefile |6 > arch/arm/mach-omap2/board-omap3beagle.c | 104 ++ > arch/arm/mach-omap2/board-omap3evm.c | 329 ++ > arch/arm/mach-omap2/board-omap3pandora.c | 45 + > arch/arm/mach-omap2/board-overo.c| 76 + > arch/arm/mach-omap2/board-rx51-peripherals.c | 30 - > arch/arm/mach-omap2/board-zoom-debugboard.c | 160 +++ > arch/arm/mach-omap2/board-zoom2.c| 110 ++ > arch/arm/mach-omap2/mmc-twl4030.c| 280 ++--- > arch/arm/mach-omap2/mmc-twl4030.h|3 > drivers/mmc/host/omap_hsmmc.c|6 > 14 files changed, 3693 insertions(+), 203 deletions(-) > create mode 100644 arch/arm/configs/omap3_evm_defconfig > create mode 100644 arch/arm/configs/omap_zoom2_defconfig > create mode 100644 arch/arm/mach-omap2/board-omap3evm.c > create mode 100644 arch/arm/mach-omap2/board-zoom-debugboard.c > create mode 100644 arch/arm/mach-omap2/board-zoom2.c > > -- > Signature > -- > 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 -- 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
Re: [PATCH] OMAP1: PM: update and decouple from OMAP2/3 PM core
* Kevin Hilman [090527 16:35]: > Update OMAP1-specific PM infrastructure. This is a sync of what is in > linux-omap for OMAP1. > > This mostly de-couples OMAP1 PM from OMAP2/3 PM and renames things > accordingly, and removes omap2/3 specific code from OMAP1 specific > headers. > > Original OMAP1 decoupling patch for OMAP PM branch by Paul Walmsley. Thanks, I've pulled your updated pm-upstream with this into omap for-next branch. Tony > Cc: Paul Walmsley > Signed-off-by: Kevin Hilman > --- > arch/arm/mach-omap1/pm.c | 11 +++-- > arch/arm/mach-omap1/pm.h | 85 > +- > arch/arm/mach-omap1/serial.c |3 - > arch/arm/mach-omap1/sleep.S |2 +- > 4 files changed, 17 insertions(+), 84 deletions(-) > > diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c > index 9774c1f..5218943 100644 > --- a/arch/arm/mach-omap1/pm.c > +++ b/arch/arm/mach-omap1/pm.c > @@ -53,11 +53,12 @@ > #include > #include > #include > -#include > #include > #include > #include > > +#include "pm.h" > + > static unsigned int arm_sleep_save[ARM_SLEEP_SAVE_SIZE]; > static unsigned short dsp_sleep_save[DSP_SLEEP_SAVE_SIZE]; > static unsigned short ulpd_sleep_save[ULPD_SLEEP_SAVE_SIZE]; > @@ -101,7 +102,7 @@ static void (*omap_sram_suspend)(unsigned long r0, > unsigned long r1) = NULL; > * going idle we continue to do idle even if we get > * a clock tick interrupt . . > */ > -void omap_pm_idle(void) > +void omap1_pm_idle(void) > { > extern __u32 arm_idlect1_mask; > __u32 use_idlect1 = arm_idlect1_mask; > @@ -222,7 +223,7 @@ static void omap_pm_wakeup_setup(void) > #define EN_APICK 6 /* ARM_IDLECT2 */ > #define DSP_EN 1 /* ARM_RSTCT1 */ > > -void omap_pm_suspend(void) > +void omap1_pm_suspend(void) > { > unsigned long arg0 = 0, arg1 = 0; > > @@ -610,7 +611,7 @@ static int omap_pm_enter(suspend_state_t state) > { > case PM_SUSPEND_STANDBY: > case PM_SUSPEND_MEM: > - omap_pm_suspend(); > + omap1_pm_suspend(); > break; > default: > return -EINVAL; > @@ -683,7 +684,7 @@ static int __init omap_pm_init(void) > return -ENODEV; > } > > - pm_idle = omap_pm_idle; > + pm_idle = omap1_pm_idle; > > if (cpu_is_omap730()) > setup_irq(INT_730_WAKE_UP_REQ, &omap_wakeup_irq); > diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h > index ce6ee79..9ed5e2c 100644 > --- a/arch/arm/mach-omap1/pm.h > +++ b/arch/arm/mach-omap1/pm.h > @@ -1,7 +1,7 @@ > /* > - * arch/arm/plat-omap/include/mach/pm.h > + * arch/arm/mach-omap1/pm.h > * > - * Header file for OMAP Power Management Routines > + * Header file for OMAP1 Power Management Routines > * > * Author: MontaVista Software, Inc. > * supp...@mvista.com > @@ -31,8 +31,8 @@ > * 675 Mass Ave, Cambridge, MA 02139, USA. > */ > > -#ifndef __ASM_ARCH_OMAP_PM_H > -#define __ASM_ARCH_OMAP_PM_H > +#ifndef __ARCH_ARM_MACH_OMAP1_PM_H > +#define __ARCH_ARM_MACH_OMAP1_PM_H > > /* > * > > @@ -106,8 +106,7 @@ > > #if !defined(CONFIG_ARCH_OMAP730) && \ > !defined(CONFIG_ARCH_OMAP15XX) && \ > - !defined(CONFIG_ARCH_OMAP16XX) && \ > - !defined(CONFIG_ARCH_OMAP24XX) > + !defined(CONFIG_ARCH_OMAP16XX) > #warning "Power management for this processor not implemented yet" > #endif > > @@ -115,29 +114,27 @@ > > #include > > +extern struct kset power_subsys; > + > extern void prevent_idle_sleep(void); > extern void allow_idle_sleep(void); > > -extern void omap_pm_idle(void); > -extern void omap_pm_suspend(void); > +extern void omap1_pm_idle(void); > +extern void omap1_pm_suspend(void); > + > extern void omap730_cpu_suspend(unsigned short, unsigned short); > extern void omap1510_cpu_suspend(unsigned short, unsigned short); > extern void omap1610_cpu_suspend(unsigned short, unsigned short); > -extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl, > - void __iomem *sdrc_power); > extern void omap730_idle_loop_suspend(void); > extern void omap1510_idle_loop_suspend(void); > extern void omap1610_idle_loop_suspend(void); > -extern void omap24xx_idle_loop_suspend(void); > > extern unsigned int omap730_cpu_suspend_sz; > extern unsigned int omap1510_cpu_suspend_sz; > extern unsigned int omap1610_cpu_suspend_sz; > -extern unsigned int omap24xx_cpu_suspend_sz; > extern unsigned int omap730_idle_loop_suspend_sz; > extern unsigned int omap1510_idle_loop_suspend_sz; > extern unsigned int omap1610_idle_loop_suspend_sz; > -extern unsigned int omap24xx_idle_loop_suspend_sz; > > #ifdef CONFIG_OMAP_SERIAL_WAKE > extern void omap_serial_wake_trigger(int enable); > @@ -170,10 +167,6 @@ extern void omap_serial_wake_trigger(int enable); > #define MPUI1610_RES
[PATCH] OMAP1: PM: update and decouple from OMAP2/3 PM core
Update OMAP1-specific PM infrastructure. This is a sync of what is in linux-omap for OMAP1. This mostly de-couples OMAP1 PM from OMAP2/3 PM and renames things accordingly, and removes omap2/3 specific code from OMAP1 specific headers. Original OMAP1 decoupling patch for OMAP PM branch by Paul Walmsley. Cc: Paul Walmsley Signed-off-by: Kevin Hilman --- arch/arm/mach-omap1/pm.c | 11 +++-- arch/arm/mach-omap1/pm.h | 85 +- arch/arm/mach-omap1/serial.c |3 - arch/arm/mach-omap1/sleep.S |2 +- 4 files changed, 17 insertions(+), 84 deletions(-) diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c index 9774c1f..5218943 100644 --- a/arch/arm/mach-omap1/pm.c +++ b/arch/arm/mach-omap1/pm.c @@ -53,11 +53,12 @@ #include #include #include -#include #include #include #include +#include "pm.h" + static unsigned int arm_sleep_save[ARM_SLEEP_SAVE_SIZE]; static unsigned short dsp_sleep_save[DSP_SLEEP_SAVE_SIZE]; static unsigned short ulpd_sleep_save[ULPD_SLEEP_SAVE_SIZE]; @@ -101,7 +102,7 @@ static void (*omap_sram_suspend)(unsigned long r0, unsigned long r1) = NULL; * going idle we continue to do idle even if we get * a clock tick interrupt . . */ -void omap_pm_idle(void) +void omap1_pm_idle(void) { extern __u32 arm_idlect1_mask; __u32 use_idlect1 = arm_idlect1_mask; @@ -222,7 +223,7 @@ static void omap_pm_wakeup_setup(void) #define EN_APICK 6 /* ARM_IDLECT2 */ #define DSP_EN 1 /* ARM_RSTCT1 */ -void omap_pm_suspend(void) +void omap1_pm_suspend(void) { unsigned long arg0 = 0, arg1 = 0; @@ -610,7 +611,7 @@ static int omap_pm_enter(suspend_state_t state) { case PM_SUSPEND_STANDBY: case PM_SUSPEND_MEM: - omap_pm_suspend(); + omap1_pm_suspend(); break; default: return -EINVAL; @@ -683,7 +684,7 @@ static int __init omap_pm_init(void) return -ENODEV; } - pm_idle = omap_pm_idle; + pm_idle = omap1_pm_idle; if (cpu_is_omap730()) setup_irq(INT_730_WAKE_UP_REQ, &omap_wakeup_irq); diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h index ce6ee79..9ed5e2c 100644 --- a/arch/arm/mach-omap1/pm.h +++ b/arch/arm/mach-omap1/pm.h @@ -1,7 +1,7 @@ /* - * arch/arm/plat-omap/include/mach/pm.h + * arch/arm/mach-omap1/pm.h * - * Header file for OMAP Power Management Routines + * Header file for OMAP1 Power Management Routines * * Author: MontaVista Software, Inc. *supp...@mvista.com @@ -31,8 +31,8 @@ * 675 Mass Ave, Cambridge, MA 02139, USA. */ -#ifndef __ASM_ARCH_OMAP_PM_H -#define __ASM_ARCH_OMAP_PM_H +#ifndef __ARCH_ARM_MACH_OMAP1_PM_H +#define __ARCH_ARM_MACH_OMAP1_PM_H /* * @@ -106,8 +106,7 @@ #if !defined(CONFIG_ARCH_OMAP730) && \ !defined(CONFIG_ARCH_OMAP15XX) && \ - !defined(CONFIG_ARCH_OMAP16XX) && \ - !defined(CONFIG_ARCH_OMAP24XX) + !defined(CONFIG_ARCH_OMAP16XX) #warning "Power management for this processor not implemented yet" #endif @@ -115,29 +114,27 @@ #include +extern struct kset power_subsys; + extern void prevent_idle_sleep(void); extern void allow_idle_sleep(void); -extern void omap_pm_idle(void); -extern void omap_pm_suspend(void); +extern void omap1_pm_idle(void); +extern void omap1_pm_suspend(void); + extern void omap730_cpu_suspend(unsigned short, unsigned short); extern void omap1510_cpu_suspend(unsigned short, unsigned short); extern void omap1610_cpu_suspend(unsigned short, unsigned short); -extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl, - void __iomem *sdrc_power); extern void omap730_idle_loop_suspend(void); extern void omap1510_idle_loop_suspend(void); extern void omap1610_idle_loop_suspend(void); -extern void omap24xx_idle_loop_suspend(void); extern unsigned int omap730_cpu_suspend_sz; extern unsigned int omap1510_cpu_suspend_sz; extern unsigned int omap1610_cpu_suspend_sz; -extern unsigned int omap24xx_cpu_suspend_sz; extern unsigned int omap730_idle_loop_suspend_sz; extern unsigned int omap1510_idle_loop_suspend_sz; extern unsigned int omap1610_idle_loop_suspend_sz; -extern unsigned int omap24xx_idle_loop_suspend_sz; #ifdef CONFIG_OMAP_SERIAL_WAKE extern void omap_serial_wake_trigger(int enable); @@ -170,10 +167,6 @@ extern void omap_serial_wake_trigger(int enable); #define MPUI1610_RESTORE(x) omap_writel((mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_##x]), (x)) #define MPUI1610_SHOW(x) mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_##x] -#define OMAP24XX_SAVE(x) omap24xx_sleep_save[OMAP24XX_SLEEP_SAVE_##x] = x -#define OMAP24XX_RESTORE(x) x = omap24xx_sleep_save[OMAP24XX_SLEEP_SAVE_##x] -#define OMAP24XX_SHOW(x) omap24xx_sleep_save[OMAP24XX_SLEEP_SAVE_##x] -
Re: [PATCH] ARM: OMAP3: pandora: add support for mode devices
* Grazvydas Ignotas [090527 12:48]: > Add support for keypad, GPIO keys and LEDs. Also enable hardware > debounce feature for GPIO keys. > > Signed-off-by: Grazvydas Ignotas > --- > This patch was somehow left out, so Tony suggested posting it directly here. Thanks, I've added this patch to my queue. Tony > arch/arm/mach-omap2/board-omap3pandora.c | 149 > ++ > 1 files changed, 149 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-omap3pandora.c > b/arch/arm/mach-omap2/board-omap3pandora.c > index 2ab2497..e32aa23 100644 > --- a/arch/arm/mach-omap2/board-omap3pandora.c > +++ b/arch/arm/mach-omap2/board-omap3pandora.c > @@ -25,6 +25,9 @@ > #include > #include > #include > +#include > +#include > +#include > > #include > #include > @@ -36,12 +39,154 @@ > #include > #include > #include > +#include > > #include "sdram-micron-mt46h32m32lf-6.h" > #include "mmc-twl4030.h" > > #define OMAP3_PANDORA_TS_GPIO94 > > +/* hardware debounce: (value + 1) * 31us */ > +#define GPIO_DEBOUNCE_TIME 127 > + > +static struct gpio_led pandora_gpio_leds[] = { > + { > + .name = "pandora::sd1", > + .default_trigger= "mmc0", > + .gpio = 128, > + }, { > + .name = "pandora::sd2", > + .default_trigger= "mmc1", > + .gpio = 129, > + }, { > + .name = "pandora::bluetooth", > + .gpio = 158, > + }, { > + .name = "pandora::wifi", > + .gpio = 159, > + }, > +}; > + > +static struct gpio_led_platform_data pandora_gpio_led_data = { > + .leds = pandora_gpio_leds, > + .num_leds = ARRAY_SIZE(pandora_gpio_leds), > +}; > + > +static struct platform_device pandora_leds_gpio = { > + .name = "leds-gpio", > + .id = -1, > + .dev= { > + .platform_data = &pandora_gpio_led_data, > + }, > +}; > + > +#define GPIO_BUTTON(gpio_num, ev_type, ev_code, act_low, descr) \ > +{\ > + .gpio = gpio_num, \ > + .type = ev_type, \ > + .code = ev_code, \ > + .active_low = act_low, \ > + .desc = "btn " descr, \ > +} > + > +#define GPIO_BUTTON_LOW(gpio_num, event_code, description) \ > + GPIO_BUTTON(gpio_num, EV_KEY, event_code, 1, description) > + > +static struct gpio_keys_button pandora_gpio_keys[] = { > + GPIO_BUTTON_LOW(110,KEY_UP, "up"), > + GPIO_BUTTON_LOW(103,KEY_DOWN, "down"), > + GPIO_BUTTON_LOW(96, KEY_LEFT, "left"), > + GPIO_BUTTON_LOW(98, KEY_RIGHT, "right"), > + GPIO_BUTTON_LOW(111,BTN_A, "a"), > + GPIO_BUTTON_LOW(106,BTN_B, "b"), > + GPIO_BUTTON_LOW(109,BTN_X, "x"), > + GPIO_BUTTON_LOW(101,BTN_Y, "y"), > + GPIO_BUTTON_LOW(102,BTN_TL, "l"), > + GPIO_BUTTON_LOW(97, BTN_TL2,"l2"), > + GPIO_BUTTON_LOW(105,BTN_TR, "r"), > + GPIO_BUTTON_LOW(107,BTN_TR2,"r2"), > + GPIO_BUTTON_LOW(104,KEY_LEFTCTRL, "ctrl"), > + GPIO_BUTTON_LOW(99, KEY_MENU, "menu"), > + GPIO_BUTTON_LOW(176,KEY_COFFEE, "hold"), > + GPIO_BUTTON(100, EV_KEY, KEY_LEFTALT, 0, "alt"), > + GPIO_BUTTON(108, EV_SW, SW_LID, 1, "lid"), > +}; > + > +static struct gpio_keys_platform_data pandora_gpio_key_info = { > + .buttons= pandora_gpio_keys, > + .nbuttons = ARRAY_SIZE(pandora_gpio_keys), > +}; > + > +static struct platform_device pandora_keys_gpio = { > + .name = "gpio-keys", > + .id = -1, > + .dev= { > + .platform_data = &pandora_gpio_key_info, > + }, > +}; > + > +static void __init pandora_keys_gpio_init(void) > +{ > + /* set debounce time for GPIO banks 4 and 6 */ > + omap_set_gpio_debounce_time(32 * 3, GPIO_DEBOUNCE_TIME); > + omap_set_gpio_debounce_time(32 * 5, GPIO_DEBOUNCE_TIME); > +} > + > +static int pandora_keypad_map[] = { > + /* col, row, code */ > + KEY(0, 0, KEY_9), > + KEY(0, 1, KEY_0), > + KEY(0, 2, KEY_BACKSPACE), > + KEY(0, 3, KEY_O), > + KEY(0, 4, KEY_P), > + KEY(0, 5, KEY_K), > + KEY(0, 6, KEY_L), > + KEY(0, 7, KEY_ENTER), > + KEY(1, 0, KEY_8), > + KEY(1, 1, KEY_7), > + KEY(1, 2, KEY_6), > + KEY(1, 3, KEY_5), > + KEY(1, 4, KEY_4), > + KEY(1, 5, KEY_3), > + KEY(1, 6, KEY_2), > + KEY(1, 7, KEY_1), > + KEY(2, 0, KEY_I), > + KEY(2, 1, KEY_U), > + KEY(2, 2, KEY_Y), > + KEY(2
[PATCH] ARM: OMAP3: pandora: add support for mode devices
Add support for keypad, GPIO keys and LEDs. Also enable hardware debounce feature for GPIO keys. Signed-off-by: Grazvydas Ignotas --- This patch was somehow left out, so Tony suggested posting it directly here. arch/arm/mach-omap2/board-omap3pandora.c | 149 ++ 1 files changed, 149 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c index 2ab2497..e32aa23 100644 --- a/arch/arm/mach-omap2/board-omap3pandora.c +++ b/arch/arm/mach-omap2/board-omap3pandora.c @@ -25,6 +25,9 @@ #include #include #include +#include +#include +#include #include #include @@ -36,12 +39,154 @@ #include #include #include +#include #include "sdram-micron-mt46h32m32lf-6.h" #include "mmc-twl4030.h" #define OMAP3_PANDORA_TS_GPIO 94 +/* hardware debounce: (value + 1) * 31us */ +#define GPIO_DEBOUNCE_TIME 127 + +static struct gpio_led pandora_gpio_leds[] = { + { + .name = "pandora::sd1", + .default_trigger= "mmc0", + .gpio = 128, + }, { + .name = "pandora::sd2", + .default_trigger= "mmc1", + .gpio = 129, + }, { + .name = "pandora::bluetooth", + .gpio = 158, + }, { + .name = "pandora::wifi", + .gpio = 159, + }, +}; + +static struct gpio_led_platform_data pandora_gpio_led_data = { + .leds = pandora_gpio_leds, + .num_leds = ARRAY_SIZE(pandora_gpio_leds), +}; + +static struct platform_device pandora_leds_gpio = { + .name = "leds-gpio", + .id = -1, + .dev= { + .platform_data = &pandora_gpio_led_data, + }, +}; + +#define GPIO_BUTTON(gpio_num, ev_type, ev_code, act_low, descr)\ +{ \ + .gpio = gpio_num, \ + .type = ev_type, \ + .code = ev_code, \ + .active_low = act_low, \ + .desc = "btn " descr, \ +} + +#define GPIO_BUTTON_LOW(gpio_num, event_code, description) \ + GPIO_BUTTON(gpio_num, EV_KEY, event_code, 1, description) + +static struct gpio_keys_button pandora_gpio_keys[] = { + GPIO_BUTTON_LOW(110,KEY_UP, "up"), + GPIO_BUTTON_LOW(103,KEY_DOWN, "down"), + GPIO_BUTTON_LOW(96, KEY_LEFT, "left"), + GPIO_BUTTON_LOW(98, KEY_RIGHT, "right"), + GPIO_BUTTON_LOW(111,BTN_A, "a"), + GPIO_BUTTON_LOW(106,BTN_B, "b"), + GPIO_BUTTON_LOW(109,BTN_X, "x"), + GPIO_BUTTON_LOW(101,BTN_Y, "y"), + GPIO_BUTTON_LOW(102,BTN_TL, "l"), + GPIO_BUTTON_LOW(97, BTN_TL2,"l2"), + GPIO_BUTTON_LOW(105,BTN_TR, "r"), + GPIO_BUTTON_LOW(107,BTN_TR2,"r2"), + GPIO_BUTTON_LOW(104,KEY_LEFTCTRL, "ctrl"), + GPIO_BUTTON_LOW(99, KEY_MENU, "menu"), + GPIO_BUTTON_LOW(176,KEY_COFFEE, "hold"), + GPIO_BUTTON(100, EV_KEY, KEY_LEFTALT, 0, "alt"), + GPIO_BUTTON(108, EV_SW, SW_LID, 1, "lid"), +}; + +static struct gpio_keys_platform_data pandora_gpio_key_info = { + .buttons= pandora_gpio_keys, + .nbuttons = ARRAY_SIZE(pandora_gpio_keys), +}; + +static struct platform_device pandora_keys_gpio = { + .name = "gpio-keys", + .id = -1, + .dev= { + .platform_data = &pandora_gpio_key_info, + }, +}; + +static void __init pandora_keys_gpio_init(void) +{ + /* set debounce time for GPIO banks 4 and 6 */ + omap_set_gpio_debounce_time(32 * 3, GPIO_DEBOUNCE_TIME); + omap_set_gpio_debounce_time(32 * 5, GPIO_DEBOUNCE_TIME); +} + +static int pandora_keypad_map[] = { + /* col, row, code */ + KEY(0, 0, KEY_9), + KEY(0, 1, KEY_0), + KEY(0, 2, KEY_BACKSPACE), + KEY(0, 3, KEY_O), + KEY(0, 4, KEY_P), + KEY(0, 5, KEY_K), + KEY(0, 6, KEY_L), + KEY(0, 7, KEY_ENTER), + KEY(1, 0, KEY_8), + KEY(1, 1, KEY_7), + KEY(1, 2, KEY_6), + KEY(1, 3, KEY_5), + KEY(1, 4, KEY_4), + KEY(1, 5, KEY_3), + KEY(1, 6, KEY_2), + KEY(1, 7, KEY_1), + KEY(2, 0, KEY_I), + KEY(2, 1, KEY_U), + KEY(2, 2, KEY_Y), + KEY(2, 3, KEY_T), + KEY(2, 4, KEY_R), + KEY(2, 5, KEY_E), + KEY(2, 6, KEY_W), + KEY(2, 7, KEY_Q), + KEY(3, 0, KEY_J), + KEY(3, 1, KEY_H), + KEY(3, 2, KEY_G), + KEY(3, 3, KEY_F), +
Re: Touchscreen getting stuck on resume or blanking briefly
Hi, A quick update, I've been informed that DSS2 does not support off mode. So perhaps if someone has a solution as to why the GPIO Led that is connected to the system heartbeat varies upon resume, it would be one small step towarding fixing these issues. Also, application of the full set of pm patches (191 in total) renders my touchscreen inoperable. Any ideas why that might happen? Best regards, Elvis -- 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
Touchscreen getting stuck on resume or blanking briefly
Hi, Is there a fix for the touchscreen getting stuck on resume or going back to resume if you touch the screen lightly? I am using a gumstix overo earth (TI OMAP 3503) with the gumstix Palo43 board which has a Samsung LCD display connected, and it uses an ADS7846 touchscreen controller. I have a situation where the screen goes to suspend mode, and if I press the touchscreen once it briefly comes on and goes back to suspend mode. Now two things can happen at this stage. a. if you leave it to go off for just a second, and touch the screen lightly, it will come out of suspend and go back into suspend. So, a brief light touch is not enough to bring it out of suspend mode. b. if you leave it off for more than 15 second, the system briefly comes on, blanks out once, and if you touch it once mode, comes out of suspend. the GPIO Led connected to the heartbeat, beats normally, something like a human heart lub-dub pace. :-) In all this, once in a while, the system doesn't wake up at all a and the touchscreen input doesnt work at all and the system is un-usable, and gets stuck completely. Sometime, if it comes back on, the system heartbeat beats at a much faster pace, after coming out of suspend mode. Has anyone else noticed this type of behavior and is there a patch available to fix it? Best regards, Elvis -- 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
Re: Gumstix Overo Low Power Standby?
On May 27, 2009, at 2:59 PM, Dirk Behme wrote: Blazej Kot wrote: Thanks for that, it is an interesting link. I have now reached the new low of around 170mW (at 3.28V), but this is high. I basically used the TWL (PMC) scripts in the linked post, and also turned off the U6 chip on the gumstix, which is the USB PHY layer driver. Also, I noticed that my systems becomes unusable after suspending for more than abut a minute, and it will not wake from sleep. I will try to troubleshot and narrow this down. I think to remember there was some discussion about SDRAM self refresh. Look for thread "OMAP3: PM: SDRC: ensure mux of SDRC clock enable pins for self-refresh" and http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=commit;h=4025cfbde3611b14c0d4831a5524e5e061128e30 Just guessing, though. Dirk Yes, you are quite right. Kevin Hilman pointed out the patch [1] to me, I just applied it and suspend/resume works for at least 5-10 minutes. I'll try it overnight next :) One small thing is I had to manually insert and include for mach/ mux.c to the top of sdrc.c for it to compile. Thanks! Blazej PS: I'm now down to 141mW in suspend :) I know a lot of the rest must be getting used up in the TPS/TWL PM chip, as it is slightly warm to the touch while the OMAP/RAM stack and the only other chip on the overo, the USB PHY chip, are stone cold to the touch. [1] http://marc.info/?l=linux-omap&m=124283570910883&w=2 -- 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
Re: Gumstix Overo Low Power Standby?
Blazej Kot wrote: On May 20, 2009, at 1:55 PM, Kevin Hilman wrote: Kevin Hilman writes: Blazej Kot writes: I have been working with the linux-pm kernel on the Gumstix Overo, seeing how low it's power consumption can go, both during the cpu "on" and especially while the CPU is suspended. Thus far, I've had some disappointing results, the best I could get is about 500mW while on, and 250mW while suspended (ie by running "echo mem > /sys/power/ state"). I am led to believe that the OMAP processor is capable of much lower power consumption during standby. I am wondering if anybody in the gumstix community is looking into the software support for very-low-power modes on the overo. If so, I am wondering what the lowest power levels are which you have reached during standby are. I have seen this: http://markmail.org/message/ge5hec5f5asp7a67#query:omap%20linux %2080%20ma+page:1+mid:t2erlwweknakm767+state:results Which seems to indicate the lowest power reached is 80mA at 3.3V -> 0.264 W, which is about what I'm seeing. Is it really true that the overo draws a quarter of a watt when doing absolutely nothing? There are lots of factors involved. The current OMAP PM branch is focused on minimizing power consumed by the OMAP SoC itself. However, there are lots of other things on-board (audio codecs, regulators, WiFi chipsets etc.) that can consume power that we may not be currently managing in the omap kernel. I don't have an Overo so am not familiar with all the on board peripherals, but you should probably do some experiments where you can put all the on-board devices into low-power/off states and run some experiments as well. In the case of the Beagle results you referenced, I'm pretty sure it is something on board that is drawing the ~80mA and not on-chip. I assume this because setting the OMAP to use OFF-mode in suspend or idle results in the drop of a few mA reflecting an expected drop in power consumed by OMAP itself, but still leaving lots of power consumed. For example, testing today's PM branch on Beagle gives me roughly the same numbers as the post you referenced, but slightly better: - boot idle: 323 mA - screen blank: 216 mA # echo 3 > /sys/class/graphics/fb0/blank - suspend (OMAP retention): 75 mA # echo mem > /sys/power/state - sleep-while-idle: 75 mA - this same power state as suspend, but happens in idle # echo 1 > /sys/power/sleep_while_idle - suspend (OMAP off): 72 mA # echo 1 > /sys/power/enable_off_mode # echo 1 > /sys/power/voltage_off_while_idle Ultimitately the answer is that more work needs to be done with the using the regulator framework and/or the drivers for the on-chip peripherals to be sure they can be powered off when needed. After digging a little more in the beagle forums, someone has already done the work to confirm that it is indeed board level design and issues that are drawing the rest of the power on Beagle. There's a thread[1] in the beagleboard list about how to get down to 8mW power on Beagle, but it does require hardware changes. This should shed some light on the types of things you'd probably have to do for Overo. Kevin [1] http://groups.google.com/group/beagleboard/browse_thread/thread/197a8ef6b46cc828/6e98db4cbe2cebaa?# Thanks for that, it is an interesting link. I have now reached the new low of around 170mW (at 3.28V), but this is high. I basically used the TWL (PMC) scripts in the linked post, and also turned off the U6 chip on the gumstix, which is the USB PHY layer driver. Also, I noticed that my systems becomes unusable after suspending for more than abut a minute, and it will not wake from sleep. I will try to troubleshot and narrow this down. I think to remember there was some discussion about SDRAM self refresh. Look for thread "OMAP3: PM: SDRC: ensure mux of SDRC clock enable pins for self-refresh" and http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=commit;h=4025cfbde3611b14c0d4831a5524e5e061128e30 Just guessing, though. Dirk I am wondering, is there anyone out there working on PM issues on the Gumstix? Perhaps if there are some gumstix company people here they can answer what their status is. I will ask around on the gumstix emailing list also. thanks, Blazej -- 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 -- 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
Re: Please help in adding ams-delta support to ASoC
Hi, Tired with hopeless looking for the correct mcbsp dai format, I took the oposite direciton, trying to break what Mark Underwood had managed to get working. Step by step, I got to exactly the same mcbsp register configuration as used in the reference osk board, reverting all changes that Mark could introduce, and the driver still worked as before. So it looks like playing with mcbsp dai format is not the way to solve the problem. Wednesday 27 May 2009 07:57:27 Peter Ujfalusi wrote: > This means that the McBSP module is not transmitting/receiving any data. > Which suggests that the clocking is not working in your setup. Check the > slave master mode for the codec. Now I think I understand better what you mean. However, I don't know any way of configuring the codec except for switching its pin connections from msbcp to modem chip and back. I can find nothing relevant in the original patch that could help. > Also worth checking the PIN configuration for the McBSP1 module, just in > case it is correct. Wednesday 27 May 2009 08:59:49 Jarkko Nikula wrote: > Looks like McBSP is not getting bit-clock and frame-sync signals from > the codec. Do you have any way to measure is the codec sending those? > > Another possibility are the OMAP pins muxed for McBSP? I assume they > are if the bootloader is still the same but worth to find check was > previous kernel doing any runtime remuxing for those pins with > omap_cfg_reg calls. So I am going to restart with checking if the original patch still works with the latest kernel version supporting omap-alsa. Thanks for your help so far. Any hints are still welcome. Cheers, Janusz -- 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
Re: [PATCH 0/4]ARM: OMAP4: SMP: Patch series
* Shilimkar, Santosh [090527 09:22]: > Russell, > I have rebased this series on top of your arm-smp patches and my earlier > basic omap4 patches. > Series is based of kernel.org 2.6.30-rc6 ( > commit:1406de8e11eb043681297adf86d6892ff8efc27a). This series have dependency > on [1],[2],[3],[4] and latest mach-types > > The series contains: > [PATCH 1/4] ARM: OMAP4: SMP: Add OMAP4430 SMP board files > [PATCH 2/4] ARM: OMAP4: SMP: Add mpu timer support for OMAP4430 > [PATCH 3/4] ARM: OMAP4: SMP: Enable SMP support for OMAP4430 > [PATCH 4/4] ARM: OMAP4: SMP: Update defconfig for OMAP4430 > > Regards, > Santosh > > [1]: Russell's arm-smp patch series + one of my patch > http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/arm:smp.diff > > [2]: Tony's : [PATCH 0/5] More header clean-up > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12231.html > > [3]: Mine [PATCH 0/4] OMAP: Cleanup series. > > http://lists.arm.linux.org.uk/lurker/message/20090519.131647.c2c471ef.en.html > > [4]: Mine [PATCH 0/4] ARM: OMPA4: Basic boot patch series based on linux-omap > > http://lists.arm.linux.org.uk/lurker/message/20090520.125900.9209eb81.en.html Just to summarize, I have pretty much things ready for Russell to merge for all the posted omap stuff. That includes sets 2 + 3 + 4 above, but not this series. That should remove any remaining merge dependencies for this series. 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.org/majordomo-info.html
Re: [PATCH][RFC] OMAP4: McSPI Register Offset Changes For OMAP_4430SDP
"Syed Rafiuddin" writes: > This patch updates McSPI register offset addresses with respect to OMAP4 > > Signed-off-by: Syed Rafiuddin > --- > arch/arm/mach-omap2/devices.c | 10 > drivers/spi/omap2_mcspi.c | 51 > -- > 2 files changed, 41 insertions(+), 20 deletions(-) > > Index: omap4_dev/arch/arm/mach-omap2/devices.c > === > --- omap4_dev.orig/arch/arm/mach-omap2/devices.c > +++ omap4_dev/arch/arm/mach-omap2/devices.c > @@ -301,7 +301,8 @@ static struct platform_device omap2_mcsp > }, > }; > > -#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) > +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \ > +defined(CONFIG_ARCH_OMAP4) > static struct omap2_mcspi_platform_config omap2_mcspi3_config = { > .num_cs = 2, > }; > @@ -325,7 +326,7 @@ static struct platform_device omap2_mcsp > }; > #endif > > -#ifdef CONFIG_ARCH_OMAP3 > +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) > static struct omap2_mcspi_platform_config omap2_mcspi4_config = { > .num_cs = 1, > }; > @@ -353,10 +354,11 @@ static void omap_init_mcspi(void) > { > platform_device_register(&omap2_mcspi1); > platform_device_register(&omap2_mcspi2); > -#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) > +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \ > +defined(CONFIG_ARCH_OMAP4) > platform_device_register(&omap2_mcspi3); > #endif > -#ifdef CONFIG_ARCH_OMAP3 > +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) > platform_device_register(&omap2_mcspi4); > #endif > } > Index: omap4_dev/drivers/spi/omap2_mcspi.c > === > --- omap4_dev.orig/drivers/spi/omap2_mcspi.c > +++ omap4_dev/drivers/spi/omap2_mcspi.c > @@ -42,21 +42,38 @@ > #define OMAP2_MCSPI_MAX_FREQ 4800 > > #define OMAP2_MCSPI_REVISION 0x00 > -#define OMAP2_MCSPI_SYSCONFIG0x10 > -#define OMAP2_MCSPI_SYSSTATUS0x14 > -#define OMAP2_MCSPI_IRQSTATUS0x18 > -#define OMAP2_MCSPI_IRQENABLE0x1c > -#define OMAP2_MCSPI_WAKEUPENABLE 0x20 > -#define OMAP2_MCSPI_SYST 0x24 > -#define OMAP2_MCSPI_MODULCTRL0x28 > +#ifdef CONFIG_ARCH_OMAP4 Why do you need an #ifdef for OMAP4. This breaks multi-omap. > +#define OMAP2_MCSPI_SYSCONFIG0x110 > +#define OMAP2_MCSPI_SYSSTATUS0x114 > +#define OMAP2_MCSPI_IRQSTATUS0x118 > +#define OMAP2_MCSPI_IRQENABLE0x11c > +#define OMAP2_MCSPI_WAKEUPENABLE 0x120 > +#define OMAP2_MCSPI_SYST 0x124 > +#define OMAP2_MCSPI_MODULCTRL0x128 Looking closer, these are all the same register offsets as OMAP2/3, except you are adding 0x100. Instead of changing these register defines, you should just be updating the base address for OMAP4. The rest of the patch suggests that this is indeed an identical HW block to what is on OMAP2/3. Kevin > /* per-channel banks, 0x14 bytes each, first is: */ > -#define OMAP2_MCSPI_CHCONF0 0x2c > -#define OMAP2_MCSPI_CHSTAT0 0x30 > -#define OMAP2_MCSPI_CHCTRL0 0x34 > -#define OMAP2_MCSPI_TX0 0x38 > -#define OMAP2_MCSPI_RX0 0x3c > +#define OMAP2_MCSPI_CHCONF0 0x12c > +#define OMAP2_MCSPI_CHSTAT0 0x130 > +#define OMAP2_MCSPI_CHCTRL0 0x134 > +#define OMAP2_MCSPI_TX0 0x138 > +#define OMAP2_MCSPI_RX0 0x13c > +#else > +#define OMAP2_MCSPI_REVISION0x00 > +#define OMAP2_MCSPI_SYSCONFIG 0x10 > +#define OMAP2_MCSPI_SYSSTATUS 0x14 > +#define OMAP2_MCSPI_IRQSTATUS 0x18 > +#define OMAP2_MCSPI_IRQENABLE 0x1c > +#define OMAP2_MCSPI_WAKEUPENABLE0x20 > +#define OMAP2_MCSPI_SYST0x24 > +#define OMAP2_MCSPI_MODULCTRL 0x28 > > +/* per-channel banks, 0x14 bytes each, first is: */ > +#define OMAP2_MCSPI_CHCONF0 0x2c > +#define OMAP2_MCSPI_CHSTAT0 0x30 > +#define OMAP2_MCSPI_CHCTRL0 0x34 > +#define OMAP2_MCSPI_TX0 0x38 > +#define OMAP2_MCSPI_RX0 0x3c > +#endif > /* per-register bitmasks: */ > > #define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 << 0) > @@ -918,7 +935,8 @@ static u8 __initdata spi2_txdma_id[] = { > OMAP24XX_DMA_SPI2_TX1, > }; > > -#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX) > +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX) ||\ > +defined(CONFIG_ARCH_OMAP44XX) > static u8 __initdata spi3_rxdma_id[] = { > OMAP24XX_DMA_SPI3_RX0, > OMAP24XX_DMA_SPI3_RX1, > @@ -930,7 +948,7 @@ static u8 __initdata spi3_txdma_id[] = { > }; > #endif > > -#ifdef CONFIG_ARCH_OMAP3 > +#if def
Re: [PATCH 1/8] ARM: OMAP3: mmc-twl4030 uses regulator framework, v2
* Daniel Ribeiro [090525 15:47]: > Em Seg, 2009-05-25 às 10:48 -0700, Tony Lindgren escreveu: > > + /* UGLY HACK: workaround regulator framework bugs. > > +* When the bootloader leaves a supply active, it's > > +* initialized with zero usecount ... and we can't > > +* disable it without first disabling it. Until the > > +* framework is fixed, we need a workaround like this > > +* (which is safe for MMC, but not in general). > > +*/ > > + if (regulator_is_enabled(hsmmc[i].vcc) > 0) { > > + regulator_enable(hsmmc[i].vcc); > > + regulator_disable(hsmmc[i].vcc); > > + } > > + if (hsmmc[i].vcc_aux) { > > + if (regulator_is_enabled(reg) > 0) { > > + regulator_enable(reg); > > + regulator_disable(reg); > > + } > > + } > > + > > This hack would look less ugly on twl4030reg_probe(). There you can > disable the regulator without first enabling it. Based on Mark's comments let's do that with machine constraints later on. > (btw, there is a typo in the comment: "disable it without first > disabling it"). Thanks, updated patch below. Tony >From 354cb21a0267230f27d60e1d2b054275274e6dd9 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Mon, 25 May 2009 11:09:04 -0700 Subject: [PATCH] ARM: OMAP3: mmc-twl4030 uses regulator framework Decouple the HSMMC glue from the twl4030 as the only regulator provider, using the regulator framework instead. This makes the glue's "mmc-twl4030" name become a complete misnomer ... this code could probably all migrate into the HSMMC driver now. Tested on 3430SDP (SD and low-voltage MMC) and Beagle (SD), plus some other boards (including Overo) after they were converted to set up MMC regulators properly. Eventually all boards should just associate a regulator with each MMC controller they use. In some cases (Overo MMC2 and Pandora MMC3, at least) that would be a fixed-voltage regulator with no real software control. As a temporary hack (pending regulator-next updates to make the "fixed.c" regulator become usable) there's a new ocr_mask field for those boards. Patch updated with a fix for disabling vcc_aux by Adrian Hunter Cc: Pierre Ossman Signed-off-by: David Brownell Signed-off-by: Tony Lindgren diff --git a/arch/arm/mach-omap2/mmc-twl4030.c b/arch/arm/mach-omap2/mmc-twl4030.c index dc40b3e..9756a87 100644 --- a/arch/arm/mach-omap2/mmc-twl4030.c +++ b/arch/arm/mach-omap2/mmc-twl4030.c @@ -16,8 +16,8 @@ #include #include #include -#include -#include +#include +#include #include #include @@ -26,31 +26,9 @@ #include "mmc-twl4030.h" -#if defined(CONFIG_TWL4030_CORE) && \ - (defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)) -#define LDO_CLR 0x00 -#define VSEL_S2_CLR 0x40 - -#define VMMC1_DEV_GRP 0x27 -#define VMMC1_CLR 0x00 -#define VMMC1_315V 0x03 -#define VMMC1_300V 0x02 -#define VMMC1_285V 0x01 -#define VMMC1_185V 0x00 -#define VMMC1_DEDICATED 0x2A - -#define VMMC2_DEV_GRP 0x2B -#define VMMC2_CLR 0x40 -#define VMMC2_315V 0x0c -#define VMMC2_300V 0x0b -#define VMMC2_285V 0x0a -#define VMMC2_280V 0x09 -#define VMMC2_260V 0x08 -#define VMMC2_185V 0x06 -#define VMMC2_DEDICATED 0x2E - -#define VMMC_DEV_GRP_P1 0x20 +#if defined(CONFIG_REGULATOR) && \ + (defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)) static u16 control_pbias_offset; static u16 control_devconf1_offset; @@ -59,19 +37,16 @@ static u16 control_devconf1_offset; static struct twl_mmc_controller { struct omap_mmc_platform_data *mmc; - u8 twl_vmmc_dev_grp; - u8 twl_mmc_dedicated; - char name[HSMMC_NAME_LEN + 1]; -} hsmmc[OMAP34XX_NR_MMC] = { - { - .twl_vmmc_dev_grp = VMMC1_DEV_GRP, - .twl_mmc_dedicated = VMMC1_DEDICATED, - }, - { - .twl_vmmc_dev_grp = VMMC2_DEV_GRP, - .twl_mmc_dedicated = VMMC2_DEDICATED, - }, -}; + /* Vcc == configured supply + * Vcc_alt == optional + * - MMC1, supply for DAT4..DAT7 + * - MMC2/MMC2, external level shifter voltage supply, for + * chip (SDIO, eMMC, etc) or transceiver (MMC2 only) + */ + struct regulator *vcc; + struct regulator *vcc_aux; + charname[HSMMC_NAME_LEN + 1]; +} hsmmc[OMAP34XX_NR_MMC]; static int twl_mmc_card_detect(int irq) { @@ -117,16 +92,60 @@ static int twl_mmc_late_init(struct device *dev) int ret = 0; int i; - ret = gpio_request(mmc->slots[0].switch_pin, "mmc_cd"); - if (ret) - goto done; - ret = gpio_direction_input(mmc->slots[0].switch_pin); - if (ret) - goto err; + /* MMC/SD/SDIO doesn't require a card detect switch */ + if (gpio_is_valid(mmc->slots[0].switch_pin)) { + ret = gpio_request(mmc->slots[0].switch_pin, "mmc_cd"); + if (ret) + goto done; + ret = gpio
[PATCH][RFC] OMAP4: McSPI Register Offset Changes For OMAP_4430SDP
This patch updates McSPI register offset addresses with respect to OMAP4 Signed-off-by: Syed Rafiuddin --- arch/arm/mach-omap2/devices.c | 10 drivers/spi/omap2_mcspi.c | 51 -- 2 files changed, 41 insertions(+), 20 deletions(-) Index: omap4_dev/arch/arm/mach-omap2/devices.c === --- omap4_dev.orig/arch/arm/mach-omap2/devices.c +++ omap4_dev/arch/arm/mach-omap2/devices.c @@ -301,7 +301,8 @@ static struct platform_device omap2_mcsp }, }; -#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \ +defined(CONFIG_ARCH_OMAP4) static struct omap2_mcspi_platform_config omap2_mcspi3_config = { .num_cs = 2, }; @@ -325,7 +326,7 @@ static struct platform_device omap2_mcsp }; #endif -#ifdef CONFIG_ARCH_OMAP3 +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) static struct omap2_mcspi_platform_config omap2_mcspi4_config = { .num_cs = 1, }; @@ -353,10 +354,11 @@ static void omap_init_mcspi(void) { platform_device_register(&omap2_mcspi1); platform_device_register(&omap2_mcspi2); -#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \ +defined(CONFIG_ARCH_OMAP4) platform_device_register(&omap2_mcspi3); #endif -#ifdef CONFIG_ARCH_OMAP3 +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) platform_device_register(&omap2_mcspi4); #endif } Index: omap4_dev/drivers/spi/omap2_mcspi.c === --- omap4_dev.orig/drivers/spi/omap2_mcspi.c +++ omap4_dev/drivers/spi/omap2_mcspi.c @@ -42,21 +42,38 @@ #define OMAP2_MCSPI_MAX_FREQ 4800 #define OMAP2_MCSPI_REVISION 0x00 -#define OMAP2_MCSPI_SYSCONFIG 0x10 -#define OMAP2_MCSPI_SYSSTATUS 0x14 -#define OMAP2_MCSPI_IRQSTATUS 0x18 -#define OMAP2_MCSPI_IRQENABLE 0x1c -#define OMAP2_MCSPI_WAKEUPENABLE 0x20 -#define OMAP2_MCSPI_SYST 0x24 -#define OMAP2_MCSPI_MODULCTRL 0x28 +#ifdef CONFIG_ARCH_OMAP4 +#define OMAP2_MCSPI_SYSCONFIG 0x110 +#define OMAP2_MCSPI_SYSSTATUS 0x114 +#define OMAP2_MCSPI_IRQSTATUS 0x118 +#define OMAP2_MCSPI_IRQENABLE 0x11c +#define OMAP2_MCSPI_WAKEUPENABLE 0x120 +#define OMAP2_MCSPI_SYST 0x124 +#define OMAP2_MCSPI_MODULCTRL 0x128 /* per-channel banks, 0x14 bytes each, first is: */ -#define OMAP2_MCSPI_CHCONF00x2c -#define OMAP2_MCSPI_CHSTAT00x30 -#define OMAP2_MCSPI_CHCTRL00x34 -#define OMAP2_MCSPI_TX00x38 -#define OMAP2_MCSPI_RX00x3c +#define OMAP2_MCSPI_CHCONF00x12c +#define OMAP2_MCSPI_CHSTAT00x130 +#define OMAP2_MCSPI_CHCTRL00x134 +#define OMAP2_MCSPI_TX00x138 +#define OMAP2_MCSPI_RX00x13c +#else +#define OMAP2_MCSPI_REVISION0x00 +#define OMAP2_MCSPI_SYSCONFIG 0x10 +#define OMAP2_MCSPI_SYSSTATUS 0x14 +#define OMAP2_MCSPI_IRQSTATUS 0x18 +#define OMAP2_MCSPI_IRQENABLE 0x1c +#define OMAP2_MCSPI_WAKEUPENABLE0x20 +#define OMAP2_MCSPI_SYST0x24 +#define OMAP2_MCSPI_MODULCTRL 0x28 +/* per-channel banks, 0x14 bytes each, first is: */ +#define OMAP2_MCSPI_CHCONF0 0x2c +#define OMAP2_MCSPI_CHSTAT0 0x30 +#define OMAP2_MCSPI_CHCTRL0 0x34 +#define OMAP2_MCSPI_TX0 0x38 +#define OMAP2_MCSPI_RX0 0x3c +#endif /* per-register bitmasks: */ #define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 << 0) @@ -918,7 +935,8 @@ static u8 __initdata spi2_txdma_id[] = { OMAP24XX_DMA_SPI2_TX1, }; -#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX) +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX) ||\ +defined(CONFIG_ARCH_OMAP44XX) static u8 __initdata spi3_rxdma_id[] = { OMAP24XX_DMA_SPI3_RX0, OMAP24XX_DMA_SPI3_RX1, @@ -930,7 +948,7 @@ static u8 __initdata spi3_txdma_id[] = { }; #endif -#ifdef CONFIG_ARCH_OMAP3 +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) static u8 __initdata spi4_rxdma_id[] = { OMAP34XX_DMA_SPI4_RX0, }; @@ -960,14 +978,15 @@ static int __init omap2_mcspi_probe(stru txdma_id = spi2_txdma_id; num_chipselect = 2; break; -#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) ||\ +defined(CONFIG_ARCH_OMAP4) case 3: rxdma_id = spi3_rxdma_id; txdma_id = spi3_txdma_id; num_chipselect = 2; break; #endif -#ifdef
[PATCH 4/4] ARM: OMAP4: SMP: Update defconfig for OMAP4430
This patch updates omap_4430sdp_defconfig to add SMP and LOCAL_TIMER support for OMAP4430 SDP platform. Signed-off-by: Santosh Shilimkar --- arch/arm/configs/omap_4430sdp_defconfig |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 67a3a77..99c5d1a 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -30,7 +30,7 @@ CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # General setup # CONFIG_EXPERIMENTAL=y -CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y @@ -104,6 +104,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set @@ -244,6 +245,9 @@ CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_LOCAL_TIMERS=y # CONFIG_PREEMPT is not set CONFIG_HZ=128 CONFIG_AEABI=y @@ -695,6 +699,7 @@ CONFIG_HAVE_FUNCTION_TRACER=y # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set +# CONFIG_ARM_UNWIND is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_ERRORS is not set # CONFIG_DEBUG_STACK_USAGE is not set -- 1.5.4.7 -- 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
[PATCH 4/5] ARM: OMAP4: SMP: Update defconfig for OMAP4430
This patch updates omap_4430sdp_defconfig to add SMP and LOCAL_TIMER support for OMAP4430 SDP platform. Signed-off-by: Santosh Shilimkar --- arch/arm/configs/omap_4430sdp_defconfig |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 67a3a77..99c5d1a 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -30,7 +30,7 @@ CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # General setup # CONFIG_EXPERIMENTAL=y -CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y @@ -104,6 +104,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set @@ -244,6 +245,9 @@ CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_LOCAL_TIMERS=y # CONFIG_PREEMPT is not set CONFIG_HZ=128 CONFIG_AEABI=y @@ -695,6 +699,7 @@ CONFIG_HAVE_FUNCTION_TRACER=y # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set +# CONFIG_ARM_UNWIND is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_ERRORS is not set # CONFIG_DEBUG_STACK_USAGE is not set -- 1.5.4.7 -- 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
[PATCH 1/4] ARM: OMAP4: SMP: Add OMAP4430 SMP board files
This patch adds SMP platform files support for OMAP4430SDP. TI's OMAP4430 SOC is based on ARM Cortex-A9 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and SCU for cache coherency. Signed-off-by: Santosh Shilimkar --- arch/arm/mach-omap2/omap-headsmp.S| 46 + arch/arm/mach-omap2/omap-smp.c| 178 + arch/arm/plat-omap/include/mach/smp.h | 51 ++ 3 files changed, 275 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/omap-headsmp.S create mode 100644 arch/arm/mach-omap2/omap-smp.c create mode 100644 arch/arm/plat-omap/include/mach/smp.h diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S new file mode 100644 index 000..4afadba --- /dev/null +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -0,0 +1,46 @@ +/* + * Secondary CPU startup routine source file. + * + * Copyright (C) 2009 Texas Instruments, Inc. + * + * Author: + * Santosh Shilimkar + * + * Interface functions needed for the SMP. This file is based on arm + * realview smp platform. + * Copyright (c) 2003 ARM Limited. + * + * This program is free software,you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include + +/* Physical address needed since MMU not enabled yet on secondary core */ +#define OMAP4_AUX_CORE_BOOT1_PA0x48281804 + + __INIT + +/* + * OMAP4 specific entry point for secondary CPU to jump from ROM + * code. This routine also provides a holding flag into which + * secondary core is held until we're ready for it to initialise. + * The primary core will update the this flag using a hardware + * register AuxCoreBoot1. + */ +ENTRY(omap_secondary_startup) + mrc p15, 0, r0, c0, c0, 5 + and r0, r0, #0x0f +hold: ldr r1, =OMAP4_AUX_CORE_BOOT1_PA@ read from AuxCoreBoot1 + ldr r2, [r1] + cmp r2, r0 + bne hold + + /* +* we've been released from the cpu_release,secondary_stack +* should now contain the SVC stack for this core +*/ + b secondary_startup + diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c new file mode 100644 index 000..e6a871f --- /dev/null +++ b/arch/arm/mach-omap2/omap-smp.c @@ -0,0 +1,178 @@ +/* + * OMAP4 SMP source file. It contains platform specific fucntions + * needed for the linux smp kernel. + * + * Copyright (C) 2009 Texas Instruments, Inc. + * + * Author: + * Santosh Shilimkar + * + * Platform file needed for the OMAP4 SMP. This file is based on arm + * realview smp platform. + * * Copyright (c) 2002 ARM Limited. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include + +#include +#include +#include + +/* Registers used for communicating startup information */ +#define OMAP4_AUXCOREBOOT_REG0 (OMAP44XX_VA_WKUPGEN_BASE + 0x800) +#define OMAP4_AUXCOREBOOT_REG1 (OMAP44XX_VA_WKUPGEN_BASE + 0x804) + +/* SCU base address */ +static void __iomem *scu_base = OMAP44XX_VA_SCU_BASE; + +/* + * Use SCU config register to count number of cores + */ +static inline unsigned int get_core_count(void) +{ + if (scu_base) + return scu_get_core_count(scu_base); + return 1; +} + +static DEFINE_SPINLOCK(boot_lock); + +void __cpuinit platform_secondary_init(unsigned int cpu) +{ + trace_hardirqs_off(); + + /* +* If any interrupts are already enabled for the primary +* core (e.g. timer irq), then they will not have been enabled +* for us: do so +*/ + + gic_cpu_init(0, IO_ADDRESS(OMAP44XX_GIC_CPU_BASE)); + + /* +* Synchronise with the boot thread. +*/ + spin_lock(&boot_lock); + spin_unlock(&boot_lock); +} + +int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle) +{ + unsigned long timeout; + + /* +* Set synchronisation state between this boot processor +* and the secondary one +*/ + spin_lock(&boot_lock); + + /* +* Update the AuxCoreBoot1 with boot state for secondary core. +* omap_secondary_startup() routine will hold the secondary core till +* the AuxCoreBoot1 register is updated with cpu state +* A barrier is added to ensure that write buffer is drained +*/ + __raw_writel(cpu, OMAP4_AUXCOREBOOT_REG1); + smp_wmb(); + + timeout = jiffies + (1 * HZ); + while (time_before(jiffies, timeout)) + ; + + /* +* Now the secondary core is starting up let it run its +* calibrations, then wait for it to finish +*/ + spin_unlock
[PATCH 3/4] ARM: OMAP4: SMP: Enable SMP support for OMAP4430
This patch enables SMP on OMAP4430 SDP platform. Signed-off-by: Santosh Shilimkar --- arch/arm/Kconfig |8 arch/arm/mach-omap2/Makefile |4 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 93d63bf..5468a32 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -858,10 +858,10 @@ source "kernel/time/Kconfig" config SMP bool "Symmetric Multi-Processing (EXPERIMENTAL)" - depends on EXPERIMENTAL && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP) + depends on EXPERIMENTAL && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP ||ARCH_OMAP4) depends on GENERIC_CLOCKEVENTS select USE_GENERIC_SMP_HELPERS - select HAVE_ARM_SCU if ARCH_REALVIEW + select HAVE_ARM_SCU if (ARCH_REALVIEW || ARCH_OMAP4) help This enables support for systems with more than one CPU. If you have a system with only one CPU, like most personal computers, say N. If @@ -929,9 +929,9 @@ config HOTPLUG_CPU config LOCAL_TIMERS bool "Use local timer interrupts" - depends on SMP && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || REALVIEW_EB_A9MP) + depends on SMP && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || REALVIEW_EB_A9MP || ARCH_OMAP4) default y - select HAVE_ARM_TWD if ARCH_REALVIEW + select HAVE_ARM_TWD if (ARCH_REALVIEW || ARCH_OMAP4) help Enable support for local timers on SMP platforms, rather then the legacy IPI broadcast method. Local timers allows the system diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index a51d811..d9175d4 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -14,6 +14,10 @@ obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o +# SMP support ONLY available for OMAP4 +obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o +obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o + # Functions loaded to SRAM obj-$(CONFIG_ARCH_OMAP2420)+= sram242x.o obj-$(CONFIG_ARCH_OMAP2430)+= sram243x.o -- 1.5.4.7 -- 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
[PATCH 2/4] ARM: OMAP4: SMP: Add mpu timer support for OMAP4430
This patch adds SMP platform specific parts for local(mpu) timer support for OMAP4430 platform. Each Cortex-a9 core has it's own local timer in the MPU domain. These timers are not in wakeup domain. Signed-off-by: Santosh Shilimkar --- arch/arm/mach-omap2/timer-gp.c|4 +++ arch/arm/mach-omap2/timer-mpu.c | 34 + arch/arm/plat-omap/include/mach/entry-macro.S | 28 arch/arm/plat-omap/include/mach/irqs.h|2 + 4 files changed, 68 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/timer-mpu.c diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c index 2ce474a..97b 100644 --- a/arch/arm/mach-omap2/timer-gp.c +++ b/arch/arm/mach-omap2/timer-gp.c @@ -38,6 +38,7 @@ #include #include +#include /* MAX_GPTIMER_ID: number of GPTIMERs on the chip */ #define MAX_GPTIMER_ID 12 @@ -229,6 +230,9 @@ static void __init omap2_gp_clocksource_init(void) static void __init omap2_gp_timer_init(void) { +#ifdef CONFIG_LOCAL_TIMERS + twd_base = IO_ADDRESS(OMAP44XX_LOCAL_TWD_BASE); +#endif omap_dm_timer_init(); omap2_gp_clockevent_init(); diff --git a/arch/arm/mach-omap2/timer-mpu.c b/arch/arm/mach-omap2/timer-mpu.c new file mode 100644 index 000..c1a650a --- /dev/null +++ b/arch/arm/mach-omap2/timer-mpu.c @@ -0,0 +1,34 @@ +/* + * The MPU local timer source file. In OMAP4, both cortex-a9 cores have + * own timer in it's MPU domain. These timers will be driving the + * linux kernel SMP tick framework when active. These timers are not + * part of the wake up domain. + * + * Copyright (C) 2009 Texas Instruments, Inc. + * + * Author: + * Santosh Shilimkar + * + * This file is based on arm realview smp platform file. + * Copyright (C) 2002 ARM Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include +#include + +/* + * Setup the local clock events for a CPU. + */ +void __cpuinit local_timer_setup(struct clock_event_device *evt) +{ + evt->irq = INT_44XX_LOCALTIMER_IRQ; + twd_timer_setup(evt); +} + diff --git a/arch/arm/plat-omap/include/mach/entry-macro.S b/arch/arm/plat-omap/include/mach/entry-macro.S index 00f45c0..56426ed 100644 --- a/arch/arm/plat-omap/include/mach/entry-macro.S +++ b/arch/arm/plat-omap/include/mach/entry-macro.S @@ -136,6 +136,34 @@ cmpne \irqnr, \tmp cmpcs \irqnr, \irqnr .endm + + /* We assume that irqstat (the raw value of the IRQ acknowledge +* register) is preserved from the macro above. +* If there is an IPI, we immediately signal end of interrupt +* on the controller, since this requires the original irqstat +* value which we won't easily be able to recreate later. +*/ + + .macro test_for_ipi, irqnr, irqstat, base, tmp + bic \irqnr, \irqstat, #0x1c00 + cmp \irqnr, #16 + it cc + strcc \irqstat, [\base, #GIC_CPU_EOI] + it cs + cmpcs \irqnr, \irqnr + .endm + + /* As above, this assumes that irqstat and base are preserved */ + + .macro test_for_ltirq, irqnr, irqstat, base, tmp + bic \irqnr, \irqstat, #0x1c00 + mov \tmp, #0 + cmp \irqnr, #29 + itt eq + moveq \tmp, #1 + streq \irqstat, [\base, #GIC_CPU_EOI] + cmp \tmp, #0 + .endm #endif .macro irq_prio_table diff --git a/arch/arm/plat-omap/include/mach/irqs.h b/arch/arm/plat-omap/include/mach/irqs.h index 5bc331e..e8f84a0 100644 --- a/arch/arm/plat-omap/include/mach/irqs.h +++ b/arch/arm/plat-omap/include/mach/irqs.h @@ -427,6 +427,8 @@ #define IRQ_GIC_START 32 +#define INT_44XX_LOCALTIMER_IRQ29 +#define INT_44XX_LOCALWDT_IRQ 30 #define INT_44XX_BENCH_MPU_EMUL(3 + IRQ_GIC_START) #define INT_44XX_SSM_ABORT_IRQ (6 + IRQ_GIC_START) -- 1.5.4.7 -- 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
[PATCH 0/4]ARM: OMAP4: SMP: Patch series
Russell, I have rebased this series on top of your arm-smp patches and my earlier basic omap4 patches. Series is based of kernel.org 2.6.30-rc6 ( commit:1406de8e11eb043681297adf86d6892ff8efc27a). This series have dependency on [1],[2],[3],[4] and latest mach-types The series contains: [PATCH 1/4] ARM: OMAP4: SMP: Add OMAP4430 SMP board files [PATCH 2/4] ARM: OMAP4: SMP: Add mpu timer support for OMAP4430 [PATCH 3/4] ARM: OMAP4: SMP: Enable SMP support for OMAP4430 [PATCH 4/4] ARM: OMAP4: SMP: Update defconfig for OMAP4430 Regards, Santosh [1]:Russell's arm-smp patch series + one of my patch http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/arm:smp.diff [2]:Tony's : [PATCH 0/5] More header clean-up http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12231.html [3]:Mine [PATCH 0/4] OMAP: Cleanup series. http://lists.arm.linux.org.uk/lurker/message/20090519.131647.c2c471ef.en.html [4]:Mine [PATCH 0/4] ARM: OMPA4: Basic boot patch series based on linux-omap http://lists.arm.linux.org.uk/lurker/message/20090520.125900.9209eb81.en.html Regards, Santosh-- 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
Re: [PATCH] OMAP3: Re-program also chipselect 1 when changing SDRAM timing
Tero Kristo writes: > From: Tero Kristo > > Previously only chipselect 0 was controlled, which would result in the > chipselect 1 running on too low rate during low core OPPs. > > Applies on top of PM branch. > > Signed-off-by: Tero Kristo Hi Tero, This does part of what Jean Pihet does in his recent patch[1] to add support for 2 CSs. Your version assumes the same parameters for both SDRAM parts, and Jean has expanded that so board code can configure different paramaters for the different CSes. I have yet to fully review Jean's patch, but will probably take his version so that two different SDRAM parts could be used. Kevin [1] See hist post from 26 May: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume) > --- > arch/arm/mach-omap2/sram34xx.S | 29 +++-- > 1 files changed, 23 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S > index f41f8d9..bcfe9eb 100644 > --- a/arch/arm/mach-omap2/sram34xx.S > +++ b/arch/arm/mach-omap2/sram34xx.S > @@ -187,15 +187,24 @@ wait_dll_unlock: > bne wait_dll_unlock > bx lr > configure_sdrc: > - ldr r11, omap3_sdrc_rfr_ctrl > + ldr r11, omap3_sdrc_rfr_ctrl_0 > str r0, [r11] > - ldr r11, omap3_sdrc_actim_ctrla > + ldr r11, omap3_sdrc_rfr_ctrl_1 > + str r0, [r11] > + ldr r11, omap3_sdrc_actim_ctrla_0 > + str r1, [r11] > + ldr r11, omap3_sdrc_actim_ctrla_1 > str r1, [r11] > - ldr r11, omap3_sdrc_actim_ctrlb > + ldr r11, omap3_sdrc_actim_ctrlb_0 > + str r2, [r11] > + ldr r11, omap3_sdrc_actim_ctrlb_1 > str r2, [r11] > ldr r11, omap3_sdrc_mr_0 > str r6, [r11] > ldr r6, [r11] @ posted-write barrier for SDRC > + ldr r11, omap3_sdrc_mr_1 > + str r6, [r11] > + ldr r6, [r11] @ posted-write barrier for SDRC > bx lr > > omap3_sdrc_power: > @@ -206,14 +215,22 @@ omap3_cm_idlest1_core: > .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST) > omap3_cm_iclken1_core: > .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_ICLKEN1) > -omap3_sdrc_rfr_ctrl: > +omap3_sdrc_rfr_ctrl_0: > .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_0) > -omap3_sdrc_actim_ctrla: > +omap3_sdrc_rfr_ctrl_1: > + .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_1) > +omap3_sdrc_actim_ctrla_0: > .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_0) > -omap3_sdrc_actim_ctrlb: > +omap3_sdrc_actim_ctrla_1: > + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_1) > +omap3_sdrc_actim_ctrlb_0: > .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_0) > +omap3_sdrc_actim_ctrlb_1: > + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_1) > omap3_sdrc_mr_0: > .word OMAP34XX_SDRC_REGADDR(SDRC_MR_0) > +omap3_sdrc_mr_1: > + .word OMAP34XX_SDRC_REGADDR(SDRC_MR_1) > omap3_sdrc_dlla_status: > .word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) > omap3_sdrc_dlla_ctrl: > -- > 1.5.4.3 > > -- > 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 -- 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
Re: how to configure android-2.6.27 kernel for an LCD display other than Zoom2 display
On Tue, May 19, 2009 at 8:17 AM, twebb wrote: > On Fri, May 15, 2009 at 3:18 PM, twebb wrote: >> I'm using the L25.6/android-2.6.27 kernel and am adapting it as >> necessary to OMAP3530-based hardware. However, I don't see how to >> configure the kernel for an LCD display other than the NEC display >> defined for ZOOM2 (which is an SPI-based display?). I'm using an LG >> display via the dss_data[17:0] interface of the 35xx - and this is >> working with a slightly modified version of lcd_omap3evm.c on the >> linux-omap-2.6.27-omap1 kernel. I'm not familiar with the new DSS >> that appears to be in android-2.6.27. >> >> The LG display is WSVGA, but I'd be happy getting WVGA or VGA working >> on it for now. How can I configure the kernel to support a >> non-SPI-based LCD panel? How does this DSS differ with what appears >> in android-2.6.29/drivers/video/omap2 ? >> >> Any help here would be appreciated. >> >> Thanks, >> twebb >> Am I off base with these questions? I'd appreciate any feedback. Thanks. -- 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
Re: Please help in adding ams-delta support to ASoC
On Wed, 27 May 2009 16:33:22 +0200 Janusz Krzysztofik wrote: > >> - .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE > >> * 2 - 1), > >> + .srgr2 = GSYNC, > >> > >> - .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ > >> ... > > I wonder why the frame sync period (FWID) wasn't set in that > > original patch but probably McBSP is able to work without :-) > > from linux-2.6.29/sound/soc/omap/omap-mcbsp.c: > switch (mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK) { > case SND_SOC_DAIFMT_I2S: > regs->srgr2 |= FPER(wlen * 2 - 1); > regs->srgr1 |= FWID(wlen - 1); > break; > case SND_SOC_DAIFMT_DSP_B: > regs->srgr2 |= FPER(wlen * channels - 1); > regs->srgr1 |= FWID(0); > break; > } > > So it looks like in case of SND_SOC_DAIFMT_DSP_B, FWID is not set, > only FPER. However, in the original patch, FPER was not set either. > Sorry, my short above. Obviously I was wondering missing FPER setting in original patch which defines the length of frame sync period. FWID defines the length of frame sync pulse (n.o. bit clock pulses - 1). Frame sync pulse length is half of the period in I2S and 1-bit clock cycle in DSP_B. WM9713 has nice drawings about different formats. Look pages 29 and 30. http://www.wolfsonmicro.com/uploads/documents/en/WM9713.pdf > I hope DMA chaining is not an issue here. If I remove the DMA > chaining workaround from the original patch, I get signle DMA > interrupts, so that is better than none that I get with my patch. > I think chaining is not issue if you are not getting any interrupt. Basically if DMA transfer is working but DMA restarting is not then there should be one completed buffer transfer and >= 2 interrupts from completed periods. -- Jarkko -- 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
[PATCH 1/2] I2C: OMAP2/3: Fix scll/sclh calculations
Fix scll/sclh calculations for HS and fast modes. Currently the driver uses equal (roughly) low/high times which will result in too short low time. OMAP3430 TRM gives the following equations: F/S: tLow = (scll + 7) * internal_clk tHigh = (sclh + 5) * internal_clk HS: tLow = (scll + 7) * fclk tHigh = (sclh + 5) * fclk Furthermore, the I2C specification sets the following minimum values for HS tLow/tHigh for capacitive bus loads 100 pF (maximum speed 3400) and 400 pF (maximum speed 1700): speed tLowtHigh 3400160 ns 60 ns 1700320 ns 120 ns and for F/S: speed tLowtHigh 400 1300 ns 600 ns 100 4700 ns 4000 ns By using duty cycles 33/66 (HS, F) and 50/50 (S) we stay above these minimum values. Signed-off-by: Aaro Koskinen --- drivers/i2c/busses/i2c-omap.c | 25 ++--- 1 files changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 9919c08..5d9880c 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -343,17 +343,28 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* If configured for High Speed */ if (dev->speed > 400) { + unsigned long scl; + /* For first phase of HS mode */ - fsscll = internal_clk / (400 * 2) - 6; - fssclh = internal_clk / (400 * 2) - 6; + scl = internal_clk / 400; + fsscll = scl - (scl / 3) - 7; + fssclh = (scl / 3) - 5; /* For second phase of HS mode */ - hsscll = fclk_rate / (dev->speed * 2) - 6; - hssclh = fclk_rate / (dev->speed * 2) - 6; + scl = fclk_rate / dev->speed; + hsscll = scl - (scl / 3) - 7; + hssclh = (scl / 3) - 5; + } else if (dev->speed > 100) { + unsigned long scl; + + /* Fast mode */ + scl = internal_clk / dev->speed; + fsscll = scl - (scl / 3) - 7; + fssclh = (scl / 3) - 5; } else { - /* To handle F/S modes */ - fsscll = internal_clk / (dev->speed * 2) - 6; - fssclh = internal_clk / (dev->speed * 2) - 6; + /* Standard mode */ + fsscll = internal_clk / (dev->speed * 2) - 7; + fssclh = internal_clk / (dev->speed * 2) - 5; } scll = (hsscll << OMAP_I2C_SCLL_HSSCLL) | fsscll; sclh = (hssclh << OMAP_I2C_SCLH_HSSCLH) | fssclh; -- 1.5.4.3 -- 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
[PATCH 2/2] I2C: OMAP3: Better noise suppression for fast/standard modes
Use longer noise filter period for fast and standard mode. Based on an earlier patch by Eero Nurkkala. Signed-off-by: Aaro Koskinen --- drivers/i2c/busses/i2c-omap.c | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 5d9880c..8c76cea 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -333,8 +333,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) if (cpu_is_omap2430() || cpu_is_omap34xx()) { - /* HSI2C controller internal clk rate should be 19.2 Mhz */ - internal_clk = 19200; + /* +* HSI2C controller internal clk rate should be 19.2 Mhz for +* HS and for all modes on 2430. On 34xx we can use lower rate +* to get longer filter period for better noise suppression. +* The filter is iclk (fclk for HS) period. +*/ + if (dev->speed > 400 || cpu_is_omap_2430()) + internal_clk = 19200; + else if (dev->speed > 100) + internal_clk = 9600; + else + internal_clk = 4000; fclk_rate = clk_get_rate(dev->fclk) / 1000; /* Compute prescaler divisor */ -- 1.5.4.3 -- 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
Re: Please help in adding ams-delta support to ASoC
Hi Jarkko, On Wed, 27 May 2009 08:59 Jarkko Nikula wrote: On Tue, 26 May 2009 15:17:23 +0200 Janusz Krzysztofik wrote: - .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) | - XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG, + .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0), XFIG is only difference (OMAP_MCBSP_WORD_8 = 0) -> transfer is aborted in case of unexpected frame sync. I tried commenting out RFIG and XFIG bits settings in sound/soc/omap/omap-mcbsp.c - did not help. - .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1), + .srgr1 = CLKGDV(0), Width of frame sync signal set to 1 here -> DSP_B format because no data delay set. That's what I have tried mostly. - .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1), + .srgr2 = GSYNC, - .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ No CLKXM, CLKRM and FSGM set -> codec is providing the frame sync and bit-clock signals -> SND_SOC_DAIFMT_CBM_CFM. This is my primary choice as well. CLKXP and CLKRP not set -> rising edge of bit clock drives the transitions. This with DSP_B indicates inverted bit clock so SND_SOC_DAIFMT_IB_NF. I have given it a try this morning - no go. I wonder why the frame sync period (FWID) wasn't set in that original patch but probably McBSP is able to work without :-) from linux-2.6.29/sound/soc/omap/omap-mcbsp.c: switch (mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK) { case SND_SOC_DAIFMT_I2S: regs->srgr2 |= FPER(wlen * 2 - 1); regs->srgr1 |= FWID(wlen - 1); break; case SND_SOC_DAIFMT_DSP_B: regs->srgr2 |= FPER(wlen * channels - 1); regs->srgr1 |= FWID(0); break; } So it looks like in case of SND_SOC_DAIFMT_DSP_B, FWID is not set, only FPER. However, in the original patch, FPER was not set either. ... aplay and arecord wait forever, cat to/from /dev/dsp breaks with hardware error messgae. DMA interrput counters stay at 0. However, codec Looks like McBSP is not getting bit-clock and frame-sync signals from the codec. Do you have any way to measure is the codec sending those? Well, I am not sure, but I'll try if nothing helps. Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same I boot both kernels, working 2.6.16 and not working 2.6.30-rc5, with the same u-boot.bin. > but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls. I was not able to find anything relevant. ... OMAP1510 doesn't support DMA chaining so there are few cpu_is_omap1510() code snippets in sound/soc/omap/omap-pcm.c which I think I have only simulated using OMAP2420. I hope DMA chaining is not an issue here. If I remove the DMA chaining workaround from the original patch, I get signle DMA interrupts, so that is better than none that I get with my patch. Thanks, Janusz -- 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
Re: Please help in adding ams-delta support to ASoC
Hi Peter, On Wuesday 27 May 2009 07:57 Peter Ujfalusi wrote: On Tuesday 26 May 2009 16:17:23 ext Janusz Krzysztofik wrote: 4. the following McBSP register settings changes: - .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) | - XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG, + .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0), - .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1), + .srgr1 = CLKGDV(0), - .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1), + .srgr2 = GSYNC, - .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ Since I don't have the original osk/aic23 thing, this does not mean to much... Just a bit confusing. OK, once again then. original omap-alsa mcbsp register settings for osk board, as found in linux-2.6.16/arch/arm/mach-omap1/board-osk.c: - #define DEFAULT_BITPERSAMPLE 16 static struct omap_mcbsp_reg_cfg mcbsp_regs = { .spcr2 = FREE | FRST | GRST | XRST | XINTM(3), .spcr1 = RINTM(3) | RRST, .rcr2 = RPHASE | RFRLEN2(OMAP_MCBSP_WORD_8) | RWDLEN2(OMAP_MCBSP_WORD_16) | RDATDLY(0), .rcr1 = RFRLEN1(OMAP_MCBSP_WORD_8) | RWDLEN1(OMAP_MCBSP_WORD_16), .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) | XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG, .xcr1 = XFRLEN1(OMAP_MCBSP_WORD_8) | XWDLEN1(OMAP_MCBSP_WORD_16), .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1), .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1), /*.pcr0 = FSXM | FSRM | CLKXM | CLKRM | CLKXP | CLKRP,*/ /* mcbsp: master */ .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ }; - the same for ams-delta, as found in Mark Underwood patch: - static struct omap_mcbsp_reg_cfg mcbsp_regs = { .spcr2 = FREE | XRST | GRST | XINTM(3) | FRST, .spcr1 = RINTM(3) | RRST, .rcr2 = RPHASE | RWDLEN2(OMAP_MCBSP_WORD_16) | RFRLEN2(0), .rcr1 = RWDLEN1(OMAP_MCBSP_WORD_16) | RFRLEN1(0), .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0), .xcr1 = XWDLEN1(OMAP_MCBSP_WORD_16) | XFRLEN1(0), .srgr1 = CLKGDV(0), .srgr2 = GSYNC, }; - currnet soc-audio mcbsp config for osk, as found in linux-2.6.29/sound/soc/omap/osk5912.c: - err = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM); - Using exactly the same does not work on my ams-delta. > The configuration suggest slave McBSP with NB_IF polarity, dual phase format, 16 bit words, 16*2 long frames, the FS pulse is probably a pulse... Suggesting kind of DSP mode, but with not so correct configuration, which happens to be working. So I will try the following then: err = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_NB_IF | SND_SOC_DAIFMT_CBM_CFM); and this: err = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_NB_IF | SND_SOC_DAIFMT_CBM_CFM); and give you a feedback. ... aplay and arecord wait forever, cat to/from /dev/dsp breaks with hardware error messgae. DMA interrput counters stay at 0. This means that the McBSP module is not transmitting/receiving any data. Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec. Do you mean trying with codec as slave and McBSP as master, like this? err = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_NB_IF | SND_SOC_DAIFMT_CBS_CFS); I'll give it a try as well. Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct. Do you mean mux setup? Reading OMAP5910 Data Manual I found only 2 relevant signals, MCBSP1.FSX and MCBSP1.DX, that could be swapped from pin H15 to H18 and vice versa. However, there is no pin configuration entry for neither, both in 2.6.16 and 2.6.29 arch/arm/mach-omap1/mux.c, so I assume default setup should just work. I keep on digging. Thanks, Janusz -- 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
[PATCH] OMAP3: Re-program also chipselect 1 when changing SDRAM timing
From: Tero Kristo Previously only chipselect 0 was controlled, which would result in the chipselect 1 running on too low rate during low core OPPs. Applies on top of PM branch. Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/sram34xx.S | 29 +++-- 1 files changed, 23 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index f41f8d9..bcfe9eb 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -187,15 +187,24 @@ wait_dll_unlock: bne wait_dll_unlock bx lr configure_sdrc: - ldr r11, omap3_sdrc_rfr_ctrl + ldr r11, omap3_sdrc_rfr_ctrl_0 str r0, [r11] - ldr r11, omap3_sdrc_actim_ctrla + ldr r11, omap3_sdrc_rfr_ctrl_1 + str r0, [r11] + ldr r11, omap3_sdrc_actim_ctrla_0 + str r1, [r11] + ldr r11, omap3_sdrc_actim_ctrla_1 str r1, [r11] - ldr r11, omap3_sdrc_actim_ctrlb + ldr r11, omap3_sdrc_actim_ctrlb_0 + str r2, [r11] + ldr r11, omap3_sdrc_actim_ctrlb_1 str r2, [r11] ldr r11, omap3_sdrc_mr_0 str r6, [r11] ldr r6, [r11] @ posted-write barrier for SDRC + ldr r11, omap3_sdrc_mr_1 + str r6, [r11] + ldr r6, [r11] @ posted-write barrier for SDRC bx lr omap3_sdrc_power: @@ -206,14 +215,22 @@ omap3_cm_idlest1_core: .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST) omap3_cm_iclken1_core: .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_ICLKEN1) -omap3_sdrc_rfr_ctrl: +omap3_sdrc_rfr_ctrl_0: .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_0) -omap3_sdrc_actim_ctrla: +omap3_sdrc_rfr_ctrl_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_1) +omap3_sdrc_actim_ctrla_0: .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_0) -omap3_sdrc_actim_ctrlb: +omap3_sdrc_actim_ctrla_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_1) +omap3_sdrc_actim_ctrlb_0: .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_0) +omap3_sdrc_actim_ctrlb_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_1) omap3_sdrc_mr_0: .word OMAP34XX_SDRC_REGADDR(SDRC_MR_0) +omap3_sdrc_mr_1: + .word OMAP34XX_SDRC_REGADDR(SDRC_MR_1) omap3_sdrc_dlla_status: .word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) omap3_sdrc_dlla_ctrl: -- 1.5.4.3 -- 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
Re: USB Host on OMAP3 EVM, 2.6.29
Hi Eikka. Am not familiar with OMAP35xx. Also don't know, what's the config of EVM (if it uses twl4030 tranceiver or external). Can it play as a HOST which is the case to supply VBUS ? Otherwise external self-powered hub might be needed. -niilo- On Wed, 2009-05-27 at 02:59 +0200, ext Eino-Ville Talvala wrote: > Hi, > > We're trying to get basic USB host mode up and running on a OMAP3530 > EVM, with no success. We're (now, after many permutations of kernels > and .config settings) using the vanilla 2.6.29-omap1 kernel plus the > AUTOIDLE fix from Niilo Minkkinen), with slight additions to > board-omap3evm to allow the MMC slot to work since it hosts the rootfs > (missing regulator setup, as per dfoley's mail on 3/25). > > All we've done with configuration past omap3_evm_defconfig, is to > compile in the MMC driver (to allow boot from it), enabling the EHCI > host driver (doesn't work with it off, either), and setting the > integrated USB driver to Host mode. Listed below is the resulting > .config file. We've tried many other configurations, but nothing has > worked any better. > > I'd very much appreciate it if anyone knows what magic sauce might be > missing here - the USB bus debug messages indicate that the bus is being > discovered, and powered up, but no voltage appears on the USB VBus line, > and no devices are detected when they're plugged in. Sometimes we've > seen auto-suspend messages indicating that the bus is auto-suspending, > and other times we've seen nothing - but no matter what, it doesn't seem > to work. > > Below is the output of "dmesg | grep 'usb\|hub' " for the above > configuration with a USB keyboard plugged in, followed by the .config file: > > Thanks, > > Eino-Ville Talvala > Graduate Research Assistant > Computer Graphics Laboratory > Stanford University > > > -- > twl4030_usb twl4030_usb: HW_CONDITIONS 0x50/80; link 1 > twl4030_usb twl4030_usb: Initialized TWL4030 USB module > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > musb_hdrc: version 6.0, musb-dma, host, debug=0 > musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk > split (X), HB-ISO Rx (X), HB-ISO Tx (X), SoftConn) > musb_hdrc: MHDRC RTL version 1.400 > musb_hdrc: setup fifo_mode 4 > musb_hdrc: 29/31 max ep, 15424/16384 memory > musb_hdrc: hw_ep 0shared, max 64 > musb_hdrc: hw_ep 1tx, max 512 > musb_hdrc: hw_ep 1rx, max 512 > musb_hdrc: hw_ep 2tx, max 512 > musb_hdrc: hw_ep 2rx, max 512 > musb_hdrc: hw_ep 3tx, max 512 > musb_hdrc: hw_ep 3rx, max 512 > musb_hdrc: hw_ep 4tx, max 512 > musb_hdrc: hw_ep 4rx, max 512 > musb_hdrc: hw_ep 5tx, max 512 > musb_hdrc: hw_ep 5rx, max 512 > musb_hdrc: hw_ep 6tx, max 512 > musb_hdrc: hw_ep 6rx, max 512 > musb_hdrc: hw_ep 7tx, max 512 > musb_hdrc: hw_ep 7rx, max 512 > musb_hdrc: hw_ep 8tx, max 512 > musb_hdrc: hw_ep 8rx, max 512 > musb_hdrc: hw_ep 9tx, max 512 > musb_hdrc: hw_ep 9rx, max 512 > musb_hdrc: hw_ep 10tx, max 512 > musb_hdrc: hw_ep 10rx, max 512 > musb_hdrc: hw_ep 11tx, max 512 > musb_hdrc: hw_ep 11rx, max 512 > musb_hdrc: hw_ep 12tx, max 512 > musb_hdrc: hw_ep 12rx, max 512 > musb_hdrc: hw_ep 13tx, max 512 > musb_hdrc: hw_ep 13rx, max 512 > musb_hdrc: hw_ep 14shared, max 1024 > musb_hdrc: hw_ep 15shared, max 1024 > musb_hdrc: USB Host mode controller at d80ab000 using DMA, IRQ 92 > musb_hdrc musb_hdrc: MUSB HDRC host driver > drivers/usb/core/inode.c: creating file 'devices' > drivers/usb/core/inode.c: creating file '001' > musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 > usb usb1: default language 0x0409 > usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: MUSB HDRC host driver > usb usb1: Manufacturer: Linux 2.6.29-omap1-05531-g0dfe43a-dirty musb-hcd > usb usb1: SerialNumber: musb_hdrc > usb usb1: uevent > usb usb1: usb_probe_device > usb usb1: configuration #1 chosen from 1 choice > usb usb1: adding 1-0:1.0 (config #1, interface 0) > usb 1-0:1.0: uevent > hub 1-0:1.0: usb_probe_interface > hub 1-0:1.0: usb_probe_interface - got id > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 1 port detected > hub 1-0:1.0: standalone hub > hub 1-0:1.0: individual port power switching > hub 1-0:1.0: no over-current protection > hub 1-0:1.0: power on to power good time: 10ms > hub 1-0:1.0: 100mA bus power budget for each child > hub 1-0:1.0: local power source is good > hub 1-0:1.0: enabling power on all ports > drivers/usb/core/inode.c: creating file '001' > hub 1-0:1.0: state 7 ports 1 chg evt > usbmon: debugfs is not available > drivers/usb/core/inode.c: creating file '002' > usb usb2: default language 0x0409 > usb usb2: New USB device found, idVendor=1d6b, idProduct
Re: Please help in adding ams-delta support to ASoC
Hi On Tue, 26 May 2009 15:17:23 +0200 Janusz Krzysztofik wrote: Grr, these McBSP bits are always almost un-readable :-) > 4. the following McBSP register settings changes: > > - .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) | > - XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG, > + .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0), > XFIG is only difference (OMAP_MCBSP_WORD_8 = 0) -> transfer is aborted in case of unexpected frame sync. > - .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1), > + .srgr1 = CLKGDV(0), > Width of frame sync signal set to 1 here -> DSP_B format because no data delay set. > - .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * > 2 - 1), > + .srgr2 = GSYNC, > > - .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ > No CLKXM, CLKRM and FSGM set -> codec is providing the frame sync and bit-clock signals -> SND_SOC_DAIFMT_CBM_CFM. CLKXP and CLKRP not set -> rising edge of bit clock drives the transitions. This with DSP_B indicates inverted bit clock so SND_SOC_DAIFMT_IB_NF. I wonder why the frame sync period (FWID) wasn't set in that original patch but probably McBSP is able to work without :-) > safely access the device, however it does not work as expected. aplay > and arecord wait forever, cat to/from /dev/dsp breaks with hardware > error messgae. DMA interrput counters stay at 0. However, codec Looks like McBSP is not getting bit-clock and frame-sync signals from the codec. Do you have any way to measure is the codec sending those? Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls. > First of all, I'd like to make sure if my problem is related to my > code only. As I am new in these areas, I would like to ask you if the > omap asoc framework is stable enough to relay on. If yes, could you > please look at my dirty code (attached) an give me some hints? I can > provide you with more information if necessary. > I hope it's stable enough for you to get going. It would be nice to get this working since it would be the first OMAP5910 == OMAP1510 based machine driver. OMAP1510 doesn't support DMA chaining so there are few cpu_is_omap1510() code snippets in sound/soc/omap/omap-pcm.c which I think I have only simulated using OMAP2420. -- Jarkko -- 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