RE: [RFC][PATCH 0/4] TWL6030 patch series
Mark, Felipe, -Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Friday, July 24, 2009 2:51 PM To: Shilimkar, Santosh Cc: Felipe Balbi; Krishnamoorthy, Balaji T; linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com; davi...@pacbell.net; Nayak, Rajendra Subject: Re: [RFC][PATCH 0/4] TWL6030 patch series On Fri, Jul 24, 2009 at 09:46:27AM +0530, Shilimkar, Santosh wrote: Mark, Liam, Can you please your comments of regulator patches. I'd really like to see the ifdefs go as someone else requested earlier in the thread. Allowing both twl4030 and twl6030 support to be built simultaneously is much nicer from a maintinance perspective and will scale better as further devices are added to the family. Can you please provide your comments on the v2 version of the patches in which Balaji has fixed the ifdef's Thanks!! Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
Hello Moiz,
A few remaining comments, most of these from an earlier message.
On Tue, 21 Jul 2009, Sonasath, Moiz wrote:
When an XRDY/XDR is hit, wait for XUDF before writing data to DATA_REG.
Otherwise some data bytes can be lost while transferring them from the
memory to the I2C interface.
Do a Busy-wait for XUDF, before writing data to DATA_REG. While waiting
if there is NACK | AL, set the appropriate error flags, ack the pending
interrupts and return from the ISR.
Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Vikram panditavikram.pand...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 24 +++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 05b5e4c..8deaf87 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -672,9 +672,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
break;
}
+ err = 0;
+complete:
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
- err = 0;
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -764,6 +765,27 @@ omap_i2c_isr(int this_irq, void *dev_id)
data to send\n);
break;
}
+
+ /*
+ * OMAP3430 Errata 1.153: When an XRDY/XDR
+ * is hit, wait for XUDF before writing data
+ * to DATA_REG. Otherwise some data bytes can
+ * be lost while transferring them from the
+ * memory to the I2C interface.
+ */
Based on this description, shouldn't this patch also zero the transmit
FIFO threshold? Consider what the transmit path becomes after this patch:
1. Fill transmit FIFO
2. Leave ISR wait for interrupt
3. Interrupt happens due to XDR/XRDY (transmit FIFO low-water-mark
reached)
4. Busy-wait until transmit FIFO shift register completely empty
5. If more data to send, go to step #1
i2c-omap.c currently sets the transmit FIFO threshold to 1/2 of the total
FIFO size[1]. This means that, in the worst case, I2C3, the I2C ISR will
busy-wait in step 4 for the time it takes 32 bytes to be transmitted.
This is time that the MPU spends doing nothing but spinning, wasting
power. This seems unnecessary and wasteful. The time the driver spends
busy-waiting in the ISR should be reduced to the lowest possible duration.
To do this, what I suggest that you additionally do in the patch is to
reduce the transit FIFO threshold/low-water-mark, controlled by
I2C_BUF.XTRSH, to the lowest possible value. This should maximize the
time spent between steps 2 and 3 and minimize the time spent between steps
3 and 5.
Is there a reason why this can't be done?
+
+ if (cpu_is_omap34xx()) {
Does this erratum apply to the I2C IP block on OMAP2430? It also has FIFO
transmit capability. It would be ideal if you can find out from the I2C
IP block designers. If you cannot, please consider adding a comment that
this may also apply to the I2C block on OMAP2430.
In general it is best to enable these workarounds based on the I2C IP
block's own revision register contents, not the OMAP CPU type. The goal
is to remove all these OMAP-specific cpu_is_omap() macros from
device drivers. For example, what if a future DaVinci part uses the same
I2C IP block?
+ while (!(stat
OMAP_I2C_STAT_XUDF)) {
Is there a reason why you can't just reuse the main while() loop in the
ISR, and add a state variable to handle any special casing needed in this
context? That will avoid this separate while() loop.
+ if (stat
(OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+
omap_i2c_ack_stat(dev, stat (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
+ err |=
OMAP_I2C_STAT_XUDF;
+ goto complete;
+ }
+ cpu_relax();
+ stat =
omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ }
+ }
+
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
omap_i2c_ack_stat(dev,
For those following along in the archives, this is an extension of
[PATCH] OMAP: PM: warn if CONFIG_CPU_IDLE is not enabled
For MPU latency constraints to work, CONFIG_CPU_IDLE must be enabled, since CPUIdle is where the constraints are evaluated. Warn during compilation if CONFIG_CPU_IDLE is not defined. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/resource34xx.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c index 25535a3..1693e9b 100644 --- a/arch/arm/mach-omap2/resource34xx.c +++ b/arch/arm/mach-omap2/resource34xx.c @@ -28,6 +28,10 @@ #include cm.h #include cm-regbits-34xx.h +#ifndef CONFIG_CPU_IDLE +#warning MPU latency constraints require CONFIG_CPU_IDLE to function! +#endif + /** * init_latency - Initializes the mpu/core latency resource. * @resp: Latency resource to be initalized -- 1.6.3.GIT -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
On Fri, Jul 31, 2009 at 07:26:11PM +0200, ext Jarkko Nikula wrote:
On Fri, 31 Jul 2009 10:58:23 +0300
Eduardo Valentin eduardo.valen...@nokia.com wrote:
On Thu, Jul 30, 2009 at 08:57:21PM +0200, ext Jarkko Nikula wrote:
On Thu, 30 Jul 2009 15:49:32 +0300
Eduardo Valentin eduardo.valen...@nokia.com wrote:
From: Peter Ujfalusi peter.ujfal...@nokia.com
Do not allow applications to use the full buffer found on
McBSP1,3,4,5. Using the full buffer in threshold mode causes
the McBSP buffer to run dry, which can be observed as channels
are switching (in reality the channels are shifting).
...
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -129,7 +129,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = { .rx_irq =
INT_24XX_MCBSP1_IRQ_RX, .tx_irq =
INT_24XX_MCBSP1_IRQ_TX, .ops= omap2_mcbsp_ops,
- .buffer_size= 0x7F,
+ .buffer_size= 0x6F,
},
Is it possible that also McBSP2 would require that maximum burst
transmit size should be 0x10 smaller than size of internal
buffer/fifo?
That's already not at full size. There is room for 1024+256 places on
mcbsp2.
True, but I was wondering can this same problem occur also on McBSP2 if
using proper size threshold? Like size near the McBSP2 audio buffer
(1024x32) or near the TX buffer (256x32).
Yes, it can happen with mcbsp2 also if you use all places (1024+256).
--
Jarkko
--
Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
Hi On Mon, 3 Aug 2009 03:32:04 +0200 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: This patch tries to correct the problem of full duplex mode not working over a single McBSP based CPU DAI. Created against linux-2.6.31-rc5. Tested on Amstrad Delta. Do you have some specific test case how to trigger this? I haven't seen this on 2420 or 34xx (e.g. with 'arecord -d 1 -f dat |aplay') but I have no doubt that this can happen on 1510. At least this doesn't cause any harm on Beagle so I'm fine with the fix. @@ -191,6 +192,14 @@ static int omap_mcbsp_dai_trigger(struct case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: if (!mcbsp_data-active++) omap_mcbsp_start(mcbsp_data-bus_id); + else if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) + /* looks like capture already in progress, + * start playback by taking it out of error condition */ + omap_mcbsp_pollwrite(mcbsp_data-bus_id, 0x0); + else + /* looks like playback already in progress, + * start capture by taking it out of error condition */ + omap_mcbsp_pollread(mcbsp_data-bus_id, buf); break; Minor note: See preferred style for multi-line comments in Documentation/CodingStyle. I'm not 100 % sure about the braces but I think they are also preferred if there are indented comment lines with the single code line. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
On Mon, 3 Aug 2009 11:11:07 +0300 Eduardo Valentin eduardo.valen...@nokia.com wrote: True, but I was wondering can this same problem occur also on McBSP2 if using proper size threshold? Like size near the McBSP2 audio buffer (1024x32) or near the TX buffer (256x32). Yes, it can happen with mcbsp2 also if you use all places (1024+256). So should the patch then take into account McBSP2 also? -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
On Mon, Aug 03, 2009 at 10:36:38AM +0200, ext Jarkko Nikula wrote: On Mon, 3 Aug 2009 11:11:07 +0300 Eduardo Valentin eduardo.valen...@nokia.com wrote: True, but I was wondering can this same problem occur also on McBSP2 if using proper size threshold? Like size near the McBSP2 audio buffer (1024x32) or near the TX buffer (256x32). Yes, it can happen with mcbsp2 also if you use all places (1024+256). So should the patch then take into account McBSP2 also? hmmm.. But I've seen the problem only if you use 1024+256 for mcbsp2 (0x500) or very close to that (0x4F0). I haven't seen this problem using 0x3FF, as currently is. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Eduardo Valentin -- 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
Pull Request for OMAP4
Hi Russell, Could you please pull four patches below for the upcoming merging window. The patches are rebased on commit 4be3bd7849165e7efa6b0b35a23d6a3598d97465: Linus Torvalds (1):Linux 2.6.31-rc4 and available in the git repository at: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4_upstream Summary: Santosh Shilimkar (1): OMAP4: sDMA: Update the request lines and new registers. Syed Rafiuddin (3): ARM: OMAP4: Add McBSP support ARM: OMAP4: Add UART4 support ARM: OMAP4: Update the GPIO support arch/arm/mach-omap2/board-4430sdp.c |2 +- arch/arm/mach-omap2/mcbsp.c | 41 + arch/arm/mach-omap2/serial.c| 10 ++ arch/arm/plat-omap/gpio.c | 249 --- arch/arm/plat-omap/include/mach/dma.h | 88 +++ arch/arm/plat-omap/include/mach/mcbsp.h |8 +- arch/arm/plat-omap/mcbsp.c |2 +- 7 files changed, 346 insertions(+), 54 deletions(-) Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
On Mon, Aug 03, 2009 at 11:29:50AM +0300, Jarkko Nikula wrote: Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: + else + /* looks like playback already in progress, +* start capture by taking it out of error condition */ + omap_mcbsp_pollread(mcbsp_data-bus_id, buf); Minor note: See preferred style for multi-line comments in Documentation/CodingStyle. I'm not 100 % sure about the braces but I think they are also preferred if there are indented comment lines with the single code line. Indeed; only omit the braces if the *only* thing in the block is a single statement. -- 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 11/20] OMAP: McBSP: Add link DMA mode selection
On Thu, Jul 30, 2009 at 03:47:25PM +0200, ext Mark Brown wrote: On Thu, Jul 30, 2009 at 04:28:08PM +0300, Eduardo Valentin wrote: On Thu, Jul 30, 2009 at 03:04:42PM +0200, ext Mark Brown wrote: Is this really something that people would want to tweak at runtime (except for test purposes)? Yes, test purposes, bug also, the same link could be sometime used for low-power playback while sometime for low-latency processing where as accurate as possible DMA pointer position info is needed. Latency you *should* be able to infer from the application behaviour. Yes that's true. But I think using ELEMENT mode, position reports are much more accurate, which will result in more precise inferences for latencies. -- Eduardo Valentin -- 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: MMC3 Overo
Paul,
On Sun, Aug 2, 2009 at 9:20 PM, Paul Walmsleyp...@pwsan.com wrote:
Hello John,
you are using the PM branch, correct?
Unfortunately I am not using the pm patch, because I am stuck at
2.6.30-rc8. This is because it is the last place I have usb host
working. I backported the necessary changes and pm wasn't an absolute
necessity, basically equivalent to not compiling in PM. I basically
used nearly every related patch after 6-6-09 - the 32 mmc patches.
On Thu, 30 Jul 2009, John Sarman wrote:
On Thu, Jul 30, 2009 at 11:49 AM, John Sarmanjohnsar...@gmail.com wrote:
I am trying to use mmc3 on the Overo Gumstix board with no luck. I
have patched the kernel with the latest changes and have yet to see a
clk pulse, both before and after the patches.
After adding some debugging printks, I have determined the mmc3 fails
getting IRQ
mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
REQUEST IRQ = 83 HOST = -812068416
mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
REQUEST IRQ = 86 HOST = -812067392
mmci-omap-hs mmci-omap-hs.2: Failed to get debounce clock
REQUEST IRQ = 83 HOST = -812066368
mmci-omap-hs mmci-omap-hs.2: Unable to grab HSMMC IRQ
mmci-omap-hs mmci-omap-hs.2: Probe Failed
mmci-omap-hs: probe of mmci-omap-hs.2 failed with error -16
For some reason mmc1 and mmc3 ask for the same interrupt 83 ???
Why would this be assigned the same value?
Developer error. Does this patch fix it for you?
- Paul
From baca68c40ec3b391cdbfc0fb20ac5092b4ab7025 Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Mon, 3 Aug 2009 04:18:45 +0300
Subject: [PATCH] OMAP3 hwmod: fix MMC3 IRQ
The MMC3 IRQ is incorrect in mach-omap2/omap_hwmod_34xx.h, which causes
MMC3 init to fail.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_34xx.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
b/arch/arm/mach-omap2/omap_hwmod_34xx.h
index 29a2d60..56215bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
+++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
@@ -470,7 +470,7 @@ static struct omap_hwmod omap34xx_mmc2_hwmod = {
static struct mmc_dev_attr mmc3_dev_attr;
static u8 mmc3_mpu_irqs[] = {
- INT_24XX_MMC_IRQ,
+ INT_34XX_MMC3_IRQ,
};
static struct omap_hwmod_dma_info mmc3_sdma_chs[] = {
--
1.6.3.GIT
Thanks for the patch, I will apply that and keep on testing.
John Sarman
--
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: drivers that require headers in mach-omap
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Monday, August 03, 2009 5:04 AM To: Pandita, Vikram Cc: Mike Chan; Kevin Hilman; linux-omap@vger.kernel.org Subject: RE: drivers that require headers in mach-omap On Fri, 31 Jul 2009, Pandita, Vikram wrote: -Original Message- From: Mike Chan [mailto:m...@android.com] Sent: Thursday, July 30, 2009 6:20 PM To: Pandita, Vikram Cc: Kevin Hilman; linux-omap@vger.kernel.org Subject: Re: drivers that require headers in mach-omap On Thu, Jul 30, 2009 at 8:44 AM, Pandita, Vikramvikram.pand...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mike Chan Sent: Tuesday, July 28, 2009 8:49 PM To: Kevin Hilman; linux-omap@vger.kernel.org Subject: drivers that require headers in mach-omap Omap folks, how are drivers that require access to prm and cm registers via cm_read_mod_reg() etc... suppose to access these? For example if drivers/usb/host/ohci-omap.c wanted to call: cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_IDLEST); The design was supposed to encapsulate the PRCM API's from drivers. Driver has control over the iclk and fclk and the clock framework would take care of any CM/PRM register settings. Accessing these registers in drivers would make the driver non-compatible for non-omap platforms. Are drivers such as drivers/usb/host/ohci-omap.c drivers/usb/musb/omap2430.c suppose to be compatible for non-omap platforms? As you put it, no they are not. All PRM/CM register accesses have been restricted to mach-omap2/plat-omap parts till now. The question to ask is, what functionality is missing on enabling say the usbhost clock that clock framework is not doing, that driver has a need to do. Just to follow up on this: the plan should be to remove all PRM and CM references from those drivers. Some of those can be replaced with clock framework calls, others may need platform_data function pointers. To add to the list, drivers/usb/host/ehci-omap.c need a similar re-work. At the moment, it does some amount of DPLL5 programming in itself before enabling the iclk and fclk. - 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 -- 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
Work in progress recipes for power management for overo
Hi John, Here is a link to download the omap-pm recipes for the overo that I've created so far. http://web.me.com/elvis.dowson/Download/OpenEmbedded/Entries/2009/8/3_Power_management_for_gumstix_Overo.html Let me know if you have any problems building these recipes. These recipes were original created for the corresponding android kernel builds, and I just removed the android patches from them. So, you will have to do bitbake -c menuconfig linux-omap3-2.6.29 load the defconfig file in the linux-omap3-2.6.29/overo folder, and then save it back, to remove the android specific kernel configuration settings. In the linux-omap3-2.6.29/overo/backup/defconfig folder, you will find various work in progress defconfig settings. Let me know how it goes. Oh, I forgot one more thing, in the linux-omap3-2.6.29.bb recipe, for the mmc there are three patches # OMAP Patches \ file://omap/0300-mmc-clk.patch;patch=1 \ # file://omap/0301-mmc-off-mode-1.patch;patch=1 \ file://omap/0302-mmc-off-mode-2.patch;patch=1 \ Both mmc-off-mode-1 and mmc-off-mode-2 patches are similar, and I don't know which one to use. I was building mmc-off-mode-2 patch, but did test it yet and zipped it in a hurry. if you modify it as follows: # OMAP Patches \ file://omap/0300-mmc-clk.patch;patch=1 \ file://omap/0301-mmc-off-mode-1.patch;patch=1 \ # file://omap/0302-mmc-off-mode-2.patch;patch=1 \ It should work fine, and all power domains will reach their target state. However, at the moment, it takes a couple of seconds for the system to come back from suspend mode. Let me know how it goes. Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4) OMAPFB patches
This patch set makes preparations for the new DSS2 driver. It implements VRFB support and a VRAM manager, omapfb.h is split and moved, and a dummy DSS device is created to make it possible for old DSS and new DSS2 to co-exist. VRFB and VRAM are not used by the current DSS driver. The patches are based on linux-omap, as omapfb seems to be broken in mainstream kernel. Tomi Valkeinen arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/board-n800.c |2 +- arch/arm/mach-omap2/clock24xx.c |8 +- arch/arm/mach-omap2/clock34xx.c | 10 +- arch/arm/mach-omap2/io.c |4 +- arch/arm/plat-omap/Kconfig |6 + arch/arm/plat-omap/Makefile |2 + arch/arm/plat-omap/fb.c |2 +- arch/arm/plat-omap/include/mach/omapfb.h | 398 -- arch/arm/plat-omap/include/mach/vram.h | 63 +++ arch/arm/plat-omap/include/mach/vrfb.h | 46 ++ arch/arm/plat-omap/sram.c|8 + arch/arm/plat-omap/vram.c| 655 ++ arch/arm/plat-omap/vrfb.c| 281 + drivers/video/omap/blizzard.c|2 +- drivers/video/omap/dispc.c | 21 +- drivers/video/omap/hwa742.c |2 +- drivers/video/omap/lcd_2430sdp.c |2 +- drivers/video/omap/lcd_ams_delta.c |2 +- drivers/video/omap/lcd_apollon.c |2 +- drivers/video/omap/lcd_h3.c |2 +- drivers/video/omap/lcd_h4.c |2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |2 +- drivers/video/omap/lcd_mipid.c |3 +- drivers/video/omap/lcd_omap2evm.c|2 +- drivers/video/omap/lcd_omap3beagle.c |2 +- drivers/video/omap/lcd_omap3evm.c|2 +- drivers/video/omap/lcd_osk.c |2 +- drivers/video/omap/lcd_overo.c |3 +- drivers/video/omap/lcd_palmte.c |2 +- drivers/video/omap/lcd_palmtt.c |2 +- drivers/video/omap/lcd_palmz71.c |2 +- drivers/video/omap/lcdc.c|3 +- drivers/video/omap/omapfb.h | 227 +++ drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c|3 +- drivers/video/omap/sossi.c |2 +- include/linux/omapfb.h | 197 + 40 files changed, 1543 insertions(+), 439 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 3/4] OMAP2/3: Add VRAM manager
Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:
- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations
The upcoming DSS2 uses VRAM manager.
VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/io.c |2 +
arch/arm/plat-omap/Kconfig |3 +
arch/arm/plat-omap/Makefile|1 +
arch/arm/plat-omap/include/mach/vram.h | 63 +++
arch/arm/plat-omap/sram.c |8 +
arch/arm/plat-omap/vram.c | 655
6 files changed, 732 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vram.h
create mode 100644 arch/arm/plat-omap/vram.c
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 7a54e12..e37f736 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -32,6 +32,7 @@
#include mach/sram.h
#include mach/sdrc.h
#include mach/gpmc.h
+#include mach/vram.h
#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdev is ready */
#include clock.h
@@ -240,6 +241,7 @@ void __init omap2_map_common_io(void)
omap2_check_revision();
omap_sram_init();
omapfb_reserve_sdram();
+ omap_vram_reserve_sdram();
}
/*
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index efe85d0..ca06037 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -183,6 +183,9 @@ config OMAP_SERIAL_WAKE
to data on the serial RX line. This allows you to wake the
system from serial console.
+config OMAP2_VRAM
+ bool
+
endmenu
endif
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a832795..0472bbe 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -25,3 +25,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
+obj-$(CONFIG_OMAP2_VRAM) += vram.o
diff --git a/arch/arm/plat-omap/include/mach/vram.h
b/arch/arm/plat-omap/include/mach/vram.h
new file mode 100644
index 000..4f2c2e6
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vram.h
@@ -0,0 +1,63 @@
+/*
+ * VRAM manager for OMAP
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRAM_H__
+#define __OMAP_VRAM_H__
+
+#include linux/autoconf.h
+#include asm/types.h
+
+#define OMAP_VRAM_MEMTYPE_SDRAM0
+#define OMAP_VRAM_MEMTYPE_SRAM 1
+#define OMAP_VRAM_MEMTYPE_MAX 1
+
+extern int omap_vram_add_region(unsigned long paddr, size_t size);
+extern int omap_vram_free(unsigned long paddr, size_t size);
+extern int omap_vram_alloc(int mtype, size_t size, unsigned long *paddr);
+extern int omap_vram_reserve(unsigned long paddr, size_t size);
+extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
+ unsigned long *largest_free_block);
+
+#ifdef CONFIG_OMAP2_VRAM
+extern void omap_vram_set_sdram_vram(u32 size, u32 start);
+extern void omap_vram_set_sram_vram(u32 size, u32 start);
+
+extern void omap_vram_reserve_sdram(void);
+extern unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned long sram_size,
+ unsigned long pstart_avail,
+ unsigned long size_avail);
+#else
+static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
+static inline void omap_vram_set_sram_vram(u32 size, u32 start) { }
+
+static inline void omap_vram_reserve_sdram(void) { }
+static inline unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned
[PATCH 2/4] OMAP: OMAPFB: add omapdss device
The upcoming new display subsystem driver is divided to two devices,
omapdss and omapfb, of which omapdss handles the actual hardware.
This patch adds a dummy omapdss platform device for the current omapfb
driver, which is then used to get the clocks. This will make it possible
for the current and the new display drivers to co-exist.
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/clock24xx.c |8
arch/arm/mach-omap2/clock34xx.c | 10 +-
drivers/video/omap/dispc.c | 19 ---
3 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 44de027..402a3d4 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -103,10 +103,10 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL, mdm_ick, mdm_ick, CK_243X),
CLK(NULL, mdm_osc_ck, mdm_osc_ck,CK_243X),
/* DSS domain clocks */
- CLK(omapfb, ick, dss_ick, CK_243X | CK_242X),
- CLK(omapfb, dss1_fck, dss1_fck, CK_243X | CK_242X),
- CLK(omapfb, dss2_fck, dss2_fck, CK_243X | CK_242X),
- CLK(omapfb, tv_fck, dss_54m_fck, CK_243X | CK_242X),
+ CLK(omapdss, ick, dss_ick, CK_243X | CK_242X),
+ CLK(omapdss, dss1_fck, dss1_fck, CK_243X | CK_242X),
+ CLK(omapdss, dss2_fck, dss2_fck, CK_243X | CK_242X),
+ CLK(omapdss, tv_fck, dss_54m_fck, CK_243X | CK_242X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_243X | CK_242X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 045da92..dd7bba2 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -200,11 +200,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK(omap_rng, ick, rng_ick, CK_343X),
CLK(NULL, sha11_ick,sha11_ick, CK_343X),
CLK(NULL, des1_ick, des1_ick, CK_343X),
- CLK(omapfb, dss1_fck, dss1_alwon_fck, CK_343X),
- CLK(omapfb, tv_fck, dss_tv_fck,CK_343X),
- CLK(omapfb, video_fck,dss_96m_fck, CK_343X),
- CLK(omapfb, dss2_fck, dss2_alwon_fck, CK_343X),
- CLK(omapfb, ick, dss_ick, CK_343X),
+ CLK(omapdss, dss1_fck, dss1_alwon_fck, CK_343X),
+ CLK(omapdss, tv_fck, dss_tv_fck,CK_343X),
+ CLK(omapdss, video_fck,dss_96m_fck, CK_343X),
+ CLK(omapdss, dss2_fck, dss2_alwon_fck, CK_343X),
+ CLK(omapdss, ick, dss_ick, CK_343X),
CLK(NULL, cam_mclk, cam_mclk, CK_343X),
CLK(NULL, cam_ick, cam_ick, CK_343X),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_343X),
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 06438d0..cde3d18 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -24,6 +24,7 @@
#include linux/vmalloc.h
#include linux/clk.h
#include linux/io.h
+#include linux/platform_device.h
#include mach/sram.h
#include mach/board.h
@@ -188,6 +189,11 @@ static struct {
struct omapfb_color_key color_key;
} dispc;
+static struct platform_device omapdss_device = {
+ .name = omapdss,
+ .id = -1,
+};
+
static void enable_lcd_clocks(int enable);
static void inline dispc_write_reg(int idx, u32 val)
@@ -907,20 +913,20 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*dev)
static int get_dss_clocks(void)
{
- dispc.dss_ick = clk_get(dispc.fbdev-dev, ick);
+ dispc.dss_ick = clk_get(omapdss_device.dev, ick);
if (IS_ERR(dispc.dss_ick)) {
dev_err(dispc.fbdev-dev, can't get ick\n);
return PTR_ERR(dispc.dss_ick);
}
- dispc.dss1_fck = clk_get(dispc.fbdev-dev, dss1_fck);
+ dispc.dss1_fck = clk_get(omapdss_device.dev, dss1_fck);
if (IS_ERR(dispc.dss1_fck)) {
dev_err(dispc.fbdev-dev, can't get dss1_fck\n);
clk_put(dispc.dss_ick);
return PTR_ERR(dispc.dss1_fck);
}
- dispc.dss_54m_fck = clk_get(dispc.fbdev-dev, tv_fck);
+ dispc.dss_54m_fck = clk_get(omapdss_device.dev, tv_fck);
if (IS_ERR(dispc.dss_54m_fck)) {
dev_err(dispc.fbdev-dev, can't get tv_fck\n);
clk_put(dispc.dss_ick);
@@ -1371,6 +1377,12 @@ static int omap_dispc_init(struct omapfb_device *fbdev,
int ext_mode,
int skip_init = 0;
int i;
+ r = platform_device_register(omapdss_device);
+ if (r) {
+ dev_err(fbdev-dev, can't register omapdss device\n);
+ return r;
+ }
+
memset(dispc, 0, sizeof(dispc));
[PATCH 1/4] OMAP: OMAPFB: split omapfb.h
Split arch/arm/plat-omap/include/mach/omapfb.h into two files: include/linux/omapfb.h - ioctls etc for userspace and some kernel stuff for board files drivers/video/omap/omapfb.h - for omapfb internal use This cleans up omapfb.h and also makes it easier for the upcoming new DSS driver to co-exist with the old driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/board-n800.c |2 +- arch/arm/mach-omap2/io.c |2 +- arch/arm/plat-omap/fb.c |2 +- arch/arm/plat-omap/include/mach/omapfb.h | 398 -- drivers/video/omap/blizzard.c|2 +- drivers/video/omap/dispc.c |2 +- drivers/video/omap/hwa742.c |2 +- drivers/video/omap/lcd_2430sdp.c |2 +- drivers/video/omap/lcd_ams_delta.c |2 +- drivers/video/omap/lcd_apollon.c |2 +- drivers/video/omap/lcd_h3.c |2 +- drivers/video/omap/lcd_h4.c |2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |2 +- drivers/video/omap/lcd_mipid.c |3 +- drivers/video/omap/lcd_omap2evm.c|2 +- drivers/video/omap/lcd_omap3beagle.c |2 +- drivers/video/omap/lcd_omap3evm.c|2 +- drivers/video/omap/lcd_osk.c |2 +- drivers/video/omap/lcd_overo.c |3 +- drivers/video/omap/lcd_palmte.c |2 +- drivers/video/omap/lcd_palmtt.c |2 +- drivers/video/omap/lcd_palmz71.c |2 +- drivers/video/omap/lcdc.c|3 +- drivers/video/omap/omapfb.h | 227 + drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c|3 +- drivers/video/omap/sossi.c |2 +- include/linux/omapfb.h | 197 +++ 31 files changed, 455 insertions(+), 427 deletions(-) delete mode 100644 arch/arm/plat-omap/include/mach/omapfb.h create mode 100644 drivers/video/omap/omapfb.h create mode 100644 include/linux/omapfb.h diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c index ed2a48a..6fbde33 100644 --- a/arch/arm/mach-omap1/board-nokia770.c +++ b/arch/arm/mach-omap1/board-nokia770.c @@ -14,6 +14,7 @@ #include linux/platform_device.h #include linux/input.h #include linux/clk.h +#include linux/omapfb.h #include linux/spi/spi.h #include linux/spi/ads7846.h @@ -32,7 +33,6 @@ #include mach/keypad.h #include mach/common.h #include mach/dsp_common.h -#include mach/omapfb.h #include mach/hwa742.h #include mach/lcd_mipid.h #include mach/mmc.h diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-n800.c index 23296e9..e2907ac 100644 --- a/arch/arm/mach-omap2/board-n800.c +++ b/arch/arm/mach-omap2/board-n800.c @@ -22,6 +22,7 @@ #include linux/interrupt.h #include linux/irq.h #include linux/i2c.h +#include linux/omapfb.h #include mach/hardware.h #include asm/mach-types.h #include asm/mach/arch.h @@ -34,7 +35,6 @@ #include mach/lcd_mipid.h #include mach/clock.h #include mach/menelaus.h -#include mach/omapfb.h #include mach/blizzard.h #include mach/onenand.h #include mach/board-nokia.h diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 3a86b0f..7a54e12 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -22,13 +22,13 @@ #include linux/init.h #include linux/io.h #include linux/clk.h +#include linux/omapfb.h #include asm/tlb.h #include asm/mach/map.h #include mach/mux.h -#include mach/omapfb.h #include mach/sram.h #include mach/sdrc.h #include mach/gpmc.h diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c index 3746222..40615a6 100644 --- a/arch/arm/plat-omap/fb.c +++ b/arch/arm/plat-omap/fb.c @@ -28,13 +28,13 @@ #include linux/platform_device.h #include linux/bootmem.h #include linux/io.h +#include linux/omapfb.h #include mach/hardware.h #include asm/mach/map.h #include mach/board.h #include mach/sram.h -#include mach/omapfb.h #if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE) diff --git a/arch/arm/plat-omap/include/mach/omapfb.h b/arch/arm/plat-omap/include/mach/omapfb.h deleted file mode 100644 index b226bdf..000 --- a/arch/arm/plat-omap/include/mach/omapfb.h +++ /dev/null @@ -1,398 +0,0 @@ -/* - * File: arch/arm/plat-omap/include/mach/omapfb.h - * - * Framebuffer driver for TI OMAP boards - * - * Copyright (C) 2004 Nokia Corporation - * Author: Imre Deak imre.d...@nokia.com - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any
[PATCH 4/4] OMAP2/3: Add support for VRFB rotation engine
VRFB rotation engine is a block in OMAP2/3 that offers 12 independent
contexts that can be used for framebuffer rotation.
Each context has a backend area of real memory, where it stores the
pixels in undisclosed format. This memory is offered to users via 4
virtual memory areas, which see the same memory area in different
rotation angles (0, 90, 180 and 270 degrees).
Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/plat-omap/Kconfig |3 +
arch/arm/plat-omap/Makefile|1 +
arch/arm/plat-omap/include/mach/vrfb.h | 46 +
arch/arm/plat-omap/vrfb.c | 281
4 files changed, 331 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vrfb.h
create mode 100644 arch/arm/plat-omap/vrfb.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ca06037..2d6ae55 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -186,6 +186,9 @@ config OMAP_SERIAL_WAKE
config OMAP2_VRAM
bool
+config OMAP2_VRFB
+ bool
+
endmenu
endif
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 0472bbe..462edf3 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -26,3 +26,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP2_VRAM) += vram.o
+obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
diff --git a/arch/arm/plat-omap/include/mach/vrfb.h
b/arch/arm/plat-omap/include/mach/vrfb.h
new file mode 100644
index 000..8790612
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vrfb.h
@@ -0,0 +1,46 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRFB_H__
+#define __OMAP_VRFB_H__
+
+#define OMAP_VRFB_LINE_LEN 2048
+
+struct vrfb {
+ u8 context;
+ void __iomem *vaddr[4];
+ unsigned long paddr[4];
+ u16 xoffset;
+ u16 yoffset;
+ u8 bytespp;
+};
+
+extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_suspend_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_resume_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp);
+extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height,
+ unsigned bytespp, bool yuv_mode);
+extern void omap_vrfb_restore_context(void);
+
+#endif /* __VRFB_H */
diff --git a/arch/arm/plat-omap/vrfb.c b/arch/arm/plat-omap/vrfb.c
new file mode 100644
index 000..240058f
--- /dev/null
+++ b/arch/arm/plat-omap/vrfb.c
@@ -0,0 +1,281 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/ioport.h
+#include linux/io.h
+#include linux/bitops.h
+#include linux/mutex.h
+
+#include mach/io.h
+#include mach/vrfb.h
+/*#define DEBUG*/
+
+#ifdef DEBUG
+#define DBG(format, ...) pr_debug(VRFB: format, ## __VA_ARGS__)
+#else
+#define DBG(format, ...)
+#endif
+
+#define SMS_ROT_VIRT_BASE(context, rot) \
+ (((context = 4) ? 0xD000 : 0x7000) \
++ (0x400 * (context)) \
++ (0x100 * (rot)))
+
+#define OMAP_VRFB_SIZE (2048 * 2048 * 4)
+
+#define VRFB_PAGE_WIDTH_EXP5 /* Assuming SDRAM pagesize= 1024 */
+#define VRFB_PAGE_HEIGHT_EXP 5 /* 1024 = 2^5 * 2^5 */
+#define VRFB_PAGE_WIDTH(1 VRFB_PAGE_WIDTH_EXP)
+#define
Re: Work in progress recipes for power management for overo
Hi John, A quick update... On Aug 3, 2009, at 4:42 PM, Elvis Dowson wrote: Oh, I forgot one more thing, in the linux-omap3-2.6.29.bb recipe, for the mmc there are three patches # OMAP Patches \ file://omap/0300-mmc-clk.patch;patch=1 \ # file://omap/0301-mmc-off-mode-1.patch;patch=1 \ file://omap/0302-mmc-off-mode-2.patch;patch=1 \ Both mmc-off-mode-1 and mmc-off-mode-2 patches are similar, and I don't know which one to use. I was building mmc-off-mode-2 patch, but did test it yet and zipped it in a hurry. if you modify it as follows: # OMAP Patches \ file://omap/0300-mmc-clk.patch;patch=1 \ file://omap/0301-mmc-off-mode-1.patch;patch=1 \ # file://omap/0302-mmc-off-mode-2.patch;patch=1 \ I just tested mmc-off-mode-2 patch, the results are identical. Both of them have the following error: mmc1: mmc_rescan - card ocr from io_op=0x, err = -110 Have you encountered this error before? A bit of background, I got those two patches from here: MMC off mode: https://review.source.android.com/#change,10666 but, I don't know what patch set 1 and patch set 2 is supposed to be. Would you happen to know ? Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] OMAP PM fixes for .31-rc series
* Russell King - ARM Linux li...@arm.linux.org.uk [090722 01:37]: On Tue, Jul 21, 2009 at 03:08:26PM -0700, Kevin Hilman wrote: Also available here as a v2.6.31-rc3 based branch from: Looks fine. Ack from me too. I assume that Kevin will post a pull request for Russell so we'll get these merged. FYI, I'm back from vacation now and reading mails. Looks like there are some fixes floating around, so I'll collect those into one more omap-fixes series once I'm done reading. 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
[RFC PATCH] OMAP3:PM: Fix OPP scale logic
While switching from higher OPP to lower OPP,
current scale logic can fail by switching to lower
voltage while frequency remains at old value.
This patch adds a cleaner recovery logic and
additional freq dpll checks. This changes
program_freq_opp return type in the process
for program_opp to handle error in a consistent
manner.
Tested on:rx-51, ported to pm branch - untested linux-omap
Patch generated on linux-omap pm branch, commit:
7e7377395d6b4576341a6939bf2179f3946f2ea0
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/resource34xx.c | 52 +---
1 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index 25535a3..1ceaed8 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -240,13 +240,23 @@ static int program_opp_freq(int res, int target_level,
int current_level)
lock_scratchpad_sem();
if (res == VDD1_OPP) {
curr_opp = curr_vdd1_opp;
- clk_set_rate(dpll1_clk, mpu_opps[target_level].rate);
- clk_set_rate(dpll2_clk, dsp_opps[target_level].rate);
+ ret = clk_set_rate(dpll1_clk, mpu_opps[target_level].rate);
+ if (unlikely(ret))
+ return ret;
+
+ ret = clk_set_rate(dpll2_clk, dsp_opps[target_level].rate);
+ if (unlikely(ret))
+ /* reset the dpll1 if failed */
+ clk_set_rate(dpll1_clk, mpu_opps[current_level].rate);
#ifndef CONFIG_CPU_FREQ
- /*Update loops_per_jiffy if processor speed is being changed*/
- loops_per_jiffy = compute_lpj(loops_per_jiffy,
- mpu_opps[current_level].rate/1000,
- mpu_opps[target_level].rate/1000);
+ else
+ /*
+* Update loops_per_jiffy if processor speed
+* is being changed
+*/
+ loops_per_jiffy = compute_lpj(loops_per_jiffy,
+ mpu_opps[current_level].rate/1000,
+ mpu_opps[target_level].rate/1000);
#endif
} else {
curr_opp = curr_vdd2_opp;
@@ -257,7 +267,7 @@ static int program_opp_freq(int res, int target_level, int
current_level)
}
if (ret) {
unlock_scratchpad_sem();
- return current_level;
+ return ret;
}
#ifdef CONFIG_PM
omap3_save_scratchpad_contents();
@@ -265,7 +275,7 @@ static int program_opp_freq(int res, int target_level, int
current_level)
unlock_scratchpad_sem();
*curr_opp = target_level;
- return target_level;
+ return ret;
}
static int program_opp(int res, struct omap_opp *opp, int target_level,
@@ -289,13 +299,35 @@ static int program_opp(int res, struct omap_opp *opp, int
target_level,
current_level);
#ifdef CONFIG_OMAP_SMARTREFLEX
else
- sr_voltagescale_vcbypass(t_opp, c_opp,
+ ret = sr_voltagescale_vcbypass(t_opp, c_opp,
opp[target_level].vsel,
opp[current_level].vsel);
+ if (ret) {
+ int ret1 = 0;
+ /*
+* If something did not work, put me back to old state.
+* Recover the other guy if at least 1 prev iteration
+* had run
+*/
+ if (i raise)
+ ret1 = sr_voltagescale_vcbypass(c_opp, t_opp,
+ opp[current_level].vsel,
+ opp[target_level].vsel);
+ else if (i)
+ ret1 = program_opp_freq(res, current_level,
+ target_level);
+ /*
+* If I could not reset my old state back.. system
+* is no longer in a controlled state.. bug me
+*/
+ if (unlikely(ret1))
+ BUG();
+ break;
+ }
#endif
}
- return ret;
+ return (res == PRCM_VDD1) ? curr_vdd1_opp : curr_vdd2_opp;
}
int resource_set_opp_level(int res, u32 target_level, int flags)
--
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: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
Jarkko Nikula wrote: On Mon, 3 Aug 2009 03:32:04 +0200 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: This patch tries to correct the problem of full duplex mode not working over a single McBSP based CPU DAI. Created against linux-2.6.31-rc5. Tested on Amstrad Delta. Do you have some specific test case how to trigger this? I haven't seen this on 2420 or 34xx (e.g. with 'arecord -d 1 -f dat |aplay') but I have no doubt that this can happen on 1510. At least this doesn't cause any harm on Beagle so I'm fine with the fix. Hi, I made more testing on my OMAP1510 and found out that I could get your example usage working without my patch, but only if started like this: arecord -D hw:0,0 -f S16_LE|aplay -D hw:0,0 If I start the same with -D hw:0,0 omitted from aplay, it doesn't work any longer, waiting forever. It definitelly doesn't work if I start capture and playback one after another, no matter which one goes first (record while playing or play while recording). So it looks like starting both streams simultaneously can do the job, but a short delay breaks it. With my patch, it seems to work fine for me in all cases. Jarkko, have you ever tried it on your OMAP2/3 with parallel playback and capture started one after another, not simultaneously? Arun, can your snd-soc-osk9512 work on OMAP1610 in full duplex mode without any limitations? If the problem appears to be OMAP1510 or AMS_DELTA specific, I can add a check for a machine or cpu type to avoid braking unaffected machines. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators
On Wed, Jul 29, 2009 at 10:06:13AM +0530, balaj...@ti.com wrote:
- if (twl_has_regulator()) {
+ if (twl_has_regulator() is_class_twl4030()) {
is_class_twl4030() feels like it should have better namespacing, though
having the part name in there means it's not actually an issue.
@@ -306,6 +306,7 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes);
#define TWL4030_INT_PWR_EDR2 0x6
#define TWL4030_INT_PWR_SIH_CTRL 0x7
+
/*--*/
/* Power bus message definitions */
Random unrelated indentation change?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/4] TWL6030 patch series
On Mon, Aug 03, 2009 at 11:45:58AM +0530, Shilimkar, Santosh wrote: Can you please provide your comments on the v2 version of the patches in which Balaji has fixed the ifdef's They're basically OK from a regulator API point of view but the series appears to depend on the renaming patch and possibly some others. -- 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: Pull Request for OMAP4
On Mon, Aug 03, 2009 at 02:37:58PM +0530, Shilimkar, Santosh wrote: Hi Russell, Could you please pull four patches below for the upcoming merging window. The patches are rebased on commit 4be3bd7849165e7efa6b0b35a23d6a3598d97465: Linus Torvalds (1):Linux 2.6.31-rc4 and available in the git repository at: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4_upstream Thanks, pulled. -- 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] ARM: OMAP: TWL4030 IRQ
On Mon, Aug 03, 2009 at 06:36:12PM +0200, Samuel Ortiz wrote: Hi Santosh, On Mon, Jul 27, 2009 at 11:30:48AM +0530, Santosh Shilimkar wrote: From: Russell King rmk+ker...@arm.linux.org.uk (Rebased on 2.6.31-rc4) The TWL4030 IRQ handler has a bug which leads to spinlock lock-up. It is calling the 'unmask' function in a process context. :The mask/unmask/ack functions are only designed to be called from the IRQ handler code, or the proper API interfaces found in linux/interrupt.h. Also there is no need to have IRQ chaining mechanism. The right way to handle this is to claim the parent interrupt as a standard interrupt and arrange for handle_twl4030_pih to take care of the rest of the devices. I'd like this one to be split in 2 different patches as you're addressing 2 different issues here. You'd like me to remove the IRQ handling entirely from this code as one patch, thereby breaking it, and then add the new IRQ handling as a separate patch? Are you sure? I really don't think so, and I suspect you haven't even read the patch. It's all _one_ issue, with two explainations of why the current code is wrong. So my reply is: unable to split patch. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
CCing Jesslyn Abdul Salam jesslyn.abdulsa...@gmail.com Hope he has one osk. On Mon, Aug 3, 2009 at 10:53 AM, Arun KS aru...@mistralsolutions.com wrote: On Mon, Aug 3, 2009 at 7:00 AM, Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Jarkko Nikula wrote: On Mon, 3 Aug 2009 03:32:04 +0200 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: This patch tries to correct the problem of full duplex mode not working over a single McBSP based CPU DAI. Created against linux-2.6.31-rc5. Tested on Amstrad Delta. Do you have some specific test case how to trigger this? I haven't seen this on 2420 or 34xx (e.g. with 'arecord -d 1 -f dat |aplay') but I have no doubt that this can happen on 1510. At least this doesn't cause any harm on Beagle so I'm fine with the fix. Hi, I made more testing on my OMAP1510 and found out that I could get your example usage working without my patch, but only if started like this: arecord -D hw:0,0 -f S16_LE|aplay -D hw:0,0 If I start the same with -D hw:0,0 omitted from aplay, it doesn't work any longer, waiting forever. It definitelly doesn't work if I start capture and playback one after another, no matter which one goes first (record while playing or play while recording). So it looks like starting both streams simultaneously can do the job, but a short delay breaks it. With my patch, it seems to work fine for me in all cases. Jarkko, have you ever tried it on your OMAP2/3 with parallel playback and capture started one after another, not simultaneously? Arun, can your snd-soc-osk9512 work on OMAP1610 in full duplex mode without any limitations? Janusz, Haven't done testing in full duplex mode. I don't have access to osk5912 board now. If someone has got osk and do the testing it ll be good. It ll take at least another 2 more month for me to do the testing on osk. Regards, Arun If the problem appears to be OMAP1510 or AMS_DELTA specific, I can add a check for a machine or cpu type to avoid braking unaffected machines. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: VDD2 setting question
Koen, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Koen Kooi Sent: Monday, August 03, 2009 9:49 AM To: Linux OMAP Users Subject: VDD2 setting question I'm to trying to lower VDD2 on beagleboard to something slightly below 1V instead of the current slightly above 1V setting, but I'm having a VDD2 is tied to OMAP voltage, am I right? OPP2 and OPP3 are respectively at 1.15 and 1.06 or there abouts if I am not wrong - since VDD2 essentially drives core domain (including L3 and SDRAM as a result), you really don't want to move the voltage lower without considering the implications. Smartreflex is the guy who can measure various points on OMAP and decide if the voltage can safely be lowered without impacting device behavior. hard time figuring out how to do that in the linux-omap (non-PM) tree. I grepped in (admittedly 2.6.29) arch/arm/mach-omap2 and it only returned hits that seem to be related to smartreflex. Now, enabling If you still insist on doing this, see arch/arm/mach-omap2/omap3-opp.h And the most important question: o Would a patch to lower the default value of VDD2 be accepted into the tree? Can it be lowered globally or should it be guarded with an machine_is_omap3beagle() clause? I don't think this is even valid. 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: drivers that require headers in mach-omap
Thanks for the input guys, Another case (currently not in omap-linux), if when the ohci-omap.c driver needs to check, val = cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_IDLEST) if (val OMAP3430ES2_ST_USBHOST_STDBY_MASK) when putting the ohci bus into suspend (which I don't think the current ohci-omap.c currently supports) currently we just have a platform_data callback into the board file, but this really feels like omap specific and would be silly for every board file to implement this if they wanted ohci bus suspend. -- Mike On Mon, Aug 3, 2009 at 3:49 AM, Lohithakshan, Ranjithranji...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Monday, August 03, 2009 5:04 AM To: Pandita, Vikram Cc: Mike Chan; Kevin Hilman; linux-omap@vger.kernel.org Subject: RE: drivers that require headers in mach-omap On Fri, 31 Jul 2009, Pandita, Vikram wrote: -Original Message- From: Mike Chan [mailto:m...@android.com] Sent: Thursday, July 30, 2009 6:20 PM To: Pandita, Vikram Cc: Kevin Hilman; linux-omap@vger.kernel.org Subject: Re: drivers that require headers in mach-omap On Thu, Jul 30, 2009 at 8:44 AM, Pandita, Vikramvikram.pand...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mike Chan Sent: Tuesday, July 28, 2009 8:49 PM To: Kevin Hilman; linux-omap@vger.kernel.org Subject: drivers that require headers in mach-omap Omap folks, how are drivers that require access to prm and cm registers via cm_read_mod_reg() etc... suppose to access these? For example if drivers/usb/host/ohci-omap.c wanted to call: cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_IDLEST); The design was supposed to encapsulate the PRCM API's from drivers. Driver has control over the iclk and fclk and the clock framework would take care of any CM/PRM register settings. Accessing these registers in drivers would make the driver non-compatible for non-omap platforms. Are drivers such as drivers/usb/host/ohci-omap.c drivers/usb/musb/omap2430.c suppose to be compatible for non-omap platforms? As you put it, no they are not. All PRM/CM register accesses have been restricted to mach-omap2/plat-omap parts till now. The question to ask is, what functionality is missing on enabling say the usbhost clock that clock framework is not doing, that driver has a need to do. Just to follow up on this: the plan should be to remove all PRM and CM references from those drivers. Some of those can be replaced with clock framework calls, others may need platform_data function pointers. To add to the list, drivers/usb/host/ehci-omap.c need a similar re-work. At the moment, it does some amount of DPLL5 programming in itself before enabling the iclk and fclk. - 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 -- 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: Enabling TPS65950 / TWL4030 Real-time clock functions
On Sat, Aug 1, 2009 at 9:56 AM, Elvis Dowsonelvis.dow...@mac.com wrote: Hi, I am using a Gumstix Overo Earth (TI OMAP 3503) and this has a TPS69590/TWL4030 module, which I understand has a real-time clock subsystem. Is there support in the linux 2.6.29 or 2.6.31 kernel for enabling the RTC functions? I would like to preserve the system data and time between reboots. I've seen a 32Khz RTC clock option in the linux kernel. Is there a separate pin for a small battery just to keep supplying power to the RTC module? It looks like VBACKUP can probably be used for this. It will power the RTC rail if the main battery goes down. Will this work for you? Cliff -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, August 03, 2009 2:36 AM
To: Sonasath, Moiz
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Menon,
Nishanth; Pandita, Vikram
Subject: Re: [PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153
Hello Moiz,
A few remaining comments, most of these from an earlier message.
On Tue, 21 Jul 2009, Sonasath, Moiz wrote:
When an XRDY/XDR is hit, wait for XUDF before writing data to DATA_REG.
Otherwise some data bytes can be lost while transferring them from the
memory to the I2C interface.
Do a Busy-wait for XUDF, before writing data to DATA_REG. While waiting
if there is NACK | AL, set the appropriate error flags, ack the pending
interrupts and return from the ISR.
Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Vikram panditavikram.pand...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 24 +++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-
omap.c
index 05b5e4c..8deaf87 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -672,9 +672,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
break;
}
+ err = 0;
+complete:
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
- err = 0;
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -764,6 +765,27 @@ omap_i2c_isr(int this_irq, void *dev_id)
data to send\n);
break;
}
+
+ /*
+* OMAP3430 Errata 1.153: When an XRDY/XDR
+* is hit, wait for XUDF before writing data
+* to DATA_REG. Otherwise some data bytes can
+* be lost while transferring them from the
+* memory to the I2C interface.
+*/
Based on this description, shouldn't this patch also zero the transmit
FIFO threshold? Consider what the transmit path becomes after this patch:
1. Fill transmit FIFO
2. Leave ISR wait for interrupt
3. Interrupt happens due to XDR/XRDY (transmit FIFO low-water-mark
reached)
4. Busy-wait until transmit FIFO shift register completely empty
5. If more data to send, go to step #1
i2c-omap.c currently sets the transmit FIFO threshold to 1/2 of the total
FIFO size[1]. This means that, in the worst case, I2C3, the I2C ISR will
busy-wait in step 4 for the time it takes 32 bytes to be transmitted.
This is time that the MPU spends doing nothing but spinning, wasting
power. This seems unnecessary and wasteful. The time the driver spends
busy-waiting in the ISR should be reduced to the lowest possible duration.
To do this, what I suggest that you additionally do in the patch is to
reduce the transit FIFO threshold/low-water-mark, controlled by
I2C_BUF.XTRSH, to the lowest possible value. This should maximize the
time spent between steps 2 and 3 and minimize the time spent between steps
3 and 5.
Is there a reason why this can't be done?
Yes, this is actually lined up in my list of actions. I will be working on this
to test the functionality and stability of I2C code with the threshold set to
zero.
+
+ if (cpu_is_omap34xx()) {
Does this erratum apply to the I2C IP block on OMAP2430? It also has FIFO
transmit capability. It would be ideal if you can find out from the I2C
IP block designers. If you cannot, please consider adding a comment that
this may also apply to the I2C block on OMAP2430.
In general it is best to enable these workarounds based on the I2C IP
block's own revision register contents, not the OMAP CPU type. The goal
is to remove all these OMAP-specific cpu_is_omap() macros from
device drivers. For example, what if a future DaVinci part uses the same
I2C IP block?
Yes this is the right way.
I am checking with the IP team and will get back on this action item.
+ while (!(stat
OMAP_I2C_STAT_XUDF)) {
Is there a reason why you can't just reuse the main while() loop in the
ISR, and add a state variable to handle any special casing needed in this
context? That will avoid this separate while() loop.
The problem with using the main while() loop is the counter 'count' associated
with it as I am not sure if the count value of 100 is enough wait time for
allowing the XUDF bit to set and if we can come up with an accurate wait count
to be used there.
The idea is that if the hardware is functional, XUDF bit will be set once the
FIFO and shift registers are
Re: Enabling TPS65950 / TWL4030 Real-time clock functions
Hi Cliff, Yes, that looks good! It might just work! Best regards, Elvis On Aug 3, 2009, at 11:34 PM, Cliff Brake wrote: On Sat, Aug 1, 2009 at 9:56 AM, Elvis Dowsonelvis.dow...@mac.com wrote: Hi, I am using a Gumstix Overo Earth (TI OMAP 3503) and this has a TPS69590/TWL4030 module, which I understand has a real-time clock subsystem. Is there support in the linux 2.6.29 or 2.6.31 kernel for enabling the RTC functions? I would like to preserve the system data and time between reboots. I've seen a 32Khz RTC clock option in the linux kernel. Is there a separate pin for a small battery just to keep supplying power to the RTC module? It looks like VBACKUP can probably be used for this. It will power the RTC rail if the main battery goes down. Will this work for you? Cliff -- 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] I2C: OMAP3: PM: (re)init for every transfer to support off-mode
Ben Dooks wrote:
On Tue, Jul 21, 2009 at 04:09:03PM -0700, Kevin Hilman wrote:
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.)
Also, The OMAP3430 TRM states:
During active mode (I2Ci.I2C_CON[15] I2C_EN bit is set to 1), make no
changes to the I2Ci.I2C_SCLL and I2Ci.I2C_SCLH registers. Changes may
result in unpredictable behavior.
Hence, the I2C_EN bit should be clearer when modifying these
registers. Please note that clearing the entire I2C_CON register to
disable the I2C module is safe, because the I2C_CON register is
re-configured for each transfer.
should this be applied as a bugfix, or kept for next merge window?
next merge window is fine.
Thanks,
Kevin
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
Cc: Jon Hunter jon-hun...@ti.com
Cc: Hu Tao ta...@motorola.com
Cc: Xiaolong Chen a21...@motorola.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
This patch has been tested extensively as part of the OMAP 'PM branch'
drivers/i2c/busses/i2c-omap.c | 64 ++--
1 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ad8d201..bb8ae50 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,18 @@ 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_CON_REG, 0);
+ 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);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
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 +273,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;
@@ -287,24 +302,22 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
SYSC_AUTOIDLE_MASK);
} 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;
+
Re: Question about tput constraint on zoom2 camera
Paul Walmsley wrote: Hello Dominic, On Sun, 2 Aug 2009, Curran, Dominic wrote: From: Paul Walmsley [p...@pwsan.com] Sent: Saturday, August 01, 2009 9:57 PM On Fri, 31 Jul 2009, Curran, Dominic wrote: I have been testing the zoom2 camera streaming while using different OPP's. Following table provides summary of what OPP's caused to happen: Streaming Vdd1(OPP)Vdd2(OPP) P/F VGA @ 30fps 12 Pass 8MP @ 7.5fps 12 Fails (stop streaming) 8MP @ 7.5fps 13 Pass So table shows that locking Vdd2 to OPP=3 when streaming 8MPixel works, but at OPP=2 then streaming fails (stops). So I thought the tput constraint made the most sense for camera. The Zoom2 camera sensor has a max tput of: 3280 x 2464 x 2bpp x 7.5fps = 121228800 bytes/s = 118387 KB/s However, this calculated value doesn't constrain Vdd2 to OPP3 (DVFS enabled). Experimentation shows that a tput value of 35 KB/s is required to constrain Vdd2 to OPP=3. Can you explain why the practical tput constraint is so much greater than the theoretical value ? Probably it is mostly due to two reasons: 1. most other L3 initiator drivers (eg., for DSS, SDMA, USB, etc) don't currently set bus throughput constraints, so we aren't currently adding in their interconnect usage; and 2. the interconnect throughput model in omap-pm-srf.c is optimistic. A couple of questions for you: (please forgive my ignorance of the camera subsystem): A. What other L3 initiators are active during the test? Presumably DSS, MPU? IVA2? B. I am assuming you are using the CCP2. What do you have CCP2_CTRL.BURST set to? This could impact interconnect utilization. - Paul Hi Paul No DSS (i'm just printing a '.' when i dequeue a frame). No IVA2. No per pixel processing by the ARM. I was trying to keep me testing as simple as possible. HOWEVER, your questions have made me think of something else which i think _may_ explain everything. The camera pipe should look like this: Sensor -- CSI2 Receiver -- CCDC -- PREVIEWER -- RESIZER -- MEM But because of a hardware bug, data has to be written to memory by Previewer and then read by Resizer. Thus a 'workaround' buffer is allocated for this purpose. Its not pretty but its the only way we can have Preview Resizer in the pipe at the same time. So the pipeline actually looks like this: Sensor -- CSI2 Receiver -- CCDC -- PREVIEWER -- Workaround MEM -- RESIZER -- MEM Thus in order to get a single pixel through the pipe there has to be three L3 operations: 1) Write to workaround mem 2) Read from workaround mem 3) Write to final memory This seems to me like it actually increases the tput by 3x. 118387 KB/s x 3 = 355161 KB/s Which looks like it is very close to the number I found in practice (35). Does this seem like a reasonable explanation to you ? It does indeed. Thanks for the explanation of the ISP pipelines. Dominic, Please be sure to update the changelog in your patch to describe the pipeline and workaround mem which leads to your tput number. Thanks, 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
arch/arm/mach-omap* organization
Is there a reason why omap2, omap3, and now omap4 files are all packed into the mach-omap2 directory? It seems like it would make more sense for each omap version to have it's own directory. -Ben Goska -- 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
