[RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430
This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses
are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures
are filled at runtime to have McSPI support on OMAP4.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/mach-omap2/devices.c | 25 +
drivers/spi/omap2_mcspi.c | 10 ++
2 files changed, 27 insertions(+), 8 deletions(-)
Index: omap4_dev/arch/arm/mach-omap2/devices.c
===
--- omap4_dev.orig/arch/arm/mach-omap2/devices.c2009-06-24
19:22:04.0
+0530
+++ omap4_dev/arch/arm/mach-omap2/devices.c 2009-06-25 10:05:39.0
+0530
@@ -257,6 +257,11 @@
#define OMAP2_MCSPI3_BASE 0x480b8000
#define OMAP2_MCSPI4_BASE 0x480ba000
+#define OMAP4_MCSPI1_BASE 0x48098100
+#define OMAP4_MCSPI2_BASE 0x4809a100
+#define OMAP4_MCSPI3_BASE 0x480b8100
+#define OMAP4_MCSPI4_BASE 0x480ba100
+
static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
};
@@ -301,7 +306,8 @@
},
};
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+ defined(CONFIG_ARCH_OMAP4)
static struct omap2_mcspi_platform_config omap2_mcspi3_config = {
.num_cs = 2,
};
@@ -325,7 +331,7 @@
};
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct omap2_mcspi_platform_config omap2_mcspi4_config = {
.num_cs = 1,
};
@@ -351,12 +357,23 @@
static void omap_init_mcspi(void)
{
+ if (cpu_is_omap44xx()) {
+ omap2_mcspi1_resources[0].start = OMAP4_MCSPI1_BASE;
+ omap2_mcspi1_resources[0].end = OMAP4_MCSPI1_BASE + 0xff;
+ omap2_mcspi2_resources[0].start = OMAP4_MCSPI2_BASE;
+ omap2_mcspi2_resources[0].end = OMAP4_MCSPI2_BASE + 0xff;
+ omap2_mcspi3_resources[0].start = OMAP4_MCSPI3_BASE;
+ omap2_mcspi3_resources[0].end = OMAP4_MCSPI3_BASE + 0xff;
+ omap2_mcspi4_resources[0].start = OMAP4_MCSPI4_BASE;
+ omap2_mcspi4_resources[0].end = OMAP4_MCSPI4_BASE + 0xff;
+ }
platform_device_register(omap2_mcspi1);
platform_device_register(omap2_mcspi2);
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+ defined(CONFIG_ARCH_OMAP4)
platform_device_register(omap2_mcspi3);
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
platform_device_register(omap2_mcspi4);
#endif
}
Index: omap4_dev/drivers/spi/omap2_mcspi.c
===
--- omap4_dev.orig/drivers/spi/omap2_mcspi.c2009-06-24 19:22:23.0
+0530
+++ omap4_dev/drivers/spi/omap2_mcspi.c 2009-06-24 19:22:46.0 +0530
@@ -918,7 +918,8 @@
OMAP24XX_DMA_SPI2_TX1,
};
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX) || \
+defined(CONFIG_ARCH_OMAP4)
static u8 __initdata spi3_rxdma_id[] = {
OMAP24XX_DMA_SPI3_RX0,
OMAP24XX_DMA_SPI3_RX1,
@@ -930,7 +931,7 @@
};
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static u8 __initdata spi4_rxdma_id[] = {
OMAP34XX_DMA_SPI4_RX0,
};
@@ -960,14 +961,15 @@
txdma_id = spi2_txdma_id;
num_chipselect = 2;
break;
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+ defined(CONFIG_ARCH_OMAP4)
case 3:
rxdma_id = spi3_rxdma_id;
txdma_id = spi3_txdma_id;
num_chipselect = 2;
break;
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
case 4:
rxdma_id = spi4_rxdma_id;
txdma_id = spi4_txdma_id;
--
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: reset USB OTG module on boot
On Wed, 24 Jun 2009, Pandita, Vikram wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Rather than simply setting force-idle mode on boot, do a reset of the OTG module. This really ensures that any bootloader/bootstrap code that leaves it active will not prevent future retention. After reset, OTG module will be in force-idle, force-standby mode. In addition, ensure that the iclk is enabled before attempting a write to the module SYSCONFIG register. This patch solves MUSB issue, but is not generic for all IP blocks on omap. ROM code or u-boot could leave the module sysconfig in a non-idle state. I recommend just like CONFIG_OMAP_RESET_CLOCKS for clocks, same could be done generically for all SYSCONFIG registers in some prcm code and not driver specific. I agree. Please contribute to the development of the omap_hwmod patchset, which does this (among other things). - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP2/3 SDRC: don't set SDRC_POWER.PWDENA on boot
Stop setting SDRC_POWER.PWDENA on boot. Turns out there is a nasty erratum (34xx erratum 1.150) that can cause memory corruption if PWDENA is enabled. Based originally on a patch from Samu P. Onkalo samu.p.onk...@nokia.com. Tested on BeagleBoard rev C2. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Samu P. Onkalo samu.p.onk...@nokia.com. --- arch/arm/mach-omap2/sdrc.c |5 - arch/arm/mach-omap2/sram34xx.S |2 -- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c index 2e9e38d..9e3bd4f 100644 --- a/arch/arm/mach-omap2/sdrc.c +++ b/arch/arm/mach-omap2/sdrc.c @@ -125,8 +125,11 @@ void __init omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0, sdrc_init_params_cs1 = sdrc_cs1; /* XXX Enable SRFRONIDLEREQ here also? */ + /* +* PWDENA should not be set due to 34xx erratum 1.150 - PWDENA +* can cause random memory corruption +*/ l = (1 SDRC_POWER_EXTCLKDIS_SHIFT) | - (1 SDRC_POWER_PWDENA_SHIFT) | (1 SDRC_POWER_PAGEPOLICY_SHIFT); sdrc_write_reg(l, SDRC_POWER); } diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 3aef744..9c2d046 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -58,7 +58,6 @@ /* SDRC_POWER bit settings */ #define SRFRONIDLEREQ_MASK 0x40 -#define PWDENA_MASK0x4 /* CM_IDLEST1_CORE bit settings */ #define ST_SDRC_MASK 0x2 @@ -160,7 +159,6 @@ sdram_in_selfrefresh: ldr r12, [r11] @ read the contents of SDRC_POWER mov r9, r12 @ keep a copy of SDRC_POWER bits orr r12, r12, #SRFRONIDLEREQ_MASK @ enable self refresh on idle - bic r12, r12, #PWDENA_MASK @ clear PWDENA str r12, [r11] @ write back to SDRC_POWER register ldr r12, [r11] @ posted-write barrier for SDRC idle_sdrc: -- 1.6.3.3.334.g916e1 -- 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] I2C:OMAP: fix status ack
I2C status ack for [RX]RDR and [RX]RDY could
cause race conditions of clearing the event
twice and a violation of the programing
sequence as defined in TRM This patch fixes
the same.
Issue identified by Jagadeesh Pakaravoor
and Ulrik Bech Hald.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/i2c/busses/i2c-omap.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ece0125..0db0051 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -651,7 +651,14 @@ omap_i2c_isr(int this_irq, void *dev_id)
break;
}
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
+ /*
+* Ack the stat in one go, but [rx]dr and [rx]rdy should be
+* acked after the data operation is complete.
+* Ref: TRM SWPU114Q Figure 18-31
+*/
+ omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat
+ ~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
err = 0;
if (stat OMAP_I2C_STAT_NACK) {
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] TI dspbridge Omapzoom tree
On Thu, Jun 4, 2009 at 1:18 AM, Ramirez Luna, Omaromar.rami...@ti.com wrote: Hi, The new dspbridge omapzoom tree has been set in place, you can clone it from: git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git or http://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git In this tree you will find the latest set of TI DSP BRIDGE patches, which are based on linux-omap kernel tree. The branch layout is as follows: master tracking L-O master bridge-pm-2.6.28 branched from omap-2.6.28, pulled linux-omap-pm pm-2.6.28 on top, + bridge patches bridge-pm-2.6.29 branched from L-O pm branch + bridge patches Special thanks to Hiroshi Doyu and Ameya Palande, and to all who have contributed with comments and patches. For the new dspbridge tree, I took the logical set of patches which was ported long time back[1] along with the new stuff, reworked what we had to migrate to this baseline and already sent the patches to the list, those patches can be found in the new tree. Where is this documented? I don't see this on the list of repos in http://git.omapzoom.org/ -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] TI dspbridge Omapzoom tree
Felipe Contreras said the following on 06/25/2009 12:46 PM: I don't see this on the list of repos in http://git.omapzoom.org/ I believe dev.omapzoom.org is new - this is not part of the repos as those deal with android.. 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: [ANNOUNCE] TI dspbridge Omapzoom tree
On Thu, Jun 25, 2009 at 12:59 PM, Nishanth Menonmenon.nisha...@gmail.com wrote: Felipe Contreras said the following on 06/25/2009 12:46 PM: I don't see this on the list of repos in http://git.omapzoom.org/ I believe dev.omapzoom.org is new - this is not part of the repos as those deal with android.. Thanks :) Shouldn't git.omapzoom.org be renamed to git.omapandroid.org or something? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Can a phone hook switch follow alsa jack model?
On Wed, Jun 24, 2009 at 03:28:11PM +0200, Janusz Krzysztofik wrote: Mark Brown wrote: type. Don't you think that a new type like SND_JACK_PHONE_HOOK or SND_JACK_PHONE_HANDSET should be defined for the purpose? Even if HEADSET may not be very different from HANDSET, corresponding SW_HEADPHONE_INSERT and SW_MICROPHONE_INSERT event names seem have very little to do with picking up a phone. Possibly, TBH I had thought I'd seen something for off-hook when I looked at this originally but I can't seem to spot it now. So, if I want to follow the ASoC jack model, my in-kernel hook switch handler should only power on/off the handset, not touching the speakerphone at all. The latter should be controlled from userspace. Please correct me if I am missing something. That's my initial guess - I've not looked at your particular hardware so it may not end up being the best way of dealing with your system but from what you said it was the approach that sprang to mind. -- 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 00/12] Omap fixes for 2.6.31
On Mon, Jun 22, 2009 at 02:36:53PM +0300, Tony Lindgren wrote: Here are some omap fixes for 2.6.31 for review. All look fine. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git pull request for omap-fixes for 2.6.31 (Re: [PATCH 00/12] Omap fixes for 2.6.31)
* Russell King - ARM Linux li...@arm.linux.org.uk [090625 15:27]: On Mon, Jun 22, 2009 at 02:36:53PM +0300, Tony Lindgren wrote: Here are some omap fixes for 2.6.31 for review. All look fine. The following changes since commit d888a4c76c51092993643f8992bf55b3c28da483: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../vapier/blackfin are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes Adrian Hunter (2): OMAP2/3: gpmc-onenand: correct use of async timings OMAP3: RX51: Use OneNAND sync read / write Andrew de Quincey (1): OMAP1: Fix N770 MMC support Fernando Guzman Lugo (1): OMAP: IOMMU: function flush_iotlb_page is not flushing correct entry Grazvydas Ignotas (1): OMAP2/3: mmc-twl4030: use correct controller in twl_mmc23_set_power Huang Weiyi (1): OMAP1: remove duplicated #include Jonathan McDowell (1): OMAP1: Fix compilation of arch/arm/mach-omap1/mailbox.c Kalle Jokiniemi (1): OMAP3: DMA: Enable idlemodes for DMA OCP Kevin Hilman (1): OMAP2/3: Add omap_type() for determining GP/EMU/HS Roel Kluin (1): OMAP2/3: omap mailbox: platform_get_irq() error ignored Tero Kristo (1): OMAP3: SRAM size fix for HS/EMU devices Tony Lindgren (1): OMAP: Fix IOMEM macro for assembly janboe (1): OMAP2/3: Initialize gpio debounce register arch/arm/mach-omap1/board-nokia770.c |3 ++- arch/arm/mach-omap1/mailbox.c|2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |1 + arch/arm/mach-omap2/gpmc-onenand.c | 21 +++-- arch/arm/mach-omap2/id.c | 22 ++ arch/arm/mach-omap2/mailbox.c|6 +++--- arch/arm/mach-omap2/mmc-twl4030.c| 13 - arch/arm/plat-omap/dma.c | 13 + arch/arm/plat-omap/gpio.c|1 + arch/arm/plat-omap/include/mach/cpu.h| 22 +++--- arch/arm/plat-omap/include/mach/dma.h| 15 +++ arch/arm/plat-omap/include/mach/io.h |2 +- arch/arm/plat-omap/iommu.c |2 +- arch/arm/plat-omap/sram.c|7 ++- 14 files changed, 108 insertions(+), 22 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Can a phone hook switch follow alsa jack model?
On 2009-06-25 13:05, Mark Brown wrote: On Wed, Jun 24, 2009 at 03:28:11PM +0200, Janusz Krzysztofik wrote: type. Don't you think that a new type like SND_JACK_PHONE_HOOK or SND_JACK_PHONE_HANDSET should be defined for the purpose? Even if HEADSET may not be very different from HANDSET, corresponding SW_HEADPHONE_INSERT and SW_MICROPHONE_INSERT event names seem have very little to do with picking up a phone. Possibly, TBH I had thought I'd seen something for off-hook when I looked at this originally but I can't seem to spot it now. As I am not native English, please somebody help me to choose best names, both SW_... event name and SND_JACK_... jack type. During my previous, gpio-keys based attempt, I submitted a patch that added new SW_HANDSET_PICK_UP event definition to include/linux/input.h. Even if not accepted because of no acompanying code that would make use of it, there were no other comments, especially on the name I have choosen. However, there were another name proposed by ams-delta board maintainer, Jonathan McDowell - SW_PHONE_HOOK. Even if my wording may better match those already existing ..._INSERT names, I am not sure which one should I use. Please also note that SND_JACK_HEADSET, that I temporarily use for now, is an alias for SND_JACK_HEADPHONE | SND_JACK_MICROPHONE. Those two can be seen as matching what a handset actually is. On headset jack insert/remove, two distinct reports/events are generated, one for a microphone, and one for a headphone. Should this schema be used with a handset? Even if it were possible to turn any of handset microphone or headphone individually, would it make any sense? Sorry for bothering you with all this stuff, but I'd like the changes to existing code I am going to propose, if any, be as much reusable as possible. So, if I want to follow the ASoC jack model, my in-kernel hook switch handler should only power on/off the handset, not touching the speakerphone at all. The latter should be controlled from userspace. Please correct me if I am missing something. That's my initial guess - I've not looked at your particular hardware so it may not end up being the best way of dealing with your system but from what you said it was the approach that sprang to mind. Mark, Thanks for now, all that seems clear enough for me. 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
About DSS2 in Kevin's l-o PM tree
Hi, Has anybody here tried DSS2 driver on top of Kevin's l-o PM tree? I was curious to try it for my camera capture tests... Regards, Sergio -- 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] serial: 8250: add IRQ trigger support
-Original Message- From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk] Subject: Re: [PATCH v2] serial: 8250: add IRQ trigger support On Mon, 22 Jun 2009 18:15:19 -0500 Vikram Pandita vikram.pand...@ti.com wrote: There is currently no provision for passing IRQ trigger flags for serial IRQs with triggering requirements (such as GPIO IRQs) This patch adds irqflags to plat_serial8250_port that can be passed from board file to reqest_irq() of 8250 driver Queued Thanks Alan for queueuing up the 8250 irq trigger patch. For OMAP Zoom2 board and some other boards needed this real bad. -- 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: git tree
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Hi, * Ryan ryanphilip...@googlemail.com [090624 12:42]: Hi, Looking at the linux-omap tree using the gitweb interface. Apart from the master branch and tags. why do we have lots of branches? How and when do they intertact with each other. Can anyone explain what exactly goes into each of them? Some are straight forward like pm, usb, tidspbridge, gateway. not sure about for-next-2.6.30, omap-fixes. More or less the various branches are topic branches of patches going to the mainline kernel. For example, omap-fixes contains fixes to be sent during the -rc cycle, omap-upstream contains omap common patches for the next merge window, omap1-upstream omap1 specific patches for the next merge window and so on. The master branch is more or less merge of all the topic branches. Currently missing from it are the pm branch and the dss2 branch. Trying to understand things/mode of development in here. Hope this helps. In general, your should now be able to do almost all the patches against Linus' mainline kernel. Of course until we get pm and dss2 into the mainline kernel, those patches need to be done against pm and dss2 branches. So everybody, where possible, please base all the patches against Linus' kernel stable something or -rc someting, that way they are easy to merge in. Are you recommending that future patches posted to l-o list should be based of kernel.org and not master of l-o? 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 -- 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: git tree
* Pandita, Vikram vikram.pand...@ti.com [090625 17:08]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Hi, * Ryan ryanphilip...@googlemail.com [090624 12:42]: Hi, Looking at the linux-omap tree using the gitweb interface. Apart from the master branch and tags. why do we have lots of branches? How and when do they intertact with each other. Can anyone explain what exactly goes into each of them? Some are straight forward like pm, usb, tidspbridge, gateway. not sure about for-next-2.6.30, omap-fixes. More or less the various branches are topic branches of patches going to the mainline kernel. For example, omap-fixes contains fixes to be sent during the -rc cycle, omap-upstream contains omap common patches for the next merge window, omap1-upstream omap1 specific patches for the next merge window and so on. The master branch is more or less merge of all the topic branches. Currently missing from it are the pm branch and the dss2 branch. Trying to understand things/mode of development in here. Hope this helps. In general, your should now be able to do almost all the patches against Linus' mainline kernel. Of course until we get pm and dss2 into the mainline kernel, those patches need to be done against pm and dss2 branches. So everybody, where possible, please base all the patches against Linus' kernel stable something or -rc someting, that way they are easy to merge in. Are you recommending that future patches posted to l-o list should be based of kernel.org and not master of l-o? Yeah, for all the patches that do not have dependencies to other topic branches such as pm, dss2. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -pm v5] OMAP3: PM: reset USB OTG module on boot
Rather than simply setting force-idle mode on boot, do a reset of the
OTG module. This really ensures that any bootloader/bootstrap code
that leaves it active will not prevent future retention. After reset,
OTG module will be in force-idle, force-standby mode.
Problem reported by Mike Chan mikec...@google.com
Tested-by: Mike Chan mikec...@google.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
I decided to drop clock stuff from this patch as the current
code is not doing it either. This simply replaces the
force-idle with a soft reset, and uses ioremap instead of
omap_write().
This will only be a temporary patch in the pm branch until
omap_hwmod is integrated and is doing the full module reset.
arch/arm/mach-omap2/usb-musb.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index d85296d..3efa19c 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -26,18 +26,32 @@
#include linux/usb/musb.h
+#include asm/sizes.h
+
#include mach/hardware.h
#include mach/irqs.h
#include mach/mux.h
#include mach/usb.h
-#define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
+#define OTG_SYSCONFIG 0x404
+#define OTG_SYSC_SOFTRESET BIT(1)
static void __init usb_musb_pm_init(void)
{
- /* Ensure force-idle mode for OTG controller */
- if (cpu_is_omap34xx())
- omap_writel(0, OTG_SYSCONFIG);
+ void __iomem *otg_base;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ otg_base = ioremap(OMAP34XX_HSUSB_OTG_BASE, SZ_4K);
+ if (WARN_ON(!otg_base))
+ return;
+
+ /* Reset OTG controller. After reset, it will be in
+* force-idle, force-standby mode. */
+ __raw_writel(OTG_SYSC_SOFTRESET, otg_base + OTG_SYSCONFIG);
+
+ iounmap(otg_base);
}
#ifdef CONFIG_USB_MUSB_SOC
--
1.6.3.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 1/2] Support OMAP3 VC adaptation with different Power IC
-Original Message-
From: Mike Chan [mailto:m...@android.com]
Sent: 2009年6月25日 9:25
To: Wang Sawsd-A24013
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/2] Support OMAP3 VC adaptation with
different Power IC
Wang Sawsd-A24013 wrote:
From c1aba8ba7af3ddd16346d95795bda71e65baa4d0 Mon Sep 17
00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Wed, 24 Jun 2009 06:48:52 +0800
Subject: [PATCH] Support OMAP3 VC adaptation with different Power IC
Current OMAP SmartReflex driver only supports TI Triton
Power IC, add a callback to make it possible to use
different PowerIC and use different settings to
configure OMAP3 Voltage Controller for DVFS
Board file can setup a new function to have different settings
on SR to configure their Power IC for voltage scaling
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/mach-omap2/smartreflex.c | 13 +
arch/arm/mach-omap2/smartreflex.h |4
arch/arm/plat-omap/Kconfig|2 +-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9d462e3..bacf602 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -52,6 +52,8 @@ struct omap_sr {
#define SR_REGADDR(offs) (sr-srbase_addr + offset)
+static omap3_voltagescale_vcbypass_t omap3_volscale_vcbypass_fun;
Perhaps use
static int (*omap3_volscale_vcbypass_fun) (u32, u32, u8, u8);
This gets rid of the compiler warning on incompatible pointer
types when
you register a function via omap3_voltagescale_vcbypass_setup().
-- Mike
Thanks Mike, but we do not see the warnning with the original
Code, note this patch is slightly different with the one we sent
To you based on K29, this new patch have four parameters
Sinc some change has been made in the
sr_voltagescale_vcbypass to add two more parameters.
Is your warnning caused by this?
Thanks,
Chunqiu
--
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
bootarg mpurate is ignored
Hi, I was trying to change the MPU frequency by using the bootarg mpurate. But there was no impact of the same. In the bootlog: ... ... Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz ...later.. Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz ... ... From the code, it clearly seemed to be ignored. So, I made the change below: diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index 045da92..5bdd978 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -948,13 +948,20 @@ static int __init omap2_clk_arch_init(void) if (clk_set_rate(virt_prcm_set, mpurate)) printk(KERN_ERR Could not find matching MPU rate\n); #endif + printk(KERN_ERR Before change: %ld\n, dpll1_ck.rate); + + if (clk_set_rate(dpll1_ck, mpurate)) + printk(KERN_ERR *** Unable to set MPU rate\n); + omap3_dpll_recalc(dpll1_ck); + + printk(KERN_ERR After change: %ld\n, dpll1_ck.rate); recalculate_root_clocks(); - printk(KERN_INFO Switched to new clocking rate (Crystal/DPLL3/MPU): + printk(KERN_INFO Switched to new clocking rate (Crystal/Core/MPU): %ld.%01ld/%ld/%ld MHz\n, (osc_sys_ck.rate / 100), (osc_sys_ck.rate / 10) % 10, - (core_ck.rate / 100), (dpll1_fck.rate / 100)) ; + (core_ck.rate / 100), (dpll1_ck.rate / 100)) ; return 0; } Now the bootlog seems fine: ... ... Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz ...later.. Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/550 MHz ... ... However, cat /cpu/procinfo still shows: Processor : ARMv7 Processor rev 3 (v7l) BogoMIPS: 499.92 Features: swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part: 0xc08 CPU revision: 3 Am I missing some step here? Also, I tried changing arm_ck directly (evidently not right) as well :( Best regards, Sanjeev -- 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 12/11] OMAP: PM: CPUfreq: obey min/max settings of policy
From: Eero Nurkkala ext-eero.nurkk...@nokia.com Use the min/max settings from CPUfreq policy rather than processor defined min/max settings. Without this patch, it's possible to scale frequency outside the current policy range. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/cpu-omap.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index 843e8af..1868c0d 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -78,10 +78,10 @@ static int omap_target(struct cpufreq_policy *policy, /* Ensure desired rate is within allowed range. Some govenors * (ondemand) will just pass target_freq=0 to get the minimum. */ - if (target_freq policy-cpuinfo.min_freq) - target_freq = policy-cpuinfo.min_freq; - if (target_freq policy-cpuinfo.max_freq) - target_freq = policy-cpuinfo.max_freq; + if (target_freq policy-min) + target_freq = policy-min; + if (target_freq policy-max) + target_freq = policy-max; freqs.old = omap_getspeed(0); freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000; -- 1.6.3.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 11/11] OMAP2/3/4: UART: Allow per-UART disabling wakeup for serial ports
This patch causes the OMAP uarts to honor the sysfs power/wakeup file
for IOPAD wakeups. Before the OMAP was always woken up from off mode
on a rs232 signal change. This patch also creates a different
platform device for each serial port so that the wakeup properties can
be control per port.
By default, IOPAD wakeups are enabled for each UART. To disable,
# echo disabled /sys/devices/platform/serial8250.0/power/wakeup
Where serial8250.0 can be replaced by .1, or .2 to control the other
ports.
Original idea and original patch from Russ Dill russ.d...@gmail.com
Cc: Russ Dill russ.d...@gmail.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/serial.c | 174 --
1 files changed, 116 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5352d05..6f35a7e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -54,6 +54,7 @@ struct omap_uart_state {
struct plat_serial8250_port *p;
struct list_head node;
+ struct platform_device pdev;
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
int context_valid;
@@ -68,10 +69,9 @@ struct omap_uart_state {
#endif
};
-static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS];
static LIST_HEAD(uart_list);
-static struct plat_serial8250_port serial_platform_data[] = {
+static struct plat_serial8250_port serial_platform_data0[] = {
{
.membase= IO_ADDRESS(OMAP_UART1_BASE),
.mapbase= OMAP_UART1_BASE,
@@ -81,6 +81,12 @@ static struct plat_serial8250_port serial_platform_data[] = {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
+ .flags = 0
+ }
+};
+
+static struct plat_serial8250_port serial_platform_data1[] = {
+ {
.membase= IO_ADDRESS(OMAP_UART2_BASE),
.mapbase= OMAP_UART2_BASE,
.irq= 73,
@@ -89,6 +95,12 @@ static struct plat_serial8250_port serial_platform_data[] = {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
+ .flags = 0
+ }
+};
+
+static struct plat_serial8250_port serial_platform_data2[] = {
+ {
.membase= IO_ADDRESS(OMAP_UART3_BASE),
.mapbase= OMAP_UART3_BASE,
.irq= 74,
@@ -217,6 +229,40 @@ static inline void omap_uart_disable_clocks(struct
omap_uart_state *uart)
clk_disable(uart-fck);
}
+static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
+{
+ /* Set wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v |= uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+
+ /* Ensure IOPAD wake-enables are set */
+ if (cpu_is_omap34xx() uart-padconf) {
+ u16 v = omap_ctrl_readw(uart-padconf);
+ v |= OMAP3_PADCONF_WAKEUPENABLE0;
+ omap_ctrl_writew(v, uart-padconf);
+ }
+}
+
+static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
+{
+ /* Clear wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v = ~uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+
+ /* Ensure IOPAD wake-enables are cleared */
+ if (cpu_is_omap34xx() uart-padconf) {
+ u16 v = omap_ctrl_readw(uart-padconf);
+ v = ~OMAP3_PADCONF_WAKEUPENABLE0;
+ omap_ctrl_writew(v, uart-padconf);
+ }
+}
+
static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
int enable)
{
@@ -246,6 +292,11 @@ static void omap_uart_block_sleep(struct omap_uart_state
*uart)
static void omap_uart_allow_sleep(struct omap_uart_state *uart)
{
+ if (device_may_wakeup(uart-pdev.dev))
+ omap_uart_enable_wakeup(uart);
+ else
+ omap_uart_disable_wakeup(uart);
+
if (!uart-clocked)
return;
@@ -292,7 +343,6 @@ void omap_uart_resume_idle(int num)
/* Check for normal UART wakeup */
if (__raw_readl(uart-wk_st) uart-wk_mask)
omap_uart_block_sleep(uart);
-
return;
}
}
@@ -346,16 +396,13 @@ static irqreturn_t omap_uart_interrupt(int irq, void
*dev_id)
return IRQ_NONE;
}
-static u32 sleep_timeout = DEFAULT_TIMEOUT;
-
static void omap_uart_idle_init(struct omap_uart_state *uart)
{
- u32 v;
struct plat_serial8250_port *p = uart-p;
int ret;
uart-can_sleep = 0;
- uart-timeout = sleep_timeout;
+ uart-timeout =
[PATCH 10/11] OMAP3: Fixed crash bug with serial + suspend
From: Tero Kristo tero.kri...@nokia.com
It was possible for an unhandled interrupt to occur if there was incoming
serial traffic during wakeup from suspend. This was caused by the code
in arch-arm/mach-omap2/serial.c keeping interrupt enabled all the time,
but not acking its interrupts. Applies on top of PM branch.
Use the PM begin/end hooks to ensure that the serial idle interrupts
are disabled during the suspend path. Also, since begin/end hooks are
now used, use the suspend_state that is passed in the begin hook instead
of the enter hook as per the platform_suspend_ops docs.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c | 23 +--
arch/arm/mach-omap2/serial.c | 14 ++
arch/arm/plat-omap/include/mach/serial.h |1 +
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 528f725..b07efb2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -296,6 +296,8 @@ out:
}
#ifdef CONFIG_SUSPEND
+static suspend_state_t suspend_state;
+
static int omap3_pm_prepare(void)
{
disable_hlt();
@@ -342,11 +344,11 @@ restore:
return ret;
}
-static int omap3_pm_enter(suspend_state_t state)
+static int omap3_pm_enter(suspend_state_t unused)
{
int ret = 0;
- switch (state) {
+ switch (suspend_state) {
case PM_SUSPEND_STANDBY:
case PM_SUSPEND_MEM:
ret = omap3_pm_suspend();
@@ -363,7 +365,24 @@ static void omap3_pm_finish(void)
enable_hlt();
}
+/* Hooks to enable / disable UART interrupts during suspend */
+static int omap3_pm_begin(suspend_state_t state)
+{
+ suspend_state = state;
+ omap_uart_enable_irqs(0);
+ return 0;
+}
+
+static void omap3_pm_end(void)
+{
+ suspend_state = PM_SUSPEND_ON;
+ omap_uart_enable_irqs(1);
+ return;
+}
+
static struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap3_pm_begin,
+ .end= omap3_pm_end,
.prepare= omap3_pm_prepare,
.enter = omap3_pm_enter,
.finish = omap3_pm_finish,
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c82ec95..5352d05 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -435,6 +435,20 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
WARN_ON(ret);
}
+void omap_uart_enable_irqs(int enable)
+{
+ int ret;
+ struct omap_uart_state *uart;
+
+ list_for_each_entry(uart, uart_list, node) {
+ if (enable)
+ ret = request_irq(uart-p-irq, omap_uart_interrupt,
+ IRQF_SHARED, serial idle, (void *)uart);
+ else
+ free_irq(uart-p-irq, (void *)uart);
+ }
+}
+
static ssize_t sleep_timeout_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
diff --git a/arch/arm/plat-omap/include/mach/serial.h
b/arch/arm/plat-omap/include/mach/serial.h
index 13abd02..def0529 100644
--- a/arch/arm/plat-omap/include/mach/serial.h
+++ b/arch/arm/plat-omap/include/mach/serial.h
@@ -59,6 +59,7 @@ extern void omap_uart_check_wakeup(void);
extern void omap_uart_prepare_suspend(void);
extern void omap_uart_prepare_idle(int num);
extern void omap_uart_resume_idle(int num);
+extern void omap_uart_enable_irqs(int enable);
#endif
#endif
--
1.6.3.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 01/11] OMAP: SDRC: Add several new register definitions
From: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/include/mach/sdrc.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/sdrc.h
b/arch/arm/plat-omap/include/mach/sdrc.h
index adc7352..7cc6568 100644
--- a/arch/arm/plat-omap/include/mach/sdrc.h
+++ b/arch/arm/plat-omap/include/mach/sdrc.h
@@ -21,15 +21,28 @@
/* SDRC register offsets - read/write with sdrc_{read,write}_reg() */
#define SDRC_SYSCONFIG 0x010
+#define SDRC_CS_CFG0x040
+#define SDRC_SHARING 0x044
+#define SDRC_ERR_TYPE 0x04C
#define SDRC_DLLA_CTRL 0x060
#define SDRC_DLLA_STATUS 0x064
#define SDRC_DLLB_CTRL 0x068
#define SDRC_DLLB_STATUS 0x06C
#define SDRC_POWER 0x070
+#define SDRC_MCFG_00x080
#define SDRC_MR_0 0x084
+#define SDRC_EMR2_00x08c
#define SDRC_ACTIM_CTRL_A_00x09c
#define SDRC_ACTIM_CTRL_B_00x0a0
#define SDRC_RFR_CTRL_00x0a4
+#define SDRC_MANUAL_0 0x0a8
+#define SDRC_MCFG_10x0B0
+#define SDRC_MR_1 0x0B4
+#define SDRC_EMR2_10x0BC
+#define SDRC_ACTIM_CTRL_A_10x0C4
+#define SDRC_ACTIM_CTRL_B_10x0C8
+#define SDRC_RFR_CTRL_10x0D4
+#define SDRC_MANUAL_1 0x0D8
/*
* These values represent the number of memory clock cycles between
--
1.6.3.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 08/11] OMAP3: PM: reset USB OTG module on boot
Rather than simply setting force-idle mode on boot, do a reset of the
OTG module. This really ensures that any bootloader/bootstrap code
that leaves it active will not prevent future retention. After reset,
OTG module will be in force-idle, force-standby mode.
Problem reported by Mike Chan mikec...@google.com
Tested-by: Mike Chan mikec...@google.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/usb-musb.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index d85296d..3efa19c 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -26,18 +26,32 @@
#include linux/usb/musb.h
+#include asm/sizes.h
+
#include mach/hardware.h
#include mach/irqs.h
#include mach/mux.h
#include mach/usb.h
-#define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
+#define OTG_SYSCONFIG 0x404
+#define OTG_SYSC_SOFTRESET BIT(1)
static void __init usb_musb_pm_init(void)
{
- /* Ensure force-idle mode for OTG controller */
- if (cpu_is_omap34xx())
- omap_writel(0, OTG_SYSCONFIG);
+ void __iomem *otg_base;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ otg_base = ioremap(OMAP34XX_HSUSB_OTG_BASE, SZ_4K);
+ if (WARN_ON(!otg_base))
+ return;
+
+ /* Reset OTG controller. After reset, it will be in
+* force-idle, force-standby mode. */
+ __raw_writel(OTG_SYSC_SOFTRESET, otg_base + OTG_SYSCONFIG);
+
+ iounmap(otg_base);
}
#ifdef CONFIG_USB_MUSB_SOC
--
1.6.3.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 05/11] OMAP3: PM: Clear pending PRCM reset flags on init
Any pending reset flags can prevent retention. Ensure they are all cleared during boot. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/pm34xx.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index cc83dfc..1422e93 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -613,6 +613,15 @@ static void __init prcm_setup_regs(void) /* Clear any pending PRCM interrupts */ prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); + /* Clear any pending 'reset' flags */ + prm_write_mod_reg(0x, MPU_MOD, RM_RSTST); + prm_write_mod_reg(0x, CORE_MOD, RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_PER_MOD, RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_EMU_MOD, RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_NEON_MOD, RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_DSS_MOD, RM_RSTST); + prm_write_mod_reg(0x, OMAP3430ES2_USBHOST_MOD, RM_RSTST); + /* Clear any pending PRCM interrupts */ prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); -- 1.6.3.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
marc info dead?
Hi, Dunno if anyone noticed, but kinda think http://marc.info/?l=linux-omap linked from: http://vger.kernel.org/vger-lists.html#linux-omap seems to show only from 2009-06-15 mails.. http://www.mail-archive.com/linux-omap@vger.kernel.org/ seems to show fine.. 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] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon errata 1.153
Menon, Nishanth wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Igor Mazanov
Sent: Tuesday, June 23, 2009 4:43 PM
To: linux-omap@vger.kernel.org
Subject: Re: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon
errata 1.153
/*
* Is there a bug in the OMAP5910 I2C controller? It
* generates a bunch of fake XRDY interrupts under high load.
* As result, there is a very high chance to have a situation
* when dev-buf_len = 0 already, but I2C_CNT != 0. So, there
* is no ARDY irq then, no complete_cmd, controller timed out
* issues...
*
* Workaround:
*
* When we get XRDY interrupt without transmit underflow flag
* (XUDF bit in the I2C_STAT register), delay for 100 microsecs
* and ignore it.
*
* We write data into I2C_DATA register in case of transmit
* underflow condition ONLY.
*/
if (stat OMAP_I2C_STAT_XRDY) {
if (!(stat OMAP_I2C_STAT_XUDF)) {
udelay(100);
continue;
} else {
w = 0;
if (dev-buf_len) {
w = *dev-buf++;
dev-buf_len--;
if (dev-buf_len) {
w |= *dev-buf++ 8;
dev-buf_len--;
}
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
} else {
dev_err(dev-dev, XRDY IRQ while no
data to send\n);
break;
}
continue;
}
}
Could you submit a patch please?
OMAP1 I2C controller generates a huge amount of fake XRDY interrupts when large
continuous blocks of data are transmitted via I2C. As result data have no time
to be transmitted physically over I2C data line if we just look on XRDY bit
before writing to I2C_DATA register. Taking into account a transmit underrun
condition (XUDF bit in the I2C_STAT register) help us to transmit in more
predictable way.
So,
Signed-off-by: Igor Mazanov i.maza...@gmail.com
---
drivers/i2c/busses/i2c-omap.c | 140
1 files changed, 98 insertions(+), 42 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ece0125..7464848 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -436,10 +436,15 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev-buf_len);
- /* Clear the FIFO Buffers */
- w = omap_i2c_read_reg(dev, OMAP_I2C_BUF_REG);
- w |= OMAP_I2C_BUF_RXFIF_CLR | OMAP_I2C_BUF_TXFIF_CLR;
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, w);
+ /* Clear the FIFO Buffers
+* Useless for OMAP1 family - according TRMs (spru681b, spru760c),
+* FIFO are not controllable in this way
+*/
+ if (!cpu_class_is_omap1()) {
+ w = omap_i2c_read_reg(dev, OMAP_I2C_BUF_REG);
+ w |= OMAP_I2C_BUF_RXFIF_CLR | OMAP_I2C_BUF_TXFIF_CLR;
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, w);
+ }
init_completion(dev-cmd_complete);
dev-cmd_err = 0;
@@ -578,55 +583,106 @@ static irqreturn_t
omap_i2c_rev1_isr(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
- u16 iv, w;
+ u16 bits;
+ u16 stat, w;
+ int err, count = 0;
if (dev-idle)
return IRQ_NONE;
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG);
- switch (iv) {
- case 0x00: /* None */
- break;
- case 0x01: /* Arbitration lost */
- dev_err(dev-dev, Arbitration lost\n);
- omap_i2c_complete_cmd(dev, OMAP_I2C_STAT_AL);
- break;
- case 0x02: /* No acknowledgement */
- omap_i2c_complete_cmd(dev, OMAP_I2C_STAT_NACK);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_STP);
- break;
- case 0x03: /* Register access ready */
- omap_i2c_complete_cmd(dev, 0);
- break;
- case 0x04: /* Receive data ready */
- if (dev-buf_len) {
+ bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+ while ((stat = (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG))) bits) {
+ dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
+ if (count++ == 200) {
+ dev_warn(dev-dev, Too much work in one IRQ\n);
+ break;
+ }
+
+ omap_i2c_read_reg(dev, OMAP_I2C_IV_REG);
+
+ err = 0;
+ if (stat OMAP_I2C_STAT_NACK) {
+ err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
+ OMAP_I2C_CON_STP);
+
[PATCH 04/11] OMAP3: PM: Ensure PRCM interrupts are cleared at boot
Any pending PRCM interrupts can prevent retention. Ensure they are cleared during boot. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/pm34xx.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 765cdc0..cc83dfc 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -613,6 +613,9 @@ static void __init prcm_setup_regs(void) /* Clear any pending PRCM interrupts */ prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); + /* Clear any pending PRCM interrupts */ + prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); + omap3_iva_idle(); omap3_d2d_idle(); } -- 1.6.3.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 06/11] OMAP3: PM: prevent module wakeups from waking IVA2
By default, prevent functional wakeups from inside a module from waking up the IVA2. Let DSP Bridge code handle this when loaded. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/pm34xx.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 1422e93..c813a08 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -613,6 +613,12 @@ static void __init prcm_setup_regs(void) /* Clear any pending PRCM interrupts */ prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); + /* Don't attach IVA interrupts */ + prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL); + prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1); + prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3); + prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL); + /* Clear any pending 'reset' flags */ prm_write_mod_reg(0x, MPU_MOD, RM_RSTST); prm_write_mod_reg(0x, CORE_MOD, RM_RSTST); -- 1.6.3.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 02/11] OMAP2/3: PM: make PM __init calls static
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm.h |3 ---
arch/arm/mach-omap2/pm24xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f7b3baf..21201cd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -11,9 +11,6 @@
#ifndef __ARCH_ARM_MACH_OMAP2_PM_H
#define __ARCH_ARM_MACH_OMAP2_PM_H
-extern int omap2_pm_init(void);
-extern int omap3_pm_init(void);
-
#ifdef CONFIG_PM_DEBUG
extern void omap2_pm_dump(int mode, int resume, unsigned int us);
extern int omap2_pm_debug;
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index db10255..528dbdc 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -470,7 +470,7 @@ static void __init prcm_setup_regs(void)
WKUP_MOD, PM_WKEN);
}
-int __init omap2_pm_init(void)
+static int __init omap2_pm_init(void)
{
u32 l;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 841d4c5..765cdc0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -652,7 +652,7 @@ static int __init clkdms_setup(struct clockdomain *clkdm)
return 0;
}
-int __init omap3_pm_init(void)
+static int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
int ret;
--
1.6.3.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 03/11] OMAP3: PM: CM_REGADDR macros using wrong name
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/cm.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index 1d3c93b..f3c91a1 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -29,9 +29,9 @@ * These registers appear once per CM module. */ -#define OMAP3430_CM_REVISION OMAP_CM_REGADDR(OCP_MOD, 0x) -#define OMAP3430_CM_SYSCONFIG OMAP_CM_REGADDR(OCP_MOD, 0x0010) -#define OMAP3430_CM_POLCTRLOMAP_CM_REGADDR(OCP_MOD, 0x009c) +#define OMAP3430_CM_REVISION OMAP34XX_CM_REGADDR(OCP_MOD, 0x) +#define OMAP3430_CM_SYSCONFIG OMAP34XX_CM_REGADDR(OCP_MOD, 0x0010) +#define OMAP3430_CM_POLCTRLOMAP34XX_CM_REGADDR(OCP_MOD, 0x009c) #define OMAP3_CM_CLKOUT_CTRL_OFFSET0x0070 #define OMAP3430_CM_CLKOUT_CTRL OMAP_CM_REGADDR(OMAP3430_CCR_MOD, 0x0070) -- 1.6.3.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 07/11] OMAP3: PM: Do not build suspend code if SUSPEND is not enabled
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c813a08..528f725 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -39,7 +39,9 @@
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
+#ifdef CONFIG_SUSPEND
u32 saved_state;
+#endif
struct list_head node;
};
@@ -293,6 +295,7 @@ out:
local_irq_enable();
}
+#ifdef CONFIG_SUSPEND
static int omap3_pm_prepare(void)
{
disable_hlt();
@@ -366,6 +369,7 @@ static struct platform_suspend_ops omap_pm_ops = {
.finish = omap3_pm_finish,
.valid = suspend_valid_only_mem,
};
+#endif /* CONFIG_SUSPEND */
/**
@@ -710,7 +714,9 @@ static int __init omap3_pm_init(void)
_omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
omap34xx_cpu_suspend_sz);
+#ifdef CONFIG_SUSPEND
suspend_set_ops(omap_pm_ops);
+#endif /* CONFIG_SUSPEND */
pm_idle = omap3_pm_idle;
--
1.6.3.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 00/11] OMAP fixes from PM branch for .31-rc
This series is a set of fixes/cleanups from the PM branch targeted for the .31-rc series. Applies on top of 'omap-fixes' branch of linux-omap. Kevin Hilman (9): OMAP2/3: PM: make PM __init calls static OMAP3: PM: CM_REGADDR macros using wrong name OMAP3: PM: Ensure PRCM interrupts are cleared at boot OMAP3: PM: Clear pending PRCM reset flags on init OMAP3: PM: prevent module wakeups from waking IVA2 OMAP3: PM: Do not build suspend code if SUSPEND is not enabled OMAP3: PM: reset USB OTG module on boot OMAP4: UART: cleanup special case IRQ handling OMAP2/3/4: UART: Allow per-UART disabling wakeup for serial ports Tero Kristo (2): OMAP: SDRC: Add several new register definitions OMAP3: Fixed crash bug with serial + suspend arch/arm/mach-omap2/cm.h |6 +- arch/arm/mach-omap2/pm.h |3 - arch/arm/mach-omap2/pm24xx.c |2 +- arch/arm/mach-omap2/pm34xx.c | 49 +++- arch/arm/mach-omap2/serial.c | 195 -- arch/arm/mach-omap2/usb-musb.c | 22 +++- arch/arm/plat-omap/include/mach/sdrc.h | 13 ++ arch/arm/plat-omap/include/mach/serial.h |1 + 8 files changed, 215 insertions(+), 76 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430
Syed Rafiuddin rafiuddin.s...@ti.com writes:
This patch adds McSPI support for OMAP4430 SDP platform. All the base
addresses
are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures
are filled at runtime to have McSPI support on OMAP4.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
This driver needs some help for multi-omap, but that problem existed
before this patch, so
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/devices.c | 25 +
drivers/spi/omap2_mcspi.c | 10 ++
2 files changed, 27 insertions(+), 8 deletions(-)
Index: omap4_dev/arch/arm/mach-omap2/devices.c
===
--- omap4_dev.orig/arch/arm/mach-omap2/devices.c 2009-06-24
19:22:04.0
+0530
+++ omap4_dev/arch/arm/mach-omap2/devices.c 2009-06-25 10:05:39.0
+0530
@@ -257,6 +257,11 @@
#define OMAP2_MCSPI3_BASE0x480b8000
#define OMAP2_MCSPI4_BASE0x480ba000
+#define OMAP4_MCSPI1_BASE0x48098100
+#define OMAP4_MCSPI2_BASE0x4809a100
+#define OMAP4_MCSPI3_BASE0x480b8100
+#define OMAP4_MCSPI4_BASE0x480ba100
+
static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
};
@@ -301,7 +306,8 @@
},
};
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+ defined(CONFIG_ARCH_OMAP4)
static struct omap2_mcspi_platform_config omap2_mcspi3_config = {
.num_cs = 2,
};
@@ -325,7 +331,7 @@
};
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct omap2_mcspi_platform_config omap2_mcspi4_config = {
.num_cs = 1,
};
@@ -351,12 +357,23 @@
static void omap_init_mcspi(void)
{
+ if (cpu_is_omap44xx()) {
+ omap2_mcspi1_resources[0].start = OMAP4_MCSPI1_BASE;
+ omap2_mcspi1_resources[0].end = OMAP4_MCSPI1_BASE + 0xff;
+ omap2_mcspi2_resources[0].start = OMAP4_MCSPI2_BASE;
+ omap2_mcspi2_resources[0].end = OMAP4_MCSPI2_BASE + 0xff;
+ omap2_mcspi3_resources[0].start = OMAP4_MCSPI3_BASE;
+ omap2_mcspi3_resources[0].end = OMAP4_MCSPI3_BASE + 0xff;
+ omap2_mcspi4_resources[0].start = OMAP4_MCSPI4_BASE;
+ omap2_mcspi4_resources[0].end = OMAP4_MCSPI4_BASE + 0xff;
+ }
platform_device_register(omap2_mcspi1);
platform_device_register(omap2_mcspi2);
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+ defined(CONFIG_ARCH_OMAP4)
platform_device_register(omap2_mcspi3);
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
platform_device_register(omap2_mcspi4);
#endif
}
Index: omap4_dev/drivers/spi/omap2_mcspi.c
===
--- omap4_dev.orig/drivers/spi/omap2_mcspi.c 2009-06-24 19:22:23.0
+0530
+++ omap4_dev/drivers/spi/omap2_mcspi.c 2009-06-24 19:22:46.0
+0530
@@ -918,7 +918,8 @@
OMAP24XX_DMA_SPI2_TX1,
};
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX) || \
+ defined(CONFIG_ARCH_OMAP4)
static u8 __initdata spi3_rxdma_id[] = {
OMAP24XX_DMA_SPI3_RX0,
OMAP24XX_DMA_SPI3_RX1,
@@ -930,7 +931,7 @@
};
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static u8 __initdata spi4_rxdma_id[] = {
OMAP34XX_DMA_SPI4_RX0,
};
@@ -960,14 +961,15 @@
txdma_id = spi2_txdma_id;
num_chipselect = 2;
break;
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+ defined(CONFIG_ARCH_OMAP4)
case 3:
rxdma_id = spi3_rxdma_id;
txdma_id = spi3_txdma_id;
num_chipselect = 2;
break;
#endif
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
case 4:
rxdma_id = spi4_rxdma_id;
txdma_id = spi4_txdma_id;
--
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 12/11] OMAP: PM: CPUfreq: obey min/max settings of policy
yes, this is patch 12 of 11. :) It's an extra patch that should've been included in the original series. Kevin Kevin Hilman khil...@deeprootsystems.com writes: From: Eero Nurkkala ext-eero.nurkk...@nokia.com Use the min/max settings from CPUfreq policy rather than processor defined min/max settings. Without this patch, it's possible to scale frequency outside the current policy range. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/cpu-omap.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index 843e8af..1868c0d 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -78,10 +78,10 @@ static int omap_target(struct cpufreq_policy *policy, /* Ensure desired rate is within allowed range. Some govenors * (ondemand) will just pass target_freq=0 to get the minimum. */ - if (target_freq policy-cpuinfo.min_freq) - target_freq = policy-cpuinfo.min_freq; - if (target_freq policy-cpuinfo.max_freq) - target_freq = policy-cpuinfo.max_freq; + if (target_freq policy-min) + target_freq = policy-min; + if (target_freq policy-max) + target_freq = policy-max; freqs.old = omap_getspeed(0); freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000; -- 1.6.3.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 1/2] Support OMAP3 VC adaptation with different Power IC
Wang Sawsd-A24013 cqw...@motorola.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 2009年6月24日 8:19 To: Wang Sawsd-A24013 Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 1/2] Support OMAP3 VC adaptation with different Power IC Wang Sawsd-A24013 cqw...@motorola.com writes: From c1aba8ba7af3ddd16346d95795bda71e65baa4d0 Mon Sep 17 00:00:00 2001 From: Chunqiu Wang cqw...@motorola.com Date: Wed, 24 Jun 2009 06:48:52 +0800 Subject: [PATCH] Support OMAP3 VC adaptation with different Power IC Current OMAP SmartReflex driver only supports TI Triton Power IC, add a callback to make it possible to use different PowerIC and use different settings to configure OMAP3 Voltage Controller for DVFS Board file can setup a new function to have different settings on SR to configure their Power IC for voltage scaling Signed-off-by: Chunqiu Wang cqw...@motorola.com Your patch seems wrapped again: checkpatch reports: ERROR: patch seems to be corrupt (line wrapped?) #38: FILE: arch/arm/mach-omap2/smartreflex.c:57: u32 value) ERROR: trailing whitespace #95: FILE: arch/arm/mach-omap2/smartreflex.h:252: +^I^I^I^I^I^Iu8 t_vsel, u8 c_vsel); $ total: 2 errors, 0 warnings, 71 lines checked Sorry about that, this time I attached these two patch files. Can you please fix your mailer setup so you can resend patches inline and get a broader review. I suggest bypassing any mailer such as outlook and configuring git-send-email to send them directly to an SMTP server. If your local SMTP is really that broken to be wrapping text, I suggest you send via a gmail account. This link describes how to set this up for gmail, but also works for a local SMTP server. http://git.or.cz/gitwiki/GitTips#Mail 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 1/2] Support OMAP3 VC adaptation with different Power IC
Can you please fix your mailer setup so you can resend patches inline and get a broader review. I suggest bypassing any mailer such as outlook and configuring git-send-email to send them directly to an SMTP server. If your local SMTP is really that broken to be wrapping text, I suggest you send via a gmail account. This link describes how to set this up for gmail, but also works for a local SMTP server. http://git.or.cz/gitwiki/GitTips#Mail Kevin Thanks Kevin, sure I will resend them. Thanks, Chunqiu -- 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/2] Support OMAP3 VC adaptation with different Power IC
On Thu, Jun 25, 2009 at 1:12 PM, Wang Sawsd-A24013cqw...@motorola.com wrote:
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9d462e3..bacf602 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -52,6 +52,8 @@ struct omap_sr {
#define SR_REGADDR(offs) (sr-srbase_addr + offset)
+static omap3_voltagescale_vcbypass_t omap3_volscale_vcbypass_fun;
Perhaps use
static int (*omap3_volscale_vcbypass_fun) (u32, u32, u8, u8);
This gets rid of the compiler warning on incompatible pointer
types when
you register a function via omap3_voltagescale_vcbypass_setup().
-- Mike
Thanks Mike, but we do not see the warnning with the original
Code, note this patch is slightly different with the one we sent
To you based on K29, this new patch have four parameters
Sinc some change has been made in the
sr_voltagescale_vcbypass to add two more parameters.
Is your warnning caused by this?
This patch stand-alone doesn't give me any warnings. Its only when you
hook into this from your board file. Might be the compiler I'm using.
I used this patch + modified version of the patches you sent me before
to get the two working. (Yes, 4 params).
I just verified the change on both current linux-omap pm branch and
The branch we are using, neither of them reports any warnning.
Just reminder, the patch I sent to you are different in all these files,
Since we should use 2 params in our kernel, the patch I sent to
This list has 4 params. Please check whether the warnning
Is caused by the mismatch in the function declaration and
The function definition in the board file.
It should not cause the warning even you are using different
Compiler.
Ah you're right, I must have done something wrong on my side. It was
probably the 2 vs 4 params.
-- Mike
-- MIke
Thanks,
Chunqiu
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] driver updates from PM branch for upstream
This is a series of driver patches (i2c, SPI) from the PM branch that are ready to go upstream via the sybsystem lists. Here's one more review pass before I send them to their respective lists. Applies to current Linus' tree or 'omap-fixes' branch of linux-omap. Kevin Hemanth V (1): OMAP3 McSPI: Adds context save/restore Jouni Hogander (2): OMAP: McSPI: enable wake-ups and smart-idle OMAP: McSPI: Convert bit shifted values into BIT format Rajendra Nayak (1): I2C: OMAP3: PM: (re)init for every transfer to support off-mode drivers/i2c/busses/i2c-omap.c | 59 +- drivers/spi/omap2_mcspi.c | 179 + 2 files changed, 165 insertions(+), 73 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] OMAP: McSPI: enable wake-ups and smart-idle
From: Jouni Hogander jouni.hogan...@nokia.com
By default, enable module wakeups and put module in smart-idle.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/spi/omap2_mcspi.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index eee4b6e..2b64091 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -59,6 +59,8 @@
/* per-register bitmasks: */
+#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLE(2 3)
+#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUP(1 2)
#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 0)
#define OMAP2_MCSPI_SYSCONFIG_SOFTRESET(1 1)
@@ -90,6 +92,7 @@
#define OMAP2_MCSPI_CHCTRL_EN (1 0)
+#define OMAP2_MCSPI_WAKEUPENABLE_WKEN (1 0)
/* We have 2 DMA channels per CS, one for RX and one for TX */
struct omap2_mcspi_dma {
@@ -873,8 +876,12 @@ static int __init omap2_mcspi_reset(struct omap2_mcspi
*mcspi)
} while (!(tmp OMAP2_MCSPI_SYSSTATUS_RESETDONE));
mcspi_write_reg(master, OMAP2_MCSPI_SYSCONFIG,
- /* (3 8) | (2 3) | */
- OMAP2_MCSPI_SYSCONFIG_AUTOIDLE);
+ OMAP2_MCSPI_SYSCONFIG_AUTOIDLE |
+ OMAP2_MCSPI_SYSCONFIG_ENAWAKEUP |
+ OMAP2_MCSPI_SYSCONFIG_SMARTIDLE);
+
+ mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE,
+ OMAP2_MCSPI_WAKEUPENABLE_WKEN);
omap2_mcspi_set_master_mode(master);
--
1.6.3.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 2/4] OMAP: McSPI: Convert bit shifted values into BIT format
From: Jouni Hogander jouni.hogan...@nokia.com
Convert bit shifted values into BIT format
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/spi/omap2_mcspi.c | 50 ++--
1 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2b64091..0016078 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -59,40 +59,40 @@
/* per-register bitmasks: */
-#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLE(2 3)
-#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUP(1 2)
-#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 0)
-#define OMAP2_MCSPI_SYSCONFIG_SOFTRESET(1 1)
+#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLEBIT(4)
+#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUPBIT(2)
+#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE BIT(0)
+#define OMAP2_MCSPI_SYSCONFIG_SOFTRESETBIT(1)
-#define OMAP2_MCSPI_SYSSTATUS_RESETDONE(1 0)
+#define OMAP2_MCSPI_SYSSTATUS_RESETDONEBIT(0)
-#define OMAP2_MCSPI_MODULCTRL_SINGLE (1 0)
-#define OMAP2_MCSPI_MODULCTRL_MS (1 2)
-#define OMAP2_MCSPI_MODULCTRL_STEST(1 3)
+#define OMAP2_MCSPI_MODULCTRL_SINGLE BIT(0)
+#define OMAP2_MCSPI_MODULCTRL_MS BIT(2)
+#define OMAP2_MCSPI_MODULCTRL_STESTBIT(3)
-#define OMAP2_MCSPI_CHCONF_PHA (1 0)
-#define OMAP2_MCSPI_CHCONF_POL (1 1)
+#define OMAP2_MCSPI_CHCONF_PHA BIT(0)
+#define OMAP2_MCSPI_CHCONF_POL BIT(1)
#define OMAP2_MCSPI_CHCONF_CLKD_MASK (0x0f 2)
-#define OMAP2_MCSPI_CHCONF_EPOL(1 6)
+#define OMAP2_MCSPI_CHCONF_EPOLBIT(6)
#define OMAP2_MCSPI_CHCONF_WL_MASK (0x1f 7)
-#define OMAP2_MCSPI_CHCONF_TRM_RX_ONLY (0x01 12)
-#define OMAP2_MCSPI_CHCONF_TRM_TX_ONLY (0x02 12)
+#define OMAP2_MCSPI_CHCONF_TRM_RX_ONLY BIT(12)
+#define OMAP2_MCSPI_CHCONF_TRM_TX_ONLY BIT(13)
#define OMAP2_MCSPI_CHCONF_TRM_MASK(0x03 12)
-#define OMAP2_MCSPI_CHCONF_DMAW(1 14)
-#define OMAP2_MCSPI_CHCONF_DMAR(1 15)
-#define OMAP2_MCSPI_CHCONF_DPE0(1 16)
-#define OMAP2_MCSPI_CHCONF_DPE1(1 17)
-#define OMAP2_MCSPI_CHCONF_IS (1 18)
-#define OMAP2_MCSPI_CHCONF_TURBO (1 19)
-#define OMAP2_MCSPI_CHCONF_FORCE (1 20)
+#define OMAP2_MCSPI_CHCONF_DMAWBIT(14)
+#define OMAP2_MCSPI_CHCONF_DMARBIT(15)
+#define OMAP2_MCSPI_CHCONF_DPE0BIT(16)
+#define OMAP2_MCSPI_CHCONF_DPE1BIT(17)
+#define OMAP2_MCSPI_CHCONF_IS BIT(18)
+#define OMAP2_MCSPI_CHCONF_TURBO BIT(19)
+#define OMAP2_MCSPI_CHCONF_FORCE BIT(20)
-#define OMAP2_MCSPI_CHSTAT_RXS (1 0)
-#define OMAP2_MCSPI_CHSTAT_TXS (1 1)
-#define OMAP2_MCSPI_CHSTAT_EOT (1 2)
+#define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
+#define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
+#define OMAP2_MCSPI_CHSTAT_EOT BIT(2)
-#define OMAP2_MCSPI_CHCTRL_EN (1 0)
+#define OMAP2_MCSPI_CHCTRL_EN BIT(0)
-#define OMAP2_MCSPI_WAKEUPENABLE_WKEN (1 0)
+#define OMAP2_MCSPI_WAKEUPENABLE_WKEN BIT(0)
/* We have 2 DMA channels per CS, one for RX and one for TX */
struct omap2_mcspi_dma {
--
1.6.3.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 3/4] OMAP3 McSPI: Adds context save/restore
From: Hemanth V heman...@ti.com
This patch adds context save/restore feature to McSPI driver.
This includes fixes by Aaro Koskinen
Signed-off-by: Hemanth V heman...@ti.com
Reviewed-by: Aaro Koskinen aaro.koski...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/spi/omap2_mcspi.c | 134 +---
1 files changed, 100 insertions(+), 34 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 0016078..5240c01 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -41,6 +41,9 @@
#define OMAP2_MCSPI_MAX_FREQ 4800
+/* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */
+#define OMAP2_MCSPI_MAX_CTRL 4
+
#define OMAP2_MCSPI_REVISION 0x00
#define OMAP2_MCSPI_SYSCONFIG 0x10
#define OMAP2_MCSPI_SYSSTATUS 0x14
@@ -131,8 +134,21 @@ struct omap2_mcspi_cs {
void __iomem*base;
unsigned long phys;
int word_len;
+ /* Context save and restore shadow register */
+ u32 chconf0;
+};
+
+/* used for context save and restore, structure members to be updated whenever
+ * corresponding registers are modified.
+ */
+struct omap2_mcspi_regs {
+ u32 sysconfig;
+ u32 modulctrl;
+ u32 wakeupenable;
};
+static struct omap2_mcspi_regs omap2_mcspi_ctx[OMAP2_MCSPI_MAX_CTRL];
+
static struct workqueue_struct *omap2_mcspi_wq;
#define MOD_REG_BIT(val, mask, set) do { \
@@ -172,12 +188,27 @@ static inline u32 mcspi_read_cs_reg(const struct
spi_device *spi, int idx)
return __raw_readl(cs-base + idx);
}
+static inline u32 mcspi_cached_chconf0(const struct spi_device *spi)
+{
+ struct omap2_mcspi_cs *cs = spi-controller_state;
+
+ return cs-chconf0;
+}
+
+static inline void mcspi_write_chconf0(const struct spi_device *spi, u32 val)
+{
+ struct omap2_mcspi_cs *cs = spi-controller_state;
+
+ cs-chconf0 = val;
+ mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, val);
+}
+
static void omap2_mcspi_set_dma_req(const struct spi_device *spi,
int is_read, int enable)
{
u32 l, rw;
- l = mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHCONF0);
+ l = mcspi_cached_chconf0(spi);
if (is_read) /* 1 is read, 0 write */
rw = OMAP2_MCSPI_CHCONF_DMAR;
@@ -185,7 +216,7 @@ static void omap2_mcspi_set_dma_req(const struct spi_device
*spi,
rw = OMAP2_MCSPI_CHCONF_DMAW;
MOD_REG_BIT(l, rw, enable);
- mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, l);
+ mcspi_write_chconf0(spi, l);
}
static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
@@ -200,9 +231,9 @@ static void omap2_mcspi_force_cs(struct spi_device *spi,
int cs_active)
{
u32 l;
- l = mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHCONF0);
+ l = mcspi_cached_chconf0(spi);
MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
- mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, l);
+ mcspi_write_chconf0(spi, l);
}
static void omap2_mcspi_set_master_mode(struct spi_master *master)
@@ -217,6 +248,41 @@ static void omap2_mcspi_set_master_mode(struct spi_master
*master)
MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_MS, 0);
MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_SINGLE, 1);
mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
+
+ omap2_mcspi_ctx[master-bus_num - 1].modulctrl = l;
+}
+
+static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
+{
+ struct spi_master *spi_cntrl;
+ spi_cntrl = mcspi-master;
+
+ /* McSPI: context restore */
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
+
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].sysconfig);
+
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
+}
+static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
+{
+ clk_disable(mcspi-ick);
+ clk_disable(mcspi-fck);
+}
+
+static int omap2_mcspi_enable_clocks(struct omap2_mcspi *mcspi)
+{
+ if (clk_enable(mcspi-ick))
+ return -ENODEV;
+ if (clk_enable(mcspi-fck))
+ return -ENODEV;
+
+ omap2_mcspi_restore_ctx(mcspi);
+
+ return 0;
}
static unsigned
@@ -338,7 +404,7 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
c = count;
word_len = cs-word_len;
- l = mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHCONF0);
+ l = mcspi_cached_chconf0(spi);
l = ~OMAP2_MCSPI_CHCONF_TRM_MASK;
/* We store the pre-calculated register addresses on stack to speed
@@ -378,8 +444,7 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
[PATCH 4/4] I2C: OMAP3: PM: (re)init for every transfer to support off-mode
From: Rajendra Nayak rna...@ti.com
Because of OMAP off-mode, powerdomain can go off when I2C is idle.
Save enough state, and do a re-init for each transfer.
Additional save/restore state added by Jagadeesh Bhaskar Pakaravoor
(SYSC_REG) and Aaro Koskinen (wakeup sources.)
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/i2c/busses/i2c-omap.c | 59 +++--
1 files changed, 39 insertions(+), 20 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ad8d201..0a5d871 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -178,6 +178,12 @@ struct omap_i2c_dev {
unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
+ u16 pscstate;
+ u16 scllstate;
+ u16 sclhstate;
+ u16 bufstate;
+ u16 syscstate;
+ u16 westate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -230,9 +236,16 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
clk_enable(dev-iclk);
clk_enable(dev-fclk);
+ if (cpu_is_omap34xx()) {
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ }
dev-idle = 0;
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
@@ -258,7 +271,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -289,21 +302,22 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
} else if (dev-rev = OMAP_I2C_REV_ON_3430) {
u32 v;
- v = SYSC_AUTOIDLE_MASK;
- v |= SYSC_ENAWAKEUP_MASK;
- v |= (SYSC_IDLEMODE_SMART
+ dev-syscstate = SYSC_AUTOIDLE_MASK;
+ dev-syscstate |= SYSC_ENAWAKEUP_MASK;
+ dev-syscstate |= (SYSC_IDLEMODE_SMART
__ffs(SYSC_SIDLEMODE_MASK));
- v |= (SYSC_CLOCKACTIVITY_FCLK
+ dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
__ffs(SYSC_CLOCKACTIVITY_MASK));
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
+ dev-syscstate);
/*
* Enabling all wakup sources to stop I2C freezing on
* WFI instruction.
* REVISIT: Some wkup sources might not be needed.
*/
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- OMAP_I2C_WE_ALL);
+ dev-westate = OMAP_I2C_WE_ALL;
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
}
}
@@ -394,23 +408,28 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
- if (dev-fifo_size)
- /* Note: setup required fifo size - 1 */
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG,
- (dev-fifo_size - 1) 8 | /* RTRSH */
- OMAP_I2C_BUF_RXFIF_CLR |
- (dev-fifo_size - 1) | /* XTRSH */
- OMAP_I2C_BUF_TXFIF_CLR);
+ if (dev-fifo_size) {
+ /* Note: setup required fifo size - 1. RTRSH and XTRSH */
+ buf = (dev-fifo_size - 1) 8 | OMAP_I2C_BUF_RXFIF_CLR |
+ (dev-fifo_size - 1) | OMAP_I2C_BUF_TXFIF_CLR;
+
[PATCH 2/2] OMAP3: omap3evm: undo ehci change to board-omap3evm.c
Call to omap3evm_flash_init() mistakenly added by EHCI patch. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/board-omap3evm.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c index 1b7a797..595beac 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -309,7 +309,6 @@ static void __init omap3_evm_init(void) omap_serial_init(); usb_musb_init(); usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61); - omap3evm_flash_init(); ads7846_dev_init(); } -- 1.6.3.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 0/2] fixup merge mistakes in l-o master
Here's a couple patches to undo some merge mistakes and fixup l-o master so patches apply to l-o master and upstream. Kevin Hilman (2): OMAP3: Kconfig: remove duplicate board entries OMAP3: omap3evm: undo ehci change to board-omap3evm.c arch/arm/mach-omap2/Kconfig | 12 arch/arm/mach-omap2/board-omap3evm.c |1 - 2 files changed, 0 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
v4l2_int_device vs v4l2_subdev?
Still trying to wrap my head around the OMAP/34xx camera support. I need to use the TVP5150 sensor/controller, but the existing driver uses v4l_subdev. The working examples I've found (from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device Are these two totally separate beasts? If I have an infrastructure (I assume) based on v4l2_int_device, how do I use a v4l2_subdev device driver? or need I move one to the other? ... dizzy from traveling down too many twisty little passages :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 v2 0/3] OMAP2/3 clock: fix module IDLEST code for unusual devs
Hello, After Linux enables an OMAP device's clocks, it must wait for the device to leave the 'idle' state, or register accesses may result in an interconnect error and subsequent system crash. Code to do this is currently in the OMAP clock code, but is overgeneralized, and will not work correctly for several exception cases - one on 2430, and four on OMAP3. This series fixes these bugs by modularizing omap2_clk_wait_ready(), allowing custom CM_IDLEST register and bit shift data to be supplied on a per-clock basis, if necessary. (This was originally fixed in the linux-omap kernel during 2.6.29 in a slightly different manner.) In the medium term, the module wait code will be moved to omap_hwmod or a similar OMAP device layer. Tested on BeagleBoard rev C2 (OMAP3530 ES3); compile-tested with the N800 defconfig. This second version fills in the clock.c documentation and removes one of the custom find_idlest functions (since DSS and USBHOST use the same target IDLEST shift). - Paul --- size: textdata bss dec hex filename 3405015 191408 103632 3700055 387557 vmlinux.beagle.orig 3405475 192144 103632 3701251 387a03 vmlinux.beagle Paul Walmsley (3): OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB OMAP2 clock: 2430 I2CHS uses non-standard CM_IDLEST register OMAP2/3 clock: split, rename omap2_wait_clock_ready() arch/arm/mach-omap2/clock.c | 156 --- arch/arm/mach-omap2/clock.h |6 + arch/arm/mach-omap2/clock24xx.c | 37 +++ arch/arm/mach-omap2/clock24xx.h |4 - arch/arm/mach-omap2/clock34xx.c | 118 ++- arch/arm/mach-omap2/clock34xx.h | 85 +++-- arch/arm/mach-omap2/prcm.c | 43 + arch/arm/plat-omap/include/mach/clock.h |2 arch/arm/plat-omap/include/mach/prcm.h |1 9 files changed, 353 insertions(+), 99 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] OMAP2 clock: 2430 I2CHS uses non-standard CM_IDLEST register
OMAP2430 I2CHS CM_IDLEST bits are in CM_IDLEST1_CORE, but the CM_*CLKEN bits
are in CM_{I,F}CLKEN2_CORE [1]. Fix by implementing a custom clkops
.find_idlest function to return the correct slave IDLEST register.
...
1. OMAP2430 Multimedia Device Package-on-Package (POP) Silicon Revision 2.1
(Rev. V) Technical Reference Manual, tables 4-99 and 4-105.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock24xx.c | 37 +++--
arch/arm/mach-omap2/clock24xx.h |4 ++--
2 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 44de027..bc5d3ac 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -30,6 +30,7 @@
#include mach/clock.h
#include mach/sram.h
+#include mach/prcm.h
#include asm/div64.h
#include asm/clkdev.h
@@ -43,6 +44,18 @@
static const struct clkops clkops_oscck;
static const struct clkops clkops_fixed;
+static void omap2430_clk_i2chs_find_idlest(struct clk *clk,
+ void __iomem **idlest_reg,
+ u8 *idlest_bit);
+
+/* 2430 I2CHS has non-standard IDLEST register */
+static const struct clkops clkops_omap2430_i2chs_wait = {
+ .enable = omap2_dflt_clk_enable,
+ .disable= omap2_dflt_clk_disable,
+ .find_idlest= omap2430_clk_i2chs_find_idlest,
+ .find_companion = omap2_clk_dflt_find_companion,
+};
+
#include clock24xx.h
struct omap_clk {
@@ -240,6 +253,26 @@ static void __iomem *prcm_clksrc_ctrl;
*-*/
/**
+ * omap2430_clk_i2chs_find_idlest - return CM_IDLEST info for 2430 I2CHS
+ * @clk: struct clk * being enabled
+ * @idlest_reg: void __iomem ** to store CM_IDLEST reg address into
+ * @idlest_bit: pointer to a u8 to store the CM_IDLEST bit shift into
+ *
+ * OMAP2430 I2CHS CM_IDLEST bits are in CM_IDLEST1_CORE, but the
+ * CM_*CLKEN bits are in CM_{I,F}CLKEN2_CORE. This custom function
+ * passes back the correct CM_IDLEST register address for I2CHS
+ * modules. No return value.
+ */
+static void omap2430_clk_i2chs_find_idlest(struct clk *clk,
+ void __iomem **idlest_reg,
+ u8 *idlest_bit)
+{
+ *idlest_reg = OMAP_CM_REGADDR(CORE_MOD, CM_IDLEST);
+ *idlest_bit = clk-enable_bit;
+}
+
+
+/**
* omap2xxx_clk_get_core_rate - return the CORE_CLK rate
* @clk: pointer to the combined dpll_ck + core_ck (currently dpll_ck)
*
@@ -325,8 +358,8 @@ static int omap2_clk_fixed_enable(struct clk *clk)
else if (clk == apll54_ck)
cval = OMAP24XX_ST_54M_APLL;
- omap2_wait_clock_ready(OMAP_CM_REGADDR(PLL_MOD, CM_IDLEST), cval,
- clk-name);
+ omap2_cm_wait_idlest(OMAP_CM_REGADDR(PLL_MOD, CM_IDLEST), cval,
+clk-name);
/*
* REVISIT: Should we return an error code if omap2_wait_clock_ready()
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index 458f00c..d19cf7a 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -2337,7 +2337,7 @@ static struct clk i2c2_fck = {
static struct clk i2chs2_fck = {
.name = i2c_fck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2430_i2chs_wait,
.id = 2,
.parent = func_96m_ck,
.clkdm_name = core_l4_clkdm,
@@ -2370,7 +2370,7 @@ static struct clk i2c1_fck = {
static struct clk i2chs1_fck = {
.name = i2c_fck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2430_i2chs_wait,
.id = 1,
.parent = func_96m_ck,
.clkdm_name = core_l4_clkdm,
--
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 v2 1/3] OMAP2/3 clock: split, rename omap2_wait_clock_ready()
Some OMAP2/3 hardware modules have CM_IDLEST attributes that are not
handled by the current omap2_wait_clock_ready() code. In preparation
for patches that fix the unusual devices, rename the function
omap2_wait_clock_ready() to omap2_wait_module_ready() and split it
into three parts:
1. A clkops-specific companion clock return function (by default,
omap2_clk_dflt_find_companion())
2. A clkops-specific CM_IDLEST register address and bit shift return
function (by default, omap2_clk_dflt_find_idlest())
3. Code to wait for the CM to indicate that the module is ready
(omap2_cm_wait_idlest())
Clocks can now specify their own custom find_companion() and find_idlest()
functions; used in subsequent patches.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock.c | 156 ---
arch/arm/mach-omap2/clock.h |6 +
arch/arm/mach-omap2/prcm.c | 43 +
arch/arm/plat-omap/include/mach/clock.h |2
arch/arm/plat-omap/include/mach/prcm.h |1
5 files changed, 131 insertions(+), 77 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index b0665f1..456e2ad 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -27,6 +27,7 @@
#include mach/clock.h
#include mach/clockdomain.h
#include mach/cpu.h
+#include mach/prcm.h
#include asm/div64.h
#include mach/sdrc.h
@@ -38,8 +39,6 @@
#include cm-regbits-24xx.h
#include cm-regbits-34xx.h
-#define MAX_CLOCK_ENABLE_WAIT 10
-
/* DPLL rate rounding: minimum DPLL multiplier, divider values */
#define DPLL_MIN_MULTIPLIER1
#define DPLL_MIN_DIVIDER 1
@@ -274,83 +273,97 @@ unsigned long omap2_fixed_divisor_recalc(struct clk *clk)
}
/**
- * omap2_wait_clock_ready - wait for clock to enable
- * @reg: physical address of clock IDLEST register
- * @mask: value to mask against to determine if the clock is active
- * @name: name of the clock (for printk)
+ * omap2_clk_dflt_find_companion - find companion clock to @clk
+ * @clk: struct clk * to find the companion clock of
+ * @other_reg: void __iomem ** to return the companion clock CM_*CLKEN va in
+ * @other_bit: u8 ** to return the companion clock bit shift in
+ *
+ * Note: We don't need special code here for INVERT_ENABLE for the
+ * time being since INVERT_ENABLE only applies to clocks enabled by
+ * CM_CLKEN_PLL
*
- * Returns 1 if the clock enabled in time, or 0 if it failed to enable
- * in roughly MAX_CLOCK_ENABLE_WAIT microseconds.
+ * Convert CM_ICLKEN* - CM_FCLKEN*. This conversion assumes it's
+ * just a matter of XORing the bits.
+ *
+ * Some clocks don't have companion clocks. For example, modules with
+ * only an interface clock (such as MAILBOXES) don't have a companion
+ * clock. Right now, this code relies on the hardware exporting a bit
+ * in the correct companion register that indicates that the
+ * nonexistent 'companion clock' is active. Future patches will
+ * associate this type of code with per-module data structures to
+ * avoid this issue, and remove the casts. No return value.
*/
-int omap2_wait_clock_ready(void __iomem *reg, u32 mask, const char *name)
+void omap2_clk_dflt_find_companion(struct clk *clk, void __iomem **other_reg,
+ u8 *other_bit)
{
- int i = 0;
- int ena = 0;
+ u32 r;
/*
-* 24xx uses 0 to indicate not ready, and 1 to indicate ready.
-* 34xx reverses this, just to keep us on our toes
+* Convert CM_ICLKEN* - CM_FCLKEN*. This conversion assumes
+* it's just a matter of XORing the bits.
*/
- if (cpu_mask (RATE_IN_242X | RATE_IN_243X))
- ena = mask;
- else if (cpu_mask RATE_IN_343X)
- ena = 0;
-
- /* Wait for lock */
- while (((__raw_readl(reg) mask) != ena)
- (i++ MAX_CLOCK_ENABLE_WAIT)) {
- udelay(1);
- }
-
- if (i = MAX_CLOCK_ENABLE_WAIT)
- pr_debug(Clock %s stable after %d loops\n, name, i);
- else
- printk(KERN_ERR Clock %s didn't enable in %d tries\n,
- name, MAX_CLOCK_ENABLE_WAIT);
-
-
- return (i MAX_CLOCK_ENABLE_WAIT) ? 1 : 0;
-};
+ r = ((__force u32)clk-enable_reg ^ (CM_FCLKEN ^ CM_ICLKEN));
+ *other_reg = (__force void __iomem *)r;
+ *other_bit = clk-enable_bit;
+}
-/*
- * Note: We don't need special code here for INVERT_ENABLE
- * for the time being since INVERT_ENABLE only applies to clocks enabled by
- * CM_CLKEN_PLL
+/**
+ * omap2_clk_dflt_find_idlest - find CM_IDLEST reg va, bit shift for @clk
+ * @clk: struct clk * to find IDLEST info for
+ * @idlest_reg: void __iomem ** to return the CM_IDLEST va in
+ * @idlest_bit: u8 ** to return the CM_IDLEST bit shift in
+ *
+ * Return the CM_IDLEST register address and bit shift corresponding
+ * to the module that owns this clock. This
[PATCH v2 3/3] OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices. These devices are both interconnect
initiators and targets. Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
Clock usbhost_48m_fck didn't enable in 10 tries
Two bugs are fixed by this patch. First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond. ES1 chips
should not wait for these clocks to enable. So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks. It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1]. Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula jhnik...@gmail.com:
http://marc.info/?l=linux-omapm=124306184903679w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/clock34xx.c | 118 +--
arch/arm/mach-omap2/clock34xx.h | 85
2 files changed, 185 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 045da92..97907c6 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -2,7 +2,7 @@
* OMAP3-specific clock framework functions
*
* Copyright (C) 2007-2008 Texas Instruments, Inc.
- * Copyright (C) 2007-2008 Nokia Corporation
+ * Copyright (C) 2007-2009 Nokia Corporation
*
* Written by Paul Walmsley
* Testing and integration fixes by Jouni Högander
@@ -41,6 +41,37 @@
static const struct clkops clkops_noncore_dpll_ops;
+static void omap3430es2_clk_ssi_find_idlest(struct clk *clk,
+ void __iomem **idlest_reg,
+ u8 *idlest_bit);
+static void omap3430es2_clk_hsotgusb_find_idlest(struct clk *clk,
+ void __iomem **idlest_reg,
+ u8 *idlest_bit);
+static void omap3430es2_clk_dss_usbhost_find_idlest(struct clk *clk,
+ void __iomem **idlest_reg,
+ u8 *idlest_bit);
+
+static const struct clkops clkops_omap3430es2_ssi_wait = {
+ .enable = omap2_dflt_clk_enable,
+ .disable= omap2_dflt_clk_disable,
+ .find_idlest= omap3430es2_clk_ssi_find_idlest,
+ .find_companion = omap2_clk_dflt_find_companion,
+};
+
+static const struct clkops clkops_omap3430es2_hsotgusb_wait = {
+ .enable = omap2_dflt_clk_enable,
+ .disable= omap2_dflt_clk_disable,
+ .find_idlest= omap3430es2_clk_hsotgusb_find_idlest,
+ .find_companion = omap2_clk_dflt_find_companion,
+};
+
+static const struct clkops clkops_omap3430es2_dss_usbhost_wait = {
+ .enable = omap2_dflt_clk_enable,
+ .disable= omap2_dflt_clk_disable,
+ .find_idlest= omap3430es2_clk_dss_usbhost_find_idlest,
+ .find_companion = omap2_clk_dflt_find_companion,
+};
+
#include clock34xx.h
struct omap_clk {
@@ -157,10 +188,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, fshostusb_fck, fshostusb_fck, CK_3430ES1),
CLK(NULL, core_12m_fck, core_12m_fck, CK_343X),
CLK(omap_hdq.0, fck,hdq_fck, CK_343X),
- CLK(NULL, ssi_ssr_fck, ssi_ssr_fck, CK_343X),
- CLK(NULL, ssi_sst_fck, ssi_sst_fck, CK_343X),
+ CLK(NULL, ssi_ssr_fck, ssi_ssr_fck_3430es1, CK_3430ES1),
+ CLK(NULL, ssi_ssr_fck, ssi_ssr_fck_3430es2, CK_3430ES2),
+ CLK(NULL, ssi_sst_fck, ssi_sst_fck_3430es1, CK_3430ES1),
+ CLK(NULL, ssi_sst_fck, ssi_sst_fck_3430es2, CK_3430ES2),
CLK(NULL, core_l3_ick, core_l3_ick, CK_343X),
- CLK(musb_hdrc,ick, hsotgusb_ick, CK_343X),
+ CLK(musb_hdrc,ick, hsotgusb_ick_3430es1, CK_3430ES1),
+ CLK(musb_hdrc,ick, hsotgusb_ick_3430es2, CK_3430ES2),
CLK(NULL, sdrc_ick, sdrc_ick, CK_343X),
CLK(NULL, gpmc_fck, gpmc_fck,
[PATCH 1/2] Support OMAP3 VC adaptation with different Power IC
From c1aba8ba7af3ddd16346d95795bda71e65baa4d0 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Wed, 24 Jun 2009 06:48:52 +0800
Subject: [PATCH] Support OMAP3 VC adaptation with different Power IC
Current OMAP SmartReflex driver only supports TI Triton
Power IC, add a callback to make it possible to use
different PowerIC and use different settings to
configure OMAP3 Voltage Controller for DVFS
Board file can setup a new function to have different settings
on SR to configure their Power IC for voltage scaling
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/mach-omap2/smartreflex.c | 13 +
arch/arm/mach-omap2/smartreflex.h |4
arch/arm/plat-omap/Kconfig|2 +-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9d462e3..bacf602 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -52,6 +52,8 @@ struct omap_sr {
#define SR_REGADDR(offs) (sr-srbase_addr + offset)
+static omap3_voltagescale_vcbypass_t omap3_volscale_vcbypass_fun;
+
static inline void sr_write_reg(struct omap_sr *sr, unsigned offset, u32 value)
{
__raw_writel(value, SR_REGADDR(offset));
@@ -767,6 +769,11 @@ void disable_smartreflex(int srid)
}
}
+void omap3_voltagescale_vcbypass_setup(omap3_voltagescale_vcbypass_t fun)
+{
+ omap3_volscale_vcbypass_fun = fun;
+}
+
/* Voltage Scaling using SR VCBYPASS */
int sr_voltagescale_vcbypass(u32 target_opp, u32 current_opp,
u8 target_vsel, u8 current_vsel)
@@ -779,6 +786,10 @@ int sr_voltagescale_vcbypass(u32 target_opp, u32
current_opp,
u32 t2_smps_steps = 0;
u32 t2_smps_delay = 0;
+ if (omap3_volscale_vcbypass_fun)
+ return omap3_volscale_vcbypass_fun(target_opp, current_opp,
+ target_vsel, current_vsel);
+
vdd = get_vdd(target_opp);
target_opp_no = get_opp_no(target_opp);
current_opp_no = get_opp_no(current_opp);
@@ -940,6 +951,7 @@ static int __init omap3_sr_init(void)
return -ENODEV;
}
+#ifdef CONFIG_TWL4030_CORE
/* Enable SR on T2 */
ret = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, RdReg,
R_DCDC_GLOBAL_CFG);
@@ -947,6 +959,7 @@ static int __init omap3_sr_init(void)
RdReg |= DCDC_GLOBAL_CFG_ENABLE_SRFLX;
ret |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, RdReg,
R_DCDC_GLOBAL_CFG);
+#endif
if (cpu_is_omap34xx()) {
sr1.clk = clk_get(NULL, sr1_fck);
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 2a0e823..c4aca9d 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -248,9 +248,13 @@ void disable_smartreflex(int srid);
int sr_voltagescale_vcbypass(u32 t_opp, u32 c_opp, u8 t_vsel, u8 c_vsel);
void sr_start_vddautocomap(int srid, u32 target_opp_no);
int sr_stop_vddautocomap(int srid);
+typedef int (*omap3_voltagescale_vcbypass_t)(u32 t_opp, u32 c_opp,
+ u8 t_vsel, u8 c_vsel);
+void omap3_voltagescale_vcbypass_setup(omap3_voltagescale_vcbypass_t fun);
#else
static inline void enable_smartreflex(int srid) {}
static inline void disable_smartreflex(int srid) {}
+#define omap3_voltagescale_vcbypass_setup(fun) do {} while (0);
#endif
#endif
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index c8ba1e2..8d2c607 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -68,7 +68,7 @@ config OMAP_DEBUG_CLOCKDOMAIN
config OMAP_SMARTREFLEX
bool SmartReflex support
- depends on ARCH_OMAP34XX TWL4030_CORE PM
+ depends on ARCH_OMAP34XX PM
help
Say Y if you want to enable SmartReflex.
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP3: Implement separate function to send bypass command through VC
From 803cbdcd8df3d6f931089979c2dbad8942512cb4 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Wed, 24 Jun 2009 07:57:17 +0800
Subject: [PATCH] OMAP3: Implement separate function to send bypass
command through VC
Some system may need use OMAP VC to configure their Power IC,
so make the common code to send bypass command using SR VC
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 36 ++
arch/arm/mach-omap2/smartreflex.c | 59 +++-
3 files changed, 42 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index ddc9453..fa118cd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -44,6 +44,7 @@ extern int set_pwrdm_state(struct powerdomain
*pwrdm, u32 state);
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
extern void omap3_set_prm_setup_vc(struct prm_setup_vc *setup_vc);
+extern int omap3_vc_bypass_cmd(u8 slave_addr, u8 reg_addr, u8 cmd);
#ifdef CONFIG_CPU_IDLE
int omap3_idle_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7a4a525..85b0944 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -26,6 +26,7 @@
#include linux/err.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/delay.h
#include mach/sram.h
#include mach/prcm.h
@@ -1135,6 +1136,41 @@ err2:
return ret;
}
+/* Program Power IC via OMAP3 voltage controller bypass interface */
+int omap3_vc_bypass_cmd(u8 slave_addr, u8 reg_addr, u8 cmd)
+{
+ u32 vc_bypass_value;
+ u32 loop_cnt = 0, retries_cnt = 0;
+
+ vc_bypass_value = (cmd OMAP3430_DATA_SHIFT) |
+ (reg_addr OMAP3430_REGADDR_SHIFT) |
+ (slave_addr OMAP3430_SLAVEADDR_SHIFT);
+
+ prm_write_mod_reg(vc_bypass_value, OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ vc_bypass_value = prm_set_mod_reg_bits(OMAP3430_VALID, OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ while ((vc_bypass_value OMAP3430_VALID) != 0x0) {
+ loop_cnt++;
+ if (retries_cnt 10) {
+ printk(KERN_ERRLoop count exceeded in check SR I2C
+ write\n);
+ return 1;
+ }
+ if (loop_cnt 50) {
+ retries_cnt++;
+ loop_cnt = 0;
+ udelay(10);
+ }
+ vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+ }
+
+ return 0;
+}
+
static void __init configure_vc(void)
{
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index bacf602..2158b5c 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -35,6 +35,7 @@
#include prm.h
#include smartreflex.h
#include prm-regbits-34xx.h
+#include pm.h
struct omap_sr {
int srid;
@@ -449,8 +450,6 @@ static int sr_reset_voltage(int srid)
{
u32 target_opp_no, vsel = 0;
u32 reg_addr = 0;
- u32 loop_cnt = 0, retries_cnt = 0;
- u32 vc_bypass_value;
u32 t2_smps_steps = 0;
u32 t2_smps_delay = 0;
u32 prm_vp1_voltage, prm_vp2_voltage;
@@ -479,31 +478,8 @@ static int sr_reset_voltage(int srid)
t2_smps_steps = abs(vsel - prm_vp2_voltage);
}
- vc_bypass_value = (vsel OMAP3430_DATA_SHIFT) |
- (reg_addr OMAP3430_REGADDR_SHIFT) |
- (R_SRI2C_SLAVE_ADDR OMAP3430_SLAVEADDR_SHIFT);
-
- prm_write_mod_reg(vc_bypass_value, OMAP3430_GR_MOD,
- OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
-
- vc_bypass_value = prm_set_mod_reg_bits(OMAP3430_VALID, OMAP3430_GR_MOD,
- OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
-
- while ((vc_bypass_value OMAP3430_VALID) != 0x0) {
- loop_cnt++;
- if (retries_cnt 10) {
- pr_info(Loop count exceeded in check SR I2C
- write\n);
- return 1;
- }
- if (loop_cnt 50) {
- retries_cnt++;
- loop_cnt = 0;
- udelay(10);
- }
- vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
- OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
- }
+ if (omap3_vc_bypass_cmd(R_SRI2C_SLAVE_ADDR, reg_addr, vsel))
+ return 1;
/*
* T2 SMPS slew
RE: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, June 25, 2009 10:15 PM To: Syed, Rafiuddin Cc: linux-omap@vger.kernel.org Subject: Re: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430 Syed Rafiuddin rafiuddin.s...@ti.com writes: This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures are filled at runtime to have McSPI support on OMAP4. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com This driver needs some help for multi-omap, but that problem existed before this patch, so Acked-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/devices.c | 25 + drivers/spi/omap2_mcspi.c | 10 ++ 2 files changed, 27 insertions(+), 8 deletions(-) Not sure but looks like the patch needs split since different upstream paths 1. arch/arm/mach-omap2/devices.c -- linux-arm 2. drivers/spi/omap2_mcspi.c --- Don't know the list but should be some driver list. Is that correct ? 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: v4l2_int_device vs v4l2_subdev?
Hello, On Fri, Jun 26, 2009 at 7:43 AM, Gary Thomasg...@mlbassoc.com wrote: Still trying to wrap my head around the OMAP/34xx camera support. I need to use the TVP5150 sensor/controller, but the existing driver uses v4l_subdev. The working examples I've found (from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device Are these two totally separate beasts? If I have an infrastructure (I assume) based on v4l2_int_device, how do I use a v4l2_subdev device driver? or need I move one to the other? I've been through the same case (now I'm trying to use subdev framework and writing a new device driver based on that) As far as I understand, every v4l2 drivers are moving on subdev framework. But in user space there is nothing changed having access to device and control them. As you know, subdev and int-device is all about how to bind interface(or host?) and device and make them communicated each other. But using subdev device driver with int-device supporting interface (or host) device driver? it won't make any communication. So if you are running out of time with your project, you'd better use old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if you have enough time and wanna be challenging, try to convert in-device based omap3 camera interface driver to subdev supporting one. Cheers, Nate ... dizzy from traveling down too many twisty little passages :-( -- Gary Thomas | Consulting for the MLB Associates | Embedded world -- 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 -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430
* Shilimkar, Santosh santosh.shilim...@ti.com [090626 08:00]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, June 25, 2009 10:15 PM To: Syed, Rafiuddin Cc: linux-omap@vger.kernel.org Subject: Re: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430 Syed Rafiuddin rafiuddin.s...@ti.com writes: This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures are filled at runtime to have McSPI support on OMAP4. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com This driver needs some help for multi-omap, but that problem existed before this patch, so Acked-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/devices.c | 25 + drivers/spi/omap2_mcspi.c | 10 ++ 2 files changed, 27 insertions(+), 8 deletions(-) Not sure but looks like the patch needs split since different upstream paths 1. arch/arm/mach-omap2/devices.c -- linux-arm 2. drivers/spi/omap2_mcspi.c --- Don't know the list but should be some driver list. Is that correct ? I think this is OK to send as a single patch via the SPI list. Acked-by: Tony Lindgren t...@atomide.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
[PATCH] OMAP2/3: DMA errata correction
This errata is valid for:
OMAP2420 Errata 1.85 Impacts all 2420 ES rev
OMAP2430 Errata 1.10 Impacts only ES1.0
Description: DMA may hang when several channels are used in parallel
OMAP3430: Not impacted, so remove the errata fix for omap3
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/plat-omap/dma.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7677a4a..feebaf3 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -946,7 +946,9 @@ void omap_start_dma(int lch)
cur_lch = next_lch;
} while (next_lch != -1);
- } else if (cpu_class_is_omap2()) {
+ } else if (cpu_is_omap24xx() ||
+ (cpu_is_omap243x() omap_type() = OMAP2430_REV_ES1_0)) {
+
/* Errata: Need to write lch even if not using chaining */
dma_write(lch, CLNK_CTRL(lch));
}
--
1.6.3.3.334.g916e1
--
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: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, June 26, 2009 11:21 AM To: Shilimkar, Santosh Cc: Kevin Hilman; Syed, Rafiuddin; linux-omap@vger.kernel.org Subject: Re: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430 * Shilimkar, Santosh santosh.shilim...@ti.com [090626 08:00]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, June 25, 2009 10:15 PM To: Syed, Rafiuddin Cc: linux-omap@vger.kernel.org Subject: Re: [RESUBMIT][PATCH][RFC] OMAP4: McSPI Support for OMAP_4430 Syed Rafiuddin rafiuddin.s...@ti.com writes: This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures are filled at runtime to have McSPI support on OMAP4. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com This driver needs some help for multi-omap, but that problem existed before this patch, so Acked-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/devices.c | 25 + drivers/spi/omap2_mcspi.c | 10 ++ 2 files changed, 27 insertions(+), 8 deletions(-) Not sure but looks like the patch needs split since different upstream paths 1. arch/arm/mach-omap2/devices.c -- linux-arm 2. drivers/spi/omap2_mcspi.c --- Don't know the list but should be some driver list. Is that correct ? I think this is OK to send as a single patch via the SPI list. Acked-by: Tony Lindgren t...@atomide.com Cool !! Thanks Kevin, Tony for ACK. -- 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] OMAP: update OMAP3 Beagle defconfig
Update the OMAP3 Beagle defconfig to add EHCI, MMC, TWL4030 GPIO support. Beagle can again use MMC rootfs after this patch. Tested on BeagleBoard rev C2. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Jason Kridner jkrid...@beagleboard.org --- arch/arm/configs/omap3_beagle_defconfig | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap3_beagle_defconfig b/arch/arm/configs/omap3_beagle_defconfig index c4726f0..0c6eee7 100644 --- a/arch/arm/configs/omap3_beagle_defconfig +++ b/arch/arm/configs/omap3_beagle_defconfig @@ -236,6 +236,7 @@ CONFIG_ARM_THUMB=y # CONFIG_CPU_BPREDICT_DISABLE is not set CONFIG_HAS_TLS_REG=y # CONFIG_OUTER_CACHE is not set +CONFIG_COMMON_CLKDEV=y # # Bus support @@ -713,6 +714,7 @@ CONFIG_GPIOLIB=y # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set +CONFIG_GPIO_TWL4030=y # # PCI GPIO expanders: @@ -741,6 +743,7 @@ CONFIG_SSB_POSSIBLE=y # CONFIG_MFD_SM501 is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set +CONFIG_TWL4030_CORE=y # CONFIG_UCB1400_CORE is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set @@ -832,7 +835,7 @@ CONFIG_FONT_8x16=y CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y -# CONFIG_USB_ARCH_HAS_EHCI is not set +CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set @@ -851,6 +854,8 @@ CONFIG_USB_MON=y # # USB Host Controller Drivers # +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_ROOT_HUB_TT=y # CONFIG_USB_C67X00_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set @@ -968,6 +973,7 @@ CONFIG_MMC_BLOCK_BOUNCE=y # # CONFIG_MMC_SDHCI is not set # CONFIG_MMC_OMAP is not set +CONFIG_MMC_OMAP_HS=y # CONFIG_MEMSTICK is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_NEW_LEDS is not set @@ -1026,10 +1032,11 @@ CONFIG_RTC_INTF_DEV=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # -- 1.6.3.3.334.g916e1 -- 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
