Re: eac and mcbsp for omap850
Hello, On Tuesday 08 December 2009 15:05:47 ext Jarkko Nikula wrote: On Tue, 8 Dec 2009 13:06:05 +0100 Belisko Marek marek.beli...@gmail.com wrote: Hi, I would like to rewrite old eac audio driver for omap730 to current ASoc implementation but as I can understand new implementation use McBsP to transfer data to codec. Could this approach be used in omap850 which use EAC like codec and data from memory is transfered via DMA? Basically it should be possible to develop a new ASoC DAI driver using EAC. Even currently there is only one McBSP based DAI driver sound/soc/omap/omap-mcbsp.c, there is no restrictions to develop another DAI drivers since the sound/soc/omap/omap-pcm.c is not tied to underlying DAI. As I recall this is one of the reasons that Jarkko wants to keep the DMA and McBSP related code separately (to have the possibility to add the EAC support with the least code duplication). As I recall on OMAP2 the EAC had some bugs, which prevented it's use in certain situations, thus the McBSP mode was preferred over EAC. But yes, adding the EAC dai should be possible for OMAP. -- 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: [APPLIED] [PATCH v3] omap: serial: fix non-empty uart fifo read abort
Tony Lindgren wrote: This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next-vol2 Tony, A query on this for-next-vol2 branch: Is this branch going to be pushed in the current merge window, or is it for the -rc series? PatchWorks http://patchwork.kernel.org/patch/65022/ With current Linus' tree + this patch, I can boot up on 3630. Playing with the omap3_defconfig now, to see how many boards we can boot up with a single image :) - 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
scaling_setspeed doesn't change the frequency on beagleboard
Hi all, I'm using the beagleboard ,and android linux kernel obtained from the rowboat project . The cpufreq files are located and everything works fine except that it doesn't change the frequency it works on,I echo'ed the scaling_governor to use the userspace . However it still doesn't change the frequency I'm typing also I'm sure that my frequency is in the valid range . What may blocks this changes ? Any Idea will be appreciated :) -- tarek -- 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/2] OMAP: use physmap-flash
On Tue, 2009-12-08 at 10:33 -0800, Tony Lindgren wrote: * Ladislav Michl ladislav.mi...@seznam.cz [091208 10:20]: There is nothing special on omapflash driver, so it can be replaced with physmap-flash. First patch in serie does exactly this and second one removes drivers/mtd/maps/omap_nor.c and associated Kconfig option. I'd like to have either ack or merge into mtd git tree by mtd maintainers for that second part. Nice work! Ack from me to merge all this via the MTD tree. Acked-by: Tony Lindgren t...@atomide.com arch/arm/mach-omap1/flash.c | 33 ++ arch/arm/plat-omap/include/plat/flash.h | 16 + arch/arm/mach-omap1/Makefile |2 arch/arm/mach-omap1/board-fsample.c |9 arch/arm/mach-omap1/board-h2.c |9 arch/arm/mach-omap1/board-h3.c |9 arch/arm/mach-omap1/board-innovator.c|9 arch/arm/mach-omap1/board-osk.c |9 arch/arm/mach-omap1/board-palmte.c |9 arch/arm/mach-omap1/board-palmtt.c |9 arch/arm/mach-omap1/board-palmz71.c | 10 arch/arm/mach-omap1/board-perseus2.c |9 arch/arm/mach-omap1/board-sx1.c | 11 arch/arm/mach-omap1/board-voiceblue.c|9 arch/arm/mach-omap2/board-2430sdp.c |7 arch/arm/mach-omap2/board-h4.c |7 drivers/mtd/maps/Kconfig |9 drivers/mtd/maps/Makefile|1 drivers/mtd/maps/omap_nor.c | 188 - 19 files changed, 112 insertions(+), 253 deletions(-) I think this should be merged via the omap tree, not mtd (CCed dwmw2). -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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] AM35xx: Update the macro names
Devices AM3505 and AM3517 will be more commonly available.
Also, with more devices planned in this family, it is better
to rename the macros to follow cpu_is_amXXX() naming.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/id.c |4 ++--
arch/arm/plat-omap/include/plat/cpu.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 4fad192..9ab97ce 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -233,7 +233,7 @@ void __init omap3_check_revision(void)
case 0xb868:
/* Handle OMAP35xx/AM35xx devices
*
-* Set the device to be OMAP3505 here. Actual device
+* Set the device to be AM3505/OMAP3505 here. Actual device
* is identified later based on the features.
*/
omap_revision = OMAP3505_REV(rev);
@@ -263,7 +263,7 @@ void __init omap3_cpuinfo(void)
*/
if (cpu_is_omap3630()) {
strcpy(cpu_name, OMAP3630);
- } else if (cpu_is_omap3505()) {
+ } else if (cpu_is_am3505()) {
/*
* AM35xx devices
*/
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..8dd8801 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -399,8 +399,8 @@ IS_OMAP_TYPE(3517, 0x3517)
(omap3_has_sgx()) \
(!omap3_has_iva()))
# define cpu_is_omap3530() (cpu_is_omap3430())
-# define cpu_is_omap3505() is_omap3505()
-# define cpu_is_omap3517() is_omap3517()
+# define cpu_is_am3505() is_omap3505()
+# define cpu_is_am3517() is_omap3517()
# undef cpu_is_omap3630
# define cpu_is_omap3630() is_omap363x()
#endif
--
1.6.2.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
[PATCH] omap3: Fix macros for 3515 and 3525 inversion
From: Sergey Lapin slapi...@gmail.com The macros for detecting the cpu had same inversion problem fixed in earlier patch. [1] omap3: id code detection 3525 vs 3515 Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 8dd8801..1a80722 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -393,11 +393,11 @@ IS_OMAP_TYPE(3517, 0x3517) (!omap3_has_iva())\ (!omap3_has_sgx())) # define cpu_is_omap3515() (cpu_is_omap3430()\ - (omap3_has_iva()) \ - (!omap3_has_sgx())) + (!omap3_has_iva())\ + (omap3_has_sgx())) # define cpu_is_omap3525() (cpu_is_omap3430()\ - (omap3_has_sgx()) \ - (!omap3_has_iva())) + (!omap3_has_sgx())\ + (omap3_has_iva())) # define cpu_is_omap3530() (cpu_is_omap3430()) # define cpu_is_am3505() is_omap3505() # define cpu_is_am3517() is_omap3517() -- 1.6.2.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] Input: gpio-keys: Support for one-directional interrupts
Cory Maccarrone darkstar6...@gmail.com writes: The current gpio-keys driver assumes that each given GPIO has the ability to respond to both rising and falling interrupts at the same time. For some GPIOs on certain devices, the interrupt is only one-directional -- either rising or falling, depending on what's being listened for. In particular, the HTC Herald keyboard slide switch interrupt must be switched from rising to falling and back on each event, otherwise only one transition will be detected. Interesting. Btw. I'd like to convert gpio-keys from edge-triggered to level-triggered interrupts. Would that work for your hardware? -- Regards, Feri. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3: cm-t35: add mux initialization (was: Re: [PATCH] omap3: cm-t35: add mux initialization)
Tony,
Tony Lindgren wrote:
* Gadiyar, Anand gadi...@ti.com [091207 08:35]:
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [091206 07:30]:
Tony,
Any chance this can go to 2.6.33?
Sure, I was just waiting to hear back if the OUTPUT_PULLUP is
needed for sure? Or is just OUTPUT enough for musb to work?
Tony
OUTPUT should work too. The ULPI spec recommends a weak pull-up
on STP line, but we needn't really have that. Plain OUTPUT is sufficient.
OK, thanks for checking that. Mike, what do you prefer to do?
I guess in some cases the pull may be needed for a pin
to change faster if an external pull is not used?
We could add the OUTPUT_PULL defines, but we should probably
mark them with comments that they should be rarely needed.
Here's updated cm-t35 mux initialization that should apply to current
linux-omap-2.6/master. Please discard the previous version and sorry for the
noise.
Regards,
Tony
From 0da6d5d13351c2fc121a86ab641e25e4ff017800 Mon Sep 17 00:00:00 2001
From: Mike Rapoport m...@compulab.co.il
Date: Wed, 9 Dec 2009 15:23:24 +0200
Subject: [PATCH] omap3: cm-t35: add mux initialization
CM-T35 can be assembled with different set of peripherals thus making
certain interfaces available to user as GPIOs or dedicated pins. Because
of it CM-T35 bootloader sets up mux configuration only for pins
necessary to boot the system and the rest of the mux configuration is
done by the kernel. Besides, having mux configuration in the kernel
allows to minimize dependancy on bootloader.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/board-cm-t35.c | 96 +---
2 files changed, 90 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 16c0c13..66de47b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -136,6 +136,7 @@ config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3 ARCH_OMAP34XX
select OMAP_PACKAGE_CUS
+ select OMAP_MUX
config MACH_IGEP0020
bool IGEP0020
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 507c922..1591aae 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -482,13 +482,98 @@ static void __init cm_t35_map_io(void)
omap2_map_common_io();
}
-#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* nCS and IRQ for CM-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS5, OMAP_MUX_MODE0),
+ OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* nCS and IRQ for SB-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS4, OMAP_MUX_MODE0),
+ OMAP3_MUX(GPMC_WAIT3, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* PENDOWN GPIO */
+ OMAP3_MUX(GPMC_NCS6, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* mUSB */
+ OMAP3_MUX(HSUSB0_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_STP, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(HSUSB0_DIR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_NXT, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* MMC 2 */
+ OMAP3_MUX(SDMMC2_DAT4, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(SDMMC2_DAT5, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(SDMMC2_DAT6, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(SDMMC2_DAT7, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+
+ /* McSPI 1 */
+ OMAP3_MUX(MCSPI1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SIMO, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SOMI, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_CS0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+
+ /* McSPI 4 */
+ OMAP3_MUX(MCBSP1_CLKR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
+
+ /* McBSP 2 */
+ OMAP3_MUX(MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
+ /* serial ports */
+ OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE1 |
[PATCH v2] AM35xx: Update the macro names
Devices AM3505 and AM3517 will be more commonly available.
Also, with more devices planned in this family, it is better
to rename the macros to follow cpu_is_amXXX() naming.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/id.c |6 +++---
arch/arm/plat-omap/include/plat/cpu.h |4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 4fad192..d1bd8ba 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -233,7 +233,7 @@ void __init omap3_check_revision(void)
case 0xb868:
/* Handle OMAP35xx/AM35xx devices
*
-* Set the device to be OMAP3505 here. Actual device
+* Set the device to be AM3505/OMAP3505 here. Actual device
* is identified later based on the features.
*/
omap_revision = OMAP3505_REV(rev);
@@ -263,7 +263,7 @@ void __init omap3_cpuinfo(void)
*/
if (cpu_is_omap3630()) {
strcpy(cpu_name, OMAP3630);
- } else if (cpu_is_omap3505()) {
+ } else if (cpu_is_am3505()) {
/*
* AM35xx devices
*/
@@ -352,7 +352,7 @@ void __init omap2_check_revision(void)
} else if (cpu_is_omap242x()) {
/* Currently only supports 2420ES2.1.1 and 2420-all */
omap_chip.oc |= CHIP_IS_OMAP2420;
- } else if (cpu_is_omap3505() || cpu_is_omap3517()) {
+ } else if (cpu_is_am3505() || cpu_is_am3517()) {
omap_chip.oc = CHIP_IS_OMAP3430 | CHIP_IS_OMAP3430ES3_1;
} else if (cpu_is_omap343x()) {
omap_chip.oc = CHIP_IS_OMAP3430;
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..8dd8801 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -399,8 +399,8 @@ IS_OMAP_TYPE(3517, 0x3517)
(omap3_has_sgx()) \
(!omap3_has_iva()))
# define cpu_is_omap3530() (cpu_is_omap3430())
-# define cpu_is_omap3505() is_omap3505()
-# define cpu_is_omap3517() is_omap3517()
+# define cpu_is_am3505() is_omap3505()
+# define cpu_is_am3517() is_omap3517()
# undef cpu_is_omap3630
# define cpu_is_omap3630() is_omap363x()
#endif
--
1.6.2.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: [APPLIED] [PATCH v3] omap: serial: fix non-empty uart fifo read abort
snip With current Linus' tree + this patch, I can boot up on 3630. Playing with the omap3_defconfig now, to see how many boards we can boot up with a single image :) I got a zoom2, zoom3, 3430SDP and 3630 SDP booting with a single image. I had to disable Profiling and Sound support to get it to build with this config. Will post a patch after -rc1 if this is not resolved by then. - 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
CPUfreq deosn't change the current frequency
Hi all, CPUfreq doesn't work,,I downloaded the PM Linux kernel ,and enabled the CPUFREQ driver before compilation . However every writting in the scaling_setspeed doesn't get any return,,doesn't change the frequency however without errors . Any Idea?? -- tarek -- 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] Input: gpio-keys: Support for one-directional interrupts
On Wed, Dec 9, 2009 at 3:32 AM, Ferenc Wagner wf...@niif.hu wrote: Cory Maccarrone darkstar6...@gmail.com writes: Interesting. Btw. I'd like to convert gpio-keys from edge-triggered to level-triggered interrupts. Would that work for your hardware? I'm fairly certain it wouldn't. Each of the interrupts on my hardware has a corresponding bit in a control register that determines if it's rising or falling-edge triggered -- thus the need for my patch. To capture both directions, it's necessary to modify the control register when a falling edge is detected, so that the corresponding rising edge can be collected afterward. May I ask why you're thinking of converting to level-triggering? Perhaps it would be better to provide an option in the platform_device structure to set edge- or level-triggering, similar to the change I'm proposing for interrupts that can only signal one way at a time. - Cory -- 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/2] OMAP: use physmap-flash
* Artem Bityutskiy dedeki...@gmail.com [091209 02:06]: On Tue, 2009-12-08 at 10:33 -0800, Tony Lindgren wrote: * Ladislav Michl ladislav.mi...@seznam.cz [091208 10:20]: There is nothing special on omapflash driver, so it can be replaced with physmap-flash. First patch in serie does exactly this and second one removes drivers/mtd/maps/omap_nor.c and associated Kconfig option. I'd like to have either ack or merge into mtd git tree by mtd maintainers for that second part. Nice work! Ack from me to merge all this via the MTD tree. Acked-by: Tony Lindgren t...@atomide.com arch/arm/mach-omap1/flash.c | 33 ++ arch/arm/plat-omap/include/plat/flash.h | 16 + arch/arm/mach-omap1/Makefile |2 arch/arm/mach-omap1/board-fsample.c |9 arch/arm/mach-omap1/board-h2.c |9 arch/arm/mach-omap1/board-h3.c |9 arch/arm/mach-omap1/board-innovator.c|9 arch/arm/mach-omap1/board-osk.c |9 arch/arm/mach-omap1/board-palmte.c |9 arch/arm/mach-omap1/board-palmtt.c |9 arch/arm/mach-omap1/board-palmz71.c | 10 arch/arm/mach-omap1/board-perseus2.c |9 arch/arm/mach-omap1/board-sx1.c | 11 arch/arm/mach-omap1/board-voiceblue.c|9 arch/arm/mach-omap2/board-2430sdp.c |7 arch/arm/mach-omap2/board-h4.c |7 drivers/mtd/maps/Kconfig |9 drivers/mtd/maps/Makefile|1 drivers/mtd/maps/omap_nor.c | 188 - 19 files changed, 112 insertions(+), 253 deletions(-) I think this should be merged via the omap tree, not mtd (CCed dwmw2). OK will queue then. 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: [APPLIED] [PATCH v3] omap: serial: fix non-empty uart fifo read abort
* Gadiyar, Anand gadi...@ti.com [091209 00:41]: Tony Lindgren wrote: This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next-vol2 Tony, A query on this for-next-vol2 branch: Is this branch going to be pushed in the current merge window, or is it for the -rc series? What used to be for-next-vol2 is now the current for-next. We should be able to get that merged too this merge window. Regards, Tony PatchWorks http://patchwork.kernel.org/patch/65022/ With current Linus' tree + this patch, I can boot up on 3630. Playing with the omap3_defconfig now, to see how many boards we can boot up with a single image :) - 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 -- 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: [APPLIED] [PATCH v3] omap: serial: fix non-empty uart fifo read abort
* Gadiyar, Anand gadi...@ti.com [091209 06:16]: snip With current Linus' tree + this patch, I can boot up on 3630. Playing with the omap3_defconfig now, to see how many boards we can boot up with a single image :) I got a zoom2, zoom3, 3430SDP and 3630 SDP booting with a single image. OK good to hear. I had to disable Profiling and Sound support to get it to build with this config. Will post a patch after -rc1 if this is not resolved by then. I've applied a patch for the profiling into omap-testing from Carsten Emde I found on LKML. See patch tracing: Fix trace_marker output. 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] omap3: cm-t35: add mux initialization (was: Re: [PATCH] omap3: cm-t35: add mux initialization)
* Mike Rapoport m...@compulab.co.il [091209 05:26]:
Tony,
Tony Lindgren wrote:
* Gadiyar, Anand gadi...@ti.com [091207 08:35]:
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [091206 07:30]:
Tony,
Any chance this can go to 2.6.33?
Sure, I was just waiting to hear back if the OUTPUT_PULLUP is
needed for sure? Or is just OUTPUT enough for musb to work?
Tony
OUTPUT should work too. The ULPI spec recommends a weak pull-up
on STP line, but we needn't really have that. Plain OUTPUT is sufficient.
OK, thanks for checking that. Mike, what do you prefer to do?
I guess in some cases the pull may be needed for a pin
to change faster if an external pull is not used?
We could add the OUTPUT_PULL defines, but we should probably
mark them with comments that they should be rarely needed.
Here's updated cm-t35 mux initialization that should apply to current
linux-omap-2.6/master. Please discard the previous version and sorry for the
noise.
Great. Thanks for all your help getting the mux code sorted
out. Will queue.
Regards,
Tony
Regards,
Tony
From 0da6d5d13351c2fc121a86ab641e25e4ff017800 Mon Sep 17 00:00:00 2001
From: Mike Rapoport m...@compulab.co.il
Date: Wed, 9 Dec 2009 15:23:24 +0200
Subject: [PATCH] omap3: cm-t35: add mux initialization
CM-T35 can be assembled with different set of peripherals thus making
certain interfaces available to user as GPIOs or dedicated pins. Because
of it CM-T35 bootloader sets up mux configuration only for pins
necessary to boot the system and the rest of the mux configuration is
done by the kernel. Besides, having mux configuration in the kernel
allows to minimize dependancy on bootloader.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/board-cm-t35.c | 96
+---
2 files changed, 90 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 16c0c13..66de47b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -136,6 +136,7 @@ config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3 ARCH_OMAP34XX
select OMAP_PACKAGE_CUS
+ select OMAP_MUX
config MACH_IGEP0020
bool IGEP0020
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 507c922..1591aae 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -482,13 +482,98 @@ static void __init cm_t35_map_io(void)
omap2_map_common_io();
}
-#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* nCS and IRQ for CM-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS5, OMAP_MUX_MODE0),
+ OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* nCS and IRQ for SB-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS4, OMAP_MUX_MODE0),
+ OMAP3_MUX(GPMC_WAIT3, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* PENDOWN GPIO */
+ OMAP3_MUX(GPMC_NCS6, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* mUSB */
+ OMAP3_MUX(HSUSB0_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_STP, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(HSUSB0_DIR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_NXT, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* MMC 2 */
+ OMAP3_MUX(SDMMC2_DAT4, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(SDMMC2_DAT5, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(SDMMC2_DAT6, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(SDMMC2_DAT7, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+
+ /* McSPI 1 */
+ OMAP3_MUX(MCSPI1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SIMO, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SOMI, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_CS0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+
+ /* McSPI 4 */
+ OMAP3_MUX(MCBSP1_CLKR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
+
+ /* McBSP 2 */
+ OMAP3_MUX(MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DR,
[GIT PULL]: OMAP2/3 Display Subsystem
Linus, Here are the new display subsystem and framebuffer drivers for OMAP2/3. The drivers have been reviewed on linux-omap and linux-fbdev-devel, and are in use, for example, on N900, Beagle Board and Overo boards. The drivers are actively maintained and developed further, and I have already a bunch of patches on top of these patches, but I would like to get the big core driver merged first. After the core drivers are merged, other people can send patches to LCD drivers and board files to enable the new display subsystem on their boards. Please pull the new OMAP2/3 display subsystem drivers from: git://gitorious.org/linux-omap-dss2/linux.git for-linus Tomi --- The following changes since commit 2b876f95d03e226394b5d360c86127cbefaf614b: Linus Torvalds (1): Merge branches 'timers-for-linus-ntp' and 'irq-core-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-linus Tomi Valkeinen (19): OMAP2: Add funcs for writing SMS_ROT_* registers OMAP: OMAPFB: split omapfb.h OMAP: OMAPFB: add omapdss device OMAP: Add VRAM manager OMAP: Add support for VRFB rotation engine OMAP: DSS2: Documentation for DSS2 OMAP: DSS2: Display Subsystem Driver core OMAP: DSS2: Add more core files OMAP: DSS2: DISPC OMAP: DSS2: DPI driver OMAP: DSS2: Video encoder driver OMAP: DSS2: RFBI driver OMAP: DSS2: SDI driver OMAP: DSS2: DSI driver OMAP: DSS2: omapfb driver OMAP: DSS2: Add generic and Sharp panel drivers OMAP: DSS2: Taal DSI command mode panel driver OMAP: SDP: Enable DSS2 for OMAP3 SDP board MAINTAINERS: Add OMAP2/3 DSS and OMAPFB maintainer Documentation/arm/OMAP/DSS | 317 ++ MAINTAINERS| 17 + arch/arm/configs/omap_3430sdp_defconfig| 28 +- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/board-3430sdp.c| 167 +- arch/arm/mach-omap2/clock24xx.c|8 +- arch/arm/mach-omap2/clock34xx.c| 14 +- arch/arm/mach-omap2/io.c |4 +- arch/arm/mach-omap2/sdrc.c | 16 + arch/arm/plat-omap/fb.c| 49 +- arch/arm/plat-omap/include/plat/display.h | 575 +++ arch/arm/plat-omap/include/plat/omapfb.h | 398 --- arch/arm/plat-omap/include/plat/sdrc.h |9 +- arch/arm/plat-omap/include/plat/vram.h | 62 + arch/arm/plat-omap/include/plat/vrfb.h | 50 + arch/arm/plat-omap/sram.c |8 + drivers/video/Kconfig |1 + drivers/video/Makefile |1 + drivers/video/omap/Kconfig |5 +- drivers/video/omap/blizzard.c |2 +- drivers/video/omap/dispc.c | 21 +- drivers/video/omap/hwa742.c|3 +- drivers/video/omap/lcd_2430sdp.c |3 +- drivers/video/omap/lcd_ams_delta.c |3 +- drivers/video/omap/lcd_apollon.c |3 +- drivers/video/omap/lcd_h3.c|2 +- drivers/video/omap/lcd_h4.c|2 +- drivers/video/omap/lcd_htcherald.c |2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |3 +- drivers/video/omap/lcd_mipid.c |3 +- drivers/video/omap/lcd_omap2evm.c |3 +- drivers/video/omap/lcd_omap3beagle.c |4 +- drivers/video/omap/lcd_omap3evm.c |3 +- drivers/video/omap/lcd_osk.c |2 +- drivers/video/omap/lcd_overo.c |3 +- drivers/video/omap/lcd_palmte.c|2 +- drivers/video/omap/lcd_palmtt.c|2 +- drivers/video/omap/lcd_palmz71.c |2 +- drivers/video/omap/lcdc.c |3 +- drivers/video/omap/omapfb.h| 227 ++ drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c |3 +- drivers/video/omap/sossi.c |3 +- drivers/video/omap2/Kconfig|9 + drivers/video/omap2/Makefile |6 + drivers/video/omap2/displays/Kconfig | 22 + drivers/video/omap2/displays/Makefile |4 + drivers/video/omap2/displays/panel-generic.c | 104 + .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 153 + drivers/video/omap2/displays/panel-taal.c | 1003 ++
Re: CPUfreq deosn't change the current frequency
Hi tataki tarek attia wrote: Hi all, CPUfreq doesn't work,,I downloaded the PM Linux kernel ,and enabled the CPUFREQ driver before compilation . However every writting in the scaling_setspeed doesn't get any return,,doesn't change the frequency however without errors . Any Idea?? -- tarek -- 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 I have a board to test but now I don't have time, I just give the info to debug such issue Michael -- 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 v3 0/4] TWL patch series
Hi Balaji, On Wed, Dec 09, 2009 at 11:09:33AM +0530, Krishnamoorthy, Balaji T wrote: Hi Samuel, This patch is not merged. Please let me know if I am missing something so that i can post the patches rebased on the latest 2.6.32. I'd appreciate if you could rebase your patches, and also address Amit's concern on patch #3. I'll merge these patches then. Cheers, Samuel. Thanks and Regards, Balaji T K -Original Message- From: Krishnamoorthy, Balaji T Sent: Thursday, October 01, 2009 5:35 PM To: linux-omap@vger.kernel.org Cc: Krishnamoorthy, Balaji T; Shilimkar, Santosh; Nayak, Rajendra; a.zu...@towertech.it; p_gortma...@yahoo.com; sa...@linux.intel.com; t...@atomide.com Subject: [PATCH v3 0/4] TWL patch series This patch series v3 incorporates comments received earlier[1]. The upcoming TWL6030 is companion chip for OMAP4 like the current TWL4030 for OMAP3. The common modules like RTC, Regulator creates opportunity to re-use the most of the code from twl4030. [PATCH v3 01/04] ARM: OMAP: Rename twl4030* driver files to enable re- use [PATCH v3 02/04] ARM: OMAP: Rename all twl4030_i2c*. [PATCH v3 03/04] ARM: OMAP: Rename twl4030_ in rtc-twl.c to make it generic rtc [PATCH v3 04/04] ARM: OMAP: Rename twl4030_ to twl_ in twl-regulator.c to make it generic reg [1] http://marc.info/?l=linux-omapm=124757921417187w=2 [PATCH 0/4] TWL patch series -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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] Input: gpio-keys: Support for one-directional interrupts
On Wed, Dec 09, 2009 at 08:15:26AM -0800, Cory Maccarrone wrote: On Wed, Dec 9, 2009 at 3:32 AM, Ferenc Wagner wf...@niif.hu wrote: Cory Maccarrone darkstar6...@gmail.com writes: Interesting. Btw. I'd like to convert gpio-keys from edge-triggered to level-triggered interrupts. Would that work for your hardware? I'm fairly certain it wouldn't. Each of the interrupts on my hardware has a corresponding bit in a control register that determines if it's rising or falling-edge triggered -- thus the need for my patch. To capture both directions, it's necessary to modify the control register when a falling edge is detected, so that the corresponding rising edge can be collected afterward. This kind of ugliness should be hidden in irqchip driver. See mfd/asic3.c for an example. May I ask why you're thinking of converting to level-triggering? Perhaps it would be better to provide an option in the platform_device structure to set edge- or level-triggering, similar to the change I'm proposing for interrupts that can only signal one way at a time. Yes, we need a way fro platform code to specify desired interrupt flags but I don't believe we should be reconfiguring them on the fly. -- Dmitry -- 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/6] OMAP4: update series
Tony, Russell, This series has fixes for OMAP4430 and generated against latest mainline kernel. The series is tested on OMAP4430SDP ES1.0 silicon It's needs an UART related patch which is in your(Tony's) queue. Please review the same. The following changes since commit 2588465badb648a50cd19623f0dd0063c90d4e31: Linus Torvalds (1): Merge branch 'bkl-arch-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip Santosh Shilimkar (6): OMAP4: Fix cpu detection OMAP4: Fix SRAM base and size OMAP4: Re-arrange the low level debug code OMAP4: AuxCoreBoot registers only accessible in secure mode. OMAP4: Remove the secondary wait loop. OMAP4: Sync up omap4430 defconfig arch/arm/configs/omap_4430sdp_defconfig| 146 ++-- arch/arm/mach-omap2/id.c | 27 - arch/arm/mach-omap2/include/mach/debug-macro.S | 13 ++- arch/arm/mach-omap2/omap-headsmp.S | 35 +-- arch/arm/mach-omap2/omap-smp.c | 31 ++ arch/arm/plat-omap/common.c|2 +- arch/arm/plat-omap/include/plat/cpu.h |3 +- arch/arm/plat-omap/include/plat/smp.h |2 + arch/arm/plat-omap/sram.c | 12 ++- 9 files changed, 171 insertions(+), 100 deletions(-) Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] OMAP4: Fix SRAM base and size
This patch fixes the public sram base address and available
size on OMAP4430.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/sram.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 3e92366..3044009 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -47,8 +47,10 @@
#define OMAP3_SRAM_VA 0xfe40
#define OMAP3_SRAM_PUB_PA 0x40208000
#define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000)
-#define OMAP4_SRAM_PA 0x4020 /*0x402f*/
-#define OMAP4_SRAM_VA 0xfe40 /*0xfe4f*/
+#define OMAP4_SRAM_PA 0x4030
+#define OMAP4_SRAM_VA 0xfe40
+#define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
+#define OMAP4_SRAM_PUB_VA (OMAP4_SRAM_VA + 0x4000)
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
#define SRAM_BOOTLOADER_SZ 0x00
@@ -139,6 +141,10 @@ void __init omap_detect_sram(void)
} else {
omap_sram_size = 0x8000; /* 32K */
}
+ } else if (cpu_is_omap44xx()) {
+ omap_sram_base = OMAP4_SRAM_PUB_VA;
+ omap_sram_start = OMAP4_SRAM_PUB_PA;
+ omap_sram_size = 0xa000; /* 40K */
} else {
omap_sram_base = OMAP2_SRAM_PUB_VA;
omap_sram_start = OMAP2_SRAM_PUB_PA;
@@ -152,7 +158,7 @@ void __init omap_detect_sram(void)
} else if (cpu_is_omap44xx()) {
omap_sram_base = OMAP4_SRAM_VA;
omap_sram_start = OMAP4_SRAM_PA;
- omap_sram_size = 0x8000; /* 32K */
+ omap_sram_size = 0xe000; /* 56K */
} else {
omap_sram_base = OMAP2_SRAM_VA;
omap_sram_start = OMAP2_SRAM_PA;
--
1.6.0.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
[PATCH 5/6] OMAP4: Remove the secondary wait loop.
The secondary cores wakes up in time so the wait loop is not
necessary anymore.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-smp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 59e8478..38153e5 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -17,7 +17,6 @@
*/
#include linux/init.h
#include linux/device.h
-#include linux/jiffies.h
#include linux/smp.h
#include linux/io.h
@@ -62,8 +61,6 @@ void __cpuinit platform_secondary_init(unsigned int cpu)
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
@@ -80,10 +77,6 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
flush_cache_all();
smp_wmb();
- timeout = jiffies + (1 * HZ);
- while (time_before(jiffies, timeout))
- ;
-
/*
* Now the secondary core is starting up let it run its
* calibrations, then wait for it to finish
--
1.6.0.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
[PATCH 3/6] OMAP4: Re-arrange the low level debug code
On OMAP4430 the UART3 base address is different than that on OMAP3. Because of this existing code needs additional #ifdef'ry to accommodate that code. Hence this patch separates it. Also UART3 base address is fixed for OMAP4430 in this patch. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/include/mach/debug-macro.S | 13 - 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S index e9f255d..b2b4b29 100644 --- a/arch/arm/mach-omap2/include/mach/debug-macro.S +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S @@ -25,7 +25,7 @@ add \rx, \rx, #0x4000 @ UART 3 #endif -#elif defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) +#elif CONFIG_ARCH_OMAP3 moveq \rx, #0x4800@ physical base address movne \rx, #0xfa00@ virtual base orr \rx, \rx, #0x0006a000 @@ -36,6 +36,17 @@ add \rx, \rx, #0x00fb @ UART 3 add \rx, \rx, #0x6000 #endif +#elif CONFIG_ARCH_OMAP4 + moveq \rx, #0x4800@ physical base address + movne \rx, #0xfa00@ virtua base + orr \rx, \rx, #0x0006a000 @ UART 1 +#ifdef CONFIG_OMAP_LL_DEBUG_UART2 + add \rx, \rx, #0x2000 @ UART 2 +#endif +#ifdef CONFIG_OMAP_LL_DEBUG_UART3 + and \rx, \rx, #0xff00 + add \rx, \rx, #0x0002 @ UART 3 +#endif #endif .endm -- 1.6.0.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
[PATCH 1/6] OMAP4: Fix cpu detection
This patch fixes the OMAP4430 cpu detection. Since the omap ID
register is not fused in OMAP4430 ES1.0 silicon, identification is
done using ARM CPUID register.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/id.c | 27 ++-
arch/arm/plat-omap/common.c |2 +-
arch/arm/plat-omap/include/plat/cpu.h |3 ++-
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..52c6478 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -246,6 +246,31 @@ void __init omap3_check_revision(void)
}
}
+void __init omap4_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+ char *rev_name = ES1.0;
+
+ /*
+* The IC rev detection is done with hawkeye and rev.
+* Note that rev does not map directly to defined processor
+* revision numbers as ES1.0 uses value 0.
+*/
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+
+ if ((hawkeye == 0xb852) (rev == 0x0)) {
+ omap_revision = OMAP4430_REV_ES1_0;
+ pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ return;
+ }
+
+ printk(KERN_ERR Unknown OMAP CPU id\n);
+}
+
#define OMAP3_SHOW_FEATURE(feat) \
if (omap3_has_ ##feat())\
printk(#feat );
@@ -336,7 +361,7 @@ void __init omap2_check_revision(void)
omap3_check_features();
omap3_cpuinfo();
} else if (cpu_is_omap44xx()) {
- printk(KERN_INFO FIXME: CPU revision = OMAP4430\n);
+ omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index cc050b3..3473a80 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -280,7 +280,7 @@ void __init omap2_set_globals_343x(void)
#if defined(CONFIG_ARCH_OMAP4)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
- .tap= OMAP2_L4_IO_ADDRESS(0x4830a000),
+ .tap= OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..2a141ba 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -443,7 +443,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3505_REV(v)(OMAP35XX_CLASS | (0x3505 16) | (v
12))
#define OMAP3517_REV(v)(OMAP35XX_CLASS | (0x3517 16) | (v
12))
-#define OMAP443X_CLASS 0x44300034
+#define OMAP443X_CLASS 0x44300044
+#define OMAP4430_REV_ES1_0 0x44300044
/*
* omap_chip bits
--
1.6.0.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
[PATCH 4/6] OMAP4: AuxCoreBoot registers only accessible in secure mode.
The AuxCoreBoot0 and AuxCoreBoot1 can be only accessed in secure
mode. Replace the current code with secure monitor API's to access/modify
these registers.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-headsmp.S| 35 +---
arch/arm/mach-omap2/omap-smp.c| 24 +++---
arch/arm/plat-omap/include/plat/smp.h |2 +
3 files changed, 37 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-headsmp.S
b/arch/arm/mach-omap2/omap-headsmp.S
index 4afadba..aa3f65c 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -27,20 +27,39 @@
* 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.
+ * The primary core will update this flag using a hardware
+ * register AuxCoreBoot0.
*/
ENTRY(omap_secondary_startup)
- mrc p15, 0, r0, c0, c0, 5
- and r0, r0, #0x0f
-hold: ldr r1, =OMAP4_AUX_CORE_BOOT1_PA@ read from AuxCoreBoot1
- ldr r2, [r1]
- cmp r2, r0
+hold: ldr r12,=0x103
+ dsb
+ smc @ read from AuxCoreBoot0
+ mov r0, r0, lsr #9
+ mrc p15, 0, r4, c0, c0, 5
+ and r4, r4, #0x0f
+ cmp r0, r4
bne hold
/*
-* we've been released from the cpu_release,secondary_stack
+* we've been released from the wait loop,secondary_stack
* should now contain the SVC stack for this core
*/
b secondary_startup
+END(omap_secondary_startup)
+
+ENTRY(omap_modify_auxcoreboot0)
+ stmfd sp!, {r1-r12, lr}
+ ldr r12, =0x104
+ dsb
+ smc
+ ldmfd sp!, {r1-r12, pc}
+END(omap_modify_auxcoreboot0)
+
+ENTRY(omap_auxcoreboot_addr)
+ stmfd sp!, {r2-r12, lr}
+ ldr r12, =0x105
+ dsb
+ smc
+ ldmfd sp!, {r2-r12, pc}
+END(omap_auxcoreboot_addr)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 4890bcf..59e8478 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -21,15 +21,12 @@
#include linux/smp.h
#include linux/io.h
+#include asm/cacheflush.h
#include asm/localtimer.h
#include asm/smp_scu.h
#include mach/hardware.h
#include plat/common.h
-/* Registers used for communicating startup information */
-static void __iomem *omap4_auxcoreboot_reg0;
-static void __iomem *omap4_auxcoreboot_reg1;
-
/* SCU base address */
static void __iomem *scu_base;
@@ -74,12 +71,13 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
spin_lock(boot_lock);
/*
-* Update the AuxCoreBoot1 with boot state for secondary core.
+* Update the AuxCoreBoot0 with boot state for secondary core.
* omap_secondary_startup() routine will hold the secondary core till
* the AuxCoreBoot1 register is updated with cpu state
* A barrier is added to ensure that write buffer is drained
*/
- __raw_writel(cpu, omap4_auxcoreboot_reg1);
+ omap_modify_auxcoreboot0(0x200, 0x0);
+ flush_cache_all();
smp_wmb();
timeout = jiffies + (1 * HZ);
@@ -99,17 +97,18 @@ static void __init wakeup_secondary(void)
{
/*
* Write the address of secondary startup routine into the
-* AuxCoreBoot0 where ROM code will jump and start executing
+* AuxCoreBoot1 where ROM code will jump and start executing
* on secondary core once out of WFE
* A barrier is added to ensure that write buffer is drained
*/
- __raw_writel(virt_to_phys(omap_secondary_startup), \
- omap4_auxcoreboot_reg0);
+ omap_auxcoreboot_addr(virt_to_phys(omap_secondary_startup));
smp_wmb();
/*
* Send a 'sev' to wake the secondary core from WFE.
+* Drain the outstanding writes to memory
*/
+ dsb();
set_event();
mb();
}
@@ -136,7 +135,6 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
{
unsigned int ncores = get_core_count();
unsigned int cpu = smp_processor_id();
- void __iomem *omap4_wkupgen_base;
int i;
/* sanity check */
@@ -168,12 +166,6 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
for (i = 0; i max_cpus; i++)
set_cpu_present(i, true);
- /* Never released */
- omap4_wkupgen_base = ioremap(OMAP44XX_WKUPGEN_BASE, SZ_4K);
- BUG_ON(!omap4_wkupgen_base);
- omap4_auxcoreboot_reg0 = omap4_wkupgen_base + 0x800;
- omap4_auxcoreboot_reg1 = omap4_wkupgen_base + 0x804;
-
if (max_cpus 1) {
/*
[PATCH 6/6] OMAP4: Sync up omap4430 defconfig
Enable minimum features to boot omap4430 on es1.0 samples Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 146 ++- 1 files changed, 84 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a464ca3..49df3ad 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,26 +1,29 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 # 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_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_GENERIC_LOCKBREAK=y CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y # # General setup @@ -39,11 +42,12 @@ CONFIG_BSD_PROCESS_ACCT=y # # RCU Subsystem # -CONFIG_CLASSIC_RCU=y -# CONFIG_TREE_RCU is not set -# CONFIG_PREEMPT_RCU is not set +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set -# CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_GROUP_SCHED=y @@ -52,8 +56,7 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y @@ -70,7 +73,6 @@ CONFIG_UID16=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set -# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y @@ -83,6 +85,10 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y @@ -90,13 +96,16 @@ CONFIG_COMPAT_BRK=y CONFIG_SLUB=y # 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_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# # CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y @@ -110,7 +119,7 @@ CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y -# CONFIG_LBD is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -131,6 +140,7 @@ CONFIG_DEFAULT_IOSCHED=anticipatory # # System Type # +CONFIG_MMU=y # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set @@ -142,8 +152,10 @@ CONFIG_DEFAULT_IOSCHED=anticipatory # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -166,10 +178,13 @@ CONFIG_DEFAULT_IOSCHED=anticipatory # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set +# CONFIG_ARCH_S5PC1XX is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_U300 is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y +# CONFIG_ARCH_BCMRING is not set # # TI OMAP Implementations @@ -190,9 +205,12 @@ CONFIG_ARCH_OMAP4=y CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_DM_TIMER=y -CONFIG_OMAP_LL_DEBUG_UART1=y +# CONFIG_OMAP_LL_DEBUG_UART1 is not set # CONFIG_OMAP_LL_DEBUG_UART2 is not set -# CONFIG_OMAP_LL_DEBUG_UART3 is not set +CONFIG_OMAP_LL_DEBUG_UART3=y +# CONFIG_OMAP_LL_DEBUG_NONE is not set +# CONFIG_OMAP_PM_NONE is not set +CONFIG_OMAP_PM_NOOP=y # # OMAP Board Type @@ -207,7 +225,7 @@ CONFIG_CPU_32v6K=y CONFIG_CPU_V7=y CONFIG_CPU_32v7=y CONFIG_CPU_ABRT_EV7=y -CONFIG_CPU_PABRT_IFAR=y +CONFIG_CPU_PABRT_V7=y CONFIG_CPU_CACHE_V7=y CONFIG_CPU_CACHE_VIPT=y CONFIG_CPU_COPY_V6=y @@ -222,9 +240,10 @@ CONFIG_CPU_CP15_MMU=y # CONFIG_ARM_THUMB is not set # CONFIG_ARM_THUMBEE is not set # CONFIG_CPU_ICACHE_DISABLE is not set
[PATCH 0/4] OMAP4: Enable L2 cache
Tony, Russell, This series is based on top of earlier series [1] and generated against latest Mainline. This enables the L2 cache support on OMAP4430 SDP platform. [1] http://patchwork.kernel.org/patch/66028/ [PATCH 0/6] OMAP4: update series The Errata patch [PATCH 3/4] may need to be streamlined bit since it's touching generic code. I didn't find a better way to patch this. Thanks for the review !! --- Santosh Shilimkar (4): OMAP4: Add L2 Cache support OMAP4: Clean the secondary_data from L2 ARM: L2 : Errata 588369: Clean Invalidate do not invalidate clean lines OMAP4: Enable L2 Cache arch/arm/Kconfig | 13 +++ arch/arm/configs/omap_4430sdp_defconfig|3 ++ arch/arm/mach-omap2/board-4430sdp.c| 30 ++ arch/arm/mach-omap2/omap-smp.c |2 + arch/arm/mm/Kconfig|2 +- arch/arm/mm/cache-l2x0.c | 32 arch/arm/plat-omap/include/plat/omap44xx.h |1 + 7 files changed, 82 insertions(+), 1 deletions(-) Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] OMAP4: Clean the secondary_data from L2
The boot_secondary() needs to call outer_clean_range() because the L2 cache is already enabled in the kernel boot with early_initcall Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-smp.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c index 38153e5..2d0733a 100644 --- a/arch/arm/mach-omap2/omap-smp.c +++ b/arch/arm/mach-omap2/omap-smp.c @@ -73,6 +73,8 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle) * the AuxCoreBoot1 register is updated with cpu state * A barrier is added to ensure that write buffer is drained */ + flush_cache_all(); + outer_clean_range(__pa(secondary_data), __pa(secondary_data + 1)); omap_modify_auxcoreboot0(0x200, 0x0); flush_cache_all(); smp_wmb(); -- 1.6.0.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
[PATCH 3/4] ARM: L2 : Errata 588369: Clean Invalidate do not invalidate clean lines
This patch implements the work-around for the errata 588369. The secure API
is used to alter L2 debug regsiter because of trust-zone.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/Kconfig | 13 +
arch/arm/mm/cache-l2x0.c | 32
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cf8a99f..388d1e3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -916,6 +916,19 @@ config ARM_ERRATA_460075
ACTLR register. Note that setting specific bits in the ACTLR register
may not be available in non-secure mode.
+config PL310_ERRATA_588369
+ bool Clean Invalidate maintenance operations do not invalidate clean
lines
+ depends on CACHE_L2X0
+ default n
+ help
+ The PL310 L2 cache controller implements three types of Clean
+ Invalidate maintenance operations: by Physical Address
+ (offset 0x7F0), by Index/Way (0x7F8) and by Way (0x7FC).
+ They are architecturally defined to behave as the execution of a
+ clean operation followed immediately by an invalidate operation,
+ both performing to the same memory location. This functionality
+ is not correctly implemented in PL310 as clean lines are not
+ invalidated as a result of these operations
endmenu
source arch/arm/common/Kconfig
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 747f9a9..c3905a9 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -88,8 +88,40 @@ static void l2x0_flush_range(unsigned long start, unsigned
long end)
unsigned long addr;
start = ~(CACHE_LINE_SIZE - 1);
+#ifdef CONFIG_PL310_ERRATA_588369
+ /*
+* Disable Write-Back and Cache Linefill (set bits [1:0] of the Debug
+* Control Register)
+*/
+ __asm__ __volatile__(
+ stmfd r13!, {r0-r12, r14}\n
+ mov r0, #3\n
+ ldr r12, =0x100\n
+ dsb\n
+ smc\n
+ ldmfd r13!, {r0-r12, r14});
+
+ /* Clean by PA followed by Invalidate by PA */
+ for (addr = start; addr end; addr += CACHE_LINE_SIZE) {
+ sync_writel(addr, L2X0_CLEAN_LINE_PA, 1);
+ sync_writel(addr, L2X0_INV_LINE_PA, 1);
+ }
+
+ /*
+* Enable Write-Back and Cache Linefill (set bits [1:0] of the Debug
+* Control Register)
+*/
+ __asm__ __volatile__(
+ stmfd r13!, {r0-r12, r14}\n
+ mov r0, #0\n
+ ldr r12, =0x100\n
+ dsb\n
+ smc\n
+ ldmfd r13!, {r0-r12, r14});
+#else
for (addr = start; addr end; addr += CACHE_LINE_SIZE)
sync_writel(addr, L2X0_CLEAN_INV_LINE_PA, 1);
+#endif
cache_sync();
}
--
1.6.0.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
[PATCH 4/4] OMAP4: Enable L2 Cache
This patch enables L2 cache and associated Errata on the OMAP4430 SDP. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 49df3ad..2a8d555 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -243,10 +243,13 @@ CONFIG_CPU_CP15_MMU=y # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_CPU_BPREDICT_DISABLE is not set CONFIG_HAS_TLS_REG=y +CONFIG_OUTER_CACHE=y +CONFIG_CACHE_L2X0=y CONFIG_ARM_L1_CACHE_SHIFT=5 # CONFIG_ARM_ERRATA_430973 is not set # CONFIG_ARM_ERRATA_458693 is not set # CONFIG_ARM_ERRATA_460075 is not set +CONFIG_PL310_ERRATA_588369=y CONFIG_ARM_GIC=y # -- 1.6.0.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
[PATCH 1/4] OMAP4: Add L2 Cache support
This patch adds L2 Cache support for OMAP4. External L2 cache
is used in OMPA4
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 30
arch/arm/mm/Kconfig|2 +-
arch/arm/plat-omap/include/plat/omap44xx.h |1 +
3 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 0c6be6b..ceb2490 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -28,6 +28,7 @@
#include plat/control.h
#include plat/timer-gp.h
#include asm/hardware/gic.h
+#include asm/hardware/cache-l2x0.h
static struct platform_device sdp4430_lcd_device = {
.name = sdp4430_lcd,
@@ -49,6 +50,35 @@ static struct omap_lcd_config sdp4430_lcd_config __initdata
= {
static struct omap_board_config_kernel sdp4430_config[] __initdata = {
{ OMAP_TAG_LCD, sdp4430_lcd_config },
};
+#ifdef CONFIG_CACHE_L2X0
+static int __init omap_l2_cache_init(void)
+{
+ void __iomem *l2cache_base;
+
+ /* Static mapping, never released */
+ l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
+ BUG_ON(!l2cache_base);
+
+ /* Enable L2 Cache using secure api
+* Save/Restore relevant registers
+*/
+ __asm__ __volatile__(
+ stmfd r13!, {r0-r12, r14}\n
+ mov r0, #1\n
+ ldr r12, =0x102\n
+ dsb\n
+ smc\n
+ ldmfd r13!, {r0-r12, r14});
+
+ /* 32KB way size, 16-way associativity,
+ * parity disabled
+ */
+ l2x0_init(l2cache_base, 0x0e05, 0xcfff);
+
+ return 0;
+}
+early_initcall(omap_l2_cache_init);
+#endif
static void __init gic_init_irq(void)
{
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index dd4698c..b146ae2 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -758,7 +758,7 @@ config CACHE_FEROCEON_L2_WRITETHROUGH
config CACHE_L2X0
bool Enable the L2x0 outer cache controller
depends on REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP ||
MACH_REALVIEW_PB1176 || \
- REALVIEW_EB_A9MP || ARCH_MX35 || ARCH_MX31 ||
MACH_REALVIEW_PBX || ARCH_NOMADIK
+ REALVIEW_EB_A9MP || ARCH_MX35 || ARCH_MX31 ||
MACH_REALVIEW_PBX || ARCH_NOMADIK || ARCH_OMAP4
default y
select OUTER_CACHE
help
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
b/arch/arm/plat-omap/include/plat/omap44xx.h
index e52902a..9b7870c 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -38,6 +38,7 @@
#define OMAP44XX_GIC_CPU_BASE 0x48240100
#define OMAP44XX_SCU_BASE 0x4824
#define OMAP44XX_LOCAL_TWD_BASE0x48240600
+#define OMAP44XX_L2CACHE_BASE 0x48242000
#define OMAP44XX_WKUPGEN_BASE 0x48281000
#define OMAP44XX_MAILBOX_BASE (L4_44XX_BASE + 0xF4000)
--
1.6.0.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: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig
Santosh -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Wednesday, December 09, 2009 12:29 PM To: t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk; Shilimkar, Santosh Subject: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig Enable minimum features to boot omap4430 on es1.0 samples Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 146 ++- 1 files changed, 84 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a464ca3..49df3ad 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,26 +1,29 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 snip -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y This is a deprecated feature and don't introduce it back again. There haven been patches in recent past to get rid of this. # CONFIG_RELAY is not set -- 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 6/6] OMAP4: Sync up omap4430 defconfig
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Wednesday, December 09, 2009 12:29 PM To: t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk; Shilimkar, Santosh Subject: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig Enable minimum features to boot omap4430 on es1.0 samples Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 146 ++- 1 files changed, 84 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a464ca3..49df3ad 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,26 +1,29 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 snip -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y This is a deprecated feature and don't introduce it back again. There haven been patches in recent past to get rid of this. Thanks Vikram. The thing is some of the busy box people are using get confused and stuck without this. Do you have pointers to those patches ? Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig
-Original Message- From: Shilimkar, Santosh Sent: Wednesday, December 09, 2009 12:49 PM To: Pandita, Vikram; t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk Subject: RE: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Wednesday, December 09, 2009 12:29 PM To: t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk; Shilimkar, Santosh Subject: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig Enable minimum features to boot omap4430 on es1.0 samples Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 146 ++- 1 files changed, 84 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a464ca3..49df3ad 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,26 +1,29 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 snip -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y This is a deprecated feature and don't introduce it back again. There haven been patches in recent past to get rid of this. Thanks Vikram. The thing is some of the busy box people are using get confused and stuck without this. The reason is they have not upgraded to latest busybox yet. Do you have pointers to those patches ? Here's the reference in k.org http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6502401d8169f76c6a72849cb55e8302226ca930 Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig
# Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 snip -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y This is a deprecated feature and don't introduce it back again. There haven been patches in recent past to get rid of this. Thanks Vikram. The thing is some of the busy box people are using get confused and stuck without this. The reason is they have not upgraded to latest busybox yet. I guessed so. Time to upgrade the file system. Do you have pointers to those patches ? Here's the reference in k.org http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- 2.6.git;a=commit;h=6502401d8169f76c6a72849cb55e8302226ca930 OK. Then we can get rid of this on OMAP4 too. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig
Shilimkar, Santosh wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Wednesday, December 09, 2009 12:29 PM To: t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk; Shilimkar, Santosh Subject: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig Enable minimum features to boot omap4430 on es1.0 samples Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 146 ++- 1 files changed, 84 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a464ca3..49df3ad 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,26 +1,29 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 snip -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y This is a deprecated feature and don't introduce it back again. There haven been patches in recent past to get rid of this. Thanks Vikram. The thing is some of the busy box people are using get confused and stuck without this. Do you have pointers to those patches ? Poky, and other open-embedded based distros expect this to be disabled to work correctly The solution is to upgrade busybox, not enable a deprecated CONFIG option. Patches to update the different OMAP defconfig were posted to l-o a few months ago. Here's one.such patch. http://patchwork.kernel.org/patch/40949/ - 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 3/4] ARM: L2 : Errata 588369: Clean Invalidate do not invalidate clean lines
Hi,
* Santosh Shilimkar santosh.shilim...@ti.com [091209 10:42]:
This patch implements the work-around for the errata 588369. The secure API
is used to alter L2 debug regsiter because of trust-zone.
This one should be queued via Russell's patch system. It should
be also acked by Catalin.
Regards,
Tony
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/Kconfig | 13 +
arch/arm/mm/cache-l2x0.c | 32
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cf8a99f..388d1e3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -916,6 +916,19 @@ config ARM_ERRATA_460075
ACTLR register. Note that setting specific bits in the ACTLR register
may not be available in non-secure mode.
+config PL310_ERRATA_588369
+ bool Clean Invalidate maintenance operations do not invalidate clean
lines
+ depends on CACHE_L2X0
+ default n
+ help
+The PL310 L2 cache controller implements three types of Clean
+Invalidate maintenance operations: by Physical Address
+(offset 0x7F0), by Index/Way (0x7F8) and by Way (0x7FC).
+They are architecturally defined to behave as the execution of a
+clean operation followed immediately by an invalidate operation,
+both performing to the same memory location. This functionality
+is not correctly implemented in PL310 as clean lines are not
+invalidated as a result of these operations
endmenu
source arch/arm/common/Kconfig
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 747f9a9..c3905a9 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -88,8 +88,40 @@ static void l2x0_flush_range(unsigned long start, unsigned
long end)
unsigned long addr;
start = ~(CACHE_LINE_SIZE - 1);
+#ifdef CONFIG_PL310_ERRATA_588369
+ /*
+ * Disable Write-Back and Cache Linefill (set bits [1:0] of the Debug
+ * Control Register)
+ */
+ __asm__ __volatile__(
+ stmfd r13!, {r0-r12, r14}\n
+ mov r0, #3\n
+ ldr r12, =0x100\n
+ dsb\n
+ smc\n
+ ldmfd r13!, {r0-r12, r14});
+
+ /* Clean by PA followed by Invalidate by PA */
+ for (addr = start; addr end; addr += CACHE_LINE_SIZE) {
+ sync_writel(addr, L2X0_CLEAN_LINE_PA, 1);
+ sync_writel(addr, L2X0_INV_LINE_PA, 1);
+ }
+
+ /*
+ * Enable Write-Back and Cache Linefill (set bits [1:0] of the Debug
+ * Control Register)
+ */
+ __asm__ __volatile__(
+ stmfd r13!, {r0-r12, r14}\n
+ mov r0, #0\n
+ ldr r12, =0x100\n
+ dsb\n
+ smc\n
+ ldmfd r13!, {r0-r12, r14});
+#else
for (addr = start; addr end; addr += CACHE_LINE_SIZE)
sync_writel(addr, L2X0_CLEAN_INV_LINE_PA, 1);
+#endif
cache_sync();
}
--
1.6.0.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: [PATCH 1/6] OMAP4: Fix cpu detection
On Wed, Dec 9, 2009 at 12:29 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
This patch fixes the OMAP4430 cpu detection. Since the omap ID
register is not fused in OMAP4430 ES1.0 silicon, identification is
done using ARM CPUID register.
Am I reading the commit message wrong? the code seems to check on
TAPID instead of checking the arm CPUID...
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/id.c | 27 ++-
arch/arm/plat-omap/common.c | 2 +-
arch/arm/plat-omap/include/plat/cpu.h | 3 ++-
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..52c6478 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -246,6 +246,31 @@ void __init omap3_check_revision(void)
}
}
+void __init omap4_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+ char *rev_name = ES1.0;
+
+ /*
+ * The IC rev detection is done with hawkeye and rev.
+ * Note that rev does not map directly to defined processor
+ * revision numbers as ES1.0 uses value 0.
+ */
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+
+ if ((hawkeye == 0xb852) (rev == 0x0)) {
+ omap_revision = OMAP4430_REV_ES1_0;
+ pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ return;
+ }
+
+ printk(KERN_ERR Unknown OMAP CPU id\n);
a) Do you want to state unknown OMAP4 CPU id?
b) why not use pr_err?
+}
+
#define OMAP3_SHOW_FEATURE(feat) \
if (omap3_has_ ##feat()) \
printk(#feat );
@@ -336,7 +361,7 @@ void __init omap2_check_revision(void)
omap3_check_features();
omap3_cpuinfo();
} else if (cpu_is_omap44xx()) {
- printk(KERN_INFO FIXME: CPU revision = OMAP4430\n);
+ omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index cc050b3..3473a80 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -280,7 +280,7 @@ void __init omap2_set_globals_343x(void)
#if defined(CONFIG_ARCH_OMAP4)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
- .tap = OMAP2_L4_IO_ADDRESS(0x4830a000),
+ .tap = OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
What does this have to do with the subject of the patch? I agree it is
a good thing to have, but probably belongs elsewhere.
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm = OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..2a141ba 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -443,7 +443,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3505_REV(v) (OMAP35XX_CLASS | (0x3505 16) | (v
12))
#define OMAP3517_REV(v) (OMAP35XX_CLASS | (0x3517 16) | (v
12))
-#define OMAP443X_CLASS 0x44300034
+#define OMAP443X_CLASS 0x44300044
+#define OMAP4430_REV_ES1_0 0x44300044
Errr.. why? I suspect this might be to get the class and subclass right..
Dont we need an cpu_is_omap_4430() to use it correctly? (unless I
missed a pending patch series as I am checking l-o kernel codebase)..
do we need the following?
IS_OMAP_CLASS(44xx, 0x44)
IS_OMAP_SUBCLASS(443x, 0x443)
then you will have is_omap_443x() and you can now:
#define cpu_is_omap4430 is_omap443x()
just my 2cents..
/*
* omap_chip bits
Regards,
Nishanth Menon
--
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/6] OMAP4: Fix cpu detection
Hi Santosh,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
This patch fixes the OMAP4430 cpu detection. Since the omap ID
register is not fused in OMAP4430 ES1.0 silicon, identification is
done using ARM CPUID register.
I think that this description is not reflecting your current patch that does
use the DEVICE_ID register.
Regards,
Benoit
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/id.c | 27 ++-
arch/arm/plat-omap/common.c |2 +-
arch/arm/plat-omap/include/plat/cpu.h |3 ++-
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..52c6478 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -246,6 +246,31 @@ void __init omap3_check_revision(void)
}
}
+void __init omap4_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+ char *rev_name = ES1.0;
+
+ /*
+ * The IC rev detection is done with hawkeye and rev.
+ * Note that rev does not map directly to defined processor
+ * revision numbers as ES1.0 uses value 0.
+ */
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+
+ if ((hawkeye == 0xb852) (rev == 0x0)) {
+ omap_revision = OMAP4430_REV_ES1_0;
+ pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ return;
+ }
+
+ printk(KERN_ERR Unknown OMAP CPU id\n);
+}
+
#define OMAP3_SHOW_FEATURE(feat) \
if (omap3_has_ ##feat())\
printk(#feat );
@@ -336,7 +361,7 @@ void __init omap2_check_revision(void)
omap3_check_features();
omap3_cpuinfo();
} else if (cpu_is_omap44xx()) {
- printk(KERN_INFO FIXME: CPU revision = OMAP4430\n);
+ omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index cc050b3..3473a80 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -280,7 +280,7 @@ void __init omap2_set_globals_343x(void)
#if defined(CONFIG_ARCH_OMAP4)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
- .tap= OMAP2_L4_IO_ADDRESS(0x4830a000),
+ .tap= OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-
omap/include/plat/cpu.h
index 2e17890..2a141ba 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -443,7 +443,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3505_REV(v) (OMAP35XX_CLASS | (0x3505 16) | (v
12))
#define OMAP3517_REV(v) (OMAP35XX_CLASS | (0x3517 16) | (v
12))
-#define OMAP443X_CLASS0x44300034
+#define OMAP443X_CLASS0x44300044
+#define OMAP4430_REV_ES1_00x44300044
/*
* omap_chip bits
--
1.6.0.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
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
--
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/6] OMAP4: Fix cpu detection
-Original Message- From: Cousson, Benoit Sent: Thursday, December 10, 2009 1:04 AM To: Shilimkar, Santosh; t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk Subject: RE: [PATCH 1/6] OMAP4: Fix cpu detection Hi Santosh, From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh This patch fixes the OMAP4430 cpu detection. Since the omap ID register is not fused in OMAP4430 ES1.0 silicon, identification is done using ARM CPUID register. I think that this description is not reflecting your current patch that does use the DEVICE_ID register. Yes. The second version uses ID_CODE but the commit message still refers to the 1st one. Will fix Commit message. -- 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/6] OMAP4: Fix cpu detection
Thanks Nishant !!
+ if ((hawkeye == 0xb852) (rev == 0x0)) {
+ omap_revision = OMAP4430_REV_ES1_0;
+ pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ return;
+ }
+
+ printk(KERN_ERR Unknown OMAP CPU id\n);
a) Do you want to state unknown OMAP4 CPU id?
b) why not use pr_err?
OK
@@ -280,7 +280,7 @@ void __init omap2_set_globals_343x(void)
#if defined(CONFIG_ARCH_OMAP4)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
- .tap = OMAP2_L4_IO_ADDRESS(0x4830a000),
+ .tap = OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
What does this have to do with the subject of the patch? I agree it is
a good thing to have, but probably belongs elsewhere.
This is everything to do with subject. ID_CODE reg is in SCM and you
Need a right base to read that reg, Isn't it ?
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm = OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..2a141ba 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -443,7 +443,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3505_REV(v) (OMAP35XX_CLASS | (0x3505 16) |
(v 12))
#define OMAP3517_REV(v) (OMAP35XX_CLASS | (0x3517 16) |
(v 12))
-#define OMAP443X_CLASS 0x44300034
+#define OMAP443X_CLASS 0x44300044
+#define OMAP4430_REV_ES1_0 0x44300044
Errr.. why? I suspect this might be to get the class and subclass right..
Dont we need an cpu_is_omap_4430() to use it correctly? (unless I
missed a pending patch series as I am checking l-o kernel codebase)..
do we need the following?
IS_OMAP_CLASS(44xx, 0x44)
IS_OMAP_SUBCLASS(443x, 0x443)
then you will have is_omap_443x() and you can now:
#define cpu_is_omap4430 is_omap443x()
This has to be done and I planning to do this in next series. This series just
enables the basic boot on ES1.0.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAP4: Fix cpu detection
On Wed, Dec 9, 2009 at 1:50 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
Thanks Nishant !!
+ if ((hawkeye == 0xb852) (rev == 0x0)) {
+ omap_revision = OMAP4430_REV_ES1_0;
+ pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ return;
+ }
+
+ printk(KERN_ERR Unknown OMAP CPU id\n);
a) Do you want to state unknown OMAP4 CPU id?
b) why not use pr_err?
OK
@@ -280,7 +280,7 @@ void __init omap2_set_globals_343x(void)
#if defined(CONFIG_ARCH_OMAP4)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
- .tap = OMAP2_L4_IO_ADDRESS(0x4830a000),
+ .tap = OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
What does this have to do with the subject of the patch? I agree it is
a good thing to have, but probably belongs elsewhere.
This is everything to do with subject. ID_CODE reg is in SCM and you
Need a right base to read that reg, Isn't it ?
Gotcha.. thanks, could be an info useful in your rev2 commit message.
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm = OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..2a141ba 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -443,7 +443,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3505_REV(v) (OMAP35XX_CLASS | (0x3505 16) |
(v 12))
#define OMAP3517_REV(v) (OMAP35XX_CLASS | (0x3517 16) |
(v 12))
-#define OMAP443X_CLASS 0x44300034
+#define OMAP443X_CLASS 0x44300044
+#define OMAP4430_REV_ES1_0 0x44300044
Errr.. why? I suspect this might be to get the class and subclass right..
Dont we need an cpu_is_omap_4430() to use it correctly? (unless I
missed a pending patch series as I am checking l-o kernel codebase)..
do we need the following?
IS_OMAP_CLASS(44xx, 0x44)
IS_OMAP_SUBCLASS(443x, 0x443)
then you will have is_omap_443x() and you can now:
#define cpu_is_omap4430 is_omap443x()
This has to be done and I planning to do this in next series. This series just
enables the basic boot on ES1.0.
not sure, but might be good to do this in this patch as the CLASS and
ES1 value change dont make much sense without it.. it should not
change your basic boot behavior.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/5] OMAP: McBSP: Use register cache
Change the way McBSP registers are maintained: store values written to the device in a cache in order to make use of those cached values when convenient. This could help for developing the McBSP context save/restore features, as well as solve the problem of possible register corruption, experienced on OMAP1510 based Amstrad Delta board at least. Series created against linux-omap for-next, commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c. All patches tested on OMAP1510 based Amstrad Delta and compile-tested using omap_3430sdp_defconfig at least. Janusz Krzysztofik (5): OMAP: McBSP: Use macros for all register read/write operations OMAP: McBSP: Modify macros/functions API for easy cache access OMAP: McBSP: Introduce caching in register write operations OMAP: McBSP: Use cache when modifying individual register bits OMAP: McBSP: Split and move read/write functions to mach-omap1/2 arch/arm/mach-omap1/mcbsp.c | 28 + arch/arm/mach-omap2/mcbsp.c | 42 ++ arch/arm/plat-omap/include/plat/mcbsp.h |6 arch/arm/plat-omap/mcbsp.c | 470 +++- 4 files changed, 292 insertions(+), 254 deletions(-) Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/5] OMAP: McBSP: Use macros for all register read/write operations
There are several places where readw()/writew() functions are used instead of
OMAP_MCBSP_READ()/WRITE() macros for manipulating McBSP registers. Replace
them with macros to ensure consistent behaviour after caching is introduced.
Created against linux-omap for-next,
commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c.
Tested on OMAP1510 based Amstrad Delta.
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
No functional changes since v3.
arch/arm/plat-omap/mcbsp.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff -upr git.orig/arch/arm/plat-omap/mcbsp.c git/arch/arm/plat-omap/mcbsp.c
--- git.orig/arch/arm/plat-omap/mcbsp.c 2009-12-02 15:48:52.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2009-12-09 15:10:56.0 +0100
@@ -622,26 +622,26 @@ int omap_mcbsp_pollwrite(unsigned int id
mcbsp = id_to_mcbsp_ptr(id);
base = mcbsp-io_base;
- writew(buf, base + OMAP_MCBSP_REG_DXR1);
+ OMAP_MCBSP_WRITE(base, DXR1, buf);
/* if frame sync error - clear the error */
- if (readw(base + OMAP_MCBSP_REG_SPCR2) XSYNC_ERR) {
+ if (OMAP_MCBSP_READ(base, SPCR2) XSYNC_ERR) {
/* clear error */
- writew(readw(base + OMAP_MCBSP_REG_SPCR2) (~XSYNC_ERR),
- base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2) (~XSYNC_ERR));
/* resend */
return -1;
} else {
/* wait for transmit confirmation */
int attemps = 0;
- while (!(readw(base + OMAP_MCBSP_REG_SPCR2) XRDY)) {
+ while (!(OMAP_MCBSP_READ(base, SPCR2) XRDY)) {
if (attemps++ 1000) {
- writew(readw(base + OMAP_MCBSP_REG_SPCR2)
- (~XRST),
- base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2)
+ (~XRST));
udelay(10);
- writew(readw(base + OMAP_MCBSP_REG_SPCR2) |
- (XRST),
- base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2) |
+ (XRST));
udelay(10);
dev_err(mcbsp-dev, Could not write to
McBSP%d Register\n, mcbsp-id);
@@ -667,24 +667,24 @@ int omap_mcbsp_pollread(unsigned int id,
base = mcbsp-io_base;
/* if frame sync error - clear the error */
- if (readw(base + OMAP_MCBSP_REG_SPCR1) RSYNC_ERR) {
+ if (OMAP_MCBSP_READ(base, SPCR1) RSYNC_ERR) {
/* clear error */
- writew(readw(base + OMAP_MCBSP_REG_SPCR1) (~RSYNC_ERR),
- base + OMAP_MCBSP_REG_SPCR1);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1) (~RSYNC_ERR));
/* resend */
return -1;
} else {
/* wait for recieve confirmation */
int attemps = 0;
- while (!(readw(base + OMAP_MCBSP_REG_SPCR1) RRDY)) {
+ while (!(OMAP_MCBSP_READ(base, SPCR1) RRDY)) {
if (attemps++ 1000) {
- writew(readw(base + OMAP_MCBSP_REG_SPCR1)
- (~RRST),
- base + OMAP_MCBSP_REG_SPCR1);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1)
+ (~RRST));
udelay(10);
- writew(readw(base + OMAP_MCBSP_REG_SPCR1) |
- (RRST),
- base + OMAP_MCBSP_REG_SPCR1);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1) |
+ (RRST));
udelay(10);
dev_err(mcbsp-dev, Could not read from
McBSP%d Register\n, mcbsp-id);
@@ -692,7 +692,7 @@ int omap_mcbsp_pollread(unsigned int id,
}
}
}
- *buf = readw(base + OMAP_MCBSP_REG_DRR1);
+ *buf = OMAP_MCBSP_READ(base, DRR1);
[PATCH v7 2/5] OMAP: McBSP: Modify macros/functions API for easy cache access
OMAP_MCBSP_READ()/_WRITE() macros and omap_mcbsp_read()/_write() functions
accept McBSP register base address as an argument. In order to support
caching, that must be replaced with an address of the omap_mcbsp structure
that would provide addresses for both register AND cache access.
Since OMAP_ prefix seems obvious in macro names, drop it off in order to
minimize line wrapping throughout the file.
Applies on top of patch 1 from this series:
[PATCH v7 1/5] OMAP: McBSP: Use macros for all register read/write operations
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next,
commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c.
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes since v3:
- modify API of omap_mcbsp_read()/_write() functions as well, since those will
actually provide caching operations, not macros like before.
arch/arm/plat-omap/mcbsp.c | 281
-
1 file changed, 125 insertions(+), 156 deletions(-)
diff -upr git.orig/arch/arm/plat-omap/mcbsp.c git/arch/arm/plat-omap/mcbsp.c
--- git.orig/arch/arm/plat-omap/mcbsp.c 2009-12-09 15:28:33.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2009-12-09 15:29:16.0 +0100
@@ -30,26 +30,26 @@
struct omap_mcbsp **mcbsp_ptr;
int omap_mcbsp_count;
-void omap_mcbsp_write(void __iomem *io_base, u16 reg, u32 val)
+void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
{
if (cpu_class_is_omap1() || cpu_is_omap2420())
- __raw_writew((u16)val, io_base + reg);
+ __raw_writew((u16)val, mcbsp-io_base + reg);
else
- __raw_writel(val, io_base + reg);
+ __raw_writel(val, mcbsp-io_base + reg);
}
-int omap_mcbsp_read(void __iomem *io_base, u16 reg)
+int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16 reg)
{
if (cpu_class_is_omap1() || cpu_is_omap2420())
- return __raw_readw(io_base + reg);
+ return __raw_readw(mcbsp-io_base + reg);
else
- return __raw_readl(io_base + reg);
+ return __raw_readl(mcbsp-io_base + reg);
}
-#define OMAP_MCBSP_READ(base, reg) \
- omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg)
-#define OMAP_MCBSP_WRITE(base, reg, val) \
- omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val)
+#define MCBSP_READ(mcbsp, reg) \
+ omap_mcbsp_read(mcbsp, OMAP_MCBSP_REG_##reg)
+#define MCBSP_WRITE(mcbsp, reg, val) \
+ omap_mcbsp_write(mcbsp, OMAP_MCBSP_REG_##reg, val)
#define omap_mcbsp_check_valid_id(id) (id omap_mcbsp_count)
#define id_to_mcbsp_ptr(id)mcbsp_ptr[id];
@@ -60,31 +60,31 @@ static void omap_mcbsp_dump_reg(u8 id)
dev_dbg(mcbsp-dev, McBSP%d regs \n, mcbsp-id);
dev_dbg(mcbsp-dev, DRR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR2));
+ MCBSP_READ(mcbsp, DRR2));
dev_dbg(mcbsp-dev, DRR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR1));
+ MCBSP_READ(mcbsp, DRR1));
dev_dbg(mcbsp-dev, DXR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR2));
+ MCBSP_READ(mcbsp, DXR2));
dev_dbg(mcbsp-dev, DXR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR1));
+ MCBSP_READ(mcbsp, DXR1));
dev_dbg(mcbsp-dev, SPCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SPCR2));
+ MCBSP_READ(mcbsp, SPCR2));
dev_dbg(mcbsp-dev, SPCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SPCR1));
+ MCBSP_READ(mcbsp, SPCR1));
dev_dbg(mcbsp-dev, RCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, RCR2));
+ MCBSP_READ(mcbsp, RCR2));
dev_dbg(mcbsp-dev, RCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, RCR1));
+ MCBSP_READ(mcbsp, RCR1));
dev_dbg(mcbsp-dev, XCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, XCR2));
+ MCBSP_READ(mcbsp, XCR2));
dev_dbg(mcbsp-dev, XCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, XCR1));
+ MCBSP_READ(mcbsp, XCR1));
dev_dbg(mcbsp-dev, SRGR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SRGR2));
+ MCBSP_READ(mcbsp, SRGR2));
dev_dbg(mcbsp-dev, SRGR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SRGR1));
+ MCBSP_READ(mcbsp, SRGR1));
dev_dbg(mcbsp-dev, PCR0: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, PCR0));
+ MCBSP_READ(mcbsp, PCR0));
dev_dbg(mcbsp-dev, ***\n);
}
@@ -93,15 +93,14 @@ static
[PATCH v7 3/5] OMAP: McBSP: Introduce caching in register write operations
Determine cache size required per McBSP port at init time, based on processor
type running on.
Allocate space for storing cached copies of McBSP register values at port
request.
Modify omap_msbcp_write() function to update the cache with every register
write operation.
Modify omap_mcbsp_read() to support reading from cache or hardware.
Update MCBSP_READ() macro for modified omap_mcbsp_read() function API.
Introduce a new macro that reads from the cache.
Applies on top of patch 2 from this series:
[PATCH v7 2/5] OMAP: McBSP: Modify macros/functions API for easy cache access
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next,
commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c.
Compile-tested with: omap_perseus2_730_defconfig, omap_generic_1610_defconfig,
omap_generic_2420_defconfig, omap_2430sdp_defconfig, omap_3430sdp_defconfig,
omap_4430sdp_defconfig with CONFIG_OMAP_MCBSP=y selected.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Changes since v3:
- replace cache table with cache pointer inside omap_mcbsp structure,
- determine cache size at runtime, allocate dynamically when port requested,
- get rid of ifdef...else by placing processor dependent snippets of new code
correctly in respective source files.
arch/arm/mach-omap1/mcbsp.c | 16 ++---
arch/arm/mach-omap2/mcbsp.c | 20 +---
arch/arm/plat-omap/include/plat/mcbsp.h |3 +-
arch/arm/plat-omap/mcbsp.c | 39
4 files changed, 61 insertions(+), 17 deletions(-)
diff -upr git.orig/arch/arm/mach-omap1/mcbsp.c git/arch/arm/mach-omap1/mcbsp.c
--- git.orig/arch/arm/mach-omap1/mcbsp.c2009-12-02 15:48:37.0
+0100
+++ git/arch/arm/mach-omap1/mcbsp.c 2009-12-09 15:35:14.0 +0100
@@ -99,9 +99,11 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP7XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap7xx_mcbsp_pdata)
+#define OMAP7XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
#else
#define omap7xx_mcbsp_pdataNULL
#define OMAP7XX_MCBSP_PDATA_SZ 0
+#define OMAP7XX_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP15XX
@@ -132,9 +134,11 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP15XX_MCBSP_PDATA_SZARRAY_SIZE(omap15xx_mcbsp_pdata)
+#define OMAP15XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
#else
#define omap15xx_mcbsp_pdata NULL
#define OMAP15XX_MCBSP_PDATA_SZ0
+#define OMAP15XX_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP16XX
@@ -165,19 +169,25 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP16XX_MCBSP_PDATA_SZARRAY_SIZE(omap16xx_mcbsp_pdata)
+#define OMAP16XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
#else
#define omap16xx_mcbsp_pdata NULL
#define OMAP16XX_MCBSP_PDATA_SZ0
+#define OMAP16XX_MCBSP_REG_NUM 0
#endif
int __init omap1_mcbsp_init(void)
{
- if (cpu_is_omap7xx())
+ if (cpu_is_omap7xx()) {
omap_mcbsp_count = OMAP7XX_MCBSP_PDATA_SZ;
- if (cpu_is_omap15xx())
+ omap_mcbsp_cache_size = OMAP7XX_MCBSP_REG_NUM * sizeof(u16);
+ } else if (cpu_is_omap15xx()) {
omap_mcbsp_count = OMAP15XX_MCBSP_PDATA_SZ;
- if (cpu_is_omap16xx())
+ omap_mcbsp_cache_size = OMAP15XX_MCBSP_REG_NUM * sizeof(u16);
+ } else if (cpu_is_omap16xx()) {
omap_mcbsp_count = OMAP16XX_MCBSP_PDATA_SZ;
+ omap_mcbsp_cache_size = OMAP16XX_MCBSP_REG_NUM * sizeof(u16);
+ }
mcbsp_ptr = kzalloc(omap_mcbsp_count * sizeof(struct omap_mcbsp *),
GFP_KERNEL);
diff -upr git.orig/arch/arm/mach-omap2/mcbsp.c git/arch/arm/mach-omap2/mcbsp.c
--- git.orig/arch/arm/mach-omap2/mcbsp.c2009-12-02 15:48:38.0
+0100
+++ git/arch/arm/mach-omap2/mcbsp.c 2009-12-09 15:35:14.0 +0100
@@ -65,9 +65,11 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP2420_MCBSP_PDATA_SZARRAY_SIZE(omap2420_mcbsp_pdata)
+#define OMAP2420_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
#else
#define omap2420_mcbsp_pdata NULL
#define OMAP2420_MCBSP_PDATA_SZ0
+#define OMAP2420_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP2430
@@ -114,9 +116,11 @@ static struct omap_mcbsp_platform_data o
},
};
#define OMAP2430_MCBSP_PDATA_SZARRAY_SIZE(omap2430_mcbsp_pdata)
+#define OMAP2430_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
#else
#define omap2430_mcbsp_pdata NULL
#define OMAP2430_MCBSP_PDATA_SZ0
+#define OMAP2430_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP34XX
@@ -168,9 +172,11 @@ static struct omap_mcbsp_platform_data o
[PATCH v7 4/5] OMAP: McBSP: Use cache when modifying individual register bits
Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.
With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta hardware. Before
that, values read back from McBSP registers to be used for updating them
happened to be errornous.
From the hardware side, the issue appeared to be caused by a relatively high
power requirements of an external USB adapter connected to the board's printer
dedicated USB port.
I think there is one important point that makes this patch worth of applying,
apart from my hardware quality. With the current code, if it ever happens to
any machine, no matter if OMAP1510 or newer, to read incorrect value from a
McBSP register, this wrong value will get written back without any checking.
That can lead to hardware damage if, for example, an input pin is turned into
output as a result.
Applies on top of patch 3 from this series:
[PATCH v7 3/5] OMAP: McBSP: Introduce caching in register write operations
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next,
commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c.
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
No functional changes since v3.
arch/arm/plat-omap/mcbsp.c | 78 +++--
1 file changed, 47 insertions(+), 31 deletions(-)
diff -upr git.orig/arch/arm/plat-omap/mcbsp.c git/arch/arm/plat-omap/mcbsp.c
--- git.orig/arch/arm/plat-omap/mcbsp.c 2009-12-09 15:49:53.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2009-12-09 15:50:05.0 +0100
@@ -114,7 +114,8 @@ static irqreturn_t omap_mcbsp_tx_irq_han
dev_err(mcbsp_tx-dev, TX Frame Sync Error! : 0x%x\n,
irqst_spcr2);
/* Writing zero to XSYNC_ERR clears the IRQ */
- MCBSP_WRITE(mcbsp_tx, SPCR2, irqst_spcr2 ~(XSYNC_ERR));
+ MCBSP_WRITE(mcbsp_tx, SPCR2,
+ MCBSP_READ_CACHE(mcbsp_tx, SPCR2) ~(XSYNC_ERR));
} else {
complete(mcbsp_tx-tx_irq_completion);
}
@@ -134,7 +135,8 @@ static irqreturn_t omap_mcbsp_rx_irq_han
dev_err(mcbsp_rx-dev, RX Frame Sync Error! : 0x%x\n,
irqst_spcr1);
/* Writing zero to RSYNC_ERR clears the IRQ */
- MCBSP_WRITE(mcbsp_rx, SPCR1, irqst_spcr1 ~(RSYNC_ERR));
+ MCBSP_WRITE(mcbsp_rx, SPCR1,
+ MCBSP_READ_CACHE(mcbsp_rx, SPCR1) ~(RSYNC_ERR));
} else {
complete(mcbsp_rx-tx_irq_completion);
}
@@ -522,24 +524,25 @@ void omap_mcbsp_start(unsigned int id, i
}
mcbsp = id_to_mcbsp_ptr(id);
- mcbsp-rx_word_length = (MCBSP_READ(mcbsp, RCR1) 5) 0x7;
- mcbsp-tx_word_length = (MCBSP_READ(mcbsp, XCR1) 5) 0x7;
+ mcbsp-rx_word_length = (MCBSP_READ_CACHE(mcbsp, RCR1) 5) 0x7;
+ mcbsp-tx_word_length = (MCBSP_READ_CACHE(mcbsp, XCR1) 5) 0x7;
- idle = !((MCBSP_READ(mcbsp, SPCR2) | MCBSP_READ(mcbsp, SPCR1)) 1);
+ idle = !((MCBSP_READ_CACHE(mcbsp, SPCR2) |
+ MCBSP_READ_CACHE(mcbsp, SPCR1)) 1);
if (idle) {
/* Start the sample generator */
- w = MCBSP_READ(mcbsp, SPCR2);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 6));
}
/* Enable transmitter and receiver */
tx = 1;
- w = MCBSP_READ(mcbsp, SPCR2);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | tx);
rx = 1;
- w = MCBSP_READ(mcbsp, SPCR1);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR1);
MCBSP_WRITE(mcbsp, SPCR1, w | rx);
/*
@@ -552,16 +555,16 @@ void omap_mcbsp_start(unsigned int id, i
if (idle) {
/* Start frame sync */
- w = MCBSP_READ(mcbsp, SPCR2);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 7));
}
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
/* Release the transmitter and receiver */
- w = MCBSP_READ(mcbsp, XCCR);
+ w = MCBSP_READ_CACHE(mcbsp, XCCR);
w = ~(tx ? XDISABLE : 0);
MCBSP_WRITE(mcbsp, XCCR, w);
- w = MCBSP_READ(mcbsp, RCCR);
+ w = MCBSP_READ_CACHE(mcbsp, RCCR);
w = ~(rx ? RDISABLE : 0);
MCBSP_WRITE(mcbsp, RCCR, w);
}
@@ -587,28 +590,29 @@ void omap_mcbsp_stop(unsigned int id, in
/* Reset transmitter */
tx = 1;
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
- w = MCBSP_READ(mcbsp, XCCR);
+ w = MCBSP_READ_CACHE(mcbsp, XCCR);
w |= (tx ? XDISABLE : 0);
MCBSP_WRITE(mcbsp, XCCR, w);
}
-
[PATCH v7 5/5] OMAP: McBSP: Split and move read/write functions to mach-omap1/2
Split omap_mcbsp_read()/_write() functions logic into omap1 and omap2/3/4
parts, then move them out of plat-omap/mcbsp.c into mach-omap1/mcbsp.c and
mach-omap2/mcbsp.c respectively, to leave some of the if cpu_is_omap()
else stuff.
Applies on top of patch 4 from this series:
[PATCH v7 4/5] OMAP: McBSP: Use cache when modifying individual register bits
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next,
commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c.
Compile-tested with omap_generic_2420_defconfig and omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Wednesday 09 December 2009 00:39:16 Tony Lindgren napisał(a):
* Tony Lindgren t...@atomide.com [091208 15:32]:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091208 11:45]:
Tuesday 08 December 2009 17:59:31 Tony Lindgren napisał(a):
Actually since we already have mach-omap1/mcbsp.c and
mach-omap2/mcbsp.c, it would be best to pass the cache size from
omap1_mcbsp_init and omap2_mcbsp_init. That leaves some of the if
cpu_is_omap() else stuff.
Tony,
Almost ready with it, one more question: what do you think about
splitting and moving omap_mcbsp_read()/_write() there as well? If you
agree, should I submit 2 patches, one with this cleanup, the other one
actually introducing cache support, or is one combined OK?
Sounds good to me!
Oh sorry forgot to reply to your question. If a single patch looks
unreadable, then split it into two where the first patch splits
omap_mcbsp_read/write.
Tony,
Since this one is new, in order to not block the 4 preceding patches that do
not really need this one, I decided to create this additional cleanup as the
last one in the series, to be dropped easily if not accepted for any problems
with it.
Thanks,
Janusz
arch/arm/mach-omap1/mcbsp.c | 12
arch/arm/mach-omap2/mcbsp.c | 22 ++
arch/arm/plat-omap/include/plat/mcbsp.h |3 +++
arch/arm/plat-omap/mcbsp.c | 28
4 files changed, 37 insertions(+), 28 deletions(-)
diff -upr git.orig/arch/arm/mach-omap1/mcbsp.c git/arch/arm/mach-omap1/mcbsp.c
--- git.orig/arch/arm/mach-omap1/mcbsp.c2009-12-09 15:49:52.0
+0100
+++ git/arch/arm/mach-omap1/mcbsp.c 2009-12-09 16:20:43.0 +0100
@@ -31,6 +31,18 @@ static int dsp_use;
static struct clk *api_clk;
static struct clk *dsp_clk;
+void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
+{
+ ((u16 *)mcbsp-reg_cache)[reg / sizeof(u16)] = (u16)val;
+ __raw_writew((u16)val, mcbsp-io_base + reg);
+}
+
+int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16 reg, bool from_cache)
+{
+ return !from_cache ? __raw_readw(mcbsp-io_base + reg) :
+ ((u16 *)mcbsp-reg_cache)[reg / sizeof(u16)];
+}
+
static void omap1_mcbsp_request(unsigned int id)
{
/*
diff -upr git.orig/arch/arm/mach-omap2/mcbsp.c git/arch/arm/mach-omap2/mcbsp.c
--- git.orig/arch/arm/mach-omap2/mcbsp.c2009-12-09 15:49:52.0
+0100
+++ git/arch/arm/mach-omap2/mcbsp.c 2009-12-09 16:20:43.0 +0100
@@ -23,6 +23,28 @@
#include plat/cpu.h
#include plat/mcbsp.h
+void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
+{
+ if (cpu_is_omap2420()) {
+ ((u16 *)mcbsp-reg_cache)[reg / sizeof(u32)] = (u16)val;
+ __raw_writew((u16)val, mcbsp-io_base + reg);
+ } else {
+ ((u32 *)mcbsp-reg_cache)[reg / sizeof(u32)] = val;
+ __raw_writel(val, mcbsp-io_base + reg);
+ }
+}
+
+int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16 reg, bool from_cache)
+{
+ if (cpu_is_omap2420()) {
+ return !from_cache ? __raw_readw(mcbsp-io_base + reg) :
+ ((u16 *)mcbsp-reg_cache)[reg / sizeof(u32)];
+ } else {
+ return !from_cache ? __raw_readl(mcbsp-io_base + reg) :
+ ((u32 *)mcbsp-reg_cache)[reg / sizeof(u32)];
+ }
+}
+
static void omap2_mcbsp2_mux_setup(void)
{
omap_cfg_reg(Y15_24XX_MCBSP2_CLKX);
diff -upr git.orig/arch/arm/plat-omap/include/plat/mcbsp.h
git/arch/arm/plat-omap/include/plat/mcbsp.h
--- git.orig/arch/arm/plat-omap/include/plat/mcbsp.h2009-12-09
15:49:53.0 +0100
+++ git/arch/arm/plat-omap/include/plat/mcbsp.h 2009-12-09 16:20:43.0
+0100
@@ -420,6 +420,9 @@ struct omap_mcbsp {
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count, omap_mcbsp_cache_size;
+void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val);
+int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16 reg, bool from_cache);
+
int omap_mcbsp_init(void);
void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data *config,
int size);
diff -upr git.orig/arch/arm/plat-omap/mcbsp.c git/arch/arm/plat-omap/mcbsp.c
--- git.orig/arch/arm/plat-omap/mcbsp.c
[PATCH v7 2/5] [Resend] OMAP: McBSP: Modify macros/functions API for easy cache access
OMAP_MCBSP_READ()/_WRITE() macros and omap_mcbsp_read()/_write() functions
accept McBSP register base address as an argument. In order to support
caching, that must be replaced with an address of the omap_mcbsp structure
that would provide addresses for both register AND cache access.
Since OMAP_ prefix seems obvious in macro names, drop it off in order to
minimize line wrapping throughout the file.
Applies on top of patch 1 from this series:
[PATCH v7 1/5] OMAP: McBSP: Use macros for all register read/write operations
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next,
commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c.
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Line-wrapped again, sorry.
Changes since v3:
- modify API of omap_mcbsp_read()/_write() functions as well, since those will
actually provide caching operations, not macros like before.
arch/arm/plat-omap/mcbsp.c | 281 -
1 file changed, 125 insertions(+), 156 deletions(-)
diff -upr git.orig/arch/arm/plat-omap/mcbsp.c git/arch/arm/plat-omap/mcbsp.c
--- git.orig/arch/arm/plat-omap/mcbsp.c 2009-12-09 15:28:33.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2009-12-09 15:29:16.0 +0100
@@ -30,26 +30,26 @@
struct omap_mcbsp **mcbsp_ptr;
int omap_mcbsp_count;
-void omap_mcbsp_write(void __iomem *io_base, u16 reg, u32 val)
+void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
{
if (cpu_class_is_omap1() || cpu_is_omap2420())
- __raw_writew((u16)val, io_base + reg);
+ __raw_writew((u16)val, mcbsp-io_base + reg);
else
- __raw_writel(val, io_base + reg);
+ __raw_writel(val, mcbsp-io_base + reg);
}
-int omap_mcbsp_read(void __iomem *io_base, u16 reg)
+int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16 reg)
{
if (cpu_class_is_omap1() || cpu_is_omap2420())
- return __raw_readw(io_base + reg);
+ return __raw_readw(mcbsp-io_base + reg);
else
- return __raw_readl(io_base + reg);
+ return __raw_readl(mcbsp-io_base + reg);
}
-#define OMAP_MCBSP_READ(base, reg) \
- omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg)
-#define OMAP_MCBSP_WRITE(base, reg, val) \
- omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val)
+#define MCBSP_READ(mcbsp, reg) \
+ omap_mcbsp_read(mcbsp, OMAP_MCBSP_REG_##reg)
+#define MCBSP_WRITE(mcbsp, reg, val) \
+ omap_mcbsp_write(mcbsp, OMAP_MCBSP_REG_##reg, val)
#define omap_mcbsp_check_valid_id(id) (id omap_mcbsp_count)
#define id_to_mcbsp_ptr(id)mcbsp_ptr[id];
@@ -60,31 +60,31 @@ static void omap_mcbsp_dump_reg(u8 id)
dev_dbg(mcbsp-dev, McBSP%d regs \n, mcbsp-id);
dev_dbg(mcbsp-dev, DRR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR2));
+ MCBSP_READ(mcbsp, DRR2));
dev_dbg(mcbsp-dev, DRR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR1));
+ MCBSP_READ(mcbsp, DRR1));
dev_dbg(mcbsp-dev, DXR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR2));
+ MCBSP_READ(mcbsp, DXR2));
dev_dbg(mcbsp-dev, DXR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR1));
+ MCBSP_READ(mcbsp, DXR1));
dev_dbg(mcbsp-dev, SPCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SPCR2));
+ MCBSP_READ(mcbsp, SPCR2));
dev_dbg(mcbsp-dev, SPCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SPCR1));
+ MCBSP_READ(mcbsp, SPCR1));
dev_dbg(mcbsp-dev, RCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, RCR2));
+ MCBSP_READ(mcbsp, RCR2));
dev_dbg(mcbsp-dev, RCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, RCR1));
+ MCBSP_READ(mcbsp, RCR1));
dev_dbg(mcbsp-dev, XCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, XCR2));
+ MCBSP_READ(mcbsp, XCR2));
dev_dbg(mcbsp-dev, XCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, XCR1));
+ MCBSP_READ(mcbsp, XCR1));
dev_dbg(mcbsp-dev, SRGR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SRGR2));
+ MCBSP_READ(mcbsp, SRGR2));
dev_dbg(mcbsp-dev, SRGR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SRGR1));
+ MCBSP_READ(mcbsp, SRGR1));
dev_dbg(mcbsp-dev, PCR0: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, PCR0));
+ MCBSP_READ(mcbsp, PCR0));
dev_dbg(mcbsp-dev, ***\n);
}
@@ -93,15
[PATCH] omap: header: remove unused data-type
Remove unused data type omap_gpio_switch_config
Thereby also get rid of following sparse warnings:
arch/arm/plat-omap/include/plat/board.h :121:20:
warning: dubious bitfield without explicit `signed' or `unsigned'
arch/arm/plat-omap/include/plat/board.h :122:19:
warning: dubious bitfield without explicit `signed' or `unsigned'
arch/arm/plat-omap/include/plat/board.h :123:24:
warning: dubious bitfield without explicit `signed' or `unsigned'
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/plat-omap/include/plat/board.h |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/board.h
b/arch/arm/plat-omap/include/plat/board.h
index abb17b6..376ce18 100644
--- a/arch/arm/plat-omap/include/plat/board.h
+++ b/arch/arm/plat-omap/include/plat/board.h
@@ -114,15 +114,6 @@ struct omap_pwm_led_platform_data {
void (*set_power)(struct omap_pwm_led_platform_data *self, int on_off);
};
-/* See arch/arm/plat-omap/include/mach/gpio-switch.h for definitions */
-struct omap_gpio_switch_config {
- char name[12];
- u16 gpio;
- int flags:4;
- int type:4;
- int key_code:24; /* Linux key code */
-};
-
struct omap_uart_config {
/* Bit field of UARTs present; bit 0 -- UART1 */
unsigned int enabled_uarts;
--
1.6.6.rc0.66.ge160d
--
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] Input: gpio-keys: Support for one-directional interrupts
On Wed, Dec 9, 2009 at 9:58 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Dec 09, 2009 at 08:15:26AM -0800, Cory Maccarrone wrote: On Wed, Dec 9, 2009 at 3:32 AM, Ferenc Wagner wf...@niif.hu wrote: I'm fairly certain it wouldn't. Each of the interrupts on my hardware has a corresponding bit in a control register that determines if it's rising or falling-edge triggered -- thus the need for my patch. To capture both directions, it's necessary to modify the control register when a falling edge is detected, so that the corresponding rising edge can be collected afterward. This kind of ugliness should be hidden in irqchip driver. See mfd/asic3.c for an example. I would agree with that -- it should be possible to hide that away as part of the functionality of the interrupt driver. Perhaps a fix to the OMAP1 IRQ handling is warranted. I know there are some interrupts that can do both directions out of the box, but that shouldn't be the responsibility of each driver to know. May I ask why you're thinking of converting to level-triggering? Perhaps it would be better to provide an option in the platform_device structure to set edge- or level-triggering, similar to the change I'm proposing for interrupts that can only signal one way at a time. Yes, we need a way fro platform code to specify desired interrupt flags but I don't believe we should be reconfiguring them on the fly. If the ability to handle this type of interrupt transparently was added to our board IRQ chip driver, this whole thing would be a non-issue, as gpio-keys could request edge triggered falling and rising at the same time, and the driver would Just Work. I'll take a look and see how possible that would be to do. Looking through the code for OMAP1's GPIO IRQ handlers, there's a note that OMAP1 only supports edge triggering, so if gpio-keys were to move exclusively to that, itwould stop working with those boards. But, it may be possible to do the trigger flip in the chip driver, which would make this patch unnecessary. - Cory -- 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: [PATCHv3 1/3] OMAP UART: Add omap-serial driver support.
Govindraj govindraj...@gmail.com writes: On Wed, Nov 25, 2009 at 12:18 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Govindraj.R govindraj.r...@ti.com writes: From 4756e3743c7acd2de1030b2bd432c1b19f0b9ff5 Mon Sep 17 00:00:00 2001 From: Govindraj R govindraj.r...@ti.com Date: Fri, 13 Nov 2009 12:01:54 +0530 Subject: [PATCH] OMAP UART: Add omap-serial driver support. This patch adds support for OMAP3430-HIGH SPEED UART Controller. It adds support for the following features: 1. It supports Interrupt mode and DMA mode of operation. 2. Supports Hardware flow control and sofware flow control. 3. Debug Console support on all UARTs. Signed-off-by: Govindraj R govindraj.r...@ti.com Some general comments. This should summarize how this is different from the 8250 driver on which it was based, as it's clear that it was based on 8250 but not clear at all what the changes are. At first glance, you've dropped several features from the 8250 driver which we currently use. Namely, the ability for platform code to override some of the defaults: - change irq_flags - serial_in function - optional ioremapping (omap_hwmod layer will have done ioremap already) Agree. uart_port_info [should be renamed to omap_uart_port_info] should grow with fields like irqflags, membase and mapbase feilds. adding these would need rework on the patch: http://patchwork.kernel.org/patch/62555/ Should I work on top of above patch? Yes. Serial in function might not be necessary for omap-serial driver, this function was added to handle RX reading by checking if DR bit set in LSR reg. This is taken care in omap-serial driver. OK, I didn't look closely at that but I'd like to be sure that the extra checking can be optimized out on the SoCs that don't need it. 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: Preventing OMAP3 serial driver to take control of all UARTs
[sorry for being late to the party, I've been on vacation]
Mika Westerberg ext-mika.1.westerb...@nokia.com writes:
[...]
How about something like in the patch attached?
Then for example we would do in board-rx51.c:
...
omap_serial_init_port(2);
(we only use UART3 as serial port).
I quickly tested this with RX-51 and seems to work.
I like this approach.
I'm against going back to the previsus platform_data extending
approach since it requires doing different stuff when using 8250 or
the upcoming omap-serial driver.
---
From: Mika Westerberg ext-mika.1.westerb...@nokia.com
Date: Tue, 1 Dec 2009 12:54:21 +0200
Subject: [PATCH] OMAP3: serial - allow platforms specify which UARTs to
initialize
This patch adds new function: omap_serial_init_port(port) that can be
used to initialize only selected UARTs as serial ports. Platforms can
then in their board files call this function instead of omap_serial_init()
if they don't want to use all UARTs as serial ports.
Signed-off-by: Mika Westerberg ext-mika.1.westerb...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/serial.c | 59
+++---
arch/arm/plat-omap/include/plat/serial.h |1 +
2 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 2e17b57..fe46560 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -631,24 +631,55 @@ void __init omap_serial_early_init(void)
}
}
+/**
+ * omap_serial_init_port() - initialize single serial port
+ * @port: serial port number (0-3)
+ *
+ * This function initialies serial driver for given @port only.
+ * Platforms can call this function instead of omap_serial_init()
+ * if they don't plan to use all available UARTs as serial ports.
+ *
+ * Don't mix calls to omap_serial_init_port() and omap_serial_init(),
+ * use only one of the two.
+ */
+void __init omap_serial_init_port(int port)
+{
+ struct omap_uart_state *uart;
+ struct platform_device *pdev;
+ struct device *dev;
+
+ BUG_ON(port 0);
+ BUG_ON(port = ARRAY_SIZE(omap_uart));
+
+ uart = omap_uart[port];
+ pdev = uart-pdev;
+ dev = pdev-dev;
+
+ omap_uart_reset(uart);
+ omap_uart_idle_init(uart);
+
+ if (WARN_ON(platform_device_register(pdev)))
+ return;
+
+ if ((cpu_is_omap34xx() uart-padconf) ||
+ (uart-wk_en uart-wk_mask)) {
+ device_init_wakeup(dev, true);
+ DEV_CREATE_FILE(dev, dev_attr_sleep_timeout);
+ }
+}
+
+/**
+ * omap_serial_init() - intialize all supported serial ports
+ *
+ * Initializes all available UARTs as serial ports. Platforms
+ * can call this function when they want to have default behaviour
+ * for serial ports (e.g initialize them all as serial ports).
+ */
void __init omap_serial_init(void)
{
int i;
for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
- struct omap_uart_state *uart = omap_uart[i];
- struct platform_device *pdev = uart-pdev;
- struct device *dev = pdev-dev;
-
- omap_uart_reset(uart);
- omap_uart_idle_init(uart);
-
- if (WARN_ON(platform_device_register(pdev)))
- continue;
- if ((cpu_is_omap34xx() uart-padconf) ||
- (uart-wk_en uart-wk_mask)) {
- device_init_wakeup(dev, true);
- DEV_CREATE_FILE(dev, dev_attr_sleep_timeout);
- }
+ omap_serial_init_port(i);
}
}
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index 9951345..f5a4a92 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -53,6 +53,7 @@
#ifndef __ASSEMBLER__
extern void __init omap_serial_early_init(void);
extern void omap_serial_init(void);
+extern void omap_serial_init_port(int port);
extern int omap_uart_can_sleep(void);
extern void omap_uart_check_wakeup(void);
extern void omap_uart_prepare_suspend(void);
--
1.5.6.5
--
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] OMAP3: hwmod: check for clkdomain pointer before accesing it to change the sleep dependencies.
Thara Gopinath th...@ti.com writes: Some clock nodes like wdt1_fck, sr1_fck, sr2_fck etc do not have a clock domain associated . For such nodes accessing the clock domain pointers in _add_initiator_dep and _del_initiator_dep, will lead to null pointer defreferencing crash. Adding support in these functions to check for existence of clkdm pointer before trying to acess it. Even if tomorrow we correct all the clock nodes to have an associated clock domain, checking for the existence of the pointer is a good programming practice. Signed-off-by: Thara Gopinath th...@ti.com Cc: Paul Walmsley p...@pwsan.com --- This patch depends on http://patchwork.kernel.org/patch/63383/ I think clocks without associated clockdomains should be handled with a flag instead of a check for a NULL pointer. Your current approach will silently fail if someone forgets to add a clockdomain to a clock that should have one. Kevin arch/arm/mach-omap2/omap_hwmod.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 18e6478..3edc387 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -314,8 +314,10 @@ static int _add_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh) if (!oh-_clk) return -EINVAL; - return pwrdm_add_sleepdep(oh-_clk-clkdm-pwrdm.ptr, + if (oh-_clk-clkdm) + return pwrdm_add_sleepdep(oh-_clk-clkdm-pwrdm.ptr, init_oh-_clk-clkdm-pwrdm.ptr); + return 0; } /** @@ -335,8 +337,10 @@ static int _del_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh) if (!oh-_clk) return -EINVAL; - return pwrdm_del_sleepdep(oh-_clk-clkdm-pwrdm.ptr, + if (oh-_clk-clkdm) + return pwrdm_del_sleepdep(oh-_clk-clkdm-pwrdm.ptr, init_oh-_clk-clkdm-pwrdm.ptr); + return 0; } /** -- 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 -- 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] Smartreflex: Avoid unnecessary spam
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Current warning messages will be constantly printed out during normal
operation
if smartreflex autocompensation is disabled.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Agreed that these warnings are spam, but I think they should be
replaced by some one-time warning so at least there's a hint someplace
that SR is not actually being done on a platfrom.
Kevin
---
arch/arm/mach-omap2/smartreflex.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index be3a1da..db228b2 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -675,13 +675,8 @@ void sr_start_vddautocomap(int srid, u32 target_opp_no)
sr_configure(sr);
}
- if (sr-is_autocomp_active == 1)
- pr_warning(SR%d: VDD autocomp is already active\n,
- srid);
-
sr-is_autocomp_active = 1;
if (!sr_enable(sr, target_opp_no)) {
- pr_warning(SR%d: VDD autocomp not activated\n, srid);
sr-is_autocomp_active = 0;
if (sr-is_sr_reset == 1)
sr_clk_disable(sr);
@@ -707,11 +702,8 @@ int sr_stop_vddautocomap(int srid)
/* Reset the volatage for current OPP */
sr_reset_voltage(srid);
return true;
- } else {
- pr_warning(SR%d: VDD autocomp is not active\n,
- srid);
+ } else
return false;
- }
}
EXPORT_SYMBOL(sr_stop_vddautocomap);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Smartreflex: Avoid unnecessary spam
Kevin Hilman had written, on 12/09/2009 05:15 PM, the following:
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Current warning messages will be constantly printed out during normal operation
if smartreflex autocompensation is disabled.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Agreed that these warnings are spam, but I think they should be
replaced by some one-time warning so at least there's a hint someplace
that SR is not actually being done on a platfrom.
is'nt that already taken care?
echo -n 1 /sys/power/vdd1_autocomp; echo $?
should return a non 0 value if it was not set, else should set 0 if it
went ok.
if someone wants to verify the state, it should be a cat
/sys/power/vdd1_autocomp to know if autocomp was set or not.
For some userspace to know if autocomp was set or not (if I understand
your intention) should look at return value like normal linux commands.
Kevin
---
arch/arm/mach-omap2/smartreflex.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index be3a1da..db228b2 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -675,13 +675,8 @@ void sr_start_vddautocomap(int srid, u32 target_opp_no)
sr_configure(sr);
}
- if (sr-is_autocomp_active == 1)
- pr_warning(SR%d: VDD autocomp is already active\n,
- srid);
-
sr-is_autocomp_active = 1;
if (!sr_enable(sr, target_opp_no)) {
- pr_warning(SR%d: VDD autocomp not activated\n, srid);
sr-is_autocomp_active = 0;
if (sr-is_sr_reset == 1)
sr_clk_disable(sr);
@@ -707,11 +702,8 @@ int sr_stop_vddautocomap(int srid)
/* Reset the volatage for current OPP */
sr_reset_voltage(srid);
return true;
- } else {
- pr_warning(SR%d: VDD autocomp is not active\n,
- srid);
+ } else
return false;
- }
}
EXPORT_SYMBOL(sr_stop_vddautocomap);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Nishanth Menon
--
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] Smartreflex: Avoid unnecessary spam
On Thu, Dec 10, 2009 at 12:15:26AM +0100, ext Kevin Hilman wrote:
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Current warning messages will be constantly printed out during normal operation
if smartreflex autocompensation is disabled.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Agreed that these warnings are spam, but I think they should be
replaced by some one-time warning so at least there's a hint someplace
that SR is not actually being done on a platfrom.
well, there's printk_once()
include/linux/kernel.h:
250 /*
251 * Print a one-time message (analogous to WARN_ONCE() et al):
252 */
253 #define printk_once(x...) ({\
254 static bool __print_once = true;\
255 \
256 if (__print_once) { \
257 __print_once = false; \
258 printk(x); \
259 } \
260 })
and WARN_ONCE()
include/asm-generic/bug.h:
125 #define WARN_ONCE(condition, format...) ({ \
126 static int __warned;\
127 int __ret_warn_once = !!(condition);\
128 \
129 if (unlikely(__ret_warn_once)) \
130 if (WARN(!__warned, format))\
131 __warned = 1; \
132 unlikely(__ret_warn_once); \
133 })
I guess printk_once() is better.
--
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: [PATCH V2] OMAP3: PM: Fix for MPU power domain MEM BANK position
Paul Walmsley p...@pwsan.com writes: On Thu, 26 Nov 2009, Thara Gopinath wrote: MPU power domain bank 0 bits are displayed in position of bank 1 in PWRSTS and PREPWRSTS registers. So read them from correct position Signed-off-by: Thara Gopinath th...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Thanks Thara, will queue this up. 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: [PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules
Peter Ujfalusi peter.ujfal...@nokia.com writes: Wake-up from McBSP ports are needed, especially when the THRESHOLD dma mode is in use for audio playback. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com Looks good, adding to PM branch and will queue in pm-fxies for 2.6.33-rc series. Kevin --- arch/arm/mach-omap2/pm34xx.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 81ed252..6b17647 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -878,12 +878,16 @@ static void __init prcm_setup_regs(void) /* Enable wakeups in PER */ prm_write_mod_reg(OMAP3430_EN_GPIO2 | OMAP3430_EN_GPIO3 | OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 | - OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3, + OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3 | + OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 | + OMAP3430_EN_MCBSP4, OMAP3430_PER_MOD, PM_WKEN); /* and allow them to wake up MPU */ prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2 | OMAP3430_EN_GPIO3 | OMAP3430_GRPSEL_GPIO4 | OMAP3430_EN_GPIO5 | - OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3, + OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3 | + OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 | + OMAP3430_EN_MCBSP4, OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL); /* Don't attach IVA interrupts */ -- 1.6.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Smartreflex: Avoid unnecessary spam
Felipe Balbi had written, on 12/09/2009 05:23 PM, the following:
On Thu, Dec 10, 2009 at 12:15:26AM +0100, ext Kevin Hilman wrote:
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Current warning messages will be constantly printed out during normal operation
if smartreflex autocompensation is disabled.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Agreed that these warnings are spam, but I think they should be
replaced by some one-time warning so at least there's a hint someplace
that SR is not actually being done on a platfrom.
well, there's printk_once()
include/linux/kernel.h:
250 /*
251 * Print a one-time message (analogous to WARN_ONCE() et al):
252 */
253 #define printk_once(x...) ({\
254 static bool __print_once = true;\
255 \
256 if (__print_once) { \
257 __print_once = false; \
258 printk(x); \
259 } \
260 })
and WARN_ONCE()
include/asm-generic/bug.h:
125 #define WARN_ONCE(condition, format...) ({ \
126 static int __warned;\
127 int __ret_warn_once = !!(condition);\
128 \
129 if (unlikely(__ret_warn_once)) \
130 if (WARN(!__warned, format))\
131 __warned = 1; \
132 unlikely(__ret_warn_once); \
133 })
I guess printk_once() is better.
But what is the point in having it?
situation 1:
sr_start_vddautocomap() gets called for starting AVS while dvfs. The
spam message just warns user that autocomp is not set when OPP change
happens.
case 1 against printing it:
If the user had disabled vddautocomp, then the warnings have no rational
in warning the user which he/she already knows about.
case 2 against printing it using printk_once:
situation x:
step 1: autocomp disabled, dvfs transitions - printk_once will print
only once.
step 2: autocomp enabled, dvfs transitions - no prints.
step 3: autocomp disabled, dvfs - we wont see prints :(
Agreed, we could have an equivalent implementation using a static bool
instead of using printk_once .. still a nuisance message which does not
provide additional info.. other than adding a latency overhead.
situation 2:
when attempting to enable SR when nvalues are not present (e.g. on
3530/3430 es3.0).. here the return value should be used and is more
informative and usable from a application perspective..
just my 2 cents..
--
Regards,
Nishanth Menon
--
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] Smartreflex: Avoid unnecessary spam
Nishanth Menon n...@ti.com writes:
Felipe Balbi had written, on 12/09/2009 05:23 PM, the following:
On Thu, Dec 10, 2009 at 12:15:26AM +0100, ext Kevin Hilman wrote:
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Current warning messages will be constantly printed out during normal
operation
if smartreflex autocompensation is disabled.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Agreed that these warnings are spam, but I think they should be
replaced by some one-time warning so at least there's a hint someplace
that SR is not actually being done on a platfrom.
well, there's printk_once()
include/linux/kernel.h:
250 /* 251 * Print a one-time message (analogous to
WARN_ONCE() et al):
252 */ 253 #define printk_once(x...) ({
\
254 static bool __print_once = true;\
255 \
256 if (__print_once) { \
257 __print_once = false; \
258 printk(x); \
259 } \
260 })
and WARN_ONCE()
include/asm-generic/bug.h:
125 #define WARN_ONCE(condition, format...) ({ \
126 static int __warned;\
127 int __ret_warn_once = !!(condition);\
128 \
129 if (unlikely(__ret_warn_once)) \
130 if (WARN(!__warned, format))\
131 __warned = 1; \
132 unlikely(__ret_warn_once); \
133 })
I guess printk_once() is better.
But what is the point in having it?
situation 1:
sr_start_vddautocomap() gets called for starting AVS while dvfs. The
spam message just warns user that autocomp is not set when OPP change
happens.
case 1 against printing it:
If the user had disabled vddautocomp, then the warnings have no
rational in warning the user which he/she already knows about.
case 2 against printing it using printk_once:
situation x:
step 1: autocomp disabled, dvfs transitions - printk_once will print
only once.
step 2: autocomp enabled, dvfs transitions - no prints.
step 3: autocomp disabled, dvfs - we wont see prints :(
Agreed, we could have an equivalent implementation using a static bool
instead of using printk_once .. still a nuisance message which does
not provide additional info.. other than adding a latency overhead.
situation 2:
when attempting to enable SR when nvalues are not present (e.g. on
3530/3430 es3.0).. here the return value should be used and is more
informative and usable from a application perspective..
just my 2 cents..
OK, I'm sold.
Applying Tero's original patch.
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: [PATCH V2] AM3517: Add support for TSC2004 driver
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, November 30, 2009 11:04 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH V2] AM3517: Add support for TSC2004 driver
* Hiremath, Vaibhav hvaib...@ti.com [091125 21:13]:
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, November 26, 2009 10:41 AM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; Hiremath, Vaibhav
Subject: [PATCH V2] AM3517: Add support for TSC2004 driver
From: Vaibhav Hiremath hvaib...@ti.com
Changes:
- Removed omap_cfg_reg()
Reviewed-by: Tony Lindgren t...@atomide.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 61
+
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-
omap2/board-am3517evm.c
index 415a13d..b183d93 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -20,6 +20,8 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/gpio.h
+#include linux/irq.h
+#include linux/i2c/tsc2004.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -27,10 +29,64 @@
#include asm/mach/map.h
#include plat/board.h
+#include plat/mux.h
#include plat/common.h
#include plat/usb.h
/*
+ * TSC 2004 Support
+ */
+#define GPIO_TSC2004_IRQ65
+
+static int tsc2004_init_irq(void)
+{
+ int ret = 0;
+
+ ret = gpio_request(GPIO_TSC2004_IRQ, tsc2004-irq);
+ if (ret 0) {
+ printk(KERN_WARNING failed to request GPIO#%d: %d\n,
+ GPIO_TSC2004_IRQ, ret);
+ return ret;
+ }
+
+ if (gpio_direction_input(GPIO_TSC2004_IRQ)) {
+ printk(KERN_WARNING GPIO#%d cannot be configured as
+ input\n, GPIO_TSC2004_IRQ);
+ return -ENXIO;
+ }
+
+ omap_set_gpio_debounce(GPIO_TSC2004_IRQ, 1);
+ omap_set_gpio_debounce_time(GPIO_TSC2004_IRQ, 0xa);
+ return ret;
+}
+
+static void tsc2004_exit_irq(void)
+{
+ gpio_free(GPIO_TSC2004_IRQ);
+}
+
+static int tsc2004_get_irq_level(void)
+{
+ return gpio_get_value(GPIO_TSC2004_IRQ) ? 0 : 1;
+}
+
+struct tsc2004_platform_data am3517evm_tsc2004data = {
+ .model = 2004,
+ .x_plate_ohms = 180,
+ .get_pendown_state = tsc2004_get_irq_level,
+ .init_platform_hw = tsc2004_init_irq,
+ .exit_platform_hw = tsc2004_exit_irq,
+};
+
+static struct i2c_board_info __initdata
am3517evm_tsc_i2c_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(tsc2004, 0x4B),
+ .type = tsc2004,
+ .platform_data = am3517evm_tsc2004data,
+ },
+};
+
+/*
* Board initialization
*/
static struct omap_board_config_kernel am3517_evm_config[]
__initdata = {
@@ -67,6 +123,11 @@ static void __init am3517_evm_init(void)
omap_serial_init();
usb_ehci_init(ehci_pdata);
+
+ /* TSC 2004 */
+ am3517evm_tsc_i2c_boardinfo[0].irq =
gpio_to_irq(GPIO_TSC2004_IRQ);
+ i2c_register_board_info(1, am3517evm_tsc_i2c_boardinfo,
+ ARRAY_SIZE(am3517evm_tsc_i2c_boardinfo));
}
static void __init am3517_evm_map_io(void)
[Hiremath, Vaibhav] Hi Tony,
Since I haven't received any comments on driver code it should get
merged. But I am not sure what the procedure is for input subsystem
drivers? Is it happens through linux-omap or linux-input?
I'd rather see it merged via linux-input as that's where most
of the code is. The platform init code looks OK to me to merge
via linux-input too.
[Hiremath, Vaibhav] Dmitry,
Can you please merge the TSC2004 driver patch?
Thanks,
Vaibhav
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] OMAP3: Fix omap3_defconfig build
Gadiyar, Anand wrote: Select sound codecs to allow this defconfig to build again Also, sync up this defconfig with the generated .configs. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Olof Johansson o...@lixom.net --- In addition to this, I needed this patch: http://patchwork.kernel.org/patch/65152/ With these two patches, I can build and boot on multiple omap3 boards. And additionally, with these sound options enabled, I get the following warning on a 3430 SDP: [ 36.303894] [ cut here ] [ 36.308807] WARNING: at drivers/gpio/gpiolib.c:1288 __gpio_get_value+0x30/0x5c() [ 36.316467] Modules linked in: [ 36.319610] [c003b7e8] (unwind_backtrace+0x0/0xdc) from [c0065c64] (warn_slowpath_common+0x48/0x60) [ 36.329345] [c0065c64] (warn_slowpath_common+0x48/0x60) from [c0204964] (__gpio_get_value+0x30/0x5c) [ 36.339141] [c0204964] (__gpio_get_value+0x30/0x5c) from [c033d968] (snd_soc_jack_gpio_detect+0x34/0x7c) [ 36.349334] [c033d968] (snd_soc_jack_gpio_detect+0x34/0x7c) from [c007b2c0] (worker_thread+0x21c/0x304) [ 36.359375] [c007b2c0] (worker_thread+0x21c/0x304) from [c007ea8c] (kthread+0x80/0x88) [ 36.368011] [c007ea8c] (kthread+0x80/0x88) from [c0036964] (kernel_thread_exit+0x0/0x8) [ 36.376647] ---[ end trace 9745011b5c1147df ]--- I haven't had a chance to look at this yet. I'll give it a shot tomorrow, unless someone beats me to it. - 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] OMAP3: Fix omap3_defconfig build
Hi,
{removing invalid lkml-like addressee}
On Thu, Dec 10, 2009 at 11:19:52AM +0530, Anand Gadiyar wrote:
Select sound codecs to allow this defconfig to build again
You need to fix the config option dependencies/selects, updating the
defconfig just papers over the real problem.
Also, sync up this defconfig with the generated .configs.
Good idea, but I suggest holding off until the merge window has closed
since there are still new options going in. Doing a respin after -rc2
or so makes more sense. So please redo in a few weeks?
Traditionally Linus hasn't minded pulling in defconfig updates a little
later in the release cycles.
Thanks,
-Olof
--
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 6/6 v2] OMAP4: Sync up omap4430 defconfig
Enable minimum features to boot omap4430 on es1.0 samples. v2 versions removes the CONFIG_SYSFS_DEPRECATED_V2 since it's deprecated. Without this older file system doesn't boot. One need to upgrade the filesystem if getting stuck in first init function. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 146 ++- 1 files changed, 84 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a464ca3..2319113 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,26 +1,29 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 # 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_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_GENERIC_LOCKBREAK=y CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y # # General setup @@ -39,11 +42,12 @@ CONFIG_BSD_PROCESS_ACCT=y # # RCU Subsystem # -CONFIG_CLASSIC_RCU=y -# CONFIG_TREE_RCU is not set -# CONFIG_PREEMPT_RCU is not set +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set -# CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_GROUP_SCHED=y @@ -52,8 +56,7 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y @@ -70,7 +73,6 @@ CONFIG_UID16=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set -# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y @@ -83,6 +85,10 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y @@ -90,13 +96,16 @@ CONFIG_COMPAT_BRK=y CONFIG_SLUB=y # 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_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# # CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y @@ -110,7 +119,7 @@ CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y -# CONFIG_LBD is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -131,6 +140,7 @@ CONFIG_DEFAULT_IOSCHED=anticipatory # # System Type # +CONFIG_MMU=y # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set @@ -142,8 +152,10 @@ CONFIG_DEFAULT_IOSCHED=anticipatory # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -166,10 +178,13 @@ CONFIG_DEFAULT_IOSCHED=anticipatory # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set +# CONFIG_ARCH_S5PC1XX is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_U300 is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y +# CONFIG_ARCH_BCMRING is not set # # TI OMAP Implementations @@ -190,9 +205,12 @@ CONFIG_ARCH_OMAP4=y CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_DM_TIMER=y -CONFIG_OMAP_LL_DEBUG_UART1=y +# CONFIG_OMAP_LL_DEBUG_UART1 is not set # CONFIG_OMAP_LL_DEBUG_UART2 is not set -# CONFIG_OMAP_LL_DEBUG_UART3 is not set +CONFIG_OMAP_LL_DEBUG_UART3=y +# CONFIG_OMAP_LL_DEBUG_NONE is not set +# CONFIG_OMAP_PM_NONE is not set +CONFIG_OMAP_PM_NOOP=y # # OMAP Board Type @@ -207,7 +225,7 @@ CONFIG_CPU_32v6K=y CONFIG_CPU_V7=y CONFIG_CPU_32v7=y CONFIG_CPU_ABRT_EV7=y -CONFIG_CPU_PABRT_IFAR=y +CONFIG_CPU_PABRT_V7=y CONFIG_CPU_CACHE_V7=y
[PATCH 1/6 v2] OMAP4: Fix cpu detection
This patch fixes the OMAP4430 cpu detection. The IC rev detection is
done with hawkeye and rev. Note that rev does not map directly to
defined processor revision numbers as ES1.0 uses value 0.It also fixes
the SCM base address to read the correct ID_CODE register.
Also the cpu_is_omap44xx() and cpu_is_omap443x() correctly populated
instead of always being true
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/id.c | 27 ++-
arch/arm/plat-omap/common.c |2 +-
arch/arm/plat-omap/include/plat/cpu.h |9 ++---
3 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..3641ba0 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -246,6 +246,31 @@ void __init omap3_check_revision(void)
}
}
+void __init omap4_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+ char *rev_name = ES1.0;
+
+ /*
+* The IC rev detection is done with hawkeye and rev.
+* Note that rev does not map directly to defined processor
+* revision numbers as ES1.0 uses value 0.
+*/
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+
+ if ((hawkeye == 0xb852) (rev == 0x0)) {
+ omap_revision = OMAP4430_REV_ES1_0;
+ pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ return;
+ }
+
+ pr_err(Unknown OMAP4 CPU id\n);
+}
+
#define OMAP3_SHOW_FEATURE(feat) \
if (omap3_has_ ##feat())\
printk(#feat );
@@ -336,7 +361,7 @@ void __init omap2_check_revision(void)
omap3_check_features();
omap3_cpuinfo();
} else if (cpu_is_omap44xx()) {
- printk(KERN_INFO FIXME: CPU revision = OMAP4430\n);
+ omap4_check_revision();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index cc050b3..3473a80 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -280,7 +280,7 @@ void __init omap2_set_globals_343x(void)
#if defined(CONFIG_ARCH_OMAP4)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
- .tap= OMAP2_L4_IO_ADDRESS(0x4830a000),
+ .tap= OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..9359785 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -176,11 +176,13 @@ IS_OMAP_CLASS(15xx, 0x15)
IS_OMAP_CLASS(16xx, 0x16)
IS_OMAP_CLASS(24xx, 0x24)
IS_OMAP_CLASS(34xx, 0x34)
+IS_OMAP_CLASS(44xx, 0x44)
IS_OMAP_SUBCLASS(242x, 0x242)
IS_OMAP_SUBCLASS(243x, 0x243)
IS_OMAP_SUBCLASS(343x, 0x343)
IS_OMAP_SUBCLASS(363x, 0x363)
+IS_OMAP_SUBCLASS(443x, 0x443)
#define cpu_is_omap7xx() 0
#define cpu_is_omap15xx() 0
@@ -408,8 +410,8 @@ IS_OMAP_TYPE(3517, 0x3517)
# if defined(CONFIG_ARCH_OMAP4)
# undef cpu_is_omap44xx
# undef cpu_is_omap443x
-# define cpu_is_omap44xx() 1
-# define cpu_is_omap443x() 1
+# define cpu_is_omap44xx() is_omap44xx()
+# define cpu_is_omap443x() is_omap443x()
# endif
/* Macros to detect if we have OMAP1 or OMAP2 */
@@ -443,7 +445,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3505_REV(v)(OMAP35XX_CLASS | (0x3505 16) | (v
12))
#define OMAP3517_REV(v)(OMAP35XX_CLASS | (0x3517 16) | (v
12))
-#define OMAP443X_CLASS 0x44300034
+#define OMAP443X_CLASS 0x44300044
+#define OMAP4430_REV_ES1_0 0x44300044
/*
* omap_chip bits
--
1.6.0.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: [PATCH] OMAP3: hwmod: check for clkdomain pointer before accesing it to change the sleep dependencies.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, December 10, 2009 4:39 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; Paul Walmsley Subject: Re: [PATCH] OMAP3: hwmod: check for clkdomain pointer before accesing it to change the sleep dependencies. Thara Gopinath th...@ti.com writes: Some clock nodes like wdt1_fck, sr1_fck, sr2_fck etc do not have a clock domain associated . For such nodes accessing the clock domain pointers in _add_initiator_dep and _del_initiator_dep, will lead to null pointer defreferencing crash. Adding support in these functions to check for existence of clkdm pointer before trying to acess it. Even if tomorrow we correct all the clock nodes to have an associated clock domain, checking for the existence of the pointer is a good programming practice. Signed-off-by: Thara Gopinath th...@ti.com Cc: Paul Walmsley p...@pwsan.com --- This patch depends on http://patchwork.kernel.org/patch/63383/ I think clocks without associated clockdomains should be handled with a flag instead of a check for a NULL pointer. Your current approach will silently fail if someone forgets to add a clockdomain to a clock that should have one. Are you suggesting adding a flag to the clock node in case it does not have an associated clockdomain? I am using your tree origin/pm-wip/omap_device branch. On this I see a commit (e89a95db7095d998991c564a756a33ee0ec722c5) in which a warning is printed in omap2_init_clk_clkdm if there is no clockdomain associated with a clock node. My idea was this warning plus the check so as to avoid the system crash would suffice. Kevin arch/arm/mach-omap2/omap_hwmod.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 18e6478..3edc387 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -314,8 +314,10 @@ static int _add_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh) if (!oh-_clk) return -EINVAL; - return pwrdm_add_sleepdep(oh-_clk-clkdm-pwrdm.ptr, + if (oh-_clk-clkdm) + return pwrdm_add_sleepdep(oh-_clk-clkdm-pwrdm.ptr, init_oh-_clk-clkdm-pwrdm.ptr); + return 0; } /** @@ -335,8 +337,10 @@ static int _del_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh) if (!oh-_clk) return -EINVAL; - return pwrdm_del_sleepdep(oh-_clk-clkdm-pwrdm.ptr, + if (oh-_clk-clkdm) + return pwrdm_del_sleepdep(oh-_clk-clkdm-pwrdm.ptr, init_oh-_clk-clkdm-pwrdm.ptr); + return 0; } /** -- 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 -- 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]OMAP35xx:SDIO IRQ Support for OMAP35xx
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink)
Signed-off-by: Phaneendra Kumar ph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c | 55
1 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..fa94580 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -100,6 +100,10 @@
#define SRD(1 26)
#define SOFTRESET (1 1)
#define RESETDONE (1 0)
+#define CIRQ (1 8)
+#define CIRQ_ENABLE(1 8)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -171,6 +175,7 @@ struct omap_hsmmc_host {
int vdd;
int protect_card;
int reqs_blocked;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -436,6 +441,13 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
else
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ if (host-sdio_int) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ }
+
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
if (cmd-flags MMC_RSP_136)
@@ -640,6 +652,17 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
spin_lock(host-irq_lock);
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO Card
Interrupt\n);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
OMAP_HSMMC_READ(host-base, STAT));
@@ -649,10 +672,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
return IRQ_HANDLED;
}
- data = host-data;
- status = OMAP_HSMMC_READ(host-base, STAT);
- dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
-
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1254,6 +1273,25 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return mmc_slot(host).get_ro(host-dev, 0);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+
+ host-sdio_int = enable;
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ } else {
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) (~CIRQ_ENABLE)));
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE)
(~CIRQ_ENABLE)));
+ }
+
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hsmmc_ps_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
#ifdef CONFIG_DEBUG_FS
@@ -1657,6 +1695,7 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
host-mapbase = res-start;
host-base = ioremap(host-mapbase, SZ_4K);
host-power_mode = -1;
+ host-sdio_int = 0;
platform_set_drvdata(pdev, host);
INIT_WORK(host-mmc_carddetect_work, omap_hsmmc_detect);
@@ -1744,6 +1783,10 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
+ mmc-caps |= MMC_CAP_SDIO_IRQ;
+ OMAP_HSMMC_WRITE(host-base, CON,
+
