RE: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files
> Subject: RE: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files > > > > -Original Message- > > From: V, Hemanth > > Sent: Friday, May 08, 2009 11:16 AM > > To: Shilimkar, Santosh; linux-arm-ker...@lists.arm.linux.org.uk > > Cc: linux-omap@vger.kernel.org > > Subject: Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files > > > > >>U-boot has no knowledge of secondary CPUs. Kernel takes > care of it with > >>help of ROM code. > > For my information could you pl point to the routine which > does this, i.e > enable instruction cache on the secondary cpu. This is done using __enable_mmu in head.S. Bye the way even if the u-boot don't enable I-cache , D-caches, kernel does that anyways depending on settings.-- 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: Status of Beagle Board
Hi Vaibhav Hiremath,
My application can work in OMAP3 EVM and other v4l2 platform, but there
is another issue in beagle board. as follow:
1. NormalSize() -> RequestBuffer() -> mmap()
2. playing...
3. FullScreen() -> VIDIOC_STREAMOFF
-> munmap()
-> VIDIOC_REQBUFS
-> VIDIOC_QUERYBUF
-> RequestBuffer() -> mmap()
-> VIDIOC_S_CROP
-> VIDIOC_S_FMT
-> VIDIOC_QBUF
-> VIDIOC_STREAMON
When I want to call VIDIOC_REQBUFS in FullScreen(), it always fail.
Best Regards,
George.Qiao
Great, please see my comments in-lined below -
Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927
-Original Message-
From: George.Qiao [mailto:qiao_shans...@visualon.com]
Sent: Thursday, May 07, 2009 3:51 PM
To: Hiremath, Vaibhav
Cc: Syed Mohammed, Khasim; Shah, Hardik; wan_jin...@visualon.com;
Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit; Andrews,
Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xuejun Dong'; 'YangCai';
linux-omap-open-sou...@linux.omap.com
Subject: Re: Status of Beagle Board
Dear Vaibhav Hiremath,
I can play video by v4l2 now! Thank you!
I have add code in board-omap3beagle.c :
#ifdef CONFIG_FB_OMAP2
static struct resource omap3beagle_vout_resource[3 -
CONFIG_FB_OMAP2_NUM_FBS] = {
};
#else
static struct resource omap3beagle_vout_resource[2] = {
};
#endif
static struct platform_device omap3beagle_vout_device = {
.name = "omap_vout",
.num_resources = ARRAY_SIZE(omap3beagle_vout_resource),
.resource = &omap3beagle_vout_resource[0],
.id = -1,
};
static struct platform_device *omap3_beagle_devices[] __initdata = {
&beagle_dss_device,
&leds_gpio,
&keys_gpio,
&omap3beagle_vout_device,
};
I have got some omapdss error and voutBuffer Size. as follow:
omapdss: Could not find exact pixel clock. Requested 23500 kHz, got
24000 kHz
omapdss error: display already enabled
omap_voutDisplay already enabled
omapdss error: display already enabled
omap_voutDisplay already enabled
[Hiremath, Vaibhav] This is not an error as such, it warning message. Actually here we are trying to enable the display which has already been enabled by Fbdev.
We can suppress this message, atleast during init.
omap_voutBuffer Size = 3686400
omap_vout: registered and initialized video device 0 [v4l2]
omap_voutBuffer Size = 3686400
omap_vout: registered and initialized video device 1 [v4l2]
[Hiremath, Vaibhav] This is just a debug massage; it is neither a error nor a
warning. So don't worry.
Can you share the code-base or submit the patches to the list, so that
interested people can use it.
Could I change 'voutBuffer Size'? How to fix it?
Best Regards,
George.Qiao
===
Yes Definitely this is the issue. If the platform_device.name
doesn't match with the platform_driver.driver.name then your probe
function will not be called at all.
Can you just copy the board-omap3evm.c changes related to
V4L2/DSS2 and give a shot? I think it should work straight away.
Please let me know if you need any further clarification or help.
Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927
-Original Message-
From: George.Qiao [mailto:qiao_shans...@visualon.com]
Sent: Thursday, May 07, 2009 12:55 PM
To: Hiremath, Vaibhav
Cc: Syed Mohammed, Khasim; Shah, Hardik; wan_jin...@visualon.com;
Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit; Andrews,
Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xuejun Dong'; 'YangCai';
linux-omap-open-sou...@linux.omap.com
Subject: Re: Status of Beagle Board
Hi Hiremath, Vaibhav,
Thank you very much for your instant response!
I've checked the file 'board-omap3beagle.c' and found nothing
looking
like omap_vout in it, no platform_device, either. And I've also
compared
it with board-omap3evm.c.
Below is some difference between them:
board-omap3evm.c has:
*+static struct platform_device omap3evm_vout_device = {
**+ .name = "omap_vout",
...
}
*
But 'board-omap3beagle.c' does not have anything looking like:
*+static struct platform_device omap3beagle_vout_device = {*
*+ .name = "omap_vout",
...
}
*
So, I think there's no patch on V4L2 for beagle done and this is
the
root cause of this issue. Do you agree with me? Thanks a lot.
Best Regards,
George.Qiao
===
Hi George,
I have looked into your config file and it looks ok to me.
Can you conform that, you have added "platform_device"
definitions
in board-omap3beagle.c?
Can you please create complete patch on top of your baseline (O-
L
RE: Status of Beagle Board
> -Original Message-
> From: George.Qiao [mailto:qiao_shans...@visualon.com]
> Sent: Friday, May 08, 2009 11:57 AM
> To: Hiremath, Vaibhav
> Cc: Syed Mohammed, Khasim; Shah, Hardik; wan_jin...@visualon.com;
> Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit; Andrews,
> Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xuejun Dong'; 'YangCai';
> linux-omap@vger.kernel.org
> Subject: Re: Status of Beagle Board
>
> Hi Vaibhav Hiremath,
>
> My application can work in OMAP3 EVM and other v4l2 platform, but
> there
> is another issue in beagle board. as follow:
>
[Hiremath, Vaibhav] Are you saying, same application works on OMAP3EVM but
fails on beagle board?
> 1. NormalSize() -> RequestBuffer() -> mmap()
> 2. playing...
> 3. FullScreen() -> VIDIOC_STREAMOFF
> -> munmap()
> -> VIDIOC_REQBUFS
> -> VIDIOC_QUERYBUF
> -> RequestBuffer() -> mmap()
> -> VIDIOC_S_CROP
> -> VIDIOC_S_FMT
> -> VIDIOC_QBUF
> -> VIDIOC_STREAMON
>
> When I want to call VIDIOC_REQBUFS in FullScreen(), it always fail.
>
[Hiremath, Vaibhav] Is it possible for you to share your application, so that I
can give try here at my end?
Thanks,
Vaibhav Hiremath
>
> Best Regards,
> George.Qiao
>
>
> > Great, please see my comments in-lined below -
> >
> >
> > Thanks,
> > Vaibhav Hiremath
> > Platform Support Products
> > Texas Instruments Inc
> > Ph: +91-80-25099927
> >
> >
> >> -Original Message-
> >> From: George.Qiao [mailto:qiao_shans...@visualon.com]
> >> Sent: Thursday, May 07, 2009 3:51 PM
> >> To: Hiremath, Vaibhav
> >> Cc: Syed Mohammed, Khasim; Shah, Hardik; wan_jin...@visualon.com;
> >> Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit; Andrews,
> >> Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xuejun Dong'; 'YangCai';
> >> linux-omap-open-sou...@linux.omap.com
> >> Subject: Re: Status of Beagle Board
> >>
> >> Dear Vaibhav Hiremath,
> >>
> >> I can play video by v4l2 now! Thank you!
> >>
> >> I have add code in board-omap3beagle.c :
> >>
> >> #ifdef CONFIG_FB_OMAP2
> >> static struct resource omap3beagle_vout_resource[3 -
> >> CONFIG_FB_OMAP2_NUM_FBS] = {
> >> };
> >> #else
> >> static struct resource omap3beagle_vout_resource[2] = {
> >> };
> >> #endif
> >>
> >> static struct platform_device omap3beagle_vout_device = {
> >>.name = "omap_vout",
> >>.num_resources = ARRAY_SIZE(omap3beagle_vout_resource),
> >>.resource = &omap3beagle_vout_resource[0],
> >>.id = -1,
> >> };
> >>
> >> static struct platform_device *omap3_beagle_devices[] __initdata
> = {
> >> &beagle_dss_device,
> >> &leds_gpio,
> >> &keys_gpio,
> >> &omap3beagle_vout_device,
> >> };
> >>
> >>
> >> I have got some omapdss error and voutBuffer Size. as follow:
> >>
> >> omapdss: Could not find exact pixel clock. Requested 23500 kHz,
> got
> >> 24000 kHz
> >> omapdss error: display already enabled
> >> omap_voutDisplay already enabled
> >> omapdss error: display already enabled
> >> omap_voutDisplay already enabled
> >>
> >
> >
> > [Hiremath, Vaibhav] This is not an error as such, it warning
> message. Actually here we are trying to enable the display which has
> already been enabled by Fbdev.
> > We can suppress this message, atleast during init.
> >
> >
> >> omap_voutBuffer Size = 3686400
> >> omap_vout: registered and initialized video device 0 [v4l2]
> >> omap_voutBuffer Size = 3686400
> >> omap_vout: registered and initialized video device 1 [v4l2]
> >>
> >>
> >
> > [Hiremath, Vaibhav] This is just a debug massage; it is neither a
> error nor a warning. So don't worry.
> >
> > Can you share the code-base or submit the patches to the list, so
> that interested people can use it.
> >
> >
> >> Could I change 'voutBuffer Size'? How to fix it?
> >>
> >> Best Regards,
> >> George.Qiao
> >>
> >> ===
> >>
> >>> Yes Definitely this is the issue. If the platform_device.name
> >>>
> >> doesn't match with the platform_driver.driver.name then your
> probe
> >> function will not be called at all.
> >>
> >>> Can you just copy the board-omap3evm.c changes related to
> >>>
> >> V4L2/DSS2 and give a shot? I think it should work straight away.
> >>
> >>> Please let me know if you need any further clarification or
> help.
> >>>
> >>> Thanks,
> >>> Vaibhav Hiremath
> >>> Platform Support Products
> >>> Texas Instruments Inc
> >>> Ph: +91-80-25099927
> >>>
> >>>
> >>>
> -Original Message-
> From: George.Qiao [mailto:qiao_shans...@visualon.com]
> Sent: Thursday, May 07, 2009 12:55 PM
> To: Hiremath, Vaibhav
> Cc: Syed Mohammed, Khasim; Shah, Hardik;
> wan_jin...@visualon.com;
> Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit;
> Andrews,
> Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xue
Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files
- Original Message - From: "Shilimkar, Santosh" To: "V, Hemanth" ; Cc: Sent: Friday, May 08, 2009 11:18 AM Subject: RE: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files -Original Message- From: V, Hemanth Sent: Friday, May 08, 2009 11:16 AM To: Shilimkar, Santosh; linux-arm-ker...@lists.arm.linux.org.uk Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files Original Message - From: "Santosh Shilimkar" Subject: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files > diff --git a/arch/arm/mach-omap2/omap-headsmp.S > b/arch/arm/mach-omap2/omap-headsmp.S > new file mode 100644 > index 000..0afe039 > --- /dev/null > +++ b/arch/arm/mach-omap2/omap-headsmp.S > @@ -0,0 +1,49 @@ > +/* > + * 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 > + > + __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. > + */ Is initialization done by u-boot like icache_enable taken care somewhere for the secondary cpu. U-boot has no knowledge of secondary CPUs. Kernel takes care of it with help of ROM code. For my information could you pl point to the routine which does this, i.e enable instruction cache on the secondary cpu. -- 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/3] OMAP4: SMP: Add OMAP4430 SMP board files
> -Original Message- > From: V, Hemanth > Sent: Friday, May 08, 2009 11:16 AM > To: Shilimkar, Santosh; linux-arm-ker...@lists.arm.linux.org.uk > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files > > Original Message - > From: "Santosh Shilimkar" > Subject: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files > > > > diff --git a/arch/arm/mach-omap2/omap-headsmp.S > > b/arch/arm/mach-omap2/omap-headsmp.S > > new file mode 100644 > > index 000..0afe039 > > --- /dev/null > > +++ b/arch/arm/mach-omap2/omap-headsmp.S > > @@ -0,0 +1,49 @@ > > +/* > > + * 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 > > + > > + __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. > > + */ > > Is initialization done by u-boot like icache_enable taken > care somewhere > for the secondary cpu. U-boot has no knowledge of secondary CPUs. Kernel takes care of it with help of ROM code.-- 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/3] OMAP4: SMP: Add OMAP4430 SMP board files
Original Message - From: "Santosh Shilimkar" Subject: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S new file mode 100644 index 000..0afe039 --- /dev/null +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -0,0 +1,49 @@ +/* + * 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 + + __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. + */ Is initialization done by u-boot like icache_enable taken care somewhere for the secondary cpu. -- 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/5] More header clean-up
If this series is planned for this window then OMAP4 series also needs few
changes. Is it ?
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Friday, May 08, 2009 2:12 AM
> To: linux-omap@vger.kernel.org
> Subject: [PATCH 0/5] More header clean-up
>
> Hi all,
>
> This series cleans up the conflicting defines a bit more.
> Now the biggest problem is till in clock24xx.h, but at least the
> conflict is local. Now changing the processors should not cause
> everything to be rebuilt..
>
> The first patch also fixes the CONFIG_SPINLOCK_DEBUG problem where
> sched_clock was called before we have things initialized.
>
> This series causes some updates to the other pending patch series,
> like the PM series. But it would be nice to get in before we add
> more code.
>
> Kevin, the 2/5 is improved version of what I sent you earlier,
> the earlier version had issues between 2420 vs 2430. Let me
> know if the other patches cause big headaches for your PM
> series.
>
> Regards,
>
> Tony
>
> ---
>
> Tony Lindgren (5):
> ARM: OMAP2/3: Remove OMAP_CM_REGADDR
> ARM: OMAP2/3: Remove OMAP2_PRCM_BASE
> ARM: OMAP2/3: Move define of OMAP2_VA_IC_BASE to be
> local to entry-macro.S
> ARM: OMAP2/3: Remove OMAP_PRM_REGADDR and OMAP2_PRM_BASE
> ARM: OMAP2/3: Remove OMAP2_32KSYNCT_BASE
>
>
> arch/arm/mach-omap2/clock24xx.c | 21 ++--
> arch/arm/mach-omap2/clock24xx.h | 11 ++
> arch/arm/mach-omap2/clock34xx.h |2
> arch/arm/mach-omap2/cm.h |5 -
> arch/arm/mach-omap2/prm.h | 136
> +
> arch/arm/mach-omap2/sdrc2xxx.c|5 +
> arch/arm/mach-omap2/sram242x.S|4 -
> arch/arm/mach-omap2/sram243x.S|4 -
> arch/arm/plat-omap/common.c | 69 +++--
> arch/arm/plat-omap/include/mach/entry-macro.S |9 +-
> arch/arm/plat-omap/include/mach/omap24xx.h| 18 ---
> arch/arm/plat-omap/include/mach/omap34xx.h|9 --
> 12 files changed, 170 insertions(+), 123 deletions(-)
>
> --
> 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
>
> N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
> ���j:+v���w�j�mzZ+�ݢj"��!�i
RE: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Friday, May 08, 2009 2:17 AM > To: Shilimkar, Santosh > Cc: linux-arm-ker...@lists.arm.linux.org.uk; > linux-omap@vger.kernel.org > Subject: Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files > > * Santosh Shilimkar [090507 00:29]: > > 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| 49 +++ > > arch/arm/mach-omap2/omap-smp.c| 238 > + > > arch/arm/plat-omap/include/mach/scu.h | 28 > > arch/arm/plat-omap/include/mach/smp.h | 56 > > 4 files changed, 371 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/scu.h > > create mode 100644 arch/arm/plat-omap/include/mach/smp.h > > > > > --- /dev/null > > +++ b/arch/arm/mach-omap2/omap-smp.c > > @@ -0,0 +1,238 @@ > > +/* > > + * 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 > > +#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) > > + > > +/* FIXME: Move to a common header file */ > > +extern void omap_secondary_startup(void); > > How about move this to cpu.h? Possible. The thing is this functions should be available only for OMAP4 SMP. We may need #ifdef ARCH_OMAP4. Is that ok ? -- 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/1] ASoC: Added OMAP3 EVM support in ASoC.
On Thu, May 7, 2009 at 9:38 PM, Anuj Aggarwal wrote:
>
> Signed-off-by: Anuj Aggarwal
> ---
> sound/soc/omap/Kconfig | 8 +++
> sound/soc/omap/Makefile | 2 +
> sound/soc/omap/omap3evm.c | 147
> +
> 3 files changed, 157 insertions(+), 0 deletions(-)
> create mode 100644 sound/soc/omap/omap3evm.c
>
> diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
> index 675732e..b771238 100644
> --- a/sound/soc/omap/Kconfig
> +++ b/sound/soc/omap/Kconfig
> @@ -39,6 +39,14 @@ config SND_OMAP_SOC_OMAP2EVM
> help
> Say Y if you want to add support for SoC audio on the omap2evm board.
>
> +config SND_OMAP_SOC_OMAP3EVM
> + tristate "SoC Audio support for OMAP3EVM board"
> + depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3EVM
> + select SND_OMAP_SOC_MCBSP
> + select SND_SOC_TWL4030
> + help
> + Say Y if you want to add support for SoC audio on the omap3evm
> board.
> +
> config SND_OMAP_SOC_SDP3430
> tristate "SoC Audio support for Texas Instruments SDP3430"
> depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_3430SDP
> diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
> index 0c9e4ac..a37f498 100644
> --- a/sound/soc/omap/Makefile
> +++ b/sound/soc/omap/Makefile
> @@ -10,6 +10,7 @@ snd-soc-n810-objs := n810.o
> snd-soc-osk5912-objs := osk5912.o
> snd-soc-overo-objs := overo.o
> snd-soc-omap2evm-objs := omap2evm.o
> +snd-soc-omap3evm-objs := omap3evm.o
> snd-soc-sdp3430-objs := sdp3430.o
> snd-soc-omap3pandora-objs := omap3pandora.o
> snd-soc-omap3beagle-objs := omap3beagle.o
> @@ -18,6 +19,7 @@ obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
> obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o
> obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o
> obj-$(CONFIG_MACH_OMAP2EVM) += snd-soc-omap2evm.o
> +obj-$(CONFIG_MACH_OMAP3EVM) += snd-soc-omap3evm.o
> obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o
> obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o
> obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o
> diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3evm.c
> new file mode 100644
> index 000..2af5d93
> --- /dev/null
> +++ b/sound/soc/omap/omap3evm.c
> @@ -0,0 +1,147 @@
> +/*
> + * omap3evm.c -- ALSA SoC support for OMAP3 EVM
> + *
> + * Author: Anuj Aggarwal
> + *
> + * Based on sound/soc/omap/beagle.c by Steve Sakoman
> + *
> + * Copyright (C) 2008 Texas Instruments, Incorporated
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
> + * whether express or implied; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "omap-mcbsp.h"
> +#include "omap-pcm.h"
> +#include "../codecs/twl4030.h"
> +
> +static int omap3evm_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct snd_soc_dai *codec_dai = rtd->dai->codec_dai;
> + struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
> + int ret;
> +
> + /* Set codec DAI configuration */
> + ret = snd_soc_dai_set_fmt(codec_dai,
> + SND_SOC_DAIFMT_I2S |
> + SND_SOC_DAIFMT_NB_NF |
> + SND_SOC_DAIFMT_CBM_CFM);
> + if (ret < 0) {
> + printk(KERN_ERR "Can't set codec DAI configuration\n");
> + return ret;
> + }
> +
> + /* Set cpu DAI configuration */
> + ret = snd_soc_dai_set_fmt(cpu_dai,
> + SND_SOC_DAIFMT_I2S |
> + SND_SOC_DAIFMT_NB_NF |
> + SND_SOC_DAIFMT_CBM_CFM);
> + if (ret < 0) {
> + printk(KERN_ERR "Can't set cpu DAI configuration\n");
> + return ret;
> + }
> +
> + /* Set the codec system clock for DAC and ADC */
> + ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600,
> + SND_SOC_CLOCK_IN);
> + if (ret < 0) {
> + printk(KERN_ERR "Can't set codec system clock\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static struct snd_soc_ops omap3evm_ops = {
> + .hw_params = omap3evm_hw_params,
> +};
> +
> +/* Digital audio interface glue - connects codec <--> CPU */
> +static struct snd_soc_dai_link omap3evm_dai = {
> + .name = "
Re: [RFC/PATCH 1/3] omap3-iommu: reorganize
From: "Balbi Felipe (Nokia-D/Helsinki)"
Subject: Re: [RFC/PATCH 1/3] omap3-iommu: reorganize
Date: Thu, 7 May 2009 23:14:47 +0200
> On Thu, May 07, 2009 at 10:11:07PM +0200, ext Felipe Contreras wrote:
> > -static struct resource omap3_iommu_res[] = {
> > - { /* Camera ISP MMU */
> > - .start = OMAP3_MMU1_BASE,
> > - .end= OMAP3_MMU1_BASE + MMU_REG_SIZE - 1,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3_MMU1_IRQ,
> > - .flags = IORESOURCE_IRQ,
> > - },
> > - { /* IVA2.2 MMU */
> > - .start = OMAP3_MMU2_BASE,
> > - .end= OMAP3_MMU2_BASE + MMU_REG_SIZE - 1,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3_MMU2_IRQ,
> > - .flags = IORESOURCE_IRQ,
> > - },
>
> i find this one much more readable :-s
>
> > +struct iommu_device {
> > + resource_size_t base;
> > + resource_size_t irq;
> > + struct iommu_platform_data pdata;
>
> generally, platform_data is a void *. Don't know if it matters here.
>
> > + struct resource res[2];
> > };
> > -#define NR_IOMMU_RES (ARRAY_SIZE(omap3_iommu_res) / 2)
> >
> > -static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
> > +static struct iommu_device devices[] = {
> > {
> > - .name = "isp",
> > - .nr_tlb_entries = 8,
> > - .clk_name = "cam_ick",
> > + .base = 0x480bd400,
> > + .irq = 24,
> > + .pdata = {
> > + .name = "isp",
> > + .nr_tlb_entries = 8,
> > + .clk_name = "cam_ick",
>
> still passing clk names ? what about clkdev ?
Useful comment, I'll update mine;) 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: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
Hi Felipe,
From: ext Felipe Contreras
Subject: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
Date: Thu, 7 May 2009 22:11:06 +0200
> This patch series cleanups up a bit the opap3-iommu device registration and
> then allows registration from other parts of the code.
I think that this part of code is just a simple conventional
platform_device registration and there may be no need to add more
complexicity by introducing a new special structure/function just for
a workaround of a client module("tidspbridge"). Also having these
device registrations here and there doesn't look so nice, looking at
other ones around kernel.
> Currently the iva2 code (tidspbridge) is not using iommu, therefore it can't
> be
> used as-is with the current omap iommu. By allowing devies to be registered
> externaly (either isp, or iva2) this problem goes away.
Fixing tidspbridge itself is the way to go, and it seems that Hari has
already verified this iommu with tidspbridge and he's pointed out some
of missing features(*1). I hope that tidspbridge will start to use
iommu soon.
*1: http://marc.info/?l=linux-omap&m=124148814309478&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: [PATCH 3/6] omap iommu: omap3 iommu device registration
Hi Felipe,
From: ext Felipe Contreras
Subject: Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
Date: Thu, 7 May 2009 22:05:00 +0200
> On Tue, May 5, 2009 at 3:47 PM, Hiroshi DOYU wrote:
> > Signed-off-by: Hiroshi DOYU
> > ---
> >
> > arch/arm/mach-omap2/omap3-iommu.c | 105
> > +
> > 1 files changed, 105 insertions(+), 0 deletions(-)
> > create mode 100644 arch/arm/mach-omap2/omap3-iommu.c
> >
> > diff --git a/arch/arm/mach-omap2/omap3-iommu.c
> > b/arch/arm/mach-omap2/omap3-iommu.c
> > new file mode 100644
> > index 000..367f36a
> > --- /dev/null
> > +++ b/arch/arm/mach-omap2/omap3-iommu.c
> > @@ -0,0 +1,105 @@
> > +/*
> > + * omap iommu: omap3 device registration
> > + *
> > + * Copyright (C) 2008-2009 Nokia Corporation
> > + *
> > + * Written by Hiroshi DOYU
> > + *
> > + * 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
> > +
> > +#define OMAP3_MMU1_BASE 0x480bd400
> > +#define OMAP3_MMU2_BASE 0x5d00
> > +#define OMAP3_MMU1_IRQ 24
> > +#define OMAP3_MMU2_IRQ 28
> > +
> > +static struct resource omap3_iommu_res[] = {
> > + { /* Camera ISP MMU */
> > + .start = OMAP3_MMU1_BASE,
> > + .end = OMAP3_MMU1_BASE + MMU_REG_SIZE - 1,
> > + .flags = IORESOURCE_MEM,
> > + },
> > + {
> > + .start = OMAP3_MMU1_IRQ,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + { /* IVA2.2 MMU */
> > + .start = OMAP3_MMU2_BASE,
> > + .end = OMAP3_MMU2_BASE + MMU_REG_SIZE - 1,
> > + .flags = IORESOURCE_MEM,
> > + },
> > + {
> > + .start = OMAP3_MMU2_IRQ,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > +};
> > +#define NR_IOMMU_RES (ARRAY_SIZE(omap3_iommu_res) / 2)
>
>
>
> > + err = platform_device_add_resources(pdev,
> > + &omap3_iommu_res[2 * i], NR_IOMMU_RES);
>
> This is wrong. In this particular case NR_IOMMU_RES is 2, but not
> because there's 2 resources: MEM and IRQ, but because there's 2 iommu
> devices: isp and iva2.
Does the following make sense?
+#define NR_IOMMU_RES 2
+ err = platform_device_add_resources(pdev,
+ omap3_iommu_res + i * NR_IOMMU_RES,
NR_IOMMU_RES);
--
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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
Stanley.miao wrote: > Russell King - ARM Linux wrote: > > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: > > > >> Hi, Tony, > >> > >> Now the kernel can't boot on LDP. The attached file is the boot log. > >> > > > > No boot log found. > > > > > > > Sorry, forgot to attach the boot log. > > It is linux-omap master branch. > > Stanley. Looks like you used the CodeSourcery 2007q3 toolchain. This had been reported earlier. Switching to 2008q3 works. - Anand -- 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
Russell King - ARM Linux wrote: On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: Hi, Tony, Now the kernel can't boot on LDP. The attached file is the boot log. No boot log found. Sorry, forgot to attach the boot log. It is linux-omap master branch. Stanley. Uncompressing Linux done, booting the kernel. <5>Linux version 2.6.30-rc4-omap1-05873-g2489dcb (stan...@stanley-desktop) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53)) #1 Thu May 7 22:52:12 CST9 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP LDP board Memory policy: ECC disabled, Data cache writeback <7>On node 0 totalpages: 32768 <7>free_area_init_node: node 0, pgdat c038db50, node_mem_map c03a9000 <7> Normal zone: 256 pages used for memmap <7> Normal zone: 0 pages reserved <7> Normal zone: 32512 pages, LIFO batch:7 <6>OMAP3430 ES2.1 <6>SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 <5>Kernel command line: root=/dev/nfs rw nfsroot=128.224.163.169:/export/rootfs console=ttyS2,115200n8 mem=128M ip=128.224.163.125:128.224.163.169:128.224.162.1:25} <6>NR_IRQS:402 <6>Clocking rate (Crystal/DPLL/ARM core): 26.0/266/500 MHz <6>GPMC revision 5.0 <6>IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts <6>Total of 96 interrupts on 1 active controller <6>OMAP34xx GPIO hardware version 2.5 PID hash table entries: 512 (order: 9, 2048 bytes) <6>OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 <6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) <6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) <6>Memory: 128MB = 128MB total <5>Memory: 126036KB available (3176K code, 292K data, 132K init, 0K highmem) <6>Calibrating delay loop...
Re: [RFC/PATCH 1/3] omap3-iommu: reorganize
On Fri, May 8, 2009 at 12:14 AM, Felipe Balbi wrote:
> On Thu, May 07, 2009 at 10:11:07PM +0200, ext Felipe Contreras wrote:
>> -static struct resource omap3_iommu_res[] = {
>> - { /* Camera ISP MMU */
>> - .start = OMAP3_MMU1_BASE,
>> - .end = OMAP3_MMU1_BASE + MMU_REG_SIZE - 1,
>> - .flags = IORESOURCE_MEM,
>> - },
>> - {
>> - .start = OMAP3_MMU1_IRQ,
>> - .flags = IORESOURCE_IRQ,
>> - },
>> - { /* IVA2.2 MMU */
>> - .start = OMAP3_MMU2_BASE,
>> - .end = OMAP3_MMU2_BASE + MMU_REG_SIZE - 1,
>> - .flags = IORESOURCE_MEM,
>> - },
>> - {
>> - .start = OMAP3_MMU2_IRQ,
>> - .flags = IORESOURCE_IRQ,
>> - },
>
> i find this one much more readable :-s
You find an array of 'struct resource' more readable than this?
+ .base = 0x480bd400,
+ .irq = 24,
+ .base = 0x5d00,
+ .irq = 28,
+ res[0].start = d->base;
+ res[0].end = d->base + MMU_REG_SIZE - 1;
+
+ res[1].start = d->irq;
How would you calculate the number of resources per iommu device?
How about these?
- err = platform_device_add_resources(pdev,
- &omap3_iommu_res[2 * i], NR_IOMMU_RES);
+ err = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
if (err)
goto err_out;
- err = platform_device_add_data(pdev, &omap3_iommu_pdata[i],
- sizeof(omap3_iommu_pdata[0]));
+ err = platform_device_add_data(pdev, &d->pdata,
sizeof(d->pdata));
if (err)
goto err_out;
Do you find the original version easier to read?
>> +struct iommu_device {
>> + resource_size_t base;
>> + resource_size_t irq;
>> + struct iommu_platform_data pdata;
>
> generally, platform_data is a void *. Don't know if it matters here.
Yes but we need to set the actual contents for platform_device_add_data.
>> + struct resource res[2];
>> };
>> -#define NR_IOMMU_RES (ARRAY_SIZE(omap3_iommu_res) / 2)
>>
>> -static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
>> +static struct iommu_device devices[] = {
>> {
>> - .name = "isp",
>> - .nr_tlb_entries = 8,
>> - .clk_name = "cam_ick",
>> + .base = 0x480bd400,
>> + .irq = 24,
>> + .pdata = {
>> + .name = "isp",
>> + .nr_tlb_entries = 8,
>> + .clk_name = "cam_ick",
>
> still passing clk names ? what about clkdev ?
That's for iommu to fix. I'm simply interested on decoupling iommu and
a hypothetical tidspbridge that doesn't exists yet.
--
Felipe Contreras
--
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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
* stanley.miao [090507 07:59]: > Tony Lindgren wrote: >> * Tony Lindgren [090505 21:00]: >> >>> * Russell King - ARM Linux [090505 12:52]: >>> On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux [090428 15:07]: > >> Tony, et.al., >> >> Any ideas when more LDP support will be pushed into mainline (such as >> the framebuffer support)? >> > I'll be looking at the board-*.c patches for the next merge window > hopefully this week or next week. > > Looks like LDP keyboard, touchscreen & RTC are pretty much ready > to go. Then the MMC has some regulator updates, but AFAIK the MMC > should work OK already. > > For the framebuffer, Imre and Tomi know the status the best, so > I've added them to Cc. > > Imre has been meaning to send a bunch of drivers/video/omap changes > to the fbdev list for a while now and LDP framebuffer may depend on > those. Imre, any news on the status of sending the fb patches > upstream? > > Then there are the upcoming DSS patches from Tomi, but those still > need some work before they're ready to go. > Is there any news on this? Will we see more functional OMAP3 / LDP support queued for the next merge window? >>> Yes fro the stuff listed above, but still no news on the framebuffer >>> patches. Imre? >>> >> >> Added Stanley Miao to Cc. Here's an updated version of Stanley's patch to >> add fb support for LDP. >> >> I don't have an LDP, maybe you guys can give it a try against the mainline >> kernel and see if it works! There might be some changes needed to >> drivers/video/omap/dispc.c too.. And those should be handled by Imre. >> >> But if this works, at least we can then add support for few more boards >> easily while waiting for Imre to send his updates. >> > Hi, Tony, > > Now the kernel can't boot on LDP. The attached file is the boot log. > > I will check it when I have time. Looks like the get_dss_clocks() in dispc.c at least needs updating for omap3. It should use clkdev too now btw. 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
[PATCH 2/3] OMAP3:zoom2: Defconfig for Zoom2 board
This patch adds OMAP3 Zoom2 board defconfig. Signed-off-by: Mikkel Christensen Signed-off-by: Vikram Pandita --- arch/arm/configs/omap3_zoom2_defconfig | 1211 1 files changed, 1211 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/omap3_zoom2_defconfig diff --git a/arch/arm/configs/omap3_zoom2_defconfig b/arch/arm/configs/omap3_zoom2_defconfig new file mode 100644 index 000..213fe9c --- /dev/null +++ b/arch/arm/configs/omap3_zoom2_defconfig @@ -0,0 +1,1211 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.27-rc5 +# Fri Oct 10 11:49:41 2008 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_MMU=y +# CONFIG_NO_IOPORT is not set +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_ARCH_SUPPORTS_AOUT=y +CONFIG_ZONE_DMA=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +# CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is not set +# CONFIG_HAVE_IOREMAP_PROT is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +# CONFIG_HAVE_ARCH_TRACEHOOK is not set +# CONFIG_HAVE_DMA_ATTRS is not set +# CONFIG_USE_GENERIC_SMP_HELPERS is not set +CONFIG_HAVE_CLK=y +CONFIG_PROC_PAGE_MONITOR=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_KMOD=y +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" +CONFIG_CLASSIC_RCU=y + +# +# System Type +# +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS7500 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_IMX is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is not set +# CONFIG_ARCH_L7200 is not set +# CONFIG_ARCH_KIRKWOOD is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_LOKI is not set +# CONFIG_ARCH_MV78XX0 is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_PNX4008 is not set +# CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_RPC is not set +# CONFIG_ARCH_SA1100 is not set +# CONFIG_ARCH_S3C2410 is not set +# CONFIG_ARCH_SHARK is not set +# CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_DAVINCI is not set +CONFIG
[PATCH 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board
This patch creates the minimal OMAP3 Zoom2 board support.
Signed-off-by: Mikkel Christensen
Signed-off-by: Vikram Pandita
---
arch/arm/mach-omap2/board-zoom2-debugboard.c | 150 ++
arch/arm/mach-omap2/board-zoom2.c| 126 +
2 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom2-debugboard.c
create mode 100644 arch/arm/mach-omap2/board-zoom2.c
diff --git a/arch/arm/mach-omap2/board-zoom2-debugboard.c
b/arch/arm/mach-omap2/board-zoom2-debugboard.c
new file mode 100644
index 000..ae90f2b
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom2-debugboard.c
@@ -0,0 +1,150 @@
+/*
+ * arch/arm/mach-omap2/board-zoom2-debugboard.c
+ *
+ * OMAP3 Zoom2 debug board support.
+ *
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Mikkel Christensen
+ *
+ * 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
+#include
+#include
+#include
+
+#define ZOOM2_SMSC911X_CS 7
+#define ZOOM2_SMSC911X_GPIO158
+#define ZOOM2_QUADUART_CS 3
+#define ZOOM2_QUADUART_GPIO102
+#define QUART_CLK 1843200
+#define DEBUG_BASE 0x0800
+#define ZOOM2_ETHR_START DEBUG_BASE
+
+static struct resource zoom2_smsc911x_resources[] = {
+ [0] = {
+ .start = ZOOM2_ETHR_START,
+ .end= ZOOM2_ETHR_START + SZ_4K,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = 0,
+ .end= 0,
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ },
+};
+
+static struct smsc911x_platform_config zoom2_smsc911x_config = {
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = SMSC911X_USE_32BIT,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
+static struct platform_device zoom2_smsc911x_device = {
+ .name = "smsc911x",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(zoom2_smsc911x_resources),
+ .resource = zoom2_smsc911x_resources,
+ .dev= {
+ .platform_data = &zoom2_smsc911x_config,
+ },
+};
+
+static inline void __init zoom2_init_smsc911x(void)
+{
+ int eth_cs;
+ unsigned long cs_mem_base;
+ int eth_gpio = 0;
+
+ eth_cs = ZOOM2_SMSC911X_CS;
+
+ if (gpmc_cs_request(eth_cs, SZ_16M, &cs_mem_base) < 0) {
+ printk(KERN_ERR "Failed to request GPMC mem for smsc911x\n");
+ return;
+ }
+
+ zoom2_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ zoom2_smsc911x_resources[0].end = cs_mem_base + 0xff;
+ udelay(100);
+
+ eth_gpio = ZOOM2_SMSC911X_GPIO;
+
+ zoom2_smsc911x_resources[1].start = OMAP_GPIO_IRQ(eth_gpio);
+
+ if (gpio_request(eth_gpio, "smsc911x irq") < 0) {
+ printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
+ eth_gpio);
+ return;
+ }
+ gpio_direction_input(eth_gpio);
+}
+
+static struct plat_serial8250_port serial_platform_data[] = {
+ {
+ .membase= 0,
+ .mapbase= 0x1000,
+ .irq= OMAP_GPIO_IRQ(102),
+ .flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
+ .iotype = UPIO_MEM,
+ .regshift = 1,
+ .uartclk= QUART_CLK,
+ }, {
+ .flags = 0
+ }
+};
+
+static struct platform_device zoom2_debugboard_serial_device = {
+ .name = "serial8250",
+ .id = PLAT8250_DEV_PLATFORM1,
+ .dev= {
+ .platform_data = serial_platform_data,
+ },
+};
+
+static inline void __init zoom2_init_quaduart(void)
+{
+ int quart_cs;
+ unsigned long cs_mem_base;
+ int quart_gpio = 0;
+
+ quart_cs = ZOOM2_QUADUART_CS;
+
+ if (gpmc_cs_request(quart_cs, SZ_1M, &cs_mem_base) < 0) {
+ printk(KERN_ERR "Failed to request GPMC mem"
+ "for Quad UART(TL16CP754C)\n");
+ return;
+ }
+
+ quart_gpio = ZOOM2_QUADUART_GPIO;
+
+ if (gpio_request(quart_gpio, "TL16CP754C GPIO") < 0) {
+ printk(KERN_ERR "Failed to request GPIO%d for TL16CP754C\n",
+ quart_gpio);
+ return;
+ }
+ gpio_direction_input(quart_gpio);
+}
+
+static struct platform_device *zoom2_devices[] __initdata = {
+ &zoom2_smsc911x_device,
+ &zoom2_debugboard_serial_device,
+};
+
+static int
[PATCH 3/3] OMAP3:zoom2: Makefile and Kconfig for Zoom2 board
This patch adds OMAP3 Zoom2 board to the Makefile and Kconfig. Signed-off-by: Mikkel Christensen Signed-off-by: Vikram Pandita --- arch/arm/mach-omap2/Kconfig |4 arch/arm/mach-omap2/Makefile |4 +++- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 64ab386..0b16255 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -67,3 +67,7 @@ config MACH_OMAP_3430SDP config MACH_NOKIA_RX51 bool "Nokia RX-51 board" depends on ARCH_OMAP3 && ARCH_OMAP34XX + +config MACH_OMAP_ZOOM2 + bool "OMAP3 Zoom2 board" + depends on ARCH_OMAP3 && ARCH_OMAP34XX \ No newline at end of file diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index c49d9bf..fe4485f 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -48,7 +48,9 @@ obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ board-rx51-peripherals.o \ mmc-twl4030.o - +obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \ + mmc-twl4030.o \ + board-zoom2-debugboard.o # Platform specific device init code ifeq ($(CONFIG_USB_MUSB_SOC),y) obj-y += usb-musb.o -- 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 0/3] Support for OMAP3 Zoom2 board
The following patch series adds support for Zoom2 board. The board has: - Modem attached to UART1 - WLAN attached to UART2 - GPS attached to UART3 An external debug board is included for console and LAN. For details refer to this site: http://www.logicpd.com/products/development-kits/texas-instruments-zoom%E2%84%A2-omap34x-ii-mdp Future work: - SMSC911x NFS mount problem - Low level debug uart need to use debug board - Dynamic detection of debug board presence TI wiki with FAQs on getting this board booting: https://omapzoom.org/gf/project/omapzoom/wiki/?pagename=GettingStartedWithZoomII_AKA_OMAP34XII_MDP -- 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: [RFC/PATCH 1/3] omap3-iommu: reorganize
On Thu, May 07, 2009 at 10:11:07PM +0200, ext Felipe Contreras wrote:
> -static struct resource omap3_iommu_res[] = {
> - { /* Camera ISP MMU */
> - .start = OMAP3_MMU1_BASE,
> - .end= OMAP3_MMU1_BASE + MMU_REG_SIZE - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3_MMU1_IRQ,
> - .flags = IORESOURCE_IRQ,
> - },
> - { /* IVA2.2 MMU */
> - .start = OMAP3_MMU2_BASE,
> - .end= OMAP3_MMU2_BASE + MMU_REG_SIZE - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = OMAP3_MMU2_IRQ,
> - .flags = IORESOURCE_IRQ,
> - },
i find this one much more readable :-s
> +struct iommu_device {
> + resource_size_t base;
> + resource_size_t irq;
> + struct iommu_platform_data pdata;
generally, platform_data is a void *. Don't know if it matters here.
> + struct resource res[2];
> };
> -#define NR_IOMMU_RES (ARRAY_SIZE(omap3_iommu_res) / 2)
>
> -static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
> +static struct iommu_device devices[] = {
> {
> - .name = "isp",
> - .nr_tlb_entries = 8,
> - .clk_name = "cam_ick",
> + .base = 0x480bd400,
> + .irq = 24,
> + .pdata = {
> + .name = "isp",
> + .nr_tlb_entries = 8,
> + .clk_name = "cam_ick",
still passing clk names ? what about clkdev ?
--
balbi
--
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: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Thursday, May 07, 2009 3:40 PM
> To: Kanigeri, Hari
> Cc: linux-omap@vger.kernel.org; Hiroshi DOYU; Felipe Contreras; Tony
> Lindgren
> Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
>
> On Thu, May 7, 2009 at 11:28 PM, Kanigeri, Hari
> wrote:
> >> Currently the iva2 code (tidspbridge) is not using iommu, therefore it
> >> can't be
> >> used as-is with the current omap iommu.
> >
> > Bridge can use IOMMU module that Hiroshi has sent by calling below 2
> lines of code.
> >
> > struct iommu *iva_iommu_ptr;
> > iva_iommu_ptr = iommu_get("iva2");
>
> From where? Care to send an actual patch?
>
I think it is in the initial set of patches that Hiroshi has sent some time ago.
He provided the link to it in this first email [patch 0/6].
http://marc.info/?l=linux-omap&m=122087083712670&w=2
Thank you,
Best regards,
Hari
--
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/3] OMAP4: SMP: Add OMAP4430 SMP board files
One more comment on this patch below.
* Santosh Shilimkar [090507 00:29]:
> 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| 49 +++
> arch/arm/mach-omap2/omap-smp.c| 238
> +
> arch/arm/plat-omap/include/mach/scu.h | 28
> arch/arm/plat-omap/include/mach/smp.h | 56
> 4 files changed, 371 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/scu.h
> create mode 100644 arch/arm/plat-omap/include/mach/smp.h
>
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> new file mode 100644
> index 000..1d18acb
> --- /dev/null
> +++ b/arch/arm/mach-omap2/omap-smp.c
> +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);
> +
> + /*
> + * The secondary processor is waiting for an event to come out of
> + * wfe. Release it, then wait for it to flag that it has been
> + * released by resetting cpu_release.
> + *
> + * Singal the ROM code that the secondary core can be released
> + */
> + cpu_release = cpu;
> + __raw_writel(cpu, OMAP4_AUXCOREBOOT_REG1);
> + flush_cache_all();
> + /*
> + * Send a 'sev' to wake the secondary core again because
> + * ROM code will put core in WFE till the cpu_release
> + * flag is set.
> + */
> + set_event();
> + mb();
> +
> + timeout = jiffies + (1 * HZ);
> + while (time_before(jiffies, timeout)) {
> + smp_rmb();
> + if (cpu_release == -1)
> + break;
> +
> + udelay(10);
> + }
> +
> + /*
> + * Now the secondary core is starting up let it run its
> + * calibrations, then wait for it to finish
> + */
> + spin_unlock(&boot_lock);
> +
> + return cpu_release != -1 ? -ENOSYS : 0;
> +}
The "Singal" should be "Signal" above :)
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 1/3] OMAP4: SMP: Add OMAP4430 SMP board files
* Santosh Shilimkar [090507 00:29]: > 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| 49 +++ > arch/arm/mach-omap2/omap-smp.c| 238 > + > arch/arm/plat-omap/include/mach/scu.h | 28 > arch/arm/plat-omap/include/mach/smp.h | 56 > 4 files changed, 371 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/scu.h > create mode 100644 arch/arm/plat-omap/include/mach/smp.h > --- /dev/null > +++ b/arch/arm/mach-omap2/omap-smp.c > @@ -0,0 +1,238 @@ > +/* > + * 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 > +#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) > + > +/* FIXME: Move to a common header file */ > +extern void omap_secondary_startup(void); How about move this to cpu.h? Regards, 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
[PATCH 5/5] ARM: OMAP2/3: Remove OMAP_CM_REGADDR
Processor specific macros should be used instead. Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/clock24xx.h|2 ++ arch/arm/mach-omap2/clock34xx.h|2 ++ arch/arm/mach-omap2/cm.h |5 - arch/arm/plat-omap/include/mach/omap24xx.h | 10 -- arch/arm/plat-omap/include/mach/omap34xx.h |6 -- 5 files changed, 4 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h index f0e4480..458f00c 100644 --- a/arch/arm/mach-omap2/clock24xx.h +++ b/arch/arm/mach-omap2/clock24xx.h @@ -26,9 +26,11 @@ /* REVISIT: These should be set dynamically for CONFIG_MULTI_OMAP2 */ #ifdef CONFIG_ARCH_OMAP2420 +#define OMAP_CM_REGADDROMAP2420_CM_REGADDR #define OMAP24XX_PRCM_CLKOUT_CTRL OMAP2420_PRCM_CLKOUT_CTRL #define OMAP24XX_PRCM_CLKEMUL_CTRL OMAP2420_PRCM_CLKEMUL_CTRL #else +#define OMAP_CM_REGADDROMAP2430_CM_REGADDR #define OMAP24XX_PRCM_CLKOUT_CTRL OMAP2430_PRCM_CLKOUT_CTRL #define OMAP24XX_PRCM_CLKEMUL_CTRL OMAP2430_PRCM_CLKEMUL_CTRL #endif diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h index 017a30e..496f0e9 100644 --- a/arch/arm/mach-omap2/clock34xx.h +++ b/arch/arm/mach-omap2/clock34xx.h @@ -27,6 +27,8 @@ #include "prm.h" #include "prm-regbits-34xx.h" +#define OMAP_CM_REGADDROMAP34XX_CM_REGADDR + static unsigned long omap3_dpll_recalc(struct clk *clk); static unsigned long omap3_clkoutx2_recalc(struct clk *clk); static void omap3_dpll_allow_idle(struct clk *clk); diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index 65fdf78..04c5fc5 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -16,17 +16,12 @@ #include "prcm-common.h" -#ifndef __ASSEMBLER__ -#define OMAP_CM_REGADDR(module, reg) \ - IO_ADDRESS(OMAP2_CM_BASE + (module) + (reg)) -#else #define OMAP2420_CM_REGADDR(module, reg) \ IO_ADDRESS(OMAP2420_CM_BASE + (module) + (reg)) #define OMAP2430_CM_REGADDR(module, reg) \ IO_ADDRESS(OMAP2430_CM_BASE + (module) + (reg)) #define OMAP34XX_CM_REGADDR(module, reg) \ IO_ADDRESS(OMAP3430_CM_BASE + (module) + (reg)) -#endif /* * Architecture-specific global CM registers diff --git a/arch/arm/plat-omap/include/mach/omap24xx.h b/arch/arm/plat-omap/include/mach/omap24xx.h index 60f8324..696edfc 100644 --- a/arch/arm/plat-omap/include/mach/omap24xx.h +++ b/arch/arm/plat-omap/include/mach/omap24xx.h @@ -85,15 +85,5 @@ #define OMAP24XX_SEC_AES_BASE (OMAP24XX_SEC_BASE + 0x6000) #define OMAP24XX_SEC_PKA_BASE (OMAP24XX_SEC_BASE + 0x8000) -#if defined(CONFIG_ARCH_OMAP2420) - -#define OMAP2_CM_BASE OMAP2420_CM_BASE - -#elif defined(CONFIG_ARCH_OMAP2430) - -#define OMAP2_CM_BASE OMAP2430_CM_BASE - -#endif - #endif /* __ASM_ARCH_OMAP24XX_H */ diff --git a/arch/arm/plat-omap/include/mach/omap34xx.h b/arch/arm/plat-omap/include/mach/omap34xx.h index 36c99ca..cc25733 100644 --- a/arch/arm/plat-omap/include/mach/omap34xx.h +++ b/arch/arm/plat-omap/include/mach/omap34xx.h @@ -83,12 +83,6 @@ #define OMAP34XX_MAILBOX_BASE (L4_34XX_BASE + 0x94000) -#if defined(CONFIG_ARCH_OMAP3430) - -#define OMAP2_CM_BASE OMAP3430_CM_BASE - -#endif - #define OMAP34XX_DSP_BASE 0x5800 #define OMAP34XX_DSP_MEM_BASE (OMAP34XX_DSP_BASE + 0x0) #define OMAP34XX_DSP_IPI_BASE (OMAP34XX_DSP_BASE + 0x100) -- 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: OMAP2/3: Remove OMAP2_PRCM_BASE
It's currently unused, and processor specific defines should be used instead. Signed-off-by: Tony Lindgren --- arch/arm/plat-omap/include/mach/omap24xx.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/omap24xx.h b/arch/arm/plat-omap/include/mach/omap24xx.h index 4ce9b6a..60f8324 100644 --- a/arch/arm/plat-omap/include/mach/omap24xx.h +++ b/arch/arm/plat-omap/include/mach/omap24xx.h @@ -87,12 +87,10 @@ #if defined(CONFIG_ARCH_OMAP2420) -#define OMAP2_PRCM_BASEOMAP2420_PRCM_BASE #define OMAP2_CM_BASE OMAP2420_CM_BASE #elif defined(CONFIG_ARCH_OMAP2430) -#define OMAP2_PRCM_BASEOMAP2430_PRCM_BASE #define OMAP2_CM_BASE OMAP2430_CM_BASE #endif -- 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 3/5] ARM: OMAP2/3: Move define of OMAP2_VA_IC_BASE to be local to entry-macro.S
Move define of OMAP2_VA_IC_BASE to be local to entry-macro.S Signed-off-by: Tony Lindgren --- arch/arm/plat-omap/include/mach/entry-macro.S |9 ++--- arch/arm/plat-omap/include/mach/omap24xx.h|2 -- arch/arm/plat-omap/include/mach/omap34xx.h|1 - 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/entry-macro.S b/arch/arm/plat-omap/include/mach/entry-macro.S index 2276f89..33256a0 100644 --- a/arch/arm/plat-omap/include/mach/entry-macro.S +++ b/arch/arm/plat-omap/include/mach/entry-macro.S @@ -58,11 +58,14 @@ #endif #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX) -#if defined(CONFIG_ARCH_OMAP24XX) #include -#endif -#if defined(CONFIG_ARCH_OMAP34XX) #include + +/* REVISIT: This should be set dynamically if CONFIG_MULTI_OMAP2 is selected */ +#if defined(CONFIG_ARCH_OMAP2420) || defined(CONFIG_ARCH_OMAP2430) +#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP24XX_IC_BASE) +#elif defined(CONFIG_ARCH_OMAP34XX) +#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP34XX_IC_BASE) #endif #define INTCPS_SIR_IRQ_OFFSET 0x0040 /* Active interrupt offset */ diff --git a/arch/arm/plat-omap/include/mach/omap24xx.h b/arch/arm/plat-omap/include/mach/omap24xx.h index 10a6413..4ce9b6a 100644 --- a/arch/arm/plat-omap/include/mach/omap24xx.h +++ b/arch/arm/plat-omap/include/mach/omap24xx.h @@ -89,13 +89,11 @@ #define OMAP2_PRCM_BASEOMAP2420_PRCM_BASE #define OMAP2_CM_BASE OMAP2420_CM_BASE -#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP24XX_IC_BASE) #elif defined(CONFIG_ARCH_OMAP2430) #define OMAP2_PRCM_BASEOMAP2430_PRCM_BASE #define OMAP2_CM_BASE OMAP2430_CM_BASE -#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP24XX_IC_BASE) #endif diff --git a/arch/arm/plat-omap/include/mach/omap34xx.h b/arch/arm/plat-omap/include/mach/omap34xx.h index 4233064..36c99ca 100644 --- a/arch/arm/plat-omap/include/mach/omap34xx.h +++ b/arch/arm/plat-omap/include/mach/omap34xx.h @@ -86,7 +86,6 @@ #if defined(CONFIG_ARCH_OMAP3430) #define OMAP2_CM_BASE OMAP3430_CM_BASE -#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP34XX_IC_BASE) #endif -- 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/5] ARM: OMAP2/3: Remove OMAP_PRM_REGADDR and OMAP2_PRM_BASE
Remove OMAP_PRM_REGADDR and use processor specific defines instead.
Also remove now unused OMAP2_PRM_BASE.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/clock24xx.c| 21 ++--
arch/arm/mach-omap2/clock24xx.h|9 ++
arch/arm/mach-omap2/prm.h | 136 +++-
arch/arm/mach-omap2/sdrc2xxx.c |5 +
arch/arm/plat-omap/include/mach/omap24xx.h |2
arch/arm/plat-omap/include/mach/omap34xx.h |1
6 files changed, 98 insertions(+), 76 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index efc59c4..54b8671 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -233,6 +233,8 @@ static struct prcm_config *curr_prcm_set;
static struct clk *vclk;
static struct clk *sclk;
+static void __iomem *prcm_clksrc_ctrl;
+
/*-
* Omap24xx specific clock functions
*-*/
@@ -269,10 +271,9 @@ static int omap2_enable_osc_ck(struct clk *clk)
{
u32 pcc;
- pcc = __raw_readl(OMAP24XX_PRCM_CLKSRC_CTRL);
+ pcc = __raw_readl(prcm_clksrc_ctrl);
- __raw_writel(pcc & ~OMAP_AUTOEXTCLKMODE_MASK,
- OMAP24XX_PRCM_CLKSRC_CTRL);
+ __raw_writel(pcc & ~OMAP_AUTOEXTCLKMODE_MASK, prcm_clksrc_ctrl);
return 0;
}
@@ -281,10 +282,9 @@ static void omap2_disable_osc_ck(struct clk *clk)
{
u32 pcc;
- pcc = __raw_readl(OMAP24XX_PRCM_CLKSRC_CTRL);
+ pcc = __raw_readl(prcm_clksrc_ctrl);
- __raw_writel(pcc | OMAP_AUTOEXTCLKMODE_MASK,
- OMAP24XX_PRCM_CLKSRC_CTRL);
+ __raw_writel(pcc | OMAP_AUTOEXTCLKMODE_MASK, prcm_clksrc_ctrl);
}
static const struct clkops clkops_oscck = {
@@ -654,7 +654,7 @@ static u32 omap2_get_sysclkdiv(void)
{
u32 div;
- div = __raw_readl(OMAP24XX_PRCM_CLKSRC_CTRL);
+ div = __raw_readl(prcm_clksrc_ctrl);
div &= OMAP_SYSCLKDIV_MASK;
div >>= OMAP_SYSCLKDIV_SHIFT;
@@ -714,10 +714,13 @@ int __init omap2_clk_init(void)
struct omap_clk *c;
u32 clkrate;
- if (cpu_is_omap242x())
+ if (cpu_is_omap242x()) {
+ prcm_clksrc_ctrl = OMAP2420_PRCM_CLKSRC_CTRL;
cpu_mask = RATE_IN_242X;
- else if (cpu_is_omap2430())
+ } else if (cpu_is_omap2430()) {
+ prcm_clksrc_ctrl = OMAP2430_PRCM_CLKSRC_CTRL;
cpu_mask = RATE_IN_243X;
+ }
clk_init(&omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index 88c5acb..f0e4480 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -24,6 +24,15 @@
#include "cm-regbits-24xx.h"
#include "sdrc.h"
+/* REVISIT: These should be set dynamically for CONFIG_MULTI_OMAP2 */
+#ifdef CONFIG_ARCH_OMAP2420
+#define OMAP24XX_PRCM_CLKOUT_CTRL OMAP2420_PRCM_CLKOUT_CTRL
+#define OMAP24XX_PRCM_CLKEMUL_CTRL OMAP2420_PRCM_CLKEMUL_CTRL
+#else
+#define OMAP24XX_PRCM_CLKOUT_CTRL OMAP2430_PRCM_CLKOUT_CTRL
+#define OMAP24XX_PRCM_CLKEMUL_CTRL OMAP2430_PRCM_CLKEMUL_CTRL
+#endif
+
static unsigned long omap2_table_mpu_recalc(struct clk *clk);
static int omap2_select_table_rate(struct clk *clk, unsigned long rate);
static long omap2_round_to_table_rate(struct clk *clk, unsigned long rate);
diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h
index 826d326..2eb8399 100644
--- a/arch/arm/mach-omap2/prm.h
+++ b/arch/arm/mach-omap2/prm.h
@@ -16,17 +16,12 @@
#include "prcm-common.h"
-#ifndef __ASSEMBLER__
-#define OMAP_PRM_REGADDR(module, reg) \
- IO_ADDRESS(OMAP2_PRM_BASE + (module) + (reg))
-#else
#define OMAP2420_PRM_REGADDR(module, reg) \
IO_ADDRESS(OMAP2420_PRM_BASE + (module) + (reg))
#define OMAP2430_PRM_REGADDR(module, reg) \
IO_ADDRESS(OMAP2430_PRM_BASE + (module) + (reg))
#define OMAP34XX_PRM_REGADDR(module, reg) \
IO_ADDRESS(OMAP3430_PRM_BASE + (module) + (reg))
-#endif
/*
* Architecture-specific global PRM registers
@@ -54,64 +49,79 @@
#define OMAP243X_PRCM_CLKCFG_CTRL OMAP2430_PRM_REGADDR(OMAP24XX_GR_MOD,
\
OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET)
-/* These will disappear */
-#define OMAP24XX_PRCM_REVISION OMAP_PRM_REGADDR(OCP_MOD, 0x)
-#define OMAP24XX_PRCM_SYSCONFIGOMAP_PRM_REGADDR(OCP_MOD,
0x0010)
-
-#define OMAP24XX_PRCM_IRQSTATUS_MPUOMAP_PRM_REGADDR(OCP_MOD, 0x0018)
-#define OMAP24XX_PRCM_IRQENABLE_MPUOMAP_PRM_REGADDR(OCP_MOD, 0x001c)
-
-#define OMAP24XX_PRCM_VOLTST OMAP_PRM_REGADDR(OCP_MOD, 0x0054)
-#define OMA
[PATCH 1/5] ARM: OMAP2/3: Remove OMAP2_32KSYNCT_BASE
Use processor specific defines instead.
As an extra bonus, this patch fixes the problem of CONFIG_DEBUG_SPINLOCK
calling sched_clock before we have things initialized:
http://patchwork.kernel.org/patch/15810/
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/sram242x.S |4 +-
arch/arm/mach-omap2/sram243x.S |4 +-
arch/arm/plat-omap/common.c| 69
arch/arm/plat-omap/include/mach/omap24xx.h |2 -
arch/arm/plat-omap/include/mach/omap34xx.h |1
5 files changed, 62 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/sram242x.S b/arch/arm/mach-omap2/sram242x.S
index af4bd34..cbb8930 100644
--- a/arch/arm/mach-omap2/sram242x.S
+++ b/arch/arm/mach-omap2/sram242x.S
@@ -128,7 +128,7 @@ omap242x_sdi_prcm_voltctrl:
prcm_mask_val:
.word 0x3FFC
omap242x_sdi_timer_32ksynct_cr:
- .word IO_ADDRESS(OMAP2_32KSYNCT_BASE + 0x010)
+ .word IO_ADDRESS(OMAP2420_32KSYNCT_BASE + 0x010)
ENTRY(omap242x_sram_ddr_init_sz)
.word . - omap242x_sram_ddr_init
@@ -224,7 +224,7 @@ omap242x_srs_prcm_voltctrl:
ddr_prcm_mask_val:
.word 0x3FFC
omap242x_srs_timer_32ksynct:
- .word IO_ADDRESS(OMAP2_32KSYNCT_BASE + 0x010)
+ .word IO_ADDRESS(OMAP2420_32KSYNCT_BASE + 0x010)
ENTRY(omap242x_sram_reprogram_sdrc_sz)
.word . - omap242x_sram_reprogram_sdrc
diff --git a/arch/arm/mach-omap2/sram243x.S b/arch/arm/mach-omap2/sram243x.S
index 84363e2..054b0f3 100644
--- a/arch/arm/mach-omap2/sram243x.S
+++ b/arch/arm/mach-omap2/sram243x.S
@@ -128,7 +128,7 @@ omap243x_sdi_prcm_voltctrl:
prcm_mask_val:
.word 0x3FFC
omap243x_sdi_timer_32ksynct_cr:
- .word IO_ADDRESS(OMAP2_32KSYNCT_BASE + 0x010)
+ .word IO_ADDRESS(OMAP2430_32KSYNCT_BASE + 0x010)
ENTRY(omap243x_sram_ddr_init_sz)
.word . - omap243x_sram_ddr_init
@@ -224,7 +224,7 @@ omap243x_srs_prcm_voltctrl:
ddr_prcm_mask_val:
.word 0x3FFC
omap243x_srs_timer_32ksynct:
- .word IO_ADDRESS(OMAP2_32KSYNCT_BASE + 0x010)
+ .word IO_ADDRESS(OMAP2430_32KSYNCT_BASE + 0x010)
ENTRY(omap243x_sram_reprogram_sdrc_sz)
.word . - omap243x_sram_reprogram_sdrc
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 433021f..e1add78 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -175,25 +175,61 @@ console_initcall(omap_add_serial_console);
* but systems won't necessarily want to spend resources that way.
*/
-#if defined(CONFIG_ARCH_OMAP16XX)
-#define TIMER_32K_SYNCHRONIZED 0xfffbc410
-#elif defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
-#define TIMER_32K_SYNCHRONIZED (OMAP2_32KSYNCT_BASE + 0x10)
-#endif
+#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410
-#ifdef TIMER_32K_SYNCHRONIZED
+#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX))
#include
-static cycle_t omap_32k_read(struct clocksource *cs)
+#ifdef CONFIG_ARCH_OMAP16XX
+static cycle_t omap16xx_32k_read(struct clocksource *cs)
+{
+ return omap_readl(OMAP16XX_TIMER_32K_SYNCHRONIZED);
+}
+#else
+#define omap16xx_32k_read NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2420
+static cycle_t omap2420_32k_read(struct clocksource *cs)
+{
+ return omap_readl(OMAP2420_32KSYNCT_BASE + 0x10);
+}
+#else
+#define omap2420_32k_read NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2430
+static cycle_t omap2430_32k_read(struct clocksource *cs)
+{
+ return omap_readl(OMAP2430_32KSYNCT_BASE + 0x10);
+}
+#else
+#define omap2430_32k_read NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP34XX
+static cycle_t omap34xx_32k_read(struct clocksource *cs)
{
- return omap_readl(TIMER_32K_SYNCHRONIZED);
+ return omap_readl(OMAP3430_32KSYNCT_BASE + 0x10);
+}
+#else
+#define omap34xx_32k_read NULL
+#endif
+
+/*
+ * Kernel assumes that sched_clock can be called early but may not have
+ * things ready yet.
+ */
+static cycle_t omap_32k_read_dummy(struct clocksource *cs)
+{
+ return 0;
}
static struct clocksource clocksource_32k = {
.name = "32k_counter",
.rating = 250,
- .read = omap_32k_read,
+ .read = omap_32k_read_dummy,
.mask = CLOCKSOURCE_MASK(32),
.shift = 10,
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
@@ -207,7 +243,7 @@ unsigned long long sched_clock(void)
{
unsigned long long ret;
- ret = (unsigned long long)omap_32k_read(&clocksource_32k);
+ ret = (unsigned long long)clocksource_32k.read(&clocksource_32k);
ret = (ret * clocksource_32k.mult_orig) >> clocksource_32k.shift;
return ret;
}
@@ -220,6 +256,17 @@ static int __init omap_init_clocksource_32k(void)
if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
struct clk *sync_32k_ick;
+ if (cpu_is_omap16xx())
+ clocksource_32k.read
[PATCH 0/5] More header clean-up
Hi all, This series cleans up the conflicting defines a bit more. Now the biggest problem is till in clock24xx.h, but at least the conflict is local. Now changing the processors should not cause everything to be rebuilt.. The first patch also fixes the CONFIG_SPINLOCK_DEBUG problem where sched_clock was called before we have things initialized. This series causes some updates to the other pending patch series, like the PM series. But it would be nice to get in before we add more code. Kevin, the 2/5 is improved version of what I sent you earlier, the earlier version had issues between 2420 vs 2430. Let me know if the other patches cause big headaches for your PM series. Regards, Tony --- Tony Lindgren (5): ARM: OMAP2/3: Remove OMAP_CM_REGADDR ARM: OMAP2/3: Remove OMAP2_PRCM_BASE ARM: OMAP2/3: Move define of OMAP2_VA_IC_BASE to be local to entry-macro.S ARM: OMAP2/3: Remove OMAP_PRM_REGADDR and OMAP2_PRM_BASE ARM: OMAP2/3: Remove OMAP2_32KSYNCT_BASE arch/arm/mach-omap2/clock24xx.c | 21 ++-- arch/arm/mach-omap2/clock24xx.h | 11 ++ arch/arm/mach-omap2/clock34xx.h |2 arch/arm/mach-omap2/cm.h |5 - arch/arm/mach-omap2/prm.h | 136 + arch/arm/mach-omap2/sdrc2xxx.c|5 + arch/arm/mach-omap2/sram242x.S|4 - arch/arm/mach-omap2/sram243x.S|4 - arch/arm/plat-omap/common.c | 69 +++-- arch/arm/plat-omap/include/mach/entry-macro.S |9 +- arch/arm/plat-omap/include/mach/omap24xx.h| 18 --- arch/arm/plat-omap/include/mach/omap34xx.h|9 -- 12 files changed, 170 insertions(+), 123 deletions(-) -- 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
Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
On Thu, May 7, 2009 at 11:28 PM, Kanigeri, Hari wrote:
>> Currently the iva2 code (tidspbridge) is not using iommu, therefore it
>> can't be
>> used as-is with the current omap iommu.
>
> Bridge can use IOMMU module that Hiroshi has sent by calling below 2 lines of
> code.
>
> struct iommu *iva_iommu_ptr;
> iva_iommu_ptr = iommu_get("iva2");
>From where? Care to send an actual patch?
--
Felipe Contreras
--
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: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
> Currently the iva2 code (tidspbridge) is not using iommu, therefore it
> can't be
> used as-is with the current omap iommu.
Bridge can use IOMMU module that Hiroshi has sent by calling below 2 lines of
code.
struct iommu *iva_iommu_ptr;
iva_iommu_ptr = iommu_get("iva2");
Thank you,
Best regards,
Hari
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Felipe Contreras
> Sent: Thursday, May 07, 2009 3:11 PM
> To: linux-omap@vger.kernel.org
> Cc: Hiroshi DOYU; Felipe Contreras; Tony Lindgren; Felipe Contreras
> Subject: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
>
> This patch series cleanups up a bit the opap3-iommu device registration
> and
> then allows registration from other parts of the code.
>
> Currently the iva2 code (tidspbridge) is not using iommu, therefore it
> can't be
> used as-is with the current omap iommu. By allowing devies to be
> registered
> externaly (either isp, or iva2) this problem goes away.
>
> Felipe Contreras (3):
> omap3-iommu: reorganize
> omap3-iommu: split init function into omap_iommu_add
> omap3-iommu: remote registration
>
> arch/arm/mach-omap2/omap3-iommu.c | 130 ++
> -
> arch/arm/plat-omap/include/mach/iommu.h |2 +
> 2 files changed, 62 insertions(+), 70 deletions(-)
>
> --
> 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
[RFC/PATCH 2/3] omap3-iommu: split init function into omap_iommu_add
In preparation for external registration.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/omap3-iommu.c | 76 -
1 files changed, 49 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
index f4232ec..149c624 100644
--- a/arch/arm/mach-omap2/omap3-iommu.c
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -45,43 +45,65 @@ static struct iommu_device devices[] = {
static struct platform_device *omap3_iommu_pdev[NR_IOMMU_DEVICES];
-static int __init omap3_iommu_init(void)
+static struct platform_device *omap_iommu_add(const char *name)
{
- int i, err;
-
- for (i = 0; i < NR_IOMMU_DEVICES; i++) {
- struct platform_device *pdev;
- const struct iommu_device *d = &devices[i];
- struct resource res[] = {
- { .flags = IORESOURCE_MEM },
- { .flags = IORESOURCE_IRQ },
- };
-
- pdev = platform_device_alloc("omap-iommu", i + 1);
- if (!pdev) {
- err = -ENOMEM;
- goto err_out;
+ struct platform_device *pdev;
+ const struct iommu_device *d = NULL;
+ struct resource res[] = {
+ { .flags = IORESOURCE_MEM },
+ { .flags = IORESOURCE_IRQ },
+ };
+ int err, i;
+
+ for (i = 0; i < ARRAY_SIZE(devices); i++)
+ if (strcmp(devices[i].pdata.name, name) == 0) {
+ d = &devices[i];
+ break;
}
- res[0].start = d->base;
- res[0].end = d->base + MMU_REG_SIZE - 1;
+ if (!d)
+ return NULL;
- res[1].start = d->irq;
+ pdev = platform_device_alloc("omap-iommu", i + 1);
+ if (!pdev)
+ return NULL;
- err = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
- if (err)
- goto err_out;
+ res[0].start = d->base;
+ res[0].end = d->base + MMU_REG_SIZE - 1;
- err = platform_device_add_data(pdev, &d->pdata,
sizeof(d->pdata));
- if (err)
- goto err_out;
+ res[1].start = d->irq;
- err = platform_device_add(pdev);
- if (err)
- goto err_out;
+ err = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
+ if (err)
+ goto err_out;
+
+ err = platform_device_add_data(pdev, &d->pdata, sizeof(d->pdata));
+ if (err)
+ goto err_out;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto err_out;
+
+ return pdev;
+err_out:
+ platform_device_put(pdev);
+ return NULL;
+}
+
+static int __init omap3_iommu_init(void)
+{
+ struct platform_device *pdev;
+ int i, err;
+
+ for (i = 0; i < ARRAY_SIZE(devices); i++) {
+ pdev = omap_iommu_add(devices[i].pdata.name);
+ if (!pdev)
+ goto err_out;
omap3_iommu_pdev[i] = pdev;
}
+
return 0;
err_out:
--
1.6.3.GIT
--
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
[RFC/PATCH 3/3] omap3-iommu: remote registration
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/omap3-iommu.c | 36 +-
arch/arm/plat-omap/include/mach/iommu.h |2 +
2 files changed, 4 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
index 149c624..8380cd5 100644
--- a/arch/arm/mach-omap2/omap3-iommu.c
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -41,11 +41,8 @@ static struct iommu_device devices[] = {
},
},
};
-#define NR_IOMMU_DEVICES ARRAY_SIZE(omap3_iommu_pdata)
-static struct platform_device *omap3_iommu_pdev[NR_IOMMU_DEVICES];
-
-static struct platform_device *omap_iommu_add(const char *name)
+struct platform_device *omap_iommu_add(const char *name)
{
struct platform_device *pdev;
const struct iommu_device *d = NULL;
@@ -91,36 +88,7 @@ err_out:
platform_device_put(pdev);
return NULL;
}
-
-static int __init omap3_iommu_init(void)
-{
- struct platform_device *pdev;
- int i, err;
-
- for (i = 0; i < ARRAY_SIZE(devices); i++) {
- pdev = omap_iommu_add(devices[i].pdata.name);
- if (!pdev)
- goto err_out;
- omap3_iommu_pdev[i] = pdev;
- }
-
- return 0;
-
-err_out:
- while (i--)
- platform_device_put(omap3_iommu_pdev[i]);
- return err;
-}
-module_init(omap3_iommu_init);
-
-static void __exit omap3_iommu_exit(void)
-{
- int i;
-
- for (i = 0; i < NR_IOMMU_DEVICES; i++)
- platform_device_unregister(omap3_iommu_pdev[i]);
-}
-module_exit(omap3_iommu_exit);
+EXPORT_SYMBOL_GPL(omap_iommu_add);
MODULE_AUTHOR("Hiroshi DOYU");
MODULE_DESCRIPTION("omap iommu: omap3 device registration");
diff --git a/arch/arm/plat-omap/include/mach/iommu.h
b/arch/arm/plat-omap/include/mach/iommu.h
index 769b00b..e22a4a4 100644
--- a/arch/arm/plat-omap/include/mach/iommu.h
+++ b/arch/arm/plat-omap/include/mach/iommu.h
@@ -165,4 +165,6 @@ extern int foreach_iommu_device(void *data,
extern ssize_t iommu_dump_ctx(struct iommu *obj, char *buf);
extern size_t dump_tlb_entries(struct iommu *obj, char *buf);
+struct platform_device *omap_iommu_add(const char *name);
+
#endif /* __MACH_IOMMU_H */
--
1.6.3.GIT
--
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
[RFC/PATCH 1/3] omap3-iommu: reorganize
No functional changes.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/omap3-iommu.c | 72 ++--
1 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
index 367f36a..f4232ec 100644
--- a/arch/arm/mach-omap2/omap3-iommu.c
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -14,43 +14,31 @@
#include
-#define OMAP3_MMU1_BASE0x480bd400
-#define OMAP3_MMU2_BASE0x5d00
-#define OMAP3_MMU1_IRQ 24
-#define OMAP3_MMU2_IRQ 28
-
-static struct resource omap3_iommu_res[] = {
- { /* Camera ISP MMU */
- .start = OMAP3_MMU1_BASE,
- .end= OMAP3_MMU1_BASE + MMU_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3_MMU1_IRQ,
- .flags = IORESOURCE_IRQ,
- },
- { /* IVA2.2 MMU */
- .start = OMAP3_MMU2_BASE,
- .end= OMAP3_MMU2_BASE + MMU_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3_MMU2_IRQ,
- .flags = IORESOURCE_IRQ,
- },
+struct iommu_device {
+ resource_size_t base;
+ resource_size_t irq;
+ struct iommu_platform_data pdata;
+ struct resource res[2];
};
-#define NR_IOMMU_RES (ARRAY_SIZE(omap3_iommu_res) / 2)
-static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
+static struct iommu_device devices[] = {
{
- .name = "isp",
- .nr_tlb_entries = 8,
- .clk_name = "cam_ick",
+ .base = 0x480bd400,
+ .irq = 24,
+ .pdata = {
+ .name = "isp",
+ .nr_tlb_entries = 8,
+ .clk_name = "cam_ick",
+ },
},
{
- .name = "iva2",
- .nr_tlb_entries = 32,
- .clk_name = "iva2_ck",
+ .base = 0x5d00,
+ .irq = 28,
+ .pdata = {
+ .name = "iva2",
+ .nr_tlb_entries = 32,
+ .clk_name = "iva2_ck",
+ },
},
};
#define NR_IOMMU_DEVICES ARRAY_SIZE(omap3_iommu_pdata)
@@ -63,23 +51,35 @@ static int __init omap3_iommu_init(void)
for (i = 0; i < NR_IOMMU_DEVICES; i++) {
struct platform_device *pdev;
+ const struct iommu_device *d = &devices[i];
+ struct resource res[] = {
+ { .flags = IORESOURCE_MEM },
+ { .flags = IORESOURCE_IRQ },
+ };
pdev = platform_device_alloc("omap-iommu", i + 1);
if (!pdev) {
err = -ENOMEM;
goto err_out;
}
- err = platform_device_add_resources(pdev,
- &omap3_iommu_res[2 * i], NR_IOMMU_RES);
+
+ res[0].start = d->base;
+ res[0].end = d->base + MMU_REG_SIZE - 1;
+
+ res[1].start = d->irq;
+
+ err = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
if (err)
goto err_out;
- err = platform_device_add_data(pdev, &omap3_iommu_pdata[i],
- sizeof(omap3_iommu_pdata[0]));
+
+ err = platform_device_add_data(pdev, &d->pdata,
sizeof(d->pdata));
if (err)
goto err_out;
+
err = platform_device_add(pdev);
if (err)
goto err_out;
+
omap3_iommu_pdev[i] = pdev;
}
return 0;
--
1.6.3.GIT
--
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
[RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
This patch series cleanups up a bit the opap3-iommu device registration and then allows registration from other parts of the code. Currently the iva2 code (tidspbridge) is not using iommu, therefore it can't be used as-is with the current omap iommu. By allowing devies to be registered externaly (either isp, or iva2) this problem goes away. Felipe Contreras (3): omap3-iommu: reorganize omap3-iommu: split init function into omap_iommu_add omap3-iommu: remote registration arch/arm/mach-omap2/omap3-iommu.c | 130 ++- arch/arm/plat-omap/include/mach/iommu.h |2 + 2 files changed, 62 insertions(+), 70 deletions(-) -- 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 3/6] omap iommu: omap3 iommu device registration
On Tue, May 5, 2009 at 3:47 PM, Hiroshi DOYU wrote:
> Signed-off-by: Hiroshi DOYU
> ---
>
> arch/arm/mach-omap2/omap3-iommu.c | 105
> +
> 1 files changed, 105 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/omap3-iommu.c
>
> diff --git a/arch/arm/mach-omap2/omap3-iommu.c
> b/arch/arm/mach-omap2/omap3-iommu.c
> new file mode 100644
> index 000..367f36a
> --- /dev/null
> +++ b/arch/arm/mach-omap2/omap3-iommu.c
> @@ -0,0 +1,105 @@
> +/*
> + * omap iommu: omap3 device registration
> + *
> + * Copyright (C) 2008-2009 Nokia Corporation
> + *
> + * Written by Hiroshi DOYU
> + *
> + * 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
> +
> +#define OMAP3_MMU1_BASE 0x480bd400
> +#define OMAP3_MMU2_BASE 0x5d00
> +#define OMAP3_MMU1_IRQ 24
> +#define OMAP3_MMU2_IRQ 28
> +
> +static struct resource omap3_iommu_res[] = {
> + { /* Camera ISP MMU */
> + .start = OMAP3_MMU1_BASE,
> + .end = OMAP3_MMU1_BASE + MMU_REG_SIZE - 1,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = OMAP3_MMU1_IRQ,
> + .flags = IORESOURCE_IRQ,
> + },
> + { /* IVA2.2 MMU */
> + .start = OMAP3_MMU2_BASE,
> + .end = OMAP3_MMU2_BASE + MMU_REG_SIZE - 1,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = OMAP3_MMU2_IRQ,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +#define NR_IOMMU_RES (ARRAY_SIZE(omap3_iommu_res) / 2)
> + err = platform_device_add_resources(pdev,
> + &omap3_iommu_res[2 * i], NR_IOMMU_RES);
This is wrong. In this particular case NR_IOMMU_RES is 2, but not
because there's 2 resources: MEM and IRQ, but because there's 2 iommu
devices: isp and iva2.
--
Felipe Contreras
--
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 3/6] omap iommu: omap3 iommu device registration
On Wed, May 6, 2009 at 9:00 AM, Hiroshi DOYU wrote:
> From: ext Felipe Contreras
> Subject: Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
> Date: Tue, 5 May 2009 21:32:34 +0200
>
>> On Tue, May 5, 2009 at 3:47 PM, Hiroshi DOYU wrote:
>> > Signed-off-by: Hiroshi DOYU
>> > ---
>> >
>> > arch/arm/mach-omap2/omap3-iommu.c | 105
>> > +
>> > 1 files changed, 105 insertions(+), 0 deletions(-)
>> > create mode 100644 arch/arm/mach-omap2/omap3-iommu.c
>> >
>> > diff --git a/arch/arm/mach-omap2/omap3-iommu.c
>> > b/arch/arm/mach-omap2/omap3-iommu.c
>> > new file mode 100644
>> > index 000..367f36a
>> > --- /dev/null
>> > +++ b/arch/arm/mach-omap2/omap3-iommu.c
>> > @@ -0,0 +1,105 @@
>> > +/*
>> > + * omap iommu: omap3 device registration
>> > + *
>> > + * Copyright (C) 2008-2009 Nokia Corporation
>> > + *
>> > + * Written by Hiroshi DOYU
>> > + *
>> > + * 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
>> > +
>> > +#define OMAP3_MMU1_BASE 0x480bd400
>> > +#define OMAP3_MMU2_BASE 0x5d00
>> > +#define OMAP3_MMU1_IRQ 24
>> > +#define OMAP3_MMU2_IRQ 28
>> > +
>> > +static struct resource omap3_iommu_res[] = {
>> > + { /* Camera ISP MMU */
>> > + .start = OMAP3_MMU1_BASE,
>> > + .end = OMAP3_MMU1_BASE + MMU_REG_SIZE - 1,
>> > + .flags = IORESOURCE_MEM,
>> > + },
>> > + {
>> > + .start = OMAP3_MMU1_IRQ,
>> > + .flags = IORESOURCE_IRQ,
>> > + },
>> > + { /* IVA2.2 MMU */
>> > + .start = OMAP3_MMU2_BASE,
>> > + .end = OMAP3_MMU2_BASE + MMU_REG_SIZE - 1,
>> > + .flags = IORESOURCE_MEM,
>> > + },
>> > + {
>> > + .start = OMAP3_MMU2_IRQ,
>> > + .flags = IORESOURCE_IRQ,
>> > + },
>> > +};
>>
>> This will break TI's bridgedriver, right?
>
> Working around is easy, but let's go forward, correcting TI's bridgedriver;-)
>
> http://marc.info/?l=linux-omap&m=124148814309478&w=2
*sigh*
I can't recall how many times I've asked for this, I'm sending a patch
series (RFC) that allows exactly what I want.
--
Felipe Contreras
--
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: Beagleboard rev C memory timings & suspend/resume
Hello Jean, one other suggestion. You mentioned that you had self-refresh working on another OMAP3430 board with two SDRAM chip-selects. You might consider dumping the SDRC registers from that board, and dumping the SDRC registers on Beagle rev C, and comparing. It could be that the bootloader on your other board is setting some important bit. - Paul -- 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: Beagleboard rev C memory timings & suspend/resume
Hello Jean On Thu, 7 May 2009, Jean Pihet wrote: > From the OMAP datasheet it looks like the ARCV setting is off: shouldn't it > be > (tREFI/tCK)+50=(7800/6)+50=0x546? Could you elaborate further what you're seeing? It would help to see the register value that you're using to come to this conclusion. - Paul > > Is there a way to know if the self refresh works on both parts? > > Regards, > Jean > > On Thursday 07 May 2009 13:18:30 Jean Pihet wrote: > > Hi Paul, > > > > On Thursday 07 May 2009 01:39:02 Paul Walmsley wrote: > > > Hello Jean, > > > > > > sorry about the delay, > > > > Thanks for replying! > > > > > On Wed, 29 Apr 2009, Jean Pihet wrote: > > > > The suspend/resume on Beagleboard has some problem due to bad memory > > > > timings. Suspending for more than 5 to 10 seconds shows memory > > > > corruption. > > > > > > > > The new chips on rev Cx boards are using 2 DDR chip selects and it > > > > looks like the 2nd memory part is not correctly put into self refresh. > > > > As an experimentation I tried the same kernel with 'mem=128M' and it > > > > resumes correctly after 1 min in suspend. > > > > > > Nice work, this seems likely to be the cause. > > > > > > > I could not find the latest DDR detailed specs from Micron. The part > > > > number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this part > > > > identical to 2 1Gb parts? > > > > > > The combined part's web page is: > > > > > > http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20IT > > > > > > The SDRAM datasheet is the same that is used for all the other Micron > > > parts that we've run across so far: > > > > > > http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_sdra > > >m_ t48m.pdf > > > > Ok so we have 2 DDRs combined. > > That does not explain why the self-refresh is ok with only 1 part while it > > fails with the 2 parts. > > Could it be that the timings are too tight? Is there something special for > > the SDRC to support the 2 CSes correctly? > > > > We already have used the self refresh with 2 parts hooked on a 3430, not > > Micron parts though, so the code looks correct. > > > > I think we need help from the HW vendors here to identify the root cause: > > SDRC, DDR parts, connections? > > > > > > Now for the code in the kernel, there are some changes needed to > > > > support 2 CS'es: > > > > - the SDRC parameters need to be updated for the new memory part > > > > - the SDRC parameters need to include the ACTIM_CTRL_A_0, > > > > ACTIM_CTRL_A_1, ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and > > > > RFR_CTRL_1 registers. Since the parameters for the 2nd CS are the same, > > > > this can be avoided by writing the same values to the 2 sets of > > > > registers > > > > - is there a need to differentiate between 1Gb and 2Gb chips, or can we > > > > just write the same params for both CS'es even if only one is being > > > > used? - the 'configure_sdrc' function in arch/arm/mach-omap2/sram34xx.S > > > > needs to program the 2 sets of registers. Here is a patch excerpt > > > > below. This patch only does not help the suspend/resume though. > > > > > > > > Any idea or suggestion? > > > > > > Looks like a good start. Since the two SDRC chip-selects can technically > > > address parts with different timings, we should not assume that the two > > > chip selects will be the same. Admittedly this seems like an unlikely > > > situation, but it's not impossible for non-POP OMAPs. > > > > Makes sense. It is better to have correct and generic code. > > > > > Re: suspend/resume, if you're talking about the code in sleep34xx.S, it > > > looks like this is already in good shape. > > > > > > Re: board & SDRC changes: would suggest modifying omap2_sdrc_init() to > > > take either two struct omap_sdrc_params pointers, or one struct with two > > > pointers. omap2_init_common_hw() will also need to be updated for that, > > > and all of the board-*.c files also. > > > > > > Sound reasonable? > > > > Sure. I can write the new code, but I prefer to have the self refresh > > working first. > > > > > > 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 > > > > > > By the way, there's no need to duplicate the posted-write barrier. There > > > should only be one, appearing right before the 'bx lr'. > > > > Ok I will take it into account. > > > > > regards, > > > > > > - Paul > > > > Regards, > > Jean > > > > -- > > 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 > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to ma
Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
Op 7 mei 2009, om 19:18 heeft Tony Lindgren het volgende geschreven: * Koen Kooi [090507 09:57]: Op 7 mei 2009, om 18:28 heeft Tony Lindgren het volgende geschreven: * Russell King - ARM Linux [090507 09:19]: On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: Hi, Tony, Now the kernel can't boot on LDP. The attached file is the boot log. No boot log found. My master branch, based upon 2.6.29-rc3 boots fine on the LDP. Uncompressing Linux. done, booting the kernel. Linux version 2.6.29-rc3 (r...@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009 omapfb: configured for panel ldp omapfb: DISPC version 3.0 initialized omapfb: Framebuffer initialized. Total vram 614400 planes 1 omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz Can you see the penguin? 2.6.29 does this on my zoom: http://www.flickr.com/photos/koenkooi/3406819626/ Boots into X and all :) That's with DSS1, not Tomi's DSS2. As I said earlier, the touchscreen is unusable. Good to hear. What patches do you have applied? None relating to DSS1, the rest are DSS2 patches (not enabled in defconfig), musb patches, etc. What exactly is wrong with the touchscreen? It seems to have a reduced resolution with lots of noise, tslib is unable to calibrate it to a usable state. It might be the mcspi problem the evm had (has?) all over again, haven't looked into that. Got any patches for that? none, sorry. regards, Koen Regards, Tony PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
McBSP in Multi Channel mode
Hello, I'm new to kernel development and so I'm a bit confused on how to do things here. I need to use the McBSP with Multi-Channel enabled and using DMA to transfer the data. The data will be PCM sound and I will have 4 cards attached to this McBSP. I'm using OMAP35xx. >From what I've seen, I have to change the files: - arch/arm/plat-omap/mcbsp.c - arch/arm/mach-omap2/mcbsp.c to support multi channel. Is that it? or I would need more changes? Is there something that I would need to change in DMA implementation? Do you know where I can get an example or documentation? Thanks, Fernando -- 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
* Koen Kooi [090507 09:57]: > > Op 7 mei 2009, om 18:28 heeft Tony Lindgren het volgende geschreven: > >> * Russell King - ARM Linux [090507 09:19]: >>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: Hi, Tony, Now the kernel can't boot on LDP. The attached file is the boot log. >>> >>> No boot log found. >>> >>> My master branch, based upon 2.6.29-rc3 boots fine on the LDP. >>> >>> Uncompressing >>> Linux. >>> done, booting the >>> kernel. >>> Linux version 2.6.29-rc3 (r...@dyn-67.arm.linux.org.uk) (gcc version >>> 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009 >> >> >> >>> omapfb: configured for panel ldp >>> omapfb: DISPC version 3.0 initialized >>> omapfb: Framebuffer initialized. Total vram 614400 planes 1 >>> omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz >> >> Can you see the penguin? > > 2.6.29 does this on my zoom: > > http://www.flickr.com/photos/koenkooi/3406819626/ > > Boots into X and all :) That's with DSS1, not Tomi's DSS2. As I said > earlier, the touchscreen is unusable. Good to hear. What patches do you have applied? What exactly is wrong with the touchscreen? Got any patches for that? Regards, 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
Op 7 mei 2009, om 18:28 heeft Tony Lindgren het volgende geschreven: * Russell King - ARM Linux [090507 09:19]: On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: Hi, Tony, Now the kernel can't boot on LDP. The attached file is the boot log. No boot log found. My master branch, based upon 2.6.29-rc3 boots fine on the LDP. Uncompressing Linux. done, booting the kernel. Linux version 2.6.29-rc3 (r...@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009 omapfb: configured for panel ldp omapfb: DISPC version 3.0 initialized omapfb: Framebuffer initialized. Total vram 614400 planes 1 omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz Can you see the penguin? 2.6.29 does this on my zoom: http://www.flickr.com/photos/koenkooi/3406819626/ Boots into X and all :) That's with DSS1, not Tomi's DSS2. As I said earlier, the touchscreen is unusable. regards, Koen PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
Re: Beagleboard rev C memory timings & suspend/resume
Hi, FYI I tried to relax the DDR timings (mainly tRC, tWTR, tXP, tXSR, ARCV) but that did not help. >From the OMAP datasheet it looks like the ARCV setting is off: shouldn't it be (tREFI/tCK)+50=(7800/6)+50=0x546? Is there a way to know if the self refresh works on both parts? Regards, Jean On Thursday 07 May 2009 13:18:30 Jean Pihet wrote: > Hi Paul, > > On Thursday 07 May 2009 01:39:02 Paul Walmsley wrote: > > Hello Jean, > > > > sorry about the delay, > > Thanks for replying! > > > On Wed, 29 Apr 2009, Jean Pihet wrote: > > > The suspend/resume on Beagleboard has some problem due to bad memory > > > timings. Suspending for more than 5 to 10 seconds shows memory > > > corruption. > > > > > > The new chips on rev Cx boards are using 2 DDR chip selects and it > > > looks like the 2nd memory part is not correctly put into self refresh. > > > As an experimentation I tried the same kernel with 'mem=128M' and it > > > resumes correctly after 1 min in suspend. > > > > Nice work, this seems likely to be the cause. > > > > > I could not find the latest DDR detailed specs from Micron. The part > > > number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this part > > > identical to 2 1Gb parts? > > > > The combined part's web page is: > > > > http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20IT > > > > The SDRAM datasheet is the same that is used for all the other Micron > > parts that we've run across so far: > > > > http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_sdra > >m_ t48m.pdf > > Ok so we have 2 DDRs combined. > That does not explain why the self-refresh is ok with only 1 part while it > fails with the 2 parts. > Could it be that the timings are too tight? Is there something special for > the SDRC to support the 2 CSes correctly? > > We already have used the self refresh with 2 parts hooked on a 3430, not > Micron parts though, so the code looks correct. > > I think we need help from the HW vendors here to identify the root cause: > SDRC, DDR parts, connections? > > > > Now for the code in the kernel, there are some changes needed to > > > support 2 CS'es: > > > - the SDRC parameters need to be updated for the new memory part > > > - the SDRC parameters need to include the ACTIM_CTRL_A_0, > > > ACTIM_CTRL_A_1, ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and > > > RFR_CTRL_1 registers. Since the parameters for the 2nd CS are the same, > > > this can be avoided by writing the same values to the 2 sets of > > > registers > > > - is there a need to differentiate between 1Gb and 2Gb chips, or can we > > > just write the same params for both CS'es even if only one is being > > > used? - the 'configure_sdrc' function in arch/arm/mach-omap2/sram34xx.S > > > needs to program the 2 sets of registers. Here is a patch excerpt > > > below. This patch only does not help the suspend/resume though. > > > > > > Any idea or suggestion? > > > > Looks like a good start. Since the two SDRC chip-selects can technically > > address parts with different timings, we should not assume that the two > > chip selects will be the same. Admittedly this seems like an unlikely > > situation, but it's not impossible for non-POP OMAPs. > > Makes sense. It is better to have correct and generic code. > > > Re: suspend/resume, if you're talking about the code in sleep34xx.S, it > > looks like this is already in good shape. > > > > Re: board & SDRC changes: would suggest modifying omap2_sdrc_init() to > > take either two struct omap_sdrc_params pointers, or one struct with two > > pointers. omap2_init_common_hw() will also need to be updated for that, > > and all of the board-*.c files also. > > > > Sound reasonable? > > Sure. I can write the new code, but I prefer to have the self refresh > working first. > > > > 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 > > > > By the way, there's no need to duplicate the posted-write barrier. There > > should only be one, appearing right before the 'bx lr'. > > Ok I will take it into account. > > > regards, > > > > - Paul > > Regards, > Jean > > -- > 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
* Russell King - ARM Linux [090507 09:37]: > On Thu, May 07, 2009 at 05:34:05PM +0100, Russell King - ARM Linux wrote: > > On Thu, May 07, 2009 at 09:28:34AM -0700, Tony Lindgren wrote: > > > * Russell King - ARM Linux [090507 09:19]: > > > > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: > > > > > Hi, Tony, > > > > > > > > > > Now the kernel can't boot on LDP. The attached file is the boot log. > > > > > > > > No boot log found. > > > > > > > > My master branch, based upon 2.6.29-rc3 boots fine on the LDP. > > > > > > > > Uncompressing > > > > Linux. > > > > done, booting the kernel. > > > > Linux version 2.6.29-rc3 (r...@dyn-67.arm.linux.org.uk) (gcc version > > > > 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009 > > > > > > > > > > > > > omapfb: configured for panel ldp > > > > omapfb: DISPC version 3.0 initialized > > > > omapfb: Framebuffer initialized. Total vram 614400 planes 1 > > > > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz > > > > > > Can you see the penguin? > > > > Interestingly, CONFIG_FB is not set, so I'm not sure why we have a > > framebuffer driver. > > > > Ah, hmm. Oh sod it, what kernel am I booting. Oh, it's an ages > > old one. Fucking $#^"$#^%$^#"^^"%#%^5268903284769065983 UBOOT. > > Sod it, I'm not going to bother with this crap with its stupidly long > build times because of bloated gcc4 requirements this side of my holiday. > I've better things to be doing like washing the car. > > So you're on your own with LDP support for the next 9 days. So this > email marks the end of my pre-holiday Linux involvement. Happy holidays :) We'll get the LDP patches ready by the time you're back. 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
On Thu, May 07, 2009 at 05:34:05PM +0100, Russell King - ARM Linux wrote: > On Thu, May 07, 2009 at 09:28:34AM -0700, Tony Lindgren wrote: > > * Russell King - ARM Linux [090507 09:19]: > > > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: > > > > Hi, Tony, > > > > > > > > Now the kernel can't boot on LDP. The attached file is the boot log. > > > > > > No boot log found. > > > > > > My master branch, based upon 2.6.29-rc3 boots fine on the LDP. > > > > > > Uncompressing > > > Linux. > > > done, booting the kernel. > > > Linux version 2.6.29-rc3 (r...@dyn-67.arm.linux.org.uk) (gcc version > > > 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009 > > > > > > > > > omapfb: configured for panel ldp > > > omapfb: DISPC version 3.0 initialized > > > omapfb: Framebuffer initialized. Total vram 614400 planes 1 > > > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz > > > > Can you see the penguin? > > Interestingly, CONFIG_FB is not set, so I'm not sure why we have a > framebuffer driver. > > Ah, hmm. Oh sod it, what kernel am I booting. Oh, it's an ages > old one. Fucking $#^"$#^%$^#"^^"%#%^5268903284769065983 UBOOT. Sod it, I'm not going to bother with this crap with its stupidly long build times because of bloated gcc4 requirements this side of my holiday. I've better things to be doing like washing the car. So you're on your own with LDP support for the next 9 days. So this email marks the end of my pre-holiday Linux involvement. -- 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
On Thu, May 07, 2009 at 09:28:34AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux [090507 09:19]: > > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: > > > Hi, Tony, > > > > > > Now the kernel can't boot on LDP. The attached file is the boot log. > > > > No boot log found. > > > > My master branch, based upon 2.6.29-rc3 boots fine on the LDP. > > > > Uncompressing > > Linux. > > done, booting the kernel. > > Linux version 2.6.29-rc3 (r...@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 > > (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009 > > > > > omapfb: configured for panel ldp > > omapfb: DISPC version 3.0 initialized > > omapfb: Framebuffer initialized. Total vram 614400 planes 1 > > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz > > Can you see the penguin? Interestingly, CONFIG_FB is not set, so I'm not sure why we have a framebuffer driver. Ah, hmm. Oh sod it, what kernel am I booting. Oh, it's an ages old one. Fucking $#^"$#^%$^#"^^"%#%^5268903284769065983 UBOOT. -- 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
* Russell King - ARM Linux [090507 09:19]: > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: > > Hi, Tony, > > > > Now the kernel can't boot on LDP. The attached file is the boot log. > > No boot log found. > > My master branch, based upon 2.6.29-rc3 boots fine on the LDP. > > Uncompressing > Linux. > done, booting the kernel. > Linux version 2.6.29-rc3 (r...@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 > (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009 > omapfb: configured for panel ldp > omapfb: DISPC version 3.0 initialized > omapfb: Framebuffer initialized. Total vram 614400 planes 1 > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz Can you see the penguin? 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote: > Hi, Tony, > > Now the kernel can't boot on LDP. The attached file is the boot log. No boot log found. My master branch, based upon 2.6.29-rc3 boots fine on the LDP. Uncompressing Linux. done, booting the kernel. Linux version 2.6.29-rc3 (r...@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP LDP board Memory policy: ECC disabled, Data cache writeback OMAP3430 ES2.1 SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyS2,115200n8 noinitrd mem=128M root=/dev/mmcblk0p2 rw ip=none rootdelay=2 video=omap24xxfb:rotation=270 Clocking rate (Crystal/DPLL/ARM core): 26.0/266/500 MHz GPMC revision 5.0 IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP34xx GPIO hardware version 2.5 PID hash table entries: 512 (order: 9, 2048 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 126292KB available (2964K code, 372K data, 120K init) Calibrating delay loop... 498.87 BogoMIPS (lpj=1945600) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok net_namespace: 296 bytes NET: Registered protocol family 16 OMAP DMA hardware revision 4.0 USB: No board-specific platform config found bio: create slab at 0 SCSI subsystem initialized i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz twl4030: PIH (irq 7) chaining IRQs 368..375 twl4030: power (irq 373) chaining IRQs 376..383 twl4030: gpio (irq 368) chaining IRQs 384..401 i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NET: Registered protocol family 1 NetWinder Floating Point Emulator V0.97 (double precision) VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) msgmni has been set to 246 io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered omapfb: configured for panel ldp omapfb: DISPC version 3.0 initialized omapfb: Framebuffer initialized. Total vram 614400 planes 1 omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654 serial8250.0: ttyS2 at MMIO 0x4902 (irq = 74) is a ST16654 console [ttyS2] enabled brd: module loaded loop: module loaded smsc911x: Driver version 2008-10-21. smsc911x-mdio: probed eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=:01, irq=-1) net eth0: MAC Address: 00:08:ee:02:24:b2 Driver 'sd' needs updating - please use bus_type methods twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc0 twl4030_rtc twl4030_rtc: Power up reset detected. twl4030_rtc twl4030_rtc: Enabling TWL4030-RTC. i2c /dev entries driver Driver for 1-wire Dallas network protocol. OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock Advanced Linux Sound Architecture Driver Version 1.0.18a. No device for DAI AD73311 No device for DAI AK4535 No device for DAI CS4270 No device for DAI PCM3008 HiFi No device for DAI SSM2602 No device for DAI tlv320aic23 No device for DAI tlv320aic3x No device for DAI twl4030 No device for DAI UDA134X No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI WM8510 HiFi No device for DAI WM8580 PAIFRX No device for DAI WM8580 PAIFTX No device for DAI WM8728 No device for DAI WM8731 No device for DAI WM8750 No device for DAI WM8971 No device for DAI WM8990 ADC/DAC Primary ALSA device list: No soundcards found. TCP cubic registered NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) Waiting 2sec before mounting root device... mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SD card at address 0002 mmcblk0: mmc0:0002 0 971 MiB mmcblk0: p1 p2 kjournald st
[PATCH 1/1] ASoC: Added OMAP3 EVM support in ASoC.
Signed-off-by: Anuj Aggarwal
---
sound/soc/omap/Kconfig|8 +++
sound/soc/omap/Makefile |2 +
sound/soc/omap/omap3evm.c | 147 +
3 files changed, 157 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/omap/omap3evm.c
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 675732e..b771238 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -39,6 +39,14 @@ config SND_OMAP_SOC_OMAP2EVM
help
Say Y if you want to add support for SoC audio on the omap2evm board.
+config SND_OMAP_SOC_OMAP3EVM
+ tristate "SoC Audio support for OMAP3EVM board"
+ depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3EVM
+ select SND_OMAP_SOC_MCBSP
+ select SND_SOC_TWL4030
+ help
+ Say Y if you want to add support for SoC audio on the omap3evm board.
+
config SND_OMAP_SOC_SDP3430
tristate "SoC Audio support for Texas Instruments SDP3430"
depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_3430SDP
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index 0c9e4ac..a37f498 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -10,6 +10,7 @@ snd-soc-n810-objs := n810.o
snd-soc-osk5912-objs := osk5912.o
snd-soc-overo-objs := overo.o
snd-soc-omap2evm-objs := omap2evm.o
+snd-soc-omap3evm-objs := omap3evm.o
snd-soc-sdp3430-objs := sdp3430.o
snd-soc-omap3pandora-objs := omap3pandora.o
snd-soc-omap3beagle-objs := omap3beagle.o
@@ -18,6 +19,7 @@ obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o
obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o
obj-$(CONFIG_MACH_OMAP2EVM) += snd-soc-omap2evm.o
+obj-$(CONFIG_MACH_OMAP3EVM) += snd-soc-omap3evm.o
obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o
diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3evm.c
new file mode 100644
index 000..2af5d93
--- /dev/null
+++ b/sound/soc/omap/omap3evm.c
@@ -0,0 +1,147 @@
+/*
+ * omap3evm.c -- ALSA SoC support for OMAP3 EVM
+ *
+ * Author: Anuj Aggarwal
+ *
+ * Based on sound/soc/omap/beagle.c by Steve Sakoman
+ *
+ * Copyright (C) 2008 Texas Instruments, Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "omap-mcbsp.h"
+#include "omap-pcm.h"
+#include "../codecs/twl4030.h"
+
+static int omap3evm_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *codec_dai = rtd->dai->codec_dai;
+ struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
+ int ret;
+
+ /* Set codec DAI configuration */
+ ret = snd_soc_dai_set_fmt(codec_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+ if (ret < 0) {
+ printk(KERN_ERR "Can't set codec DAI configuration\n");
+ return ret;
+ }
+
+ /* Set cpu DAI configuration */
+ ret = snd_soc_dai_set_fmt(cpu_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+ if (ret < 0) {
+ printk(KERN_ERR "Can't set cpu DAI configuration\n");
+ return ret;
+ }
+
+ /* Set the codec system clock for DAC and ADC */
+ ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600,
+SND_SOC_CLOCK_IN);
+ if (ret < 0) {
+ printk(KERN_ERR "Can't set codec system clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct snd_soc_ops omap3evm_ops = {
+ .hw_params = omap3evm_hw_params,
+};
+
+/* Digital audio interface glue - connects codec <--> CPU */
+static struct snd_soc_dai_link omap3evm_dai = {
+ .name = "TWL4030",
+ .stream_name= "TWL4030",
+ .cpu_dai= &omap_mcbsp_dai[0],
+ .codec_dai = &twl4030_dai,
+ .ops= &omap3evm_ops,
+};
+
+/* Audio machine driver */
+static struct snd_soc_card snd_soc_omap3evm = {
+ .name = "omap3evm",
+ .platform = &omap_soc_platfor
[PATCH 0/1] ASoC: Added OMAP3 EVM Support
With refernce to the discussion at: http://marc.info/?l=linux-omap&m=124169330310075&w=2 I am resending the patch to add OMAP3 EVM support in ASoC. It has been built/checked against the tip. Anuj Aggarwal (1): ASoC: Added OMAP3 EVM support in ASoC. sound/soc/omap/Kconfig|8 +++ sound/soc/omap/Makefile |2 + sound/soc/omap/omap3evm.c | 147 + 3 files changed, 157 insertions(+), 0 deletions(-) create mode 100644 sound/soc/omap/omap3evm.c -- 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
[APPLIED] [PATCH] OMAP: RX51: Add log partition
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 86822cc055878b6750a8a3e8c42702e3ac2fe255 PatchWorks http://patchwork.kernel.org/patch/22248/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=86822cc055878b6750a8a3e8c42702e3ac2fe255 -- 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
[APPLIED] [PATCH] onenand_init: Fix missing comma
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 87a090d5bc24cde5f43e99e26f61a0f64613bb6c PatchWorks http://patchwork.kernel.org/patch/22255/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=87a090d5bc24cde5f43e99e26f61a0f64613bb6c -- 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
Tony Lindgren wrote: * Tony Lindgren [090505 21:00]: * Russell King - ARM Linux [090505 12:52]: On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote: * Russell King - ARM Linux [090428 15:07]: Tony, et.al., Any ideas when more LDP support will be pushed into mainline (such as the framebuffer support)? I'll be looking at the board-*.c patches for the next merge window hopefully this week or next week. Looks like LDP keyboard, touchscreen & RTC are pretty much ready to go. Then the MMC has some regulator updates, but AFAIK the MMC should work OK already. For the framebuffer, Imre and Tomi know the status the best, so I've added them to Cc. Imre has been meaning to send a bunch of drivers/video/omap changes to the fbdev list for a while now and LDP framebuffer may depend on those. Imre, any news on the status of sending the fb patches upstream? Then there are the upcoming DSS patches from Tomi, but those still need some work before they're ready to go. Is there any news on this? Will we see more functional OMAP3 / LDP support queued for the next merge window? Yes fro the stuff listed above, but still no news on the framebuffer patches. Imre? Added Stanley Miao to Cc. Here's an updated version of Stanley's patch to add fb support for LDP. I don't have an LDP, maybe you guys can give it a try against the mainline kernel and see if it works! There might be some changes needed to drivers/video/omap/dispc.c too.. And those should be handled by Imre. But if this works, at least we can then add support for few more boards easily while waiting for Imre to send his updates. Hi, Tony, Now the kernel can't boot on LDP. The attached file is the boot log. I will check it when I have time. Stanley. Cheers, 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 2/6] omap iommu: omap2 architecture specific functions
Hi,
> +static irqreturn_t iommu_fault_handler(int irq, void *data)
> +{
> + u32 stat, da;
> + u32 *iopgd, *iopte;
> + int err = -EIO;
> + struct iommu *obj = data;
> +
> + if (!obj->refcount)
> + return IRQ_NONE;
> +
> + /* Dynamic loading TLB or PTE */
> + if (obj->isr)
> + err = obj->isr(obj);
> ^^
>
> If the above "isr" function sets a new "tlb" or "pte" entry, then
> further iommu fault won't happen anymore.
>
-- I think adding the new tlb entry or any other error recovery mechanism
should be deferred to the registered callback function.
Thank you,
Best regards,
Hari
--
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] PM: suspend_device_irqs(): don't disable wakeup IRQs
Kim Kyuwon writes: > 2009/5/7 Arve Hjønnevåg : >> 2009/5/6 Kim Kyuwon : >>> 2009/5/7 Arve Hjønnevåg : On Wed, May 6, 2009 at 5:16 PM, Kevin Hilman wrote: > "Rafael J. Wysocki" writes: > >> On Wednesday 06 May 2009, Kevin Hilman wrote: >>> Kevin Hilman writes: > There is at least one problem with that which is why Kyuwon Kim added > the ->disable hook to OMAP's irq_chip. The problem is with drivers > that call disable_irq() in their suspend hook, usually done to prevent > the device from waking the system since on OMAP, any IRQ can be > configured to wake the system. > This does not sound correct. disable_irq_wake should be used for this. A driver may need to mask its interrupt before suspending but this should not also disable it as a wakeup source. >>> >>> I wish I could use disable_irq_wake(), but it doesn't work in OMAP. >> >> This does not sound like a hardware problem. > > We may need advices of TI engineers. > However, as far as I know, It is impossible to disable 'interrupt > wake-up' with interrupt enabled. Because an interrupt itself generate > a system wake-up event in OMAP3430 (Hardware level). Interrupt wakeups can be disabled at the PRCM level. Or more simply we can keep a mask of wakeup-enable interrupts and use that. I will experiment with getting disable_irq_wake() working. Kevin -- 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: [alsa-devel] Beep sound in the end of audio file
On Thu, 7 May 2009 14:08:14 +0300 Peter Ujfalusi wrote: > I need to revisit this... > After more testing and debugging, it seams that I can not confirm the > existence of the "tuck" (with the latest twl4030 codec code). > As soon as I receive my Beagle board I will test it again (can anyone > test this with latest ASoC code on Beagle?)... > I can hear somewhat audible (stetson guessed -20 db from /dev/urandom level) power-up/-down pop with "aplay -f dat /dev/zero" but no any other beeps or noises. I cannot hear any difference in pop level am I using head of linux-omap or when merging sound-2.6/asoc on top of it. Of cource this pop noise can be codec output & load dependent and also possible on-board amplifier with proper power sequencing can mask the noise. For reference, output jack of the Beagle is connected directly into HSOL and HSOR pins. -- 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
Re: [alsa-devel] Beep sound in the end of audio file
On Thu, May 7, 2009 at 4:54 PM, Peter Ujfalusi wrote: > On Thursday 07 May 2009 14:16:12 ext Aggarwal, Anuj wrote: >> > [Anuj]: What kernel are you using where you have the beep? >> >> [Aggarwal, Anuj] 2.6.29-rc3 > > That version still has the old power up/down code. Since than there were 23 > patches for the twl4030 codec. > The Headset enable/disable mantra could be still wrong in the latest > version... But i tried with latest linux-omap tree(2.6.30-rc4) copying twl4030.* files from latest linux sound tree. I can still hear the tuck noise of DAPM on omap3evm board. Arun > > -- > Péter > ___ > Alsa-devel mailing list > alsa-de...@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > -- 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: [alsa-devel] Beep sound in the end of audio file
On Thursday 07 May 2009 14:16:12 ext Aggarwal, Anuj wrote: > > [Anuj]: What kernel are you using where you have the beep? > > [Aggarwal, Anuj] 2.6.29-rc3 That version still has the old power up/down code. Since than there were 23 patches for the twl4030 codec. The Headset enable/disable mantra could be still wrong in the latest version... -- Péter -- 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: Beagleboard rev C memory timings & suspend/resume
Hi Paul, On Thursday 07 May 2009 01:39:02 Paul Walmsley wrote: > Hello Jean, > > sorry about the delay, Thanks for replying! > On Wed, 29 Apr 2009, Jean Pihet wrote: > > The suspend/resume on Beagleboard has some problem due to bad memory > > timings. Suspending for more than 5 to 10 seconds shows memory > > corruption. > > > > The new chips on rev Cx boards are using 2 DDR chip selects and it looks > > like the 2nd memory part is not correctly put into self refresh. As an > > experimentation I tried the same kernel with 'mem=128M' and it resumes > > correctly after 1 min in suspend. > > Nice work, this seems likely to be the cause. > > > I could not find the latest DDR detailed specs from Micron. The part > > number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this part > > identical to 2 1Gb parts? > > The combined part's web page is: > > http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20IT > > The SDRAM datasheet is the same that is used for all the other Micron > parts that we've run across so far: > > http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_sdram_ >t48m.pdf Ok so we have 2 DDRs combined. That does not explain why the self-refresh is ok with only 1 part while it fails with the 2 parts. Could it be that the timings are too tight? Is there something special for the SDRC to support the 2 CSes correctly? We already have used the self refresh with 2 parts hooked on a 3430, not Micron parts though, so the code looks correct. I think we need help from the HW vendors here to identify the root cause: SDRC, DDR parts, connections? > > Now for the code in the kernel, there are some changes needed to support > > 2 CS'es: > > - the SDRC parameters need to be updated for the new memory part > > - the SDRC parameters need to include the ACTIM_CTRL_A_0, ACTIM_CTRL_A_1, > > ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and RFR_CTRL_1 registers. > > Since the parameters for the 2nd CS are the same, this can be avoided by > > writing the same values to the 2 sets of registers > > - is there a need to differentiate between 1Gb and 2Gb chips, or can we > > just write the same params for both CS'es even if only one is being used? > > - the 'configure_sdrc' function in arch/arm/mach-omap2/sram34xx.S needs > > to program the 2 sets of registers. Here is a patch excerpt below. This > > patch only does not help the suspend/resume though. > > > > Any idea or suggestion? > > Looks like a good start. Since the two SDRC chip-selects can technically > address parts with different timings, we should not assume that the two > chip selects will be the same. Admittedly this seems like an unlikely > situation, but it's not impossible for non-POP OMAPs. Makes sense. It is better to have correct and generic code. > Re: suspend/resume, if you're talking about the code in sleep34xx.S, it > looks like this is already in good shape. > > Re: board & SDRC changes: would suggest modifying omap2_sdrc_init() to > take either two struct omap_sdrc_params pointers, or one struct with two > pointers. omap2_init_common_hw() will also need to be updated for that, > and all of the board-*.c files also. > > Sound reasonable? Sure. I can write the new code, but I prefer to have the self refresh working first. > > 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 > > By the way, there's no need to duplicate the posted-write barrier. There > should only be one, appearing right before the 'bx lr'. Ok I will take it into account. > > regards, > > - Paul Regards, Jean -- 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: [alsa-devel] Beep sound in the end of audio file
> -Original Message- > From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] > Sent: Thursday, May 07, 2009 4:38 PM > To: alsa-de...@alsa-project.org > Cc: todd.fisc...@ridgerun.com; Aggarwal, Anuj; linux-omap@vger.kernel.org > Subject: Re: [alsa-devel] Beep sound in the end of audio file > > On Thursday 07 May 2009 08:48:25 Ujfalusi Peter (Nokia-D/Tampere) wrote: > > On Wednesday 06 May 2009 17:19:49 ext Todd Fischer wrote: > > > Hi, > > > > > > FWIW: while developing a GSTreamer presentation using a BegleBoard > (rev > > > C), I noticed the same "tuck" sound. It also occurs a second or two > > > after the GST application exits. I assumed it was some power > management > > > code that was disabling the audio codec after it had gone idle, but never > > > looked into it. BeagleBoard also uses TWL4030. > > > > > > GST command: gst-launch audiotestsrc freq=1000 num-buffers=100 ! > alsasink > > > > > > /proc/version: Linux version 2.6.28-omap1 (ddo...@aleph) (gcc version > > > 4.3.1 (GCC) ) #2 Thu Mar 5 08:55:58 CST 2009 > > > > The "tuck" is coming from the codec, when it is powered down (in the old > > twl4030 codec found in omap-2.6.28 branch of linux-omap). > > But, it still happens with the latest version, when the codec is muted > > only. I can observe the "tuck" on Headset output, but not on the > > PreDrive... The Headset enable and disable is implemented according to the > > TRM, but it seams that additional tweaking is needed.. > > I need to revisit this... > After more testing and debugging, it seams that I can not confirm the > existence of the "tuck" (with the latest twl4030 codec code). > As soon as I receive my Beagle board I will test it again (can anyone test > this with latest ASoC code on Beagle?)... > > [Anuj]: What kernel are you using where you have the beep? [Aggarwal, Anuj] 2.6.29-rc3 > > -- > Péter -- 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: [alsa-devel] Beep sound in the end of audio file
On Thursday 07 May 2009 08:48:25 Ujfalusi Peter (Nokia-D/Tampere) wrote: > On Wednesday 06 May 2009 17:19:49 ext Todd Fischer wrote: > > Hi, > > > > FWIW: while developing a GSTreamer presentation using a BegleBoard (rev > > C), I noticed the same "tuck" sound. It also occurs a second or two > > after the GST application exits. I assumed it was some power management > > code that was disabling the audio codec after it had gone idle, but never > > looked into it. BeagleBoard also uses TWL4030. > > > > GST command: gst-launch audiotestsrc freq=1000 num-buffers=100 ! alsasink > > > > /proc/version: Linux version 2.6.28-omap1 (ddo...@aleph) (gcc version > > 4.3.1 (GCC) ) #2 Thu Mar 5 08:55:58 CST 2009 > > The "tuck" is coming from the codec, when it is powered down (in the old > twl4030 codec found in omap-2.6.28 branch of linux-omap). > But, it still happens with the latest version, when the codec is muted > only. I can observe the "tuck" on Headset output, but not on the > PreDrive... The Headset enable and disable is implemented according to the > TRM, but it seams that additional tweaking is needed.. I need to revisit this... After more testing and debugging, it seams that I can not confirm the existence of the "tuck" (with the latest twl4030 codec code). As soon as I receive my Beagle board I will test it again (can anyone test this with latest ASoC code on Beagle?)... [Anuj]: What kernel are you using where you have the beep? -- Péter -- 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: [alsa-devel] Beep sound in the end of audio file
On Thu, May 7, 2009 at 3:08 PM, Mark Brown wrote: > On Thu, May 07, 2009 at 03:05:08PM +0530, Arun KS wrote: > >> Since we are not going with the generic driver, are you going to push >> this patch: > >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg07166.html > > I can't see anything wrong with it looking in the web archive but somene > should send a copy tested against current ASoC. > I tested the patch with current ASoC and it is working. Anuj, Can you send a patch against current ASoC. Arun -- 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: [alsa-devel] Beep sound in the end of audio file
On Thu, May 07, 2009 at 03:05:08PM +0530, Arun KS wrote: > Since we are not going with the generic driver, are you going to push > this patch: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg07166.html I can't see anything wrong with it looking in the web archive but somene should send a copy tested against current ASoC. -- 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: [alsa-devel] Beep sound in the end of audio file
On Wed, May 6, 2009 at 7:37 PM, Mark Brown wrote: > On Wed, May 06, 2009 at 07:30:03PM +0530, Aggarwal, Anuj wrote: > >> > After a quick look I can not pin point the soc board file used with the >> > omap3evm board. Is it in the tree? > >> [Aggarwal, Anuj] No, it is not. Reason being we already have beagle & >> sdp3430 there, which are both similar to omap3evm, which I pushed. >> So mine got rejected. We had some discussions on how to handle this >> scenario but nothing got finalized. > > Not from the ALSA side it didn't... Mark, Since we are not going with the generic driver, are you going to push this patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg07166.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 > -- 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] onenand_init: Fix missing comma
Signed-off-by: Jarkko Nikula --- arch/arm/mach-omap2/gpmc-onenand.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index 71fc05a..712af59 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -123,7 +123,7 @@ static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg, const int t_wph = 30; int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo; int tick_ns, div, fclk_offset_ns, fclk_offset, gpmc_clk_ns, latency; - int first_time = 0, hf = 0 sync_read = 0, sync_write = 0; + int first_time = 0, hf = 0, sync_read = 0, sync_write = 0; int err, ticks_cez; int cs = cfg->cs; u32 reg; -- 1.6.2.4 -- 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: PM: 4 Problems in OMAP3430 DVFS (SmartReflex, Cpufreq)
Hi Kevin, Tony, Paul and other experts. Woodruff, Richard wrote: >> From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, April >> 23, 2009 3:53 AM To: Woodruff, Richard > >>> 4. Current PM code didn't enable the maximum clock (i.e. CPU: >>> 600Mhz) according to the comment as below: >>> >>> /* Avoid registering the 120% Overdrive with CPUFreq */ prcm = >>> mpu_opps + MAX_VDD1_OPP - 1; >>> >>> But in some cases, we should use 600Mhz for multimedia >>> application. And, even thought we enable the maximum clock, CPU >>> frequency seldom goes into maximum clock. I think we don't have >>> to avoid registering the max OPP. >> Do you know if this restriction can be lifted now, i.e., can the >> silicon run at VDD1 OPP1 100% of the time and meet the device >> lifespan targets? > > So, there have been some characterization changes which give more > leeway for software usage off overdrive. > > What you found before was guarantees against typical mobile usage for > a few classes of devices. This was done using a mix of OPPs with the > majority of active time in lower OPPs and inactive time in low idles > (optimal usage for mix of typical operations, this is the way you > would want to run ideally). Against this and many more variables, > reliability data was validated and published. > > Recently there was some change to also measure active time at max > overdrive for same usage mix. This resulted in still meeting lifetime > goals for typical usage. > > This can translate to a smart phone maker of being able to use > overdrive as they see fit and still have long life (assuming they can > supply adequate power and still dissipate what ever additional heat > there is). This is still not 100% of the time in active mode. What do you think of enabling to register the 120% Overdrive with CPUFreq in l-o tree?. Regard, Kyuwon > I suspect TI will continue to create parts for certain markets when > the need is there. The part might be nearly identical but the way > it's rated (with chip binning and other tricks) will allow different > guarantees. This fits well with mobile business customer needs. > > As an open source individual owner of a device, you might do things > in a non-typical way. You are free to do this. Depending on which > base chip variant you are using, its life may have some impact (or > not). Your chip likely will still last many years. The phone or other > device might die first. > > All that said, today personally, I feel much more comfortable > exposing overdrives in the reference code. Mobile users and their > devices which actually sleep at night should be pretty safe. > > Watch data sheets for details :) > > Regards, Richard W. > -- 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/3] 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| 11 ++
arch/arm/mach-omap2/timer-mpu.c | 214 +
arch/arm/plat-omap/include/mach/common.h |3 +
arch/arm/plat-omap/include/mach/entry-macro.S | 28
arch/arm/plat-omap/include/mach/irqs.h|2 +
5 files changed, 258 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 080868d..08c6ded 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -36,6 +36,7 @@
#include
#include
+#include
static struct omap_dm_timer *gptimer;
static struct clock_event_device clockevent_gpt;
@@ -187,6 +188,16 @@ 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
+#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
+ /*
+* The dummy clock device has to be registered before the main device
+* so that the latter will broadcast the clock events
+*/
+ local_timer_setup();
+#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..bb91b24
--- /dev/null
+++ b/arch/arm/mach-omap2/timer-mpu.c
@@ -0,0 +1,214 @@
+/*
+ * 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
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+static DEFINE_PER_CPU(struct clock_event_device, local_clockevent);
+
+/*
+ * Used on SMP for either the local timer or IPI_TIMER
+ */
+void local_timer_interrupt(void)
+{
+ struct clock_event_device *clk = &__get_cpu_var(local_clockevent);
+
+ clk->event_handler(clk);
+}
+
+#ifdef CONFIG_LOCAL_TIMERS
+
+/* set up by the platform code */
+void __iomem *twd_base;
+
+static unsigned long mpcore_timer_rate;
+
+static void local_timer_set_mode(enum clock_event_mode mode,
+struct clock_event_device *clk)
+{
+ unsigned long ctrl;
+
+ switch (mode) {
+ case CLOCK_EVT_MODE_PERIODIC:
+ /* timer load already set up */
+ ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
+ | TWD_TIMER_CONTROL_PERIODIC;
+ break;
+ case CLOCK_EVT_MODE_ONESHOT:
+ /* period set, and timer enabled in 'next_event' hook */
+ ctrl = TWD_TIMER_CONTROL_IT_ENABLE | TWD_TIMER_CONTROL_ONESHOT;
+ break;
+ case CLOCK_EVT_MODE_UNUSED:
+ case CLOCK_EVT_MODE_SHUTDOWN:
+ default:
+ ctrl = 0;
+ }
+
+ __raw_writel(ctrl, twd_base + TWD_TIMER_CONTROL);
+}
+
+static int local_timer_set_next_event(unsigned long evt,
+ struct clock_event_device *unused)
+{
+ unsigned long ctrl = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+
+ __raw_writel(evt, twd_base + TWD_TIMER_COUNTER);
+ __raw_writel(ctrl | TWD_TIMER_CONTROL_ENABLE,
+ twd_base + TWD_TIMER_CONTROL);
+
+ return 0;
+}
+
+/*
+ * local_timer_ack: checks for a local timer interrupt.
+ *
+ * If a local timer interrupt has occurred, acknowledge and return 1.
+ * Otherwise, return 0.
+ */
+int local_timer_ack(void)
+{
+ if (__raw_readl(twd_base + TWD_TIMER_INTSTAT)) {
+ __raw_writel(1, twd_base + TWD_TIMER_INTSTAT);
+ return 1;
+ }
+
+ return 0;
+}
+
+static void __cpuinit twd_calibrate_rate(void)
+{
+ unsigned long load, count;
+ u64 waitjiffies;
+
+ /*
+* If this is the first time round, we need to work out how fast
+* the timer ticks
+*/
+ if (mpcore_timer_rate == 0) {
+ printk(KERN_INFO "Calibrating local timer... ");
+
+ /* Wait for a tick to start */
+ waitjiffies = get_jiffies_64() + 1;
+
+ while (get_ji
[PATCH 3/3] OMAP4: SMP: Enable SMP support for OMAP4430
This patch enables SMP on OMAP4430 SDP platform. Signed-off-by: Santosh Shilimkar --- arch/arm/Kconfig|4 ++-- arch/arm/configs/omap_4430sdp_defconfig |7 ++- arch/arm/mach-omap2/Makefile|3 +++ 3 files changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e02b893..dc9f9fd 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -807,7 +807,7 @@ 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) select USE_GENERIC_SMP_HELPERS help This enables support for systems with more than one CPU. If you have @@ -864,7 +864,7 @@ 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 help Enable support for local timers on SMP platforms, rather then the diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 43532bc..fe2690e 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 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index c5d7efa..e01dd75 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -14,6 +14,9 @@ obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o +# SMP support ONLY available for OMAP4 +obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o \ + 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 1/3] 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| 49 +++
arch/arm/mach-omap2/omap-smp.c| 238 +
arch/arm/plat-omap/include/mach/scu.h | 28
arch/arm/plat-omap/include/mach/smp.h | 56
4 files changed, 371 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/scu.h
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..0afe039
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -0,0 +1,49 @@
+/*
+ * 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
+
+ __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, #15
+ adr r4, 1f
+ ldmia r4, {r5, r6}
+ sub r4, r4, r5
+ add r6, r6, r4
+hold: ldr r7, [r6] @ read from AuxCoreBoot1
+ cmp r7, r0
+ bne hold
+
+ /*
+* we've been released from the holding pen: secondary_stack
+* should now contain the SVC stack for this core
+*/
+ b secondary_startup
+
+1: .long .
+ .long cpu_release
+
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
new file mode 100644
index 000..1d18acb
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -0,0 +1,238 @@
+/*
+ * 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
+#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)
+
+/* FIXME: Move to a common header file */
+extern void omap_secondary_startup(void);
+
+/*
+ * Control for which core is the next to come out of the secondary
+ * boot "Auxcontrol_register"
+ */
+int __cpuinitdata cpu_release = -1;
+
+/*
+ * Setup the SCU
+ */
+static void scu_enable(void)
+{
+ u32 scu_ctrl;
+ void __iomem *scu_base = OMAP44XX_VA_SCU_BASE;
+
+ scu_ctrl = __raw_readl(scu_base + SCU_CTRL);
+ scu_ctrl |= 1;
+ __raw_writel(scu_ctrl, scu_base + SCU_CTRL);
+}
+
+/*
+ * Use SCU config register to count number of cores
+ */
+static unsigned int __init get_core_count(void)
+{
+ unsigned int ncores;
+ void __iomem *scu_base = OMAP44XX_VA_SCU_BASE;
+
+ if (scu_base) {
+ ncores = __raw_readl(scu_base + SCU_CONFIG);
+ ncores = (ncores & 0x03) + 1;
+ } else {
+ ncores = 1;
+ }
+
+ return ncores;
+}
+
+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));
+
+ /*
+* Let the primary processor know we're out of the
+* pen, then head off into the C entry point
+*/
+ cpu_release = -1;
+ smp_wmb();
+
+ /*
+* Synchronise with the boot thread.
+*/
+ spin_lock(&boot_lock);
+ spin
[PATCH 0/3] OMAP4: SMP: Patch series
This patch series enables SMP support for OMAP4430 development platform. This series depends on the earlier patch series sent on the mailing list. [1] The patches are generated against mainline version 2.6.30 -rc2. The kernel is validated on the OMAP4430 software simulator platform. SMP kernel is functional with debug UART. No additional drivers are supported yet. The series contains: [PATCH 1/3]OMAP4: SMP: Add OMAP4430 SMP board files [PATCH 2/3]OMAP4: SMP: Add mpu timer support for OMAP4430 [PATCH 3/3]OMAP4: SMP: Enable SMP support for OMAP4430 Regards, Santosh [1]:[PATCH 0/7] OMAP4: Basic board support patch series http://lists.arm.linux.org.uk/lurker/message/20090428.094757.6642f1e3.en.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
