RE: [PATCH] i2c-omap: Set latency requirements only once for several messages
Hello Ben, Samu, On Fri, 3 Dec 2010, samu.p.onk...@nokia.com wrote: -Original Message- From: ext Ben Dooks [mailto:ben-...@fluff.org] Sent: 03 December, 2010 04:38 To: Onkalo Samu.P (Nokia-MS/Tampere) Cc: ben-li...@fluff.org; linux-...@vger.kernel.org; khil...@deeprootsystems.com; p...@pwsan.com; linux-omap@vger.kernel.org Subject: Re: [PATCH] i2c-omap: Set latency requirements only once for several messages On Thu, Nov 18, 2010 at 12:04:20PM +0200, Samu Onkalo wrote: Ordinary I2C read consist of two messages. First a write operation to tell register address and then read operation to get data. CPU wake up latency is set and removed twice in read case. Set latency requirement before the message processing loop and remove the requirement after the loop to remove latency adjustment operations between the messages. Signed-off-by: Samu Onkalo samu.p.onk...@nokia.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Acked-by: Paul Walmsley p...@pwsan.com I'll queue this for -rc unless it is going in via the omap list or it should wait for merge window? I first sent this to omap-list and I got instructions to send this to you. So I assume that you should queue this. Kevin, Paul, is -rc ok for you? I'd suggest that this go in through Ben, and go in as part of the 2.6.38 merge window, rather than the .37-rc. The patch doesn't fix any regressions introduced in the 2.6.37 merge window, and there's no impact on system stability, as far as I know. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7] OMAP2+: PM: omap device: API's for handling mstandby mode
On 12/2/2010 2:59 PM, G, Manjunath Kondaiah wrote: Certain errata in OMAP2+ processors will require forcing master standby to no standby mode before completing on going operation. Without this, the results will be unpredictable. Since current implementation of PM run time framework does not support changing sysconfig settings during middle of the on going operation, these API's will support the same. One API will force the device's sysconfig mstandby mode settings to no standby and other API will release no standby mode and sets it to smart standby or no standby? depending on HWMOD_SWSUP_MSTANDBY value. The hwmod API omap_hwmod_set_master_standbymode will use no_stdby_cnt(introduced in omap_hwmod structure) for controlling access to sysconfig register settings in case of overlapping request/release API's are called. It also disables interrupts during syconfig register access. These API's should be used by device drivers only incase of erratum applicable to their modules if there is no other methods to resolve. These API's are required for multiple DMA errata which require putting DMA controller in no mstandby mode before stopping dma. The applicable errata: 1. Erratum ID: i557(Applicable for omap36xx all ES versions) The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared through config port while in Standby. 2. Erratum ID: i541 sDMA FIFO draining does not finish. Applicable to all omap2+ except omap4. 3. Erratum ID:i88 The sDMA to be put in no mstandby mode before disabling the channel after completing the data transfer operation. Applicable only for OMAP3430 ES1.0 Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in omap_hwmod.h Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com Cc: Kevin Hilmankhil...@deeprootsystems.com Cc: Paul Walmsleyp...@pwsan.com Cc: linux-arm-ker...@lists.infradead.org You have to CC lakml during send-email, but it should not be in the changelog. On the other hand, it is a good practice to add all the authors of the file you change in CC. --- v3: Review comments incorporated for: https://patchwork.kernel.org/patch/282212/ v4: added mutex changes https://patchwork.kernel.org/patch/338611/ v5: typo fixes for errata and erratum https://patchwork.kernel.org/patch/352481/ v6: fixed oh increment bug and also mutex(missing in v5) https://patchwork.kernel.org/patch/372231/ v7: replaced mutex lock with spin lock. Added use count for controlling access to sysconfig registers in case if overlapping request/release API's are used. I'm not sure it should be done here. I'd rather keep that code in the DMA, since this is the only user of that feature. These hwmod APIs are rather low level and should never be used except for workaround. So I'd prefer keeping this API simple and not sexy at all in order to prevent people to abuse it. Regards, Benoit -- 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 0/5] Split powerdomain framework into plat specific/independent
Hi Rajendra, On Thu, 2 Dec 2010, Rajendra Nayak wrote: This seems to be popping up with powerdomains.h file (which now has func declarations) being included in multiple source files. It earlier had only static structs and was included in one source file. I thought the right way to fix this was to probably move the static structs from the header into a source file. See if the below patch makes sense. Also attached as I don't trust my mailer. Yes, that general approach looks fine to me. I've got some patches here that will be posted once this powerdomain series is done to convert all the remaining static allocations in .h files into .c files. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mainline OMAP3 breakage (and other OMAP?)
On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
On Thu, Dec 02, 2010 at 02:32:08PM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [101202 14:06]:
On Thu, Dec 02, 2010 at 01:58:38PM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [101202 13:04]:
This has been around since October:
drivers/video/omap2/vram.c: In function
???omap_vram_reserve_sdram_memblock???:
drivers/video/omap2/vram.c:573: error: ???MEMBLOCK_REAL_LIMIT???
undeclared (first use in this function)
drivers/video/omap2/vram.c:573: error: (Each undeclared identifier is
reported only once
drivers/video/omap2/vram.c:573: error: for each function it appears
in.)
This requires a trivial one-liner compile fix:
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index fed2a72..a8973f0 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -570,7 +570,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
return;
}
} else {
- paddr = memblock_alloc_base(size, PAGE_SIZE,
MEMBLOCK_REAL_LIMIT);
+ paddr = memblock_alloc(size, PAGE_SIZE);
}
omap_vram_add_region(paddr, size);
which restores the old behaviour before the X86 memblock changes went
in. Yes, there may be other changes due to the ioremap stuff, but
that's really no excuse for not fixing the compile error itself.
Great. Adding fbdev and Tomi to Cc.
Acked-by: Tony Lindgren t...@atomide.com
http://marc.info/?l=linux-omapw=2r=1s=MEMBLOCK_REAL_LIMIT%20vramq=b
There have been patches posted throughout November to fix this, but
the problem is they're not making it to mainline. It needs chasing
until someone does the right thing and sends one variant of the above
patch, rather than just leaving it until the ioremap fixes hit
mainline during the next merge window.
Yes this should go in during the -rc for sure.
I suggest you merge this but let's wait a bit and check if Tomi
already has a similar fix queued for the -rc series.
This has been fixed since -rc2.
So it is. However, the ioremap fix is wrong.
} else {
paddr = memblock_alloc(size, PAGE_SIZE);
}
memblock_free(paddr, size);
memblock_remove(paddr, size);
Didn't I say that such blocks were supposed to be aligned to a 2MB
boundary - and the size also so aligned?
http://lists.arm.linux.org.uk/lurker/message/20101011.152516.893a6088.en.html
It at least needs to be 1MB as that's the section size.
--
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 0/5] Split powerdomain framework into plat specific/independent
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Friday, December 03, 2010 2:11 PM To: Rajendra Nayak Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; Benoit Cousson Subject: RE: [PATCH v2 0/5] Split powerdomain framework into plat specific/independent Hi Rajendra, On Thu, 2 Dec 2010, Rajendra Nayak wrote: This seems to be popping up with powerdomains.h file (which now has func declarations) being included in multiple source files. It earlier had only static structs and was included in one source file. I thought the right way to fix this was to probably move the static structs from the header into a source file. See if the below patch makes sense. Also attached as I don't trust my mailer. Yes, that general approach looks fine to me. I've got some patches here that will be posted once this powerdomain series is done to convert all the remaining static allocations in .h files into .c files. Ok, so I'll repost the series with this patch included as well so that the warnings are'nt thrown anymore. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: pm.c correct the initcall for an early init.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, December 02, 2010 7:03 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init. Thara Gopinath th...@ti.com writes: omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation Why postcore? there are several other inicalls earlier than device_initcall. Because the init in omap_device is a core_initcall. With respect to opp layer, making this anything above device_initcall will work. But then tomorrow some other module needs these generic devices in their init, we will again have to bump up the init priority of this fn. It is a good thing to do this early on in the boot cycle rather than later. Also, does this actually work? Is the driver core initialized at postcore_initcall time such that omap_devices w/platform_device creation actually works? Yes by post_initcall the omap_device initializations would have happened. In fact these initializations happen as core_initcall. Kevin Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/pm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index 59ca03b..6ec2ee1 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -143,5 +143,5 @@ static int __init omap2_common_pm_init(void) return 0; } -device_initcall(omap2_common_pm_init); +postcore_initcall(omap2_common_pm_init); -- 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 v7] OMAP2+: PM: omap device: API's for handling mstandby mode
* Cousson, Benoit b-cous...@ti.com [2010-12-03 09:38:35 +0100]: On 12/2/2010 2:59 PM, G, Manjunath Kondaiah wrote: Certain errata in OMAP2+ processors will require forcing master standby to no standby mode before completing on going operation. Without this, the results will be unpredictable. Since current implementation of PM run time framework does not support changing sysconfig settings during middle of the on going operation, these API's will support the same. One API will force the device's sysconfig mstandby mode settings to no standby and other API will release no standby mode and sets it to smart standby or no standby? depending on HWMOD_SWSUP_MSTANDBY value. The hwmod API omap_hwmod_set_master_standbymode will use no_stdby_cnt(introduced in omap_hwmod structure) for controlling access to sysconfig register settings in case of overlapping request/release API's are called. It also disables interrupts during syconfig register access. These API's should be used by device drivers only incase of erratum applicable to their modules if there is no other methods to resolve. These API's are required for multiple DMA errata which require putting DMA controller in no mstandby mode before stopping dma. The applicable errata: 1. Erratum ID: i557(Applicable for omap36xx all ES versions) The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared through config port while in Standby. 2. Erratum ID: i541 sDMA FIFO draining does not finish. Applicable to all omap2+ except omap4. 3. Erratum ID:i88 The sDMA to be put in no mstandby mode before disabling the channel after completing the data transfer operation. Applicable only for OMAP3430 ES1.0 Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in omap_hwmod.h Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com Cc: Kevin Hilmankhil...@deeprootsystems.com Cc: Paul Walmsleyp...@pwsan.com Cc: linux-arm-ker...@lists.infradead.org You have to CC lakml during send-email, but it should not be in the changelog. On the other hand, it is a good practice to add all the authors of the file you change in CC. --- v3: Review comments incorporated for: https://patchwork.kernel.org/patch/282212/ v4: added mutex changes https://patchwork.kernel.org/patch/338611/ v5: typo fixes for errata and erratum https://patchwork.kernel.org/patch/352481/ v6: fixed oh increment bug and also mutex(missing in v5) https://patchwork.kernel.org/patch/372231/ v7: replaced mutex lock with spin lock. Added use count for controlling access to sysconfig registers in case if overlapping request/release API's are used. I'm not sure it should be done here. I'd rather keep that code in the DMA, since this is the only user of that feature. Are you referring to spin lock or usage count? -Manjunath -- 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: Unbalanced IRQ wake disable during resume from static suspend
Hi Kevin
On Thu, 2 Dec 2010, Kevin Hilman wrote:
I guess this hasn't been seen before since we haven't tested the sysfs
wakeup interface for the omap-serial driver. For on-chip OMAP UARTs,
using the sysfs interface isn't needed as the serial core is already
doing device_init_wakeup(dev, true);
Is this the code you're referring to, in serial_core.c?
tty_dev = tty_register_device(drv-tty_driver, uport-line, uport-dev);
if (likely(!IS_ERR(tty_dev))) {
device_init_wakeup(tty_dev, 1);
device_set_wakeup_enable(tty_dev, 0);
} else
I may be misreading it, but it appears that the code leaves wakeups
disabled for the serial port, by default.
As an aside, this code is somewhat perplexing: it doesn't seem accurate to
assume that every serial device really is capable of waking up the system.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Unbalanced IRQ wake disable during resume from static suspend
Hello Santosh On Thu, 2 Dec 2010, Santosh Shilimkar wrote: Just a wild guess here but is this because the 'set_wake' is not setup and then fw might be returning some error whenever driver invoke this API as part of enable_irq_wake() callback If that being the case, below patch might might help. Can somebody try this out ? This patch might remove the warnings, but I doubt that it solves the root cause. In any case, it doesn't seem correct to unconditionally return 0 (success) from an omap_irq_wake() function, given that the OMAP INTC has no functionality in this regard. The real problem appears to be in drivers/serial/serial_core.c. uart_suspend_port() doesn't check the return value of enable_irq_wake(). Seems to me that it needs to save that return value somewhere and not bother calling disable_irq_wake() in uart_resume_port() if enable_irq_wake() returned an error. That's the patch that I'd suggest that you guys put together and send to the Linux serial people. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UART RX wakeup from sleep not working
Hi Rick On Thu, 2 Dec 2010, Rick Bronson wrote: If the OMAP is in full-chip retention, the UART's asynchronous wakeup mechanism won't work, which appears to be what you're trying to use. That will only work when PER is fully powered, as far as I know. You'll need to use the IO chain wakeup feature instead. My guess is that you need to make sure that your UART input pads have the WAKEUPENABLE bits set in the CONTROL_PADCONF registers. I think that should do it. I put debug code in and the IO chain wakeup feature is enabled and the WAKEUPENABLE bit is set on the pad in question. With the IO chain feature what's the wakeup mechanism? It's described in the 34xx TRM sections 4.11.2 Device Off-Mode Configuration and 4.11.3 CORE Power Domain Off-Mode Sequences. All the references to off-mode just confuse things, since AFAIK, this wakeup mechanism also applies to the device in full-chip retention (see also the 'NOTE:' portion of section 4.8.4 Device Wake-Up Events). Does it generate an interrupt? An IO chain/ring wakeup event ultimately should generate a PRCM interrupt, which should wind up in mach-omap2/pm34xx.c:prcm_interrupt_handler(). You might want to put some debugging in prcm_clear_mod_irqs(), first to see if that function is getting called, and second, to output the state of the WKST and GRPSEL registers. I've updated my assumptions: Assumptions (using UART3) 1. OMAP3730 is in sleep mode via echo 1 /mnt/dbg/pm_debug/sleep_while_idle 2. The UARTi.SCR_REG[4] RX_CTS_WU_EN bit is set to 1. 3. The UARTi.IER_REG[4] SLEEP_MODE bit to 1 4. The UARTi.SYSC_REG[2] ENAWAKEUP bit is set to 1 5. The UARTi.WER_REG EVENT_4_RX_ACTIVITY bit is set to 1 6. The UARTi.SSR_REG RX_CTS_DSR_WAKE_UP_STS bit is set to 1 7. The PRCM.PM_WKEN_WKUP EN_IO_CHAIN bit is set to 1 via omap3_enable_io_chain() 8. The PRCM.PM_WKEN_WKUP[8] EN_IO bit is set to 1 via omap3_enable_io_chain() 9. CONTROL_PADCONF_UART3_RTS_SD[14] WAKEUPENABLE0 is set to 1 10. CONTROL_PADCONF_UART3_RTS_SD INPUTENABLE is set to 1 This may be a stupid question, but are you using serial flow control? If not, enabling wakeup on the RTS line isn't going to help. Just out of curiosity, which kernel are you using? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UART RX wakeup from sleep not working
By the way, if you're using a really recent kernel, you may want to see if sending a few breaks down the line wakes it up: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39735.html Based on your problem description, I doubt this will help, but it's worth a try. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Unbalanced IRQ wake disable during resume from static suspend
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Friday, December 03, 2010 3:53 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; Govindraj; khil...@deeprootsystems.com Subject: RE: Unbalanced IRQ wake disable during resume from static suspend Hello Santosh On Thu, 2 Dec 2010, Santosh Shilimkar wrote: Just a wild guess here but is this because the 'set_wake' is not setup and then fw might be returning some error whenever driver invoke this API as part of enable_irq_wake() callback If that being the case, below patch might might help. Can somebody try this out ? This patch might remove the warnings, but I doubt that it solves the root cause. In any case, it doesn't seem correct to unconditionally return 0 (success) from an omap_irq_wake() function, given that the OMAP INTC has no functionality in this regard. The real problem appears to be in drivers/serial/serial_core.c. uart_suspend_port() doesn't check the return value of enable_irq_wake(). Seems to me that it needs to save that return value somewhere and not bother calling disable_irq_wake() in uart_resume_port() if enable_irq_wake() returned an error. That's the patch that I'd suggest that you guys put together and send to the Linux serial people. You are right Paul. This will actually fix the broken driver rather than masking it. Will spin a patch for the same -- 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: Unbalanced IRQ wake disable during resume from static suspend
On Fri, Dec 3, 2010 at 4:38 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, December 03, 2010 3:53 PM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; Govindraj; khil...@deeprootsystems.com
Subject: RE: Unbalanced IRQ wake disable during resume from static
suspend
Hello Santosh
On Thu, 2 Dec 2010, Santosh Shilimkar wrote:
Just a wild guess here but is this because the 'set_wake' is
not setup and then fw might be returning some error whenever
driver invoke this API as part of enable_irq_wake() callback
If that being the case, below patch might might help. Can
somebody try this out ?
This patch might remove the warnings, but I doubt that it solves the
root
cause. In any case, it doesn't seem correct to unconditionally return 0
(success) from an omap_irq_wake() function, given that the OMAP INTC has
no functionality in this regard.
The real problem appears to be in drivers/serial/serial_core.c.
uart_suspend_port() doesn't check the return value of enable_irq_wake().
Seems to me that it needs to save that return value somewhere and not
bother calling disable_irq_wake() in uart_resume_port() if
enable_irq_wake() returned an error.
That's the patch that I'd suggest that you guys put together and send to
the Linux serial people.
You are right Paul. This will actually fix the broken driver rather than
masking it. Will spin a patch for the same
Hi Santosh/Paul,
How about this patch?
[Tested on 3630SDP
---
Regards,
Govindraj.R
From cb4e79a645b530f83f55d801ab054cc438ada0dd Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Fri, 3 Dec 2010 16:42:14 +0530
Subject: [PATCH] Serial: Unbalanced IRQ wake disable during resume
from static suspend
Check for return status for enable_irq_wake if irq_wake
interface is not available then during resume unconditional
disabling of irq_wake can throw below warning.
[ cut here ]
WARNING: at kernel/irq/manage.c:382 set_irq_wake+0x80/0xe4()
Unbalanced IRQ 72 wake disable
Modules linked in:
[c0062a28] (unwind_backtrace+0x0/0xec) from [c0092260]
(warn_slowpath_common+0x4c/0x64)
[c0092260] (warn_slowpath_common+0x4c/0x64) from [c00922f8]
(warn_slowpath_fmt+0x2c/0x3c
[c00922f8] (warn_slowpath_fmt+0x2c/0x3c) from [c00d3238]
(set_irq_wake+0x80/0xe4)
[c00d3238] (set_irq_wake+0x80/0xe4) from [c029dd60]
(uart_resume_port+0x84/0x248)
[c029dd60] (uart_resume_port+0x84/0x248) from [c02a2338]
(serial_omap_resume+0x20/0x2c)
[c02a2338] (serial_omap_resume+0x20/0x2c) from [c02a92d4]
(platform_pm_resume+0x48/0x54)
[c02a92d4] (platform_pm_resume+0x48/0x54) from [c02abd1c]
(pm_op+0x6c/0xac)
[c02abd1c] (pm_op+0x6c/0xac) from [c02ac0fc]
(device_resume+0x58/0x10c)
[c02ac0fc] (device_resume+0x58/0x10c) from [c02ac2ec]
(dpm_resume_end+0xf4/0x360)
[c02ac2ec] (dpm_resume_end+0xf4/0x360) from [c00cf58c]
(suspend_devices_and_enter+0x1ac/0x200)
[c00cf58c] (suspend_devices_and_enter+0x1ac/0x200) from [c00cf6c0]
(enter_state+0xe0/0x138)
[c00cf6c0] (enter_state+0xe0/0x138) from [c00ced18]
(state_store+0x90/0xb8)
[c00ced18] (state_store+0x90/0xb8) from [c0243b98]
(kobj_attr_store+0x18/0x1c)
[c0243b98] (kobj_attr_store+0x18/0x1c) from [c0176128]
(sysfs_write_file+0x10c/0x144)
[c0176128] (sysfs_write_file+0x10c/0x144) from [c0125528]
(vfs_write+0xac/0x134)
[c0125528] (vfs_write+0xac/0x134) from [c012565c]
(sys_write+0x3c/0x68)
[c012565c] (sys_write+0x3c/0x68) from [c005bb00]
(ret_fast_syscall+0x0/0x3c)
---[ end trace 19fe50b7b47ba94f ]---
Thus add a flag to check the return status for irq_wake
based on flag disable the irq_wake
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
drivers/serial/serial_core.c |6 --
include/linux/serial_core.h |1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index cd85112..0466815 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -1990,7 +1990,8 @@ int uart_suspend_port(struct uart_driver *drv,
struct uart_port *uport)
tty_dev = device_find_child(uport-dev, match, serial_match_port);
if (device_may_wakeup(tty_dev)) {
- enable_irq_wake(uport-irq);
+ if (!enable_irq_wake(uport-irq))
+ uport-irq_wake = 1;
put_device(tty_dev);
mutex_unlock(port-mutex);
return 0;
@@ -2056,7 +2057,8 @@ int uart_resume_port(struct uart_driver *drv,
struct uart_port *uport)
tty_dev = device_find_child(uport-dev, match, serial_match_port);
if (!uport-suspended device_may_wakeup(tty_dev)) {
- disable_irq_wake(uport-irq);
+ if (uport-irq_wake)
+ disable_irq_wake(uport-irq);
mutex_unlock(port-mutex);
return 0;
}
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
RE: Unbalanced IRQ wake disable during resume from static suspend
-Original Message-
From: Govindraj [mailto:govindraj...@gmail.com]
Sent: Friday, December 03, 2010 4:51 PM
To: Santosh Shilimkar
Cc: Paul Walmsley; linux-omap@vger.kernel.org;
khil...@deeprootsystems.com
Subject: Re: Unbalanced IRQ wake disable during resume from static
suspend
On Fri, Dec 3, 2010 at 4:38 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, December 03, 2010 3:53 PM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; Govindraj;
khil...@deeprootsystems.com
Subject: RE: Unbalanced IRQ wake disable during resume from static
suspend
Hello Santosh
On Thu, 2 Dec 2010, Santosh Shilimkar wrote:
Just a wild guess here but is this because the 'set_wake' is
not setup and then fw might be returning some error whenever
driver invoke this API as part of enable_irq_wake() callback
If that being the case, below patch might might help. Can
somebody try this out ?
This patch might remove the warnings, but I doubt that it solves the
root
cause. In any case, it doesn't seem correct to unconditionally
return
0
(success) from an omap_irq_wake() function, given that the OMAP INTC
has
no functionality in this regard.
The real problem appears to be in drivers/serial/serial_core.c.
uart_suspend_port() doesn't check the return value of
enable_irq_wake().
Seems to me that it needs to save that return value somewhere and not
bother calling disable_irq_wake() in uart_resume_port() if
enable_irq_wake() returned an error.
That's the patch that I'd suggest that you guys put together and send
to
the Linux serial people.
You are right Paul. This will actually fix the broken driver rather
than
masking it. Will spin a patch for the same
Hi Santosh/Paul,
How about this patch?
Looks inline with what Paul suggested.
[Tested on 3630SDP
---
Regards,
Govindraj.R
From cb4e79a645b530f83f55d801ab054cc438ada0dd Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Fri, 3 Dec 2010 16:42:14 +0530
Subject: [PATCH] Serial: Unbalanced IRQ wake disable during resume
from static suspend
Check for return status for enable_irq_wake if irq_wake
interface is not available then during resume unconditional
disabling of irq_wake can throw below warning.
[ cut here ]
WARNING: at kernel/irq/manage.c:382 set_irq_wake+0x80/0xe4()
Unbalanced IRQ 72 wake disable
Modules linked in:
[c0062a28] (unwind_backtrace+0x0/0xec) from [c0092260]
(warn_slowpath_common+0x4c/0x64)
[c0092260] (warn_slowpath_common+0x4c/0x64) from [c00922f8]
(warn_slowpath_fmt+0x2c/0x3c
[c00922f8] (warn_slowpath_fmt+0x2c/0x3c) from [c00d3238]
(set_irq_wake+0x80/0xe4)
[c00d3238] (set_irq_wake+0x80/0xe4) from [c029dd60]
(uart_resume_port+0x84/0x248)
[c029dd60] (uart_resume_port+0x84/0x248) from [c02a2338]
(serial_omap_resume+0x20/0x2c)
[c02a2338] (serial_omap_resume+0x20/0x2c) from [c02a92d4]
(platform_pm_resume+0x48/0x54)
[c02a92d4] (platform_pm_resume+0x48/0x54) from [c02abd1c]
(pm_op+0x6c/0xac)
[c02abd1c] (pm_op+0x6c/0xac) from [c02ac0fc]
(device_resume+0x58/0x10c)
[c02ac0fc] (device_resume+0x58/0x10c) from [c02ac2ec]
(dpm_resume_end+0xf4/0x360)
[c02ac2ec] (dpm_resume_end+0xf4/0x360) from [c00cf58c]
(suspend_devices_and_enter+0x1ac/0x200)
[c00cf58c] (suspend_devices_and_enter+0x1ac/0x200) from [c00cf6c0]
(enter_state+0xe0/0x138)
[c00cf6c0] (enter_state+0xe0/0x138) from [c00ced18]
(state_store+0x90/0xb8)
[c00ced18] (state_store+0x90/0xb8) from [c0243b98]
(kobj_attr_store+0x18/0x1c)
[c0243b98] (kobj_attr_store+0x18/0x1c) from [c0176128]
(sysfs_write_file+0x10c/0x144)
[c0176128] (sysfs_write_file+0x10c/0x144) from [c0125528]
(vfs_write+0xac/0x134)
[c0125528] (vfs_write+0xac/0x134) from [c012565c]
(sys_write+0x3c/0x68)
[c012565c] (sys_write+0x3c/0x68) from [c005bb00]
(ret_fast_syscall+0x0/0x3c)
---[ end trace 19fe50b7b47ba94f ]---
Thus add a flag to check the return status for irq_wake
based on flag disable the irq_wake
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
drivers/serial/serial_core.c |6 --
include/linux/serial_core.h |1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index cd85112..0466815 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -1990,7 +1990,8 @@ int uart_suspend_port(struct uart_driver *drv,
struct uart_port *uport)
tty_dev = device_find_child(uport-dev, match,
serial_match_port);
if (device_may_wakeup(tty_dev)) {
- enable_irq_wake(uport-irq);
+ if (!enable_irq_wake(uport-irq))
+ uport-irq_wake = 1;
put_device(tty_dev);
mutex_unlock(port-mutex);
return 0;
@@ -2056,7 +2057,8 @@ int uart_resume_port(struct uart_driver *drv,
struct
[PATCH v3 6/6] OMAP4: powerdomain: Add pwrdm_clear_all_prev_pwrst
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4430 ES2 has additional bitfields in PWRSTST register which help
identify the previous power state entered by the powerdomain.
Add pwrdm_clear_all_prev_pwrst api to support this.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomain44xx.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 4c828b9..33d1b69 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -55,6 +55,14 @@ static int omap4_pwrdm_set_lowpwrstchange(struct powerdomain
*pwrdm)
return 0;
}
+static int omap4_pwrdm_clear_all_prev_pwrst(struct powerdomain *pwrdm)
+{
+ prm_rmw_mod_reg_bits(OMAP4430_LASTPOWERSTATEENTERED_MASK,
+ OMAP4430_LASTPOWERSTATEENTERED_MASK,
+ pwrdm-prcm_offs, OMAP4_PM_PWSTST);
+ return 0;
+}
+
static int omap4_pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst)
{
u32 v;
@@ -155,6 +163,7 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_read_pwrst = omap4_pwrdm_read_pwrst,
.pwrdm_read_prev_pwrst = omap4_pwrdm_read_prev_pwrst,
.pwrdm_set_lowpwrstchange = omap4_pwrdm_set_lowpwrstchange,
+ .pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/6] Split powerdomain framework into plat specific/independent
OMAP4 powerdomains have some inherent differences as compared to OMAP2/3 powerdomains, starting with register offsets being different to clubbing of multiple controls into one register and in some cases splitting of control into multiple registers. There are also new features like lowpowerstatechange bits and features like HW SAR which are no longer present in the older form. Supporting all these in the existing powerdomain framework would mean adding a lot of cpu_is_* checks which makes code unmaintainable going fwd. Hence this series is an attempt to split the existing powerdomain framework into platform independent part (which does error checking, usecounting et al) which can be reused across OMAP's and hook up platform specific functions to do low level programming which varies across OMAP's. The series is boot tested on OMAP 2430sdp/3430sdp and 4430sdp platforms. Additionally on 3430sdp, Retention and OFF support in system suspend is also validated with a minimal kernel config (omap3_pm_defconfig from Kevins tree hosted here git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git) The series is based on 2.6.37-rc4 and is available here: git://gitorious.org/omap-pm/linux.git powerdomain-split-v3 regards, Rajendra Version History --- Version v3 * Additional patch to move static allocs in powerdomins.h to powerdomains_data.c * Sparse warning fixes Version v2 * powerdomain.c retained in mach-omap2 instead of moving it to plat-omap * All common powerdomain functions now in powerdomain-common.c file instead of powerdomains.c * OMAP2/3 common and specific functions in powerdomain2xxx_3xxx.c file. * Other minor review comment fixes Version v1 http://marc.info/?l=linux-omapm=128992190426815w=2 Fixes all issues discussed on the RFC series and also has a few other changes * The below patch is dropped as the dependent patches for this are still under discussion. [RFC 6/8] OMAP: PRM: split the prm accessor api funcs for omap2/3 and omap4 http://marc.info/?l=linux-omapm=128524531505429w=2 * The below patch is also dropped as there are more than one context registers to be handled in some powerdomains and hence needs to be handled differently [RFC 7/8] omap4: powerdomain: add context_offset field http://marc.info/?l=linux-omapm=128524531805435w=2 The RFC series of these patches was posted here Rajendra Nayak (5): OMAP: powerdomain: Move static allocations from powerdomains.h to a .c file OMAP: powerdomain: Infrastructure to put arch specific code OMAP: powerdomain: Arch specific funcs for state control OMAP: powerdomain: Arch specific funcs for logic control OMAP: powerdomain: Arch specific funcs for mem control Santosh Shilimkar (1): OMAP4: powerdomain: Add pwrdm_clear_all_prev_pwrst arch/arm/mach-omap2/Makefile |8 +- arch/arm/mach-omap2/clockdomains.h|5 + arch/arm/mach-omap2/io.c |3 +- arch/arm/mach-omap2/powerdomain-common.c | 111 +++ arch/arm/mach-omap2/powerdomain.c | 396 +++-- arch/arm/mach-omap2/powerdomain2xxx_3xxx.c| 227 ++ arch/arm/mach-omap2/powerdomain44xx.c | 175 +++ arch/arm/mach-omap2/powerdomains.h| 152 ++ arch/arm/mach-omap2/powerdomains_data.c | 159 ++ arch/arm/plat-omap/include/plat/powerdomain.h | 44 +++- 10 files changed, 857 insertions(+), 423 deletions(-) create mode 100644 arch/arm/mach-omap2/powerdomain-common.c create mode 100644 arch/arm/mach-omap2/powerdomain2xxx_3xxx.c create mode 100644 arch/arm/mach-omap2/powerdomain44xx.c create mode 100644 arch/arm/mach-omap2/powerdomains_data.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/6] OMAP: powerdomain: Arch specific funcs for logic control
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_logic_retst
.pwrdm_read_logic_pwrst
.pwrdm_read_prev_logic_pwrst
.pwrdm_read_logic_retst
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomain.c | 51
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 34 ++
arch/arm/mach-omap2/powerdomain44xx.c | 26 ++
3 files changed, 82 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 0ae1ebf..562a3fe 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -532,7 +532,7 @@ int pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
*/
int pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst)
{
- u32 v;
+ int ret = -EINVAL;
if (!pwrdm)
return -EINVAL;
@@ -543,17 +543,10 @@ int pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8
pwrst)
pr_debug(powerdomain: setting next logic powerstate for %s to %0x\n,
pwrdm-name, pwrst);
- /*
-* The register bit names below may not correspond to the
-* actual names of the bits in each powerdomain's register,
-* but the type of value returned is the same for each
-* powerdomain.
-*/
- v = pwrst __ffs(OMAP3430_LOGICL1CACHERETSTATE_MASK);
- prm_rmw_mod_reg_bits(OMAP3430_LOGICL1CACHERETSTATE_MASK, v,
-pwrdm-prcm_offs, pwrstctrl_reg_offs);
+ if (arch_pwrdm arch_pwrdm-pwrdm_set_logic_retst)
+ ret = arch_pwrdm-pwrdm_set_logic_retst(pwrdm, pwrst);
- return 0;
+ return ret;
}
/**
@@ -696,11 +689,15 @@ int pwrdm_set_mem_retst(struct powerdomain *pwrdm, u8
bank, u8 pwrst)
*/
int pwrdm_read_logic_pwrst(struct powerdomain *pwrdm)
{
+ int ret = -EINVAL;
+
if (!pwrdm)
return -EINVAL;
- return prm_read_mod_bits_shift(pwrdm-prcm_offs, pwrstst_reg_offs,
- OMAP3430_LOGICSTATEST_MASK);
+ if (arch_pwrdm arch_pwrdm-pwrdm_read_logic_pwrst)
+ ret = arch_pwrdm-pwrdm_read_logic_pwrst(pwrdm);
+
+ return ret;
}
/**
@@ -713,17 +710,15 @@ int pwrdm_read_logic_pwrst(struct powerdomain *pwrdm)
*/
int pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
{
+ int ret = -EINVAL;
+
if (!pwrdm)
return -EINVAL;
- /*
-* The register bit names below may not correspond to the
-* actual names of the bits in each powerdomain's register,
-* but the type of value returned is the same for each
-* powerdomain.
-*/
- return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP3430_PM_PREPWSTST,
- OMAP3430_LASTLOGICSTATEENTERED_MASK);
+ if (arch_pwrdm arch_pwrdm-pwrdm_read_prev_logic_pwrst)
+ ret = arch_pwrdm-pwrdm_read_prev_logic_pwrst(pwrdm);
+
+ return ret;
}
/**
@@ -736,17 +731,15 @@ int pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
*/
int pwrdm_read_logic_retst(struct powerdomain *pwrdm)
{
+ int ret = -EINVAL;
+
if (!pwrdm)
return -EINVAL;
- /*
-* The register bit names below may not correspond to the
-* actual names of the bits in each powerdomain's register,
-* but the type of value returned is the same for each
-* powerdomain.
-*/
- return prm_read_mod_bits_shift(pwrdm-prcm_offs, pwrstctrl_reg_offs,
- OMAP3430_LOGICSTATEST_MASK);
+ if (arch_pwrdm arch_pwrdm-pwrdm_read_logic_retst)
+ ret = arch_pwrdm-pwrdm_read_logic_retst(pwrdm);
+
+ return ret;
}
/**
diff --git a/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
index a25dd64..b7ea191 100644
--- a/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
@@ -41,6 +41,17 @@ static int omap2_pwrdm_read_pwrst(struct powerdomain *pwrdm)
OMAP2_PM_PWSTST, OMAP_POWERSTATEST_MASK);
}
+static int omap2_pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst)
+{
+ u32 v;
+
+ v = pwrst __ffs(OMAP3430_LOGICL1CACHERETSTATE_MASK);
+ prm_rmw_mod_reg_bits(OMAP3430_LOGICL1CACHERETSTATE_MASK, v,
+ pwrdm-prcm_offs, OMAP2_PM_PWSTCTRL);
+
+ return 0;
+}
+
/* Applicable only for OMAP3. Not supported on OMAP2 */
static int omap3_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
{
@@ -48,10 +59,29 @@ static int omap3_pwrdm_read_prev_pwrst(struct powerdomain
*pwrdm)
[PATCH v3 1/6] OMAP: powerdomain: Move static allocations from powerdomains.h to a .c file
From: Rajendra Nayak rna...@t.com
powerdomains.h header today has only static definitions.
Adding any function declarations into
it and including it in multiple source file is
expected to cause issues.
Hence move all the static definitions from powerdomains.h
file into powerdomains_data.c file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/clockdomains.h |5 +
arch/arm/mach-omap2/io.c |3 +--
.../{powerdomains.h = powerdomains_data.c}| 10 +-
arch/arm/plat-omap/include/plat/powerdomain.h |1 +
5 files changed, 13 insertions(+), 8 deletions(-)
rename arch/arm/mach-omap2/{powerdomains.h = powerdomains_data.c} (97%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..5e20bc5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -9,7 +9,7 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o
timer-gp.o pm.o \
omap-2-3-common= irq.o sdrc.o prm2xxx_3xxx.o
hwmod-common = omap_hwmod.o \
omap_hwmod_common_data.o
-prcm-common= prcm.o powerdomain.o
+prcm-common= prcm.o powerdomain.o
powerdomains_data.o
clock-common = clock.o clock_common_data.o \
clockdomain.o clkt_dpll.o \
clkt_clksel.o
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index 8fc19ff..2a3b10a 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -38,6 +38,11 @@
#include plat/clockdomain.h
#include cm.h
#include prm.h
+#include cm-regbits-24xx.h
+#include cm-regbits-34xx.h
+#include cm-regbits-44xx.h
+#include prm-regbits-24xx.h
+#include prm-regbits-34xx.h
/*
* Clockdomain dependencies for wkdeps/sleepdeps
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..b5b385d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -40,7 +40,6 @@
#include plat/omap-pm.h
#include plat/powerdomain.h
-#include powerdomains.h
#include plat/clockdomain.h
#include clockdomains.h
@@ -316,7 +315,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
{
u8 skip_setup_idle = 0;
- pwrdm_init(powerdomains_omap);
+ pwrdm_fw_init();
clkdm_init(clockdomains_omap, clkdm_autodeps);
if (cpu_is_omap242x())
omap2420_hwmod_init();
diff --git a/arch/arm/mach-omap2/powerdomains.h
b/arch/arm/mach-omap2/powerdomains_data.c
similarity index 97%
rename from arch/arm/mach-omap2/powerdomains.h
rename to arch/arm/mach-omap2/powerdomains_data.c
index 105cbca..475763e 100644
--- a/arch/arm/mach-omap2/powerdomains.h
+++ b/arch/arm/mach-omap2/powerdomains_data.c
@@ -18,9 +18,6 @@
*Clock Domain Framework
*/
-#ifndef ARCH_ARM_MACH_OMAP2_POWERDOMAINS
-#define ARCH_ARM_MACH_OMAP2_POWERDOMAINS
-
/*
* This file contains all of the powerdomains that have some element
* of software control for the OMAP24xx and OMAP34xx chips.
@@ -49,6 +46,7 @@
* address offset is different between the C55 and C64 DSPs.
*/
+#include linux/init.h
#include plat/powerdomain.h
#include prcm-common.h
@@ -149,5 +147,7 @@ static struct powerdomain *powerdomains_omap[] __initdata =
{
NULL
};
-
-#endif
+void pwrdm_fw_init(void)
+{
+ pwrdm_init(powerdomains_omap);
+}
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index 9ca420d..e322b39 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -118,6 +118,7 @@ struct powerdomain {
};
+void pwrdm_fw_init(void);
void pwrdm_init(struct powerdomain **pwrdm_list);
struct powerdomain *pwrdm_lookup(const char *name);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/6] OMAP: powerdomain: Arch specific funcs for mem control
Define the following architecture specific funtions for omap2/3/4 .pwrdm_set_mem_onst .pwrdm_set_mem_retst .pwrdm_read_mem_pwrst .pwrdm_read_prev_mem_pwrst .pwrdm_read_mem_retst .pwrdm_clear_all_prev_pwrst .pwrdm_enable_hdwr_sar .pwrdm_disable_hdwr_sar .pwrdm_wait_transition .pwrdm_set_lowpwrstchange Convert the platform-independent framework to call these functions. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/Makefile |9 +- arch/arm/mach-omap2/powerdomain-common.c | 111 ++ arch/arm/mach-omap2/powerdomain.c | 303 +-- arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 131 arch/arm/mach-omap2/powerdomain44xx.c | 85 arch/arm/mach-omap2/powerdomains.h |5 + 6 files changed, 393 insertions(+), 251 deletions(-) create mode 100644 arch/arm/mach-omap2/powerdomain-common.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index bba0d17..a00a9b3 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -9,7 +9,7 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \ omap-2-3-common= irq.o sdrc.o prm2xxx_3xxx.o hwmod-common = omap_hwmod.o \ omap_hwmod_common_data.o -prcm-common= prcm.o powerdomain.o powerdomains_data.o +prcm-common= prcm.o clock-common = clock.o clock_common_data.o \ clockdomain.o clkt_dpll.o \ clkt_clksel.o @@ -95,9 +95,10 @@ obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o #powerdomain framework -obj-$(CONFIG_ARCH_OMAP2) += powerdomain2xxx_3xxx.o -obj-$(CONFIG_ARCH_OMAP3) += powerdomain2xxx_3xxx.o -obj-$(CONFIG_ARCH_OMAP4) += powerdomain44xx.o +powerdomain-common += powerdomain.o powerdomains_data.o powerdomain-common.o +obj-$(CONFIG_ARCH_OMAP2) += $(powerdomain-common) powerdomain2xxx_3xxx.o +obj-$(CONFIG_ARCH_OMAP3) += $(powerdomain-common) powerdomain2xxx_3xxx.o +obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) powerdomain44xx.o # EMU peripherals obj-$(CONFIG_OMAP3_EMU)+= emu.o diff --git a/arch/arm/mach-omap2/powerdomain-common.c b/arch/arm/mach-omap2/powerdomain-common.c new file mode 100644 index 000..26c38e7 --- /dev/null +++ b/arch/arm/mach-omap2/powerdomain-common.c @@ -0,0 +1,111 @@ +/* + * linux/arch/arm/mach-omap2/powerdomain-common.c + * Contains common powerdomain framework functions + * + * Copyright (C) 2010 Texas Instruments, Inc. + * Copyright (C) 2010 Nokia Corporation + * + * Derived from mach-omap2/powerdomain.c written by Paul Walmsley + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/errno.h +#include linux/kernel.h +#include pm.h +#include cm.h +#include cm-regbits-34xx.h +#include cm-regbits-44xx.h +#include prm-regbits-34xx.h +#include prm-regbits-44xx.h +#include powerdomains.h + +/* + * OMAP3 and OMAP4 specific register bit initialisations + * Notice that the names here are not according to each power + * domain but the bit mapping used applies to all of them + */ +/* OMAP3 and OMAP4 Memory Onstate Masks (common across all power domains) */ +#define OMAP_MEM0_ONSTATE_MASK OMAP3430_SHAREDL1CACHEFLATONSTATE_MASK +#define OMAP_MEM1_ONSTATE_MASK OMAP3430_L1FLATMEMONSTATE_MASK +#define OMAP_MEM2_ONSTATE_MASK OMAP3430_SHAREDL2CACHEFLATONSTATE_MASK +#define OMAP_MEM3_ONSTATE_MASK OMAP3430_L2FLATMEMONSTATE_MASK +#define OMAP_MEM4_ONSTATE_MASK OMAP4430_OCP_NRET_BANK_ONSTATE_MASK + +/* OMAP3 and OMAP4 Memory Retstate Masks (common across all power domains) */ +#define OMAP_MEM0_RETSTATE_MASK OMAP3430_SHAREDL1CACHEFLATRETSTATE_MASK +#define OMAP_MEM1_RETSTATE_MASK OMAP3430_L1FLATMEMRETSTATE_MASK +#define OMAP_MEM2_RETSTATE_MASK OMAP3430_SHAREDL2CACHEFLATRETSTATE_MASK +#define OMAP_MEM3_RETSTATE_MASK OMAP3430_L2FLATMEMRETSTATE_MASK +#define OMAP_MEM4_RETSTATE_MASK OMAP4430_OCP_NRET_BANK_RETSTATE_MASK + +/* OMAP3 and OMAP4 Memory Status bits */ +#define OMAP_MEM0_STATEST_MASK OMAP3430_SHAREDL1CACHEFLATSTATEST_MASK +#define OMAP_MEM1_STATEST_MASK OMAP3430_L1FLATMEMSTATEST_MASK +#define OMAP_MEM2_STATEST_MASK OMAP3430_SHAREDL2CACHEFLATSTATEST_MASK +#define OMAP_MEM3_STATEST_MASK OMAP3430_L2FLATMEMSTATEST_MASK +#define OMAP_MEM4_STATEST_MASK OMAP4430_OCP_NRET_BANK_STATEST_MASK + +/* Common Internal functions used
[PATCH v3 3/6] OMAP: powerdomain: Arch specific funcs for state control
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_next_pwrst
.pwrdm_read_next_pwrst
.pwrdm_read_pwrst
.pwrdm_read_prev_pwrst
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile |5 ++
arch/arm/mach-omap2/powerdomain.c | 33 ++
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 62
arch/arm/mach-omap2/powerdomain44xx.c | 55
arch/arm/mach-omap2/powerdomains.h | 36
arch/arm/mach-omap2/powerdomains_data.c|8 +++-
6 files changed, 188 insertions(+), 11 deletions(-)
create mode 100644 arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
create mode 100644 arch/arm/mach-omap2/powerdomain44xx.c
create mode 100644 arch/arm/mach-omap2/powerdomains.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5e20bc5..bba0d17 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -94,6 +94,11 @@ obj-$(CONFIG_ARCH_OMAP2430) +=
omap_hwmod_2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
+#powerdomain framework
+obj-$(CONFIG_ARCH_OMAP2) += powerdomain2xxx_3xxx.o
+obj-$(CONFIG_ARCH_OMAP3) += powerdomain2xxx_3xxx.o
+obj-$(CONFIG_ARCH_OMAP4) += powerdomain44xx.o
+
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU)+= emu.o
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 3aa3eb3..0ae1ebf 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -439,6 +439,8 @@ int pwrdm_get_mem_bank_count(struct powerdomain *pwrdm)
*/
int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
{
+ int ret = -EINVAL;
+
if (!pwrdm)
return -EINVAL;
@@ -448,11 +450,10 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
pwrst)
pr_debug(powerdomain: setting next powerstate for %s to %0x\n,
pwrdm-name, pwrst);
- prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
-(pwrst OMAP_POWERSTATE_SHIFT),
-pwrdm-prcm_offs, pwrstctrl_reg_offs);
+ if (arch_pwrdm arch_pwrdm-pwrdm_set_next_pwrst)
+ ret = arch_pwrdm-pwrdm_set_next_pwrst(pwrdm, pwrst);
- return 0;
+ return ret;
}
/**
@@ -465,11 +466,15 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
pwrst)
*/
int pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
{
+ int ret = -EINVAL;
+
if (!pwrdm)
return -EINVAL;
- return prm_read_mod_bits_shift(pwrdm-prcm_offs,
-pwrstctrl_reg_offs, OMAP_POWERSTATE_MASK);
+ if (arch_pwrdm arch_pwrdm-pwrdm_read_next_pwrst)
+ ret = arch_pwrdm-pwrdm_read_next_pwrst(pwrdm);
+
+ return ret;
}
/**
@@ -482,11 +487,15 @@ int pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
*/
int pwrdm_read_pwrst(struct powerdomain *pwrdm)
{
+ int ret = -EINVAL;
+
if (!pwrdm)
return -EINVAL;
- return prm_read_mod_bits_shift(pwrdm-prcm_offs,
-pwrstst_reg_offs, OMAP_POWERSTATEST_MASK);
+ if (arch_pwrdm arch_pwrdm-pwrdm_read_pwrst)
+ ret = arch_pwrdm-pwrdm_read_pwrst(pwrdm);
+
+ return ret;
}
/**
@@ -499,11 +508,15 @@ int pwrdm_read_pwrst(struct powerdomain *pwrdm)
*/
int pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
{
+ int ret = -EINVAL;
+
if (!pwrdm)
return -EINVAL;
- return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP3430_PM_PREPWSTST,
- OMAP3430_LASTPOWERSTATEENTERED_MASK);
+ if (arch_pwrdm arch_pwrdm-pwrdm_read_prev_pwrst)
+ ret = arch_pwrdm-pwrdm_read_prev_pwrst(pwrdm);
+
+ return ret;
}
/**
diff --git a/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
new file mode 100644
index 000..a25dd64
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
@@ -0,0 +1,62 @@
+/*
+ * OMAP2 and OMAP3 powerdomain control
+ *
+ * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2007-2009 Nokia Corporation
+ *
+ * Derived from mach-omap2/powerdomain.c written by Paul Walmsley
+ * Rajendra Nayak rna...@ti.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.
+ */
+
+#include linux/io.h
+#include linux/errno.h
+#include linux/delay.h
+#include plat/prcm.h
+#include prm.h
+#include
Re: Mainline OMAP3 breakage (and other OMAP?)
On Fri, Dec 3, 2010 at 10:41 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
This has been fixed since -rc2.
So it is. However, the ioremap fix is wrong.
} else {
paddr = memblock_alloc(size, PAGE_SIZE);
}
memblock_free(paddr, size);
memblock_remove(paddr, size);
Didn't I say that such blocks were supposed to be aligned to a 2MB
boundary - and the size also so aligned?
I asked you if there was something special and I didn't receive any response:
http://article.gmane.org/gmane.linux.kernel/1048434
So, why SZ_2M?
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7] OMAP2+: PM: omap device: API's for handling mstandby mode
On 12/3/2010 10:47 AM, G, Manjunath Kondaiah wrote: * Cousson, Benoitb-cous...@ti.com [2010-12-03 09:38:35 +0100]: [...] v7: replaced mutex lock with spin lock. Added use count for controlling access to sysconfig registers in case if overlapping request/release API's are used. I'm not sure it should be done here. I'd rather keep that code in the DMA, since this is the only user of that feature. Are you referring to spin lock or usage count? The spinlock is needed, I was referring to the usage count. That being said, the API proposed by Paul (request/release ) sound like a get/put, so maybe he had that kind of usage in mind. I'm still not convince it should be done at hwmod API level. Paul, Any thoughts on that? Regards, Benoit -- 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] AM35x: musb: fix compilation error
On Thu, Dec 02, 2010 at 04:13:50PM +0530, Gupta, Ajay Kumar wrote:
why don't you add a proper otg_transceiver driver for am35x ?
Is it like omap4's internal phy ? A separate block ?
AM35x PHY is built inside the ip and we need to configure it through
PHY control register.
Additionally we also need to access IPSS reset and Intr clear register
as well which would not fit inside otg_transceiver.
how about passing an extra struct resource if am35x ? Then you could
ioremap that base on am35x.c and use normal musb_read/write functions.
We already have generic APIs so I think we can pass function pointers to
musb driver via struct omap_musb_board_data,
struct omap_musb_board_data {
+ void(*phy_on) (void)
+ void(*phy_off) (void)
+ void (*intr_clr) (void)
}
Reset part can be done in board file itself same as Ethernet driver is doing.
Does this look fine?
so those would be turn phy on, turn phy off and clear interrupt
apis ?
How about:
int (*set_phy_power)(unsigned on);
void (*clear_phy_irq)(void);
You'd need one less API for that. BTW, could you do it on top of my
musb-hw branch ? Then I can push together with those for merge window.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] FOR TESTING ONLY
On Thu, Dec 02, 2010 at 02:27:36PM -0800, Tony Lindgren wrote: Hi, * Felipe Balbi ba...@ti.com [101202 03:38]: Hi Tony, I have a gigantic amount of patches on musb starting to move it to a place where we can build am35x.c, omap2430.c and tusb6010.c together and have a working binary. There are a few changes still needed (as per comments Mike's comments on linux-usb) but it's working fine on my pandaboard. Mike's comments are mostly cosmetic (appending _musb suffix to function names and adding const to a struct, for example). If you could merge them into linux-omap so we can put the hwmod and pm_runtime patches on top, I'd be glad. Keep in mind that branch still might get rebased, so get ready to merge -s ours :-p Great, yeah I'll merge them into linux-omap master branch for testing probably later on today. Cool, I just made the updates Mike asked and it's now all good again :-p I'm hoping Greg will still accept these patches on monday for merge window, cross your fingers :-p for 2.6.39 I'll get them all to build together. Not quite there yet. TUSB6010 messed up the whole code with ifdefs, I need to check how to do that one properly. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mainline OMAP3 breakage (and other OMAP?)
On Fri, Dec 03, 2010 at 02:10:23PM +0200, Felipe Contreras wrote:
On Fri, Dec 3, 2010 at 10:41 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
This has been fixed since -rc2.
So it is. However, the ioremap fix is wrong.
} else {
paddr = memblock_alloc(size, PAGE_SIZE);
}
memblock_free(paddr, size);
memblock_remove(paddr, size);
Didn't I say that such blocks were supposed to be aligned to a 2MB
boundary - and the size also so aligned?
I asked you if there was something special and I didn't receive any response:
http://article.gmane.org/gmane.linux.kernel/1048434
So you thought you could ride rough-shod over my statement and ignore it?
Thank you for treating me like shit, I'll remember that for future and
treat you in a similar manner.
So, why SZ_2M?
Firstly, that's the granularity which we allocate page tables - one
Linux page table covers 2MB of memory. We want to avoid creating page
tables for the main memory mapping as that increases TLB pressure through
the use of additional TLB entries, and more page table walks.
Plus, we never used to allow the kernel's direct memory mapping to be
mapped at anything less than section size - this restriction has since
been lifted due to OMAP SRAM problems, but I'd rather we stuck with it
to ensure that we have proper behaviour from all parts of the system.
Secondly, we don't want to end up with lots of fragmentation at the end
of the memory mapping as that'll reduce performance, not only by making
the pfn_valid() search more expensive.
Emsuring a minimum allocation size and alignment makes sure that the
regions can be coalesced together into one block, and minimises run-time
expenses.
So please, 2MB, or if you object, at the _very_ _least_ 1MB. But
definitely not PAGE_SIZE.
--
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: Mainline OMAP3 breakage (and other OMAP?)
On Fri, Dec 3, 2010 at 3:07 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 03, 2010 at 02:10:23PM +0200, Felipe Contreras wrote:
On Fri, Dec 3, 2010 at 10:41 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
This has been fixed since -rc2.
So it is. However, the ioremap fix is wrong.
} else {
paddr = memblock_alloc(size, PAGE_SIZE);
}
memblock_free(paddr, size);
memblock_remove(paddr, size);
Didn't I say that such blocks were supposed to be aligned to a 2MB
boundary - and the size also so aligned?
I asked you if there was something special and I didn't receive any response:
http://article.gmane.org/gmane.linux.kernel/1048434
So you thought you could ride rough-shod over my statement and ignore it?
Thank you for treating me like shit, I'll remember that for future and
treat you in a similar manner.
No, you didn't make any statement, just provided code. I thought SZ_2M
might have just been an example for something that required that
alignment, thus my request for clarification.
So, why SZ_2M?
Firstly, that's the granularity which we allocate page tables - one
Linux page table covers 2MB of memory. We want to avoid creating page
tables for the main memory mapping as that increases TLB pressure through
the use of additional TLB entries, and more page table walks.
Plus, we never used to allow the kernel's direct memory mapping to be
mapped at anything less than section size - this restriction has since
been lifted due to OMAP SRAM problems, but I'd rather we stuck with it
to ensure that we have proper behaviour from all parts of the system.
Secondly, we don't want to end up with lots of fragmentation at the end
of the memory mapping as that'll reduce performance, not only by making
the pfn_valid() search more expensive.
Emsuring a minimum allocation size and alignment makes sure that the
regions can be coalesced together into one block, and minimises run-time
expenses.
So please, 2MB, or if you object, at the _very_ _least_ 1MB. But
definitely not PAGE_SIZE.
Fair enough. If nobody beats me to it I would send patches to fix
that, although perhaps it would make sense to write a helper function
that does exactly this.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] AM35x: musb: fix compilation error
We already have generic APIs so I think we can pass function pointers to
musb driver via struct omap_musb_board_data,
struct omap_musb_board_data {
+void(*phy_on) (void)
+void(*phy_off) (void)
+void (*intr_clr) (void)
}
Reset part can be done in board file itself same as Ethernet driver is
doing.
Does this look fine?
so those would be turn phy on, turn phy off and clear interrupt
apis ?
How about:
int (*set_phy_power)(unsigned on);
Looks good.
void (*clear_phy_irq)(void);
This is actually musb ip interrupt clear so I will make it like,
void (*clear_irq) (void);
You'd need one less API for that. BTW, could you do it on top of my
musb-hw branch ? Then I can push together with those for merge window.
Not yet, I will send once completed.
Thanks,
Ajay
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Hans, Adding by the original CC list which was dropped by mistake. On Friday 03 December 2010 13:06:18 Hans Verkuil wrote: On Friday, December 03, 2010 11:19:36 Laurent Pinchart wrote: On Sunday 28 November 2010 16:57:00 you wrote: On Sunday, November 28, 2010 13:34:45 Laurent Pinchart wrote: On Friday 26 November 2010 15:14:42 Mark Brown wrote: On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? That's a good option. Hans, do you want to comment on this ? Fine by me! It's better than 'active'. Just to confirm thinks, Mark's proposal is to replace 'connected' by 'linked' and 'active' by 'connected'. Are we on the same page here ? Yes, but when I read it back it does not make me happy. 'Connected' and 'linked' basically have the same meaning in English. I unfortunately agree that it's a bit confusing :-( I really like your analogy with valves, so perhaps we should use either 'linked' or 'connected' to describe that two entities are, well, linked/connected, and use the 'open' and 'closed' terminology to describe whether a link/connection is open (data can flow) or closed (no data can flow). I don't really like the open/closed terminology to describe links. I can think of two analogies: pipes with valves that can be opened/closed, or cables that can be connected/disconnected. In the first case, connected/linked can be used to specify the pipes that exist in the system, but I'm not happy with open/closed. In the second case, connected/linked can be used to specify whether a cable is connected, but in that case we will need another word to describe whether two pads are connectable or not. I have a slight preference for 'link' over 'connection', but that's mostly because it is a shorter word :-) Link refers to a pipe/possible cable connection. It's an object on both the kernel side and the userspace side. Using the above analogies, tt makes sense to use the word 'linked' to refer to two pads that are connected by a pipe, or between which a cable can be connected. Now we need a word to descripe whether the valve is opened or closed, or whether the cable is connected or not. I don't really like 'open'/'closed' for the first analogy. 'connected' would make sense for the second analogy, but it can indeed be a bit confusing. Thoughts ? -- Regards, Laurent Pinchart -- 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 v6 03/12] media: Entities, pads and links
On Fri, Dec 03, 2010 at 02:50:58PM +0100, Laurent Pinchart wrote: On Friday 03 December 2010 13:06:18 Hans Verkuil wrote: Just to confirm thinks, Mark's proposal is to replace 'connected' by 'linked' and 'active' by 'connected'. Are we on the same page here ? Yes, but when I read it back it does not make me happy. 'Connected' and 'linked' basically have the same meaning in English. I unfortunately agree that it's a bit confusing :-( It feels like the problem here is that for whatever reason (I'm not sure what?) you're trying to come up with verbs for links that are currently disconnected - in ASoC we just say we've got paths that exist and then we talk about the paths that are connected. Verbing everything makes it all sound active which is confusing when you're talking about links that are idle. -- 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] omap: nand: remove hardware ECC as default
On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote: * Sukumar Ghorai s-gho...@ti.com [101119 06:36]: CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36. This flag enables hw ecc by default. Boards like beagle and pandora uses sw ecc for write (e.g. binary flushed from u-boot) and read from kernel. https://patchwork.kernel.org/patch/111036/ Signed-off-by: Sukumar Ghorai s-gho...@ti.com This should go in as a fix for the -rc via MTD list if possible. Acked-by: Tony Lindgren t...@atomide.com Tony, I think this is quite simple patch, and you can merge it yourself, MTD tree is slow. I hope dwmw2 will not beat me for this, but unless he quickly jumps in and confirms he takes care of this patch, just go ahead an merge it. I've put dwmw2 to To:, just in case. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] omap: nand: remove hardware ECC as default
On Fri, 2010-12-03 at 18:22 +0200, Artem Bityutskiy wrote: On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote: * Sukumar Ghorai s-gho...@ti.com [101119 06:36]: CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36. This flag enables hw ecc by default. Boards like beagle and pandora uses sw ecc for write (e.g. binary flushed from u-boot) and read from kernel. https://patchwork.kernel.org/patch/111036/ Signed-off-by: Sukumar Ghorai s-gho...@ti.com This should go in as a fix for the -rc via MTD list if possible. Acked-by: Tony Lindgren t...@atomide.com Tony, I think this is quite simple patch, and you can merge it yourself, MTD tree is slow. I hope dwmw2 will not beat me for this, but unless he quickly jumps in and confirms he takes care of this patch, just go ahead an merge it. I've put dwmw2 to To:, just in case. Acked-by: David Woodhouse david.woodho...@intel.com Unless you'd prefer me to send it on myself, please feel free to submit it to Linus directly. -- dwmw2 -- 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 v5 09/14] OMAP: DMA: Convert DMA library into platform driver
Hi Tony, * Tony Lindgren t...@atomide.com [2010-12-02 12:52:19 -0800]: * G, Manjunath Kondaiah manj...@ti.com [101202 11:55]: Note that even with these three fixes, 5912OSK still fails to boot to init. Maybe something wrong with the framebuffer DMA? Not sure. I don't have omap1 board for testing. Patch series is only build tested for omap1. Can you pls confirm if OSK5912 boots successfully without this patch series? Yeah boots just fine without these as always. Anybody care to donate a OSK5912 or similar for the TI guys for doing quick omap1 boot testing on? If yes, I will cross verify omap1 changes again. Found the problem. INT_DMA_LCD is handled in mach-omap1/lcd_dma.c. In your omap_system_dma_probe we now exit everything if request_irq fails for one channel. So let's skip INT_DMA_LCD. Also, you should check the logic in omap_system_dma_probe as it's not very good handling right now. Note how platform_get_irq_byname does not free other dma_irqs like after request_irq we do. Fixed error handling cases. With your patches applied up to patch Convert DMA library into platform driver + my three earlie fixes + the following fix I can now boot OSK5912 and see the penguin on the LCD too. Thanks a lot. I pulled in all these fixes into the patch series. I suggest you break your series into two where the last patch in the first series is Convert DMA library into platform driver. I am ok with this approach. That way the init related changes are done, and we can merge those in for testing while you update the rest of the series. cool. I have done required changes to patch series and tested the same on omap2+ boards. Can you pls test OSK5912 board boot from the below git repo? If OSK5912 boots up(with LCD), I will post the 1st series to LO ML. git://dev.omapzoom.org/pub/scm/manju/kernel-omap3-dev.git Branch: dma_testing commit 3047de5b11cc3fef9ea18a7e8d64fec7a9ea7a89 Author: G, Manjunath Kondaiah manj...@ti.com Date: Fri Dec 3 20:03:23 2010 +0530 OMAP: DMA: Convert DMA library into platform driver Convert DMA library into DMA platform driver and make use of platform data provided by hwmod data base for OMAP2+ onwards. For OMAP1 processors, the DMA driver in mach-omap uses resource structures for getting platform data. Thanks to Tony Lindgren t...@atomide.com for fixing various omap1 issues and testing the same on OSK5912 board. Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Also, eventually within next few merge cycles we should have: arch/arm/mach-omap1/dma.c omap1 specific platform init arch/arm/mach-omap2/dma.c omap2+ specific platform init This seems to be ok. drivers/dma/omap-dma.cdriver using dmaengine.c This might require more time. -Manjunath -- 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] omap: nand: remove hardware ECC as default
* David Woodhouse dw...@infradead.org [101203 08:29]: On Fri, 2010-12-03 at 18:22 +0200, Artem Bityutskiy wrote: On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote: * Sukumar Ghorai s-gho...@ti.com [101119 06:36]: CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36. This flag enables hw ecc by default. Boards like beagle and pandora uses sw ecc for write (e.g. binary flushed from u-boot) and read from kernel. https://patchwork.kernel.org/patch/111036/ Signed-off-by: Sukumar Ghorai s-gho...@ti.com This should go in as a fix for the -rc via MTD list if possible. Acked-by: Tony Lindgren t...@atomide.com Tony, I think this is quite simple patch, and you can merge it yourself, MTD tree is slow. I hope dwmw2 will not beat me for this, but unless he quickly jumps in and confirms he takes care of this patch, just go ahead an merge it. I've put dwmw2 to To:, just in case. Acked-by: David Woodhouse david.woodho...@intel.com Unless you'd prefer me to send it on myself, please feel free to submit it to Linus directly. Thanks, I'll queue it. 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 1/5 v2] OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all
From: Richard Woodruff r-woodru...@ti.com Analysis in TI kernel with ETM showed that using cache mapped flush in kernel instead of SO mapped flush cost drops by 65% (3.39mS down to 1.17mS) for clean_l2 which is used during sleep sequences. Overall: - speed up - unfortunately there isn't a good alternative flush method today - code reduction and less maintenance and potential bug in unmaintained code This also fixes the bug with the clean_l2 function usage. Reported-by: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Tony Lindgren t...@atomide.com [...@ti.com: ported rkw's proposal to 2.6.37-rc2] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Richard Woodruff r-woodru...@ti.com --- (no change in this series, posted for completeness) v2: https://patchwork.kernel.org/patch/365222/ v1: http://marc.info/?l=linux-omapm=129013171325210w=2 arch/arm/mach-omap2/sleep34xx.S | 79 ++ 1 files changed, 13 insertions(+), 66 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 2fb205a..2c20fcf 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -520,72 +520,17 @@ clean_caches: cmp r9, #1 /* Check whether L2 inval is required or not*/ bne skip_l2_inval clean_l2: - /* read clidr */ - mrc p15, 1, r0, c0, c0, 1 - /* extract loc from clidr */ - andsr3, r0, #0x700 - /* left align loc bit field */ - mov r3, r3, lsr #23 - /* if loc is 0, then no need to clean */ - beq finished - /* start clean at cache level 0 */ - mov r10, #0 -loop1: - /* work out 3x current cache level */ - add r2, r10, r10, lsr #1 - /* extract cache type bits from clidr*/ - mov r1, r0, lsr r2 - /* mask of the bits for current cache only */ - and r1, r1, #7 - /* see what cache we have at this level */ - cmp r1, #2 - /* skip if no cache, or just i-cache */ - blt skip - /* select current cache level in cssr */ - mcr p15, 2, r10, c0, c0, 0 - /* isb to sych the new cssrcsidr */ - isb - /* read the new csidr */ - mrc p15, 1, r1, c0, c0, 0 - /* extract the length of the cache lines */ - and r2, r1, #7 - /* add 4 (line length offset) */ - add r2, r2, #4 - ldr r4, assoc_mask - /* find maximum number on the way size */ - andsr4, r4, r1, lsr #3 - /* find bit position of way size increment */ - clz r5, r4 - ldr r7, numset_mask - /* extract max number of the index size*/ - andsr7, r7, r1, lsr #13 -loop2: - mov r9, r4 - /* create working copy of max way size*/ -loop3: - /* factor way and cache number into r11 */ - orr r11, r10, r9, lsl r5 - /* factor index number into r11 */ - orr r11, r11, r7, lsl r2 - /*clean invalidate by set/way */ - mcr p15, 0, r11, c7, c10, 2 - /* decrement the way*/ - subsr9, r9, #1 - bge loop3 - /*decrement the index */ - subsr7, r7, #1 - bge loop2 -skip: - add r10, r10, #2 - /* increment cache number */ - cmp r3, r10 - bgt loop1 -finished: - /*swith back to cache level 0 */ - mov r10, #0 - /* select current cache level in cssr */ - mcr p15, 2, r10, c0, c0, 0 - isb + /* +* Jump out to kernel flush routine +* - reuse that code is better +* - it executes in a cached space so is faster than refetch per-block +* - should be faster and will change with kernel +* - 'might' have to copy address, load and jump to it +*/ + ldr r1, kernel_flush + mov lr, pc + bx r1 + skip_l2_inval: /* Data memory barrier and Data sync barrier */ mov r1, #0 @@ -668,5 +613,7 @@ cache_pred_disable_mask: .word 0xE7FB control_stat: .word CONTROL_STAT +kernel_flush: + .word v7_flush_dcache_all ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend -- 1.6.3.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 3/5 v3] OMAP3630: PM: Erratum i608: disable RTA
Erratum id: i608
RTA (Retention Till Access) feature is not supported and leads to device
stability issues when enabled. This impacts modules with embedded memories
on OMAP3630
Workaround is to disable RTA on boot and coming out of core off.
For disabling rta coming out of off mode, we do this by overriding the
restore pointer for 3630 to allow us restore handler as the first point of
entry before caches are touched and is common for GP and HS devices.
to disable earlier than this could be possible by modifying the ppa for HS
devices, but not for GP devices.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
[ambr...@ti.com: co-developer]
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
v3: additional comment to explain Ambresh's contrib
removed the redundant check for cpu_is34xx - it is already
done by pm_init
pm_errata_configure is __init
v2: https://patchwork.kernel.org/patch/365242/
fixed missing b restore for 3430 es3.1 code.
introduced erratum handling logic here splitting it out of uart errata
typo fixes for erratum
v1: http://marc.info/?l=linux-omapm=129013172825240w=2
arch/arm/mach-omap2/control.c |5 -
arch/arm/mach-omap2/control.h |5 +
arch/arm/mach-omap2/pm34xx.c| 21 +
arch/arm/mach-omap2/sleep34xx.S | 26 ++
4 files changed, 56 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..728f268 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -241,7 +241,10 @@ void omap3_save_scratchpad_contents(void)
/* Populate the Scratchpad contents */
scratchpad_contents.boot_config_ptr = 0x0;
- if (omap_rev() != OMAP3430_REV_ES3_0
+ if (cpu_is_omap3630())
+ scratchpad_contents.public_restore_ptr =
+ virt_to_phys(get_omap3630_restore_pointer());
+ else if (omap_rev() != OMAP3430_REV_ES3_0
omap_rev() != OMAP3430_REV_ES3_1)
scratchpad_contents.public_restore_ptr =
virt_to_phys(get_restore_pointer());
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..d7911c5 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -204,6 +204,10 @@
#define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014)
#define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WKUP + 0x018)
+/* 36xx-only RTA - Retention till Accesss control registers and bits */
+#define OMAP36XX_CONTROL_MEM_RTA_CTRL 0x40C
+#define OMAP36XX_RTA_DISABLE 0x0
+
/* 34xx D2D idle-related pins, handled by PM core */
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK0x254
@@ -347,6 +351,7 @@ extern void omap3_save_scratchpad_contents(void);
extern void omap3_clear_scratchpad_contents(void);
extern u32 *get_restore_pointer(void);
extern u32 *get_es3_restore_pointer(void);
+extern u32 *get_omap3630_restore_pointer(void);
extern u32 omap3_arm_context[128];
extern void omap3_control_save_context(void);
extern void omap3_control_restore_context(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..a89ffc7 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -55,6 +55,10 @@
#define OMAP343X_TABLE_VALUE_OFFSET 0xc0
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
+#define RTA_ERRATUM_i608 (1 0)
+static u16 pm34xx_errata;
+#define IS_PM34XX_ERRATUM(id) (pm34xx_errata (id))
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -989,6 +993,12 @@ void omap_push_sram_idle(void)
save_secure_ram_context_sz);
}
+static void __init pm_errata_configure(void)
+{
+ if (cpu_is_omap3630())
+ pm34xx_errata |= RTA_ERRATUM_i608;
+}
+
static int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
@@ -998,6 +1008,8 @@ static int __init omap3_pm_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
+ pm_errata_configure();
+
printk(KERN_ERR Power Management for TI OMAP3.\n);
/* XXX prcm_setup_regs needs to be before enabling hw
@@ -1045,6 +1057,15 @@ static int __init omap3_pm_init(void)
pm_idle = omap3_pm_idle;
omap3_idle_init();
+ /*
+* RTA is disabled during initialization as per erratum i608
+* it is safer to disable rta by the bootloader, but we would like
+* to be doubly sure here and prevent any mishaps.
+*/
+ if (IS_PM34XX_ERRATUM(RTA_ERRATUM_i608))
+ omap_ctrl_writel(OMAP36XX_RTA_DISABLE,
+ OMAP36XX_CONTROL_MEM_RTA_CTRL);
+
[PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2
From: Eduardo Valentin eduardo.valen...@nokia.com
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 ES1.2 is impacted as follows depending on the platform:
CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable, while
for all other sysclk frequencies, varied levels of instability
seen based on varied parameters.
CS1: impacted
This patch takes option #3 as recommended by the Silicon erratum:
Avoid core power domain transitioning to OFF mode. Power consumption
impact is expected in this case.
To do this, we route OFF requests to RET request on the impacted revisions
of silicon.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
[...@ti.com: rebased the code to 2.6.37-rc2- short circuit code changed a bit]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v3: no functional change in erratum wa implementation, just registration of
erratum is collated to a single cpu detection and version check
v2: https://patchwork.kernel.org/patch/365262/
rebased to this patch series instead of depending on hs changes
fix typo for macro definition
v1: http://marc.info/?l=linux-omapm=129013173425266w=2
arch/arm/mach-omap2/pm34xx.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b49e02b..ba3c0d6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -56,6 +56,7 @@
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
#define RTA_ERRATUM_i608 (1 0)
+#define SDRC_WAKEUP_ERRATUM_i583 (1 1)
static u16 pm34xx_errata;
#define IS_PM34XX_ERRATUM(id) (pm34xx_errata (id))
@@ -406,6 +407,17 @@ void omap_sram_idle(void)
}
/* CORE */
+ /*
+* Erratum i583: implementation for ES rev Es1.2 on 3630
+* We cannot enable OFF mode in a stable form for previous
+* revisions, transition instead to RET
+*/
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+ (core_next_state == PWRDM_POWER_OFF)) {
+ pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
+
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
@@ -999,6 +1011,8 @@ static void __init pm_errata_configure(void)
pm34xx_errata |= RTA_ERRATUM_i608;
/* Enable the l2 cache toggling in sleep logic */
enable_omap3630_toggle_l2_on_restore();
+ if (omap_rev() OMAP3630_REV_ES1_2)
+ pm34xx_errata |= SDRC_WAKEUP_ERRATUM_i583;
}
}
--
1.6.3.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 4/5 v3] OMAP3630: PM: Disable L2 cache while invalidating L2 cache
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This disables L2 cache before invalidating it and reenables it afterwards.
This is be done according to ARM documentation. Currently this is identified
as being needed on OMAP3630 as the disable/enable is done from public side
while, on OMAP3430, this is done in the secure side.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
[...@ti.com: ported to 2.6.37-rc2, added hooks to enable the logic only on 3630]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
v3: collate all silicon specific errata under a single cpu detection code
making it elegant and more maintainable.
v2: https://patchwork.kernel.org/patch/365232/
rebased out to this series independent of HS bugfixes
v1: http://marc.info/?l=linux-omapm=129013171125204w=2
arch/arm/mach-omap2/pm.h|6 ++
arch/arm/mach-omap2/pm34xx.c|5 -
arch/arm/mach-omap2/sleep34xx.S | 30 ++
3 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 0d75bfd..aff39d0 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -85,4 +85,10 @@ extern unsigned int save_secure_ram_context_sz;
extern unsigned int omap24xx_cpu_suspend_sz;
extern unsigned int omap34xx_cpu_suspend_sz;
+#if defined(CONFIG_PM)
+extern void enable_omap3630_toggle_l2_on_restore(void);
+#else
+static inline void enable_omap3630_toggle_l2_on_restore(void) { }
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a89ffc7..b49e02b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -995,8 +995,11 @@ void omap_push_sram_idle(void)
static void __init pm_errata_configure(void)
{
- if (cpu_is_omap3630())
+ if (cpu_is_omap3630()) {
pm34xx_errata |= RTA_ERRATUM_i608;
+ /* Enable the l2 cache toggling in sleep logic */
+ enable_omap3630_toggle_l2_on_restore();
+ }
}
static int __init omap3_pm_init(void)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index cc3507b..d2eda01 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -111,6 +111,19 @@ ENTRY(get_omap3630_restore_pointer_sz)
.word . - get_omap3630_restore_pointer
.text
+/*
+ * L2 cache needs to be toggled for stable OFF mode functionality on 3630.
+ * This function sets up a fflag that will allow for this toggling to take
+ * place on 3630. Hopefully some version in the future maynot need this
+ */
+ENTRY(enable_omap3630_toggle_l2_on_restore)
+stmfd sp!, {lr} @ save registers on stack
+ /* Setup so that we will disable and enable l2 */
+ mov r1, #0x1
+ str r1, l2dis_3630
+ldmfd sp!, {pc} @ restore regs and return
+
+ .text
/* Function call to get the restore pointer for for ES3 to resume from OFF */
ENTRY(get_es3_restore_pointer)
stmfd sp!, {lr} @ save registers on stack
@@ -283,6 +296,14 @@ restore:
moveq r9, #0x3@ MPU OFF = L1 and L2 lost
movne r9, #0x1@ Only L1 and L2 lost = avoid L2 invalidation
bne logic_l1_restore
+
+ ldr r0, l2dis_3630
+ cmp r0, #0x1@ should we disable L2 on 3630?
+ bne skipl2dis
+ mrc p15, 0, r0, c1, c0, 1
+ bic r0, r0, #2 @ disable L2 cache
+ mcr p15, 0, r0, c1, c0, 1
+skipl2dis:
ldr r0, control_stat
ldr r1, [r0]
and r1, #0x700
@@ -343,6 +364,13 @@ smi:.word 0xE1600070 @ Call SMI monitor
(smieq)
mov r12, #0x2
.word 0xE1600070@ Call SMI monitor (smieq)
logic_l1_restore:
+ ldr r1, l2dis_3630
+ cmp r1, #0x1@ Do we need to re-enable L2 on 3630?
+ bne skipl2reen
+ mrc p15, 0, r1, c1, c0, 1
+ orr r1, r1, #2 @ re-enable L2 cache
+ mcr p15, 0, r1, c1, c0, 1
+skipl2reen:
mov r1, #0
/* Invalidate all instruction caches to PoU
* and flush branch target cache */
@@ -678,6 +706,8 @@ control_mem_rta:
.word CONTROL_MEM_RTA_CTRL
kernel_flush:
.word v7_flush_dcache_all
+l2dis_3630:
+ .word 0
/* these 2 words need to be at the end !!! */
kick_counter:
.word 0
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5 v3] OMAP: idle path errata fixes
Hi, as discussed in [1], here is step 2 - idle path errata fixes. this is the next rev incorporating comments from V2 post of this series. V2: http://marc.info/?l=linux-omapm=129106200408109w=2 Major change in V3: Erratas are now handled per silicon - it is much cleaner :) no more redundant cpu_is_omap34xx check anymore errata configure is __init as it should be Eduardo Valentin (1): OMAP3630: PM: Erratum i583: disable coreoff if ES1.2 Nishanth Menon (1): OMAP3630: PM: Erratum i608: disable RTA Peter 'p2' De Schrijver (2): OMAP3: PM: Erratum i581 support: dll kick strategy OMAP3630: PM: Disable L2 cache while invalidating L2 cache Richard Woodruff (1): OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all arch/arm/mach-omap2/control.c |5 +- arch/arm/mach-omap2/control.h |5 + arch/arm/mach-omap2/pm.h|6 ++ arch/arm/mach-omap2/pm34xx.c| 38 arch/arm/mach-omap2/sleep34xx.S | 187 --- 5 files changed, 169 insertions(+), 72 deletions(-) bloat-o-meter report Vs 2.6.37-rc4 add/remove: 1/0 grow/shrink: 6/2 up/down: 220/-12 (208) function old new delta omap3_pm_init 17761868 +92 omap_sram_idle 10401104 +64 omap3_save_scratchpad_contents 732 760 +28 vermagic 45 60 +15 linux_banner 131 146 +15 omap2_init_mmc 10321036 +4 pm34xx_errata - 2 +2 omap_serial_init_port 11201116 -4 prcm_interrupt_handler 276 268 -8 [1] http://marc.info/?l=linux-omapm=129045338806957w=2 Cc: Charulatha Varadarajan ch...@ti.com Cc: Jean Pihet jean.pi...@newoldbits.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Tao Hu tgh...@motorola.com Cc: Tony Lindgren t...@atomide.com Cc: Vishwanath Sripathy vishwanath...@ti.com 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
[PATCH 2/5 v2] OMAP3: PM: Erratum i581 support: dll kick strategy
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Erratum i581 impacts OMAP3 platforms. PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing the DPLL not to be locked at times. IMPORTANT: *) This is not a complete workaround implementation as recommended by the silicon erratum. this is a support logic for detecting lockups and attempting to recover where possible and is known to provide stability in multiple platforms. *) This code is mostly important for inactive and retention. The ROM code waits for the maximum dll lock time when resuming from off mode. So for off mode this code isn't really needed. This should eventually get refactored as part of cleanups to sleep34xx.S Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com --- (no change done, posting for completeness of the series) v2: https://patchwork.kernel.org/patch/365252/ typo correction- erratum, support, added comment from Peter from the thread to commit message v1: http://marc.info/?l=linux-omapm=129013172525234w=2 arch/arm/mach-omap2/sleep34xx.S | 52 +++--- 1 files changed, 47 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 2c20fcf..3fbd1e5 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -42,6 +42,7 @@ OMAP3430_PM_PREPWSTST) #define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) +#define CM_IDLEST_CKGEN_V OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST) #define SRAM_BASE_P0x4020 #define CONTROL_STAT 0x480022F0 #define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is @@ -554,31 +555,67 @@ skip_l2_inval: /* Make sure SDRC accesses are ok */ wait_sdrc_ok: + +/* DPLL3 must be locked before accessing the SDRC. Maybe the HW ensures this. */ + ldr r4, cm_idlest_ckgen +wait_dpll3_lock: + ldr r5, [r4] + tst r5, #1 + beq wait_dpll3_lock + ldr r4, cm_idlest1_core +wait_sdrc_ready: ldr r5, [r4] -and r5, r5, #0x2 -cmp r5, #0 -bne wait_sdrc_ok +tst r5, #0x2 +bne wait_sdrc_ready + /* allow DLL powerdown upon hw idle req */ ldr r4, sdrc_power ldr r5, [r4] bic r5, r5, #0x40 str r5, [r4] -wait_dll_lock: +is_dll_in_lock_mode: + /* Is dll in lock mode? */ ldr r4, sdrc_dlla_ctrl ldr r5, [r4] tst r5, #0x4 bxnelr /* wait till dll locks */ -ldr r4, sdrc_dlla_status +wait_dll_lock_timed: + ldr r4, wait_dll_lock_counter + add r4, r4, #1 + str r4, wait_dll_lock_counter + ldr r4, sdrc_dlla_status +movr6, #8 /* Wait 20uS for lock */ +wait_dll_lock: + subsr6, r6, #0x1 + beq kick_dll ldr r5, [r4] and r5, r5, #0x4 cmp r5, #0x4 bne wait_dll_lock bx lr + /* disable/reenable DLL if not locked */ +kick_dll: + ldr r4, sdrc_dlla_ctrl + ldr r5, [r4] + mov r6, r5 + bic r6, #(13) /* disable dll */ + str r6, [r4] + dsb + orr r6, r6, #(13) /* enable dll */ + str r6, [r4] + dsb + ldr r4, kick_counter + add r4, r4, #1 + str r4, kick_counter + b wait_dll_lock_timed + cm_idlest1_core: .word CM_IDLEST1_CORE_V +cm_idlest_ckgen: + .word CM_IDLEST_CKGEN_V sdrc_dlla_status: .word SDRC_DLLA_STATUS_V sdrc_dlla_ctrl: @@ -615,5 +652,10 @@ control_stat: .word CONTROL_STAT kernel_flush: .word v7_flush_dcache_all + /* these 2 words need to be at the end !!! */ +kick_counter: + .word 0 +wait_dll_lock_counter: + .word 0 ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend -- 1.6.3.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] omap: remove dead wdt code in plat-omap/devices.c
Commit f2ce62312650 (OMAP: WDT: Split OMAP1 and OMAP2PLUS device
registration) removed omap_init_wdt and related structures from
plat-omap/devices.c. However a subsequent commit or merge
seems to have reintroduced these by accident. The caller of
omap_init_wdt was also removed by that commit, and this did
not get restored. So we have the following build warning now:
CC arch/arm/plat-omap/devices.o
arch/arm/plat-omap/devices.c:252: warning: 'omap_init_wdt' defined but not used
Fix this by removing this dead code.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
Couldn't figure out which commit reintroduced this code - git blame
only points to the original commits that added the code years ago.
I suspect it's the DSP bridge commits that got merged via staging.
If someone can debug this mystery for me, that'd be nice.
arch/arm/plat-omap/devices.c | 40
1 file changed, 40 deletions(-)
Index: mainline/arch/arm/plat-omap/devices.c
===
--- mainline.orig/arch/arm/plat-omap/devices.c
+++ mainline/arch/arm/plat-omap/devices.c
@@ -232,46 +232,6 @@ static void omap_init_uwire(void)
static inline void omap_init_uwire(void) {}
#endif
-/*-*/
-
-#ifdefined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-
-static struct resource wdt_resources[] = {
- {
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap_wdt_device = {
- .name = omap_wdt,
- .id = -1,
- .num_resources = ARRAY_SIZE(wdt_resources),
- .resource = wdt_resources,
-};
-
-static void omap_init_wdt(void)
-{
- if (cpu_is_omap16xx())
- wdt_resources[0].start = 0xfffeb000;
- else if (cpu_is_omap2420())
- wdt_resources[0].start = 0x48022000; /* WDT2 */
- else if (cpu_is_omap2430())
- wdt_resources[0].start = 0x49016000; /* WDT2 */
- else if (cpu_is_omap343x())
- wdt_resources[0].start = 0x48314000; /* WDT2 */
- else if (cpu_is_omap44xx())
- wdt_resources[0].start = 0x4a314000;
- else
- return;
-
- wdt_resources[0].end = wdt_resources[0].start + 0x4f;
-
- (void) platform_device_register(omap_wdt_device);
-}
-#else
-static inline void omap_init_wdt(void) {}
-#endif
-
#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
static phys_addr_t omap_dsp_phys_mempool_base;
--
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] musb: am35x: fix compile error due to control apis
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against today's linus tree.
arch/arm/mach-omap2/board-am3517evm.c | 13 +++-
arch/arm/mach-omap2/usb-musb.c| 79
arch/arm/plat-omap/include/plat/usb.h |3 +
drivers/usb/musb/am35x.c | 127 ++---
4 files changed, 133 insertions(+), 89 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..da9a70a 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -403,7 +403,18 @@ static struct omap_musb_board_data musb_board_data = {
static __init void am3517_evm_musb_init(void)
{
- u32 devconf2;
+ u32 devconf2, regval;
+
+ /* Reset the musb interface */
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ regval |= AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = ~AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
/*
* Set up USB clock/mode in the DEVCONF2 register.
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7260558..1f32fdb 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -33,6 +33,82 @@
#ifdef CONFIG_USB_MUSB_SOC
+static void am35x_musb_phy_power(u8 on)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ if (on) {
+ /*
+* Start the on-chip PHY and its PLL.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+ devconf2 |= CONF2_PHY_PLLON;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ printk(KERN_INFO Waiting for PHY clock good...\n);
+ while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+CONF2_PHYCLKGD)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ printk(KERN_ERR musb PHY clock good timed
out\n);
+ break;
+ }
+ }
+ } else {
+ /*
+* Power down the on-chip PHY.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~CONF2_PHY_PLLON;
+ devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+ }
+}
+
+static void am35x_musb_clear_irq(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval |= AM35XX_USBOTGSS_INT_CLR;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am35x_musb_set_mode(u8 musb_mode)
+{
+ u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~CONF2_OTGMODE;
+ switch (musb_mode) {
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ case MUSB_HOST: /* Force VBUS valid, ID = 0 */
+ devconf2 |= CONF2_FORCE_HOST;
+ break;
+#endif
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
+ case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
+ devconf2 |= CONF2_FORCE_DEVICE;
+ break;
+#endif
+#ifdef CONFIG_USB_MUSB_OTG
+ case MUSB_OTG: /* Don't override the VBUS/ID comparators */
+ devconf2 |= CONF2_NO_OVERRIDE;
+ break;
+#endif
+ default:
+ printk(KERN_INFO Unsupported mode %u\n, musb_mode);
+ }
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+}
+
static struct resource musb_resources[] = {
[0] = { /* start and end set dynamically */
.flags = IORESOURCE_MEM,
@@ -93,6 +169,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
} else if (cpu_is_omap3517() || cpu_is_omap3505()) {
musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
musb_resources[1].start = INT_35XX_USBOTG_IRQ;
+ board_data-set_phy_power = am35x_musb_phy_power,
+ board_data-clear_irq = am35x_musb_clear_irq,
+ board_data-set_mode = am35x_musb_set_mode,
} else if (cpu_is_omap34xx()) {
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
diff --git a/arch/arm/plat-omap/include/plat/usb.h
[PATCH RFC -next] omap: fix omap2plus_defconfig build
Having CONFIG_SWP_EMULATE causes the build of omap2plus_defconfig to fail as below: CC arch/arm/kernel/swp_emulate.o /tmp/ccCx8SX8.s: Assembler messages: /tmp/ccCx8SX8.s:339: Error: selected processor does not support ARM mode `ldrexb r7,[r6]' /tmp/ccCx8SX8.s:340: Error: selected processor does not support ARM mode `strexb r3,r2,[r6]' make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1 make: *** [arch/arm/kernel] Error 2 While a proper fix is being found, work around it by turning off the config option in the defconfig. While at it, make savedefconfig trimmed a few lines. Signed-off-by: Anand Gadiyar gadi...@ti.com --- 1. The issue has been discussed here: http://marc.info/?t=12874841253r=1w=2 It's been around for a couple of months now. The last status was that maybe the toolchain should be fixed. I'm afraid I don't know how to fix this properly, so I'm hoping we can live with a workaround like this... 2. An alternative patch is this one: http://marc.info/?l=linux-arm-kernelm=128748874510144w=2 3. Not sure if this should have been combined with the other noise from make savedefconfig - maybe I should have hand-edited the old defconfig to add one line. arch/arm/configs/omap2plus_defconfig | 68 --- 1 file changed, 8 insertions(+), 60 deletions(-) Index: mainline/arch/arm/configs/omap2plus_defconfig === --- mainline.orig/arch/arm/configs/omap2plus_defconfig +++ mainline/arch/arm/configs/omap2plus_defconfig @@ -21,57 +21,23 @@ CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set CONFIG_ARCH_OMAP=y -CONFIG_ARCH_OMAP2=y -CONFIG_ARCH_OMAP3=y -CONFIG_ARCH_OMAP4=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y -CONFIG_OMAP_32K_TIMER=y -CONFIG_MACH_OMAP_GENERIC=y -CONFIG_ARCH_OMAP2420=y -CONFIG_ARCH_OMAP2430=y -CONFIG_ARCH_OMAP3430=y -CONFIG_MACH_OMAP_H4=y -CONFIG_MACH_OMAP_APOLLON=y -CONFIG_MACH_OMAP_2430SDP=y -CONFIG_MACH_OMAP3_BEAGLE=y -CONFIG_MACH_DEVKIT8000=y -CONFIG_MACH_OMAP_LDP=y -CONFIG_MACH_OVERO=y -CONFIG_MACH_OMAP3EVM=y -CONFIG_MACH_OMAP3517EVM=y -CONFIG_MACH_OMAP3_PANDORA=y -CONFIG_MACH_OMAP3_TOUCHBOOK=y -CONFIG_MACH_OMAP_3430SDP=y -CONFIG_MACH_NOKIA_N8X0=y -CONFIG_MACH_NOKIA_RX51=y -CONFIG_MACH_OMAP_ZOOM2=y -CONFIG_MACH_OMAP_ZOOM3=y -CONFIG_MACH_CM_T35=y -CONFIG_MACH_IGEP0020=y -CONFIG_MACH_SBC3530=y -CONFIG_MACH_OMAP_3630SDP=y -CONFIG_MACH_OMAP_4430SDP=y CONFIG_ARM_THUMBEE=y -CONFIG_ARM_L1_CACHE_SHIFT=5 +# CONFIG_SWP_EMULATE is not set CONFIG_ARM_ERRATA_411920=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y # CONFIG_LOCAL_TIMERS is not set -CONFIG_AEABI=y CONFIG_LEDS=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 CONFIG_KEXEC=y CONFIG_FPE_NWFPE=y -CONFIG_VFP=y -CONFIG_NEON=y CONFIG_BINFMT_MISC=y -CONFIG_PM=y CONFIG_PM_DEBUG=y -CONFIG_PM_RUNTIME=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -90,7 +56,7 @@ CONFIG_NETFILTER=y CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m -CONFIG_BT_RFCOMM=y +CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y @@ -126,7 +92,6 @@ CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 -CONFIG_EEPROM_LEGACY=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_MULTI_LUN=y @@ -157,8 +122,6 @@ CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_INPUT_MISC=y CONFIG_INPUT_TWL4030_PWRBUTTON=y CONFIG_VT_HW_CONSOLE_BINDING=y -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y @@ -167,9 +130,7 @@ CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y # CONFIG_LEGACY_PTYS is not set CONFIG_HW_RANDOM=y -CONFIG_I2C=y CONFIG_I2C_CHARDEV=y -CONFIG_I2C_OMAP=y CONFIG_SPI=y CONFIG_SPI_OMAP24XX=y CONFIG_DEBUG_GPIO=y @@ -180,10 +141,6 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y -CONFIG_MENELAUS=y -CONFIG_TWL4030_CORE=y -CONFIG_TWL4030_POWER=y -CONFIG_REGULATOR=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y @@ -196,7 +153,6 @@ CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=y CONFIG_DISPLAY_SUPPORT=y -# CONFIG_VGA_CONSOLE is not set CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FONTS=y @@ -205,25 +161,20 @@ CONFIG_FONT_8x16=y CONFIG_LOGO=y CONFIG_SOUND=m CONFIG_SND=m -CONFIG_SND_MIXER_OSS=y -CONFIG_SND_PCM_OSS=y +CONFIG_SND_MIXER_OSS=m +CONFIG_SND_PCM_OSS=m CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y -CONFIG_SND_USB_AUDIO=y -CONFIG_SND_SOC=y -CONFIG_SND_OMAP_SOC=y -CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=y +CONFIG_SND_USB_AUDIO=m +CONFIG_SND_SOC=m +CONFIG_SND_OMAP_SOC=m +CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y
RE: [PATCH] musb: am35x: fix compile error due to control apis
Ajay Kumar Gupta wrote: As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- Patch created against today's linus tree. I hope this is a short-term fix only; otherwise you will need to duplicate this code in all boards that use an AM3517. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] omap2430: hwmod: remove stray declaration
Patch OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430
in linux-next as of 20101203 introduced the following build
warning - fix this by removing the stray i2c_dev_attr.
arch/arm/mach-omap2/omap_hwmod_2430_data.c:483: warning: 'i2c_dev_attr' defined
but not used
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 --
1 file changed, 2 deletions(-)
Index: mainline/arch/arm/mach-omap2/omap_hwmod_2430_data.c
===
--- mainline.orig/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ mainline/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -480,8 +480,6 @@ static struct omap_hwmod_class i2c_class
.sysc = i2c_sysc,
};
-static struct omap_i2c_dev_attr i2c_dev_attr;
-
/* I2C1 */
static struct omap_i2c_dev_attr i2c1_dev_attr = {
--
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] musb: am35x: fix compile error due to control apis
Hello.
Ajay Kumar Gupta wrote:
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
[...]
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7260558..1f32fdb 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -33,6 +33,82 @@
#ifdef CONFIG_USB_MUSB_SOC
+static void am35x_musb_phy_power(u8 on)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ if (on) {
+ /*
+* Start the on-chip PHY and its PLL.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+ devconf2 |= CONF2_PHY_PLLON;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ printk(KERN_INFO Waiting for PHY clock good...\n);
pr_info().
+ while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+CONF2_PHYCLKGD)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ printk(KERN_ERR musb PHY clock good timed
out\n);
pr_err().
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 59c7fe7..4299097 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -69,6 +69,9 @@ struct omap_musb_board_data {
u8 mode;
u16 power;
unsigned extvbus:1;
+ void(*set_phy_power) (u8 on);
+ void(*clear_irq) (void);
+ void(*set_mode) (u8 mode);
Should be no spaces between ) and (. scripts/checkpatch.pl used to complain
about such things, now it's silent though...
@@ -364,37 +324,21 @@ eoi:
int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
{
- u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+ struct device *dev = musb-controller;
+ struct musb_hdrc_platform_data *plat = dev-platform_data;
+ struct omap_musb_board_data *data = plat-board_data;
- devconf2 = ~CONF2_OTGMODE;
- switch (musb_mode) {
-#ifdef CONFIG_USB_MUSB_HDRC_HCD
- case MUSB_HOST: /* Force VBUS valid, ID = 0 */
- devconf2 |= CONF2_FORCE_HOST;
- break;
-#endif
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
- case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
- devconf2 |= CONF2_FORCE_DEVICE;
- break;
-#endif
-#ifdef CONFIG_USB_MUSB_OTG
- case MUSB_OTG: /* Don't override the VBUS/ID comparators */
- devconf2 |= CONF2_NO_OVERRIDE;
- break;
-#endif
- default:
- DBG(2, Trying to set unsupported mode %u\n, musb_mode);
- }
+ if (data-set_mode)
+ data-set_mode(musb_mode);
You should return -EIO if data-set_mode is NULL.
WBR, Sergei
--
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: UART RX wakeup from sleep not working
Hi Paul, Thanks again for all of the help. It's described in the 34xx TRM sections 4.11.2 Device Off-Mode Configuration and 4.11.3 CORE Power Domain Off-Mode Sequences. All the references to off-mode just confuse things, since AFAIK, this wakeup mechanism also applies to the device in full-chip retention (see also the 'NOTE:' portion of section 4.8.4 Device Wake-Up Events). Yes, I had read that in sprugn4c.pdf, hopefully it's the same as the 34xx pdf. My head is still spinning from trying to understand if I'll get an interrupt or not ;-) Does it generate an interrupt? An IO chain/ring wakeup event ultimately should generate a PRCM interrupt, which should wind up in mach-omap2/pm34xx.c:prcm_interrupt_handler(). You might want to put some debugging in prcm_clear_mod_irqs(), first to see if that function is getting called, and second, to output the state of the WKST and GRPSEL registers. This may be a stupid question, but are you using serial flow control? If not, enabling wakeup on the RTS line isn't going to help. Not a stupid question at all. We are very pin constrained so we only have RX and TX, so no modem lines at all. I was hoping to get the wakeup mechanism to be fired off of in incoming polling character on the RX line. The first character gets lost but wakes us up, then we respond to the next polling character to let the other side know we're awake, then he sends the packet. Just out of curiosity, which kernel are you using? It's the Arago (we need the low power management stuff), Linux omap 2.6.32 #32 Fri Dec 3 10:49:55 PST 2010 armv7l GNU/Linux By the way, if you're using a really recent kernel, you may want to see if sending a few breaks down the line wakes it up: Not very recent, see above. I'm still not getting an interrupt but I decided to shift my focus and I found that this change http://www.efn.org/~rick/pub/serial.patch seems to really improve the variablity in serial timeout when it's taken low. I found that when you take DEFAULT_TIMEOUT lower things start acting very erratic. We'd like to go back to sleep really quickly after a packet is received, like 10ms would be nice, 1ms would be better. Thanks again for the help. Rick -- 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
comm with FTDI usb chip from davinci dm3730 with linux and Arm
Hello List, I am working with my Texas Instruments DM3730 EVM board running its default Linux kernel 2.6.32 and default Linux distro Arago 2010.05. The cpu info is: Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS: 998.84 Features: swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part: 0xc08 CPU revision: 2 Hardware: OMAP3 EVM Revision: 0020 Serial : I need to communicate via USB master to an FTDI Ft245R device that can be found here: http://www.ftdichip.com/Products/ICs/FT245R.htm For cross-compiling I have the free CodeSourcery G++ Lite 2009q1-203 version 4.3.3. The TI EVM kit has libusb-0.1 already installed. What I *think* I need is to just build the package called libftdi that can be found here: http://www.intra2net.com/en/developer/libftdi/index.php So my questions are: 1) Has the already-installed libusb-0.1 been tested or used by anyone successfully? 2) Has anyone tried anything similar to what I need, most likely using some other FTDI chip or with libftdi ? 3) Do you know if the default EVM kernel (2.6.32) and Linux will even compile libftdi or if it works? 4) I know how to build kernels, so if someone could point me to some kernel source or patches then I could configure a working kernel. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver
* G, Manjunath Kondaiah manj...@ti.com [101203 08:32]: I have done required changes to patch series and tested the same on omap2+ boards. Can you pls test OSK5912 board boot from the below git repo? If OSK5912 boots up(with LCD), I will post the 1st series to LO ML. Yeah seems to boot OK now with tux showing up too. 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 v3 0/4] Introduce hardware spinlock framework
OMAP4 introduces a Hardware Spinlock device, which provides hardware assistance for synchronization and mutual exclusion between heterogeneous processors and those not operating under a single, shared operating system (e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP). The intention of this hardware device is to allow remote processors, that have no alternative mechanism to accomplish synchronization and mutual exclusion operations, to share resources (such as memory and/or any other hardware resource). This patchset adds hwspinlock framework that makes it possible for drivers to use those hwspinlock devices and stay platform-independent. Currently there are two users for this hwspinlock interface: 1. Inter-processor communications: on OMAP4, cpu-intensive multimedia tasks are offloaded by the host to the remote M3 and/or C64x+ slave processors. To achieve fast message-based communications, a minimal kernel support is needed to deliver messages arriving from a remote processor to the appropriate user process. This communication is based on a simple data structure that is shared between the remote processors, and access to it is synchronized using the hwspinlock module (remote processor directly places new messages in this shared data structure). 2. On some OMAP4 boards, the I2C bus is shared between the A9 and the M3, and the hwspinlock is used to synchronize access to it. While (2) can get away with an omap-specific hwspinlock implementation, (1) is by no means omap-specific, and a common hwspinlock interface is needed to keep it generic, in hopes that it will be useful for other platforms as well. Changes v2-v3: - Remove the timeout-less _lock API variant (Tony) - s/state-io_base/io_base/ (Ionut) - Remove the generic wording (David) - s/hwspinlock_/hwspin_lock_/ (Mugdha) - Use MAX_SCHEDULE_TIMEOUT to indicate no timeout (Mugdha) - Be more verbose on egregious API misuse (Olof) - locking API misuse is BUG_ON material (Russell) Note: Russell also suggested compiling out NULL checks on ARM. I've posted an initial proposal for this (see https://lkml.org/lkml/2010/11/29/96), which I'm going to resubmit separately. If accepted, I'll adopt hwspinlocks to use it. Patches are tested against linux-omap-2.6 master, which is 2.6.37-rc4 plus omap material. All, but the third (the hwmod omap patch), apply on top of mainline 2.6.37-rc4 as well Changes v1-v2: - Convert to a generic interface (Tony) - API should silently succeed if framework isn't built (Greg) - Don't use ERR_PTR pattern (Grant) - Use tristate, fix and extend commentary (Kevin) - Provide API flexibility regarding irq handling (Arnd, Grant) Note: after reviewing OMAP's L4 access times, and comparing them with external memory latencies, I can say that there is no notable difference. Because of that, we can safely treat the hwspinlock like we do with regular spinlocks: preemption should be disabled, but whether to disable interrupts or not is up to the caller. So despite the TRM's recommendation to always disable local interrupts when taking an OMAP Hardware Spinlock, I have decided to allow callers not to do that (by providing the full extent of hwspin_lock(), hwspin_lock_irq() and hwspin_lock_irqsave() API). Just like regular spinlocks, it's up to the callers to decide whether interrupts should be disabled or not. Sleeping, btw, is still prohibited of course. Contributions: Previous versions of an omap-specific hwspinlock driver circulated in linux-omap several times, and received substantial attention and contribution from many developers (see [1][2][3][4][5][6]): Simon Que did the initial implementation and pushed several iterations Benoit Cousson provided extensive review, help, improvements and hwmod support Hari Kanigeri helped out when Simon was away Sanjeev Premi, Santosh Shilimkar and Nishanth Menon did lots of review I'd like to thank Benoit Cousson, Steve Krueger, Hari Kanigeri, Nourredine Hamoudi and Richard Woodruff for useful discussions about the OMAP Spinlock requirements and use-cases. Relevant linux-omap threads: [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/38755 [2] http://thread.gmane.org/gmane.linux.ports.arm.omap/38917 [3] http://thread.gmane.org/gmane.linux.ports.arm.omap/39187 [4] http://thread.gmane.org/gmane.linux.ports.arm.omap/39365 [5] http://thread.gmane.org/gmane.linux.ports.arm.omap/39815 [6] http://thread.gmane.org/gmane.linux.ports.arm.omap/40901 Benoit Cousson (1): OMAP4: hwmod data: Add hwspinlock Ohad Ben-Cohen (1): drivers: hwspinlock: add framework Simon Que (2): drivers: hwspinlock: add OMAP implementation omap: add hwspinlock device Documentation/hwspinlock.txt | 299 +++ arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/hwspinlock.c | 63 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 64 drivers/Kconfig|2 +
[PATCH v3 1/4] drivers: hwspinlock: add framework
Add a platform-independent hwspinlock framework. Hardware spinlock devices are needed, e.g., in order to access data that is shared between remote processors, that otherwise have no alternative mechanism to accomplish synchronization and mutual exclusion operations. Signed-off-by: Ohad Ben-Cohen o...@wizery.com Cc: Hari Kanigeri h-kanige...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Tony Lindgren t...@atomide.com --- Documentation/hwspinlock.txt | 299 ++ drivers/Kconfig |2 + drivers/Makefile |1 + drivers/hwspinlock/Kconfig | 13 + drivers/hwspinlock/Makefile |5 + drivers/hwspinlock/hwspinlock.h | 61 drivers/hwspinlock/hwspinlock_core.c | 557 ++ include/linux/hwspinlock.h | 298 ++ 8 files changed, 1236 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwspinlock.txt create mode 100644 drivers/hwspinlock/Kconfig create mode 100644 drivers/hwspinlock/Makefile create mode 100644 drivers/hwspinlock/hwspinlock.h create mode 100644 drivers/hwspinlock/hwspinlock_core.c create mode 100644 include/linux/hwspinlock.h diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt new file mode 100644 index 000..65324ce --- /dev/null +++ b/Documentation/hwspinlock.txt @@ -0,0 +1,299 @@ +Hardware Spinlock Framework + +1. Introduction + +Hardware spinlock modules provide hardware assistance for synchronization +and mutual exclusion between heterogeneous processors and those not operating +under a single, shared operating system. + +For example, OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP, +each of which is running a different Operating System (the master, A9, +is usually running Linux and the slave processors, the M3 and the DSP, +are running some flavor of RTOS). + +A generic hwspinlock framework allows platform-independent drivers to use +the hwspinlock device in order to access data structures that are shared +between remote processors, that otherwise have no alternative mechanism +to accomplish synchronization and mutual exclusion operations. + +This is necessary, for example, for Inter-processor communications: +on OMAP4, cpu-intensive multimedia tasks are offloaded by the host to the +remote M3 and/or C64x+ slave processors (by an IPC subsystem called Syslink). + +To achieve fast message-based communications, a minimal kernel support +is needed to deliver messages arriving from a remote processor to the +appropriate user process. + +This communication is based on simple data structures that is shared between +the remote processors, and access to it is synchronized using the hwspinlock +module (remote processor directly places new messages in this shared data +structure). + +A common hwspinlock interface makes it possible to have generic, platform- +independent, drivers. + +2. User API + + struct hwspinlock *hwspin_lock_request(void); + - dynamically assign an hwspinlock and return its address, or NULL + in case an unused hwspinlock isn't available. Users of this + API will usually want to communicate the lock's id to the remote core + before it can be used to achieve synchronization. + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. + + struct hwspinlock *hwspin_lock_request_specific(unsigned int id); + - assign a specific hwspinlock id and return its address, or NULL + if that hwspinlock is already in use. Usually board code will + be calling this function in order to reserve specific hwspinlock + ids for predefined purposes. + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. + + int hwspin_lock_free(struct hwspinlock *hwlock); + - free a previously-assigned hwspinlock; returns 0 on success, or an + appropriate error code on failure (e.g. -EINVAL if the hwspinlock + is already free). + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. + + int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned long timeout); + - lock a previously-assigned hwspinlock with a timeout limit (specified in + jiffies). If the hwspinlock is already taken, the function will busy loop + waiting for it to be released, but give up when the timeout meets jiffies. + If timeout is 0, the function will never give up (therefore if a faulty + remote core never releases the hwspinlock, it will deadlock). + Upon a successful return from this function, preemption is disabled so + the caller must not sleep, and is advised to release the hwspinlock as + soon as possible, in order to minimize remote cores polling on the + hardware interconnect. + Returns 0
[PATCH v3 3/4] OMAP4: hwmod data: Add hwspinlock
From: Benoit Cousson b-cous...@ti.com
Add hwspinlock hwmod data for OMAP4 chip
Signed-off-by: Cousson, Benoit b-cous...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 64
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index d258936..e577d54 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1376,6 +1376,67 @@ static struct omap_hwmod omap44xx_gpio6_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_gpio6_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+
+/*
+ * 'spinlock' class
+ * spinlock provides hardware assistance for synchronizing the processes
+ * running on multiple processors
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_spinlock_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_spinlock_hwmod_class = {
+ .name = spinlock,
+ .sysc = omap44xx_spinlock_sysc,
+};
+
+/* spinlock */
+static struct omap_hwmod omap44xx_spinlock_hwmod;
+static struct omap_hwmod_addr_space omap44xx_spinlock_addrs[] = {
+ {
+ .pa_start = 0x4a0f6000,
+ .pa_end = 0x4a0f6fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - spinlock */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__spinlock = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_spinlock_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_spinlock_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_spinlock_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* spinlock slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_spinlock_slaves[] = {
+ omap44xx_l4_cfg__spinlock,
+};
+
+static struct omap_hwmod omap44xx_spinlock_hwmod = {
+ .name = spinlock,
+ .class = omap44xx_spinlock_hwmod_class,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4CFG_HW_SEM_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_spinlock_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_spinlock_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
omap44xx_dmm_hwmod,
@@ -1418,6 +1479,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_uart2_hwmod,
omap44xx_uart3_hwmod,
omap44xx_uart4_hwmod,
+
+ /* spinlock class */
+ omap44xx_spinlock_hwmod,
NULL,
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] drivers: hwspinlock: add OMAP implementation
From: Simon Que s...@ti.com
Add hwspinlock support for the OMAP4 Hardware Spinlock device.
The Hardware Spinlock device on OMAP4 provides hardware assistance
for synchronization between the multiple processors in the system
(dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP).
[o...@wizery.com: adapt to hwspinlock framework, tidy up]
Signed-off-by: Simon Que s...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Krishnamoorthy, Balaji T balaj...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tony Lindgren t...@atomide.com
---
drivers/hwspinlock/Kconfig |9 ++
drivers/hwspinlock/Makefile |1 +
drivers/hwspinlock/omap_hwspinlock.c | 231 ++
3 files changed, 241 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwspinlock/omap_hwspinlock.c
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 9dd8db4..eb4af28 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -11,3 +11,12 @@ config HWSPINLOCK
coprocessors).
If unsure, say N.
+
+config HWSPINLOCK_OMAP
+ tristate OMAP Hardware Spinlock device
+ depends on HWSPINLOCK ARCH_OMAP4
+ help
+ Say y here to support the OMAP Hardware Spinlock device (firstly
+ introduced in OMAP4).
+
+ If unsure, say N.
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index b9d2b9f..5729a3f 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_HWSPINLOCK) += hwspinlock_core.o
+obj-$(CONFIG_HWSPINLOCK_OMAP) += omap_hwspinlock.o
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
new file mode 100644
index 000..b5867e1
--- /dev/null
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -0,0 +1,231 @@
+/*
+ * OMAP hardware spinlock driver
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Contact: Simon Que s...@ti.com
+ * Hari Kanigeri h-kanige...@ti.com
+ * Ohad Ben-Cohen o...@wizery.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.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/log2.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/hwspinlock.h
+#include linux/platform_device.h
+
+#include hwspinlock.h
+
+/* Spinlock register offsets */
+#define SYSSTATUS_OFFSET 0x0014
+#define LOCK_BASE_OFFSET 0x0800
+
+#define SPINLOCK_NUMLOCKS_BIT_OFFSET (24)
+
+/* Possible values of SPINLOCK_LOCK_REG */
+#define SPINLOCK_NOTTAKEN (0) /* free */
+#define SPINLOCK_TAKEN (1) /* locked */
+
+#define to_omap_hwspinlock(lock) \
+ container_of(lock, struct omap_hwspinlock, lock)
+
+struct omap_hwspinlock {
+ struct hwspinlock lock;
+ void __iomem *addr;
+};
+
+struct omap_hwspinlock_state {
+ int num_locks; /* Total number of locks in system */
+ void __iomem *io_base; /* Mapped base address */
+};
+
+static int omap_hwspinlock_trylock(struct hwspinlock *lock)
+{
+ struct omap_hwspinlock *omap_lock = to_omap_hwspinlock(lock);
+
+ /* attempt to acquire the lock by reading its value */
+ return (SPINLOCK_NOTTAKEN == readl(omap_lock-addr));
+}
+
+static void omap_hwspinlock_unlock(struct hwspinlock *lock)
+{
+ struct omap_hwspinlock *omap_lock = to_omap_hwspinlock(lock);
+
+ /* release the lock by writing 0 to it */
+ writel(SPINLOCK_NOTTAKEN, omap_lock-addr);
+}
+
+/*
+ * relax the OMAP interconnect while spinning on it.
+ *
+ * The specs recommended that the retry delay time will be
+ * just over half of the time that a requester would be
+ * expected to hold the lock.
+ *
+ * The number below is taken from an hardware specs example,
+ * obviously it is somewhat arbitrary.
+ */
+static void omap_hwspinlock_relax(struct hwspinlock *lock)
+{
+ ndelay(50);
+}
+
+static const struct hwspinlock_ops omap_hwspinlock_ops = {
+ .trylock = omap_hwspinlock_trylock,
+ .unlock = omap_hwspinlock_unlock,
+ .relax = omap_hwspinlock_relax,
+};
+
+static int __devinit omap_hwspinlock_probe(struct platform_device *pdev)
+{
+ struct omap_hwspinlock *omap_lock;
+ struct
[PATCH v3 4/4] omap: add hwspinlock device
From: Simon Que s...@ti.com
Build and register an hwspinlock platform device.
Although only OMAP4 supports the hardware spinlock module (for now),
it is still safe to run this initcall on all omaps, because hwmod lookup
will simply fail on hwspinlock-less platforms.
Signed-off-by: Simon Que s...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/hwspinlock.c | 63 ++
2 files changed, 64 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fbc8739..0ea2df3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -197,3 +197,4 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
+obj-$(CONFIG_ARCH_OMAP4) += hwspinlock.o
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
new file mode 100644
index 000..06d4a80
--- /dev/null
+++ b/arch/arm/mach-omap2/hwspinlock.c
@@ -0,0 +1,63 @@
+/*
+ * OMAP hardware spinlock device initialization
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Contact: Simon Que s...@ti.com
+ * Hari Kanigeri h-kanige...@ti.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.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/err.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+
+struct omap_device_pm_latency omap_spinlock_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
+int __init hwspinlocks_init(void)
+{
+ int retval = 0;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ const char *oh_name = spinlock;
+ const char *dev_name = omap_hwspinlock;
+
+ /*
+* Hwmod lookup will fail in case our platform doesn't support the
+* hardware spinlock module, so it is safe to run this initcall
+* on all omaps
+*/
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh == NULL)
+ return -EINVAL;
+
+ od = omap_device_build(dev_name, 0, oh, NULL, 0,
+ omap_spinlock_latency,
+ ARRAY_SIZE(omap_spinlock_latency), false);
+ if (IS_ERR(od)) {
+ pr_err(Can't build omap_device for %s:%s\n, dev_name,
+ oh_name);
+ retval = PTR_ERR(od);
+ }
+
+ return retval;
+}
+/* early board code might need to reserve specific hwspinlock instances */
+postcore_initcall(hwspinlocks_init);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UART RX wakeup from sleep not working
Hi Rick On Fri, 3 Dec 2010, Rick Bronson wrote: This may be a stupid question, but are you using serial flow control? If not, enabling wakeup on the RTS line isn't going to help. Not a stupid question at all. We are very pin constrained so we only have RX and TX, so no modem lines at all. I was hoping to get the wakeup mechanism to be fired off of in incoming polling character on the RX line. The first character gets lost but wakes us up, then we respond to the next polling character to let the other side know we're awake, then he sends the packet. So then setting WAKEUPENABLE on the RTS line won't help, since you're not using that line as an input line. (According to Figure 17-1 UART Module that's a transmit line anyway, so the appropriate flow control line would need to be CTS for incoming data, not RTS. But you're not using flow control so that won't help either.) You might want to try setting WAKEUPENABLE on the pad that is muxed to your RX line, which is where you're receiving bits. Note that there are multiple mux pad targets for that signal, so you need to know which pad your board is actually using to figure out what register to write to. (By the way, all the documentation references in this and the previous E-mails are to the 34xx public TRM rev ZJ, downloadable from the TI web site, should also apply to OMAP3730, maybe with some padconf differences) Just out of curiosity, which kernel are you using? It's the Arago (we need the low power management stuff), Am not familiar with the Arago kernel at all, but full chip retention-idle -- which appears to be what you're trying to use -- should work on mainline Linux 2.6.36. I wouldn't try .37-rc yet, there seems to be something wrong with power management and the serial driver in those, at least on my BeagleBoard. If you need to use the Arago kernel, you'll probably need to contact TI for support. Might be worth suggesting to them that they patch the top-level Makefile to add an EXTRAVERSION of -arago1 or something like that, since this uname: Linux omap 2.6.32 #32 Fri Dec 3 10:49:55 PST 2010 armv7l GNU/Linux ... makes it look like it's just stock 2.6.32, when 'git diff v2.6.32..arago-omap3/master | diffstat' returns: 7380 files changed, 762778 insertions(+), 406769 deletions(-) I'm still not getting an interrupt but I decided to shift my focus and I found that this change http://www.efn.org/~rick/pub/serial.patch seems to really improve the variablity in serial timeout when it's taken low. If SCR_REG.RX_CTS_WU_EN is not set, then that would indeed prevent the UART from waking up. Hmm, wonder if we've got that same problem in mainline... Thanks again for the help. You're welcome. Good luck, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 3/6] TI816X: Update common OMAP machine specific sources
Pedanekar, Hemant wrote on Wednesday, December 01, 2010 7:17 AM:
Tony Lindgren wrote on Tuesday, November 30, 2010 12:59 AM:
* Pedanekar, Hemant hema...@ti.com [101129 09:07]:
Tony Lindgren wrote on Saturday, November 06, 2010 2:30 AM:
Though based on Cortex A8, TI816X series has differences in PRCM, PLL,
clock structure compared to OMAP3.
Many of the OMAP3 specific checks are not applicable for TI816X. For
example, consider following: File -
arch/arm/mach-omap2/omap_hwmod.c
Function - _wait_target_ready()
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
ret =
omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
oh-prcm.omap2.idlest_reg_id,
oh-prcm.omap2.idlest_idle_bit);
The above code inside cpu_is_omap34xx() check is not applicable for TI816X
as there are no CM_IDELST registers.
OK, so places like these will need different handling, and should
then be based on some idlest flag that gets set during the init
based on cpu_is_omap24xx() || cpu_is_omap3430() || cpu_is_omap3630().
Tony,
Thanks for clarifications. I have some concerns though:
1) I will eventually end up preceeding existing OMAP3 ckecks to have
cpu_is_34xx() fail. Fo example, in above case, since
cpu_is_omap34xx will
be true for ti81xx (which we don't want), I need to update
the code as:
if (cpu_is_omap24xx() || (cpu_is_omap34xx()
!cpu_is_ti816x()) {
OR
if (cpu_is_omap24xx() || (cpu_is_omap34xx()
omap_has_idlest()) {
Then proceed to have a TI816X specific handling in else if part with
cpu_is_ti816x() check.
2) Various module base addresses part of global data are
different compared to
OMAP3/4 - e.g., .tap, .ctrl, .prm etc are different. This
means I will still
need separate global data in arch/arm/mach-omap2/common.c as
present for
OMAP3/4 and have it set up in omap2_set_globals_ti816x().
3) Differences in PRCM, PLL mean we need a separate clock
data files such as
clock816x_data.c, clockdomains816x.h, powerdomains816x.h etc.
In fact, future
SoCs in 816x (or rather, 81xx) series will share the same organization and
we will be adding to these files instead of growing
omap3xxx_data.c etc. Of course,
I see some special handling done depending upon cpu_is_ and
features in
omap3xxx_clk_init() - but will similar approach scale with
TI816X which has
completely different clock data?
Similarly, we will also need to add TI816X specific hwmods.
4) TI816X series shares similarity with OMAP4 too - e.g.,
various IPs are same,
CM module is closer to OMAP4 than OMAP3. Thus, regaring (1)
above, I could use
OMAP4 code instead of adding new else if. Of course, again,
there are above
mentioned differences too.
With all this, won't it be better if we add TI816X (or
TI81XX) series to exist
on similar lines with OMAP3/4?
Please let me know your thoughts on the above. I can send v3 patch set
incorporating your suggestion of plugging TI816X into OMAP3.
Also, the patch set submitted doesn't have complete set of files yet
(particularly PRCM/clock code), please have a look at code
hosted on Arago.
Below is the link to mach-omap2 folder (2.6.34 at the moment)
http://arago-project.org/git/people/?p=sriram/ti-psp-omap.git;
a=tree;f=arch/arm/mach-omap2;h=
7f2c48b8cb3213b3850d0b6ea242c0c53fa5d6fa;hb=refs/heads/ti816x-master
Tony,
Could you please provide your comments on the above?
Thanks
-
Hemant
--
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] Patches to make multi-soc handling in entry-armv.S easier
Hi all, I've got some patches almost ready to go to merge the omap1 configs into a single omap1_defconfig. While working on getting that done, I had to come up with a better solution for entry-armv.S macros to detect the soc we're running on. I suggest we add asm_irq_base and asm_irq_flags as in the first patch in this series does. This way we can do the soc based detection in init_irq or similar place. This might help also the multi-arm work too. Regards, Tony --- Tony Lindgren (4): ARM: Add asm_irq_base and asm_irq_flags for entry-armv.S macros omap2+: Use asm_irq_base for entry-macro.S omap1: Use asm_irq_flags for entry-macro.S omap1: Use get_irqnr_preamble arch/arm/include/asm/irq.h |2 + arch/arm/kernel/entry-armv.S | 13 arch/arm/mach-omap1/include/mach/entry-macro.S | 20 +++-- arch/arm/mach-omap1/irq.c |4 +++ arch/arm/mach-omap2/include/mach/entry-macro.S | 37 +++- arch/arm/mach-omap2/io.c | 20 + arch/arm/plat-omap/include/plat/irqs.h |2 + 7 files changed, 49 insertions(+), 49 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: Add asm_irq_base and asm_irq_flags for entry-armv.S macros
This way we can use the SoC specific code to detect what we're running on. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/include/asm/irq.h |2 ++ arch/arm/kernel/entry-armv.S | 13 + 2 files changed, 15 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/irq.h b/arch/arm/include/asm/irq.h index 2721a58..2610c59 100644 --- a/arch/arm/include/asm/irq.h +++ b/arch/arm/include/asm/irq.h @@ -20,6 +20,8 @@ #ifndef __ASSEMBLY__ struct irqaction; struct pt_regs; +extern void __iomem *asm_irq_base; +extern unsigned int asm_irq_flags; extern void migrate_irqs(void); extern void asm_do_IRQ(unsigned int, struct pt_regs *); diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index c09e357..37cdb27 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -63,6 +63,19 @@ .endm +/* + * Allow machine specific code to initialize asm_irq_base and asm_irq_flags + * for use in get_irqnr_preamble and get_irqnr_and_base macros + */ + .pushsection .data + .globl asm_irq_base +asm_irq_base: + .long 0 + .globl asm_irq_flags +asm_irq_flags: + .long 0 + .popsection + #ifdef CONFIG_KPROBES .section.kprobes.text,ax,%progbits #else -- 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] omap2+: Use asm_irq_base for entry-macro.S
This way we can use the generic omap SoC detection code instead.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/include/mach/entry-macro.S | 37 +++-
arch/arm/mach-omap2/io.c | 20 +
2 files changed, 25 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S
b/arch/arm/mach-omap2/include/mach/entry-macro.S
index 06e64e1..c29728c 100644
--- a/arch/arm/mach-omap2/include/mach/entry-macro.S
+++ b/arch/arm/mach-omap2/include/mach/entry-macro.S
@@ -38,41 +38,14 @@
*/
#ifdef MULTI_OMAP2
- .pushsection .data
-omap_irq_base: .word 0
- .popsection
- /* Configure the interrupt base on the first interrupt */
+ /*
+* Configure the interrupt base on the first interrupt.
+* See also omap_irq_base_init for setting asm_irq_base.
+*/
.macro get_irqnr_preamble, base, tmp
-9:
- ldr \base, =omap_irq_base @ irq base address
+ ldr \base, =asm_irq_base@ irq base address
ldr \base, [\base, #0] @ irq base value
- cmp \base, #0 @ already configured?
- bne 9997f @ nothing to do
-
- mrc p15, 0, \tmp, c0, c0, 0 @ get processor revision
- and \tmp, \tmp, #0x000f @ only check architecture
- cmp \tmp, #0x0007 @ is v6?
- beq 2400f @ found v6 so it's omap24xx
- mrc p15, 0, \tmp, c0, c0, 0 @ get processor revision
- and \tmp, \tmp, #0x00f0 @ check cortex 8 or 9
- cmp \tmp, #0x0080 @ cortex A-8?
- beq 3400f @ found A-8 so it's omap34xx
- cmp \tmp, #0x0090 @ cortex A-9?
- beq 4400f @ found A-9 so it's omap44xx
-2400: ldr \base, =OMAP2_IRQ_BASE
- ldr \tmp, =omap_irq_base
- str \base, [\tmp, #0]
- b 9b
-3400: ldr \base, =OMAP3_IRQ_BASE
- ldr \tmp, =omap_irq_base
- str \base, [\tmp, #0]
- b 9b
-4400: ldr \base, =OMAP4_IRQ_BASE
- ldr \tmp, =omap_irq_base
- str \base, [\tmp, #0]
- b 9b
-9997:
.endm
/* Check the pending interrupts. Note that base already set */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index a1939b1..7ac1d31 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -46,6 +46,7 @@
#include clockdomains.h
#include plat/omap_hwmod.h
+#include plat/multi.h
/*
* The machine specific code may provide the extra mapping besides the
@@ -311,6 +312,23 @@ static int __init _omap2_init_reprogram_sdrc(void)
return v;
}
+/*
+ * Initialize asm_irq_base for entry-macro.S
+ */
+static inline void omap_irq_base_init(void)
+{
+#ifdef MULTI_OMAP2
+ if (cpu_is_omap242x())
+ asm_irq_base = OMAP2_L4_IO_ADDRESS(OMAP24XX_IC_BASE);
+ else if (cpu_is_omap34xx())
+ asm_irq_base = OMAP2_L4_IO_ADDRESS(OMAP34XX_IC_BASE);
+ else if (cpu_is_omap44xx())
+ asm_irq_base = OMAP2_L4_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE);
+ else
+ pr_err(Could not initialize asm_irq_base\n);
+#endif
+}
+
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
@@ -352,4 +370,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
_omap2_init_reprogram_sdrc();
}
gpmc_init();
+
+ omap_irq_base_init();
}
--
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] omap1: Use asm_irq_flags for entry-macro.S
Initialize asm_irq_flags in omap_init_irq and use it in
get_irqnr_and_base to detect between omap7xx and omap15xx/16xx.
Note that both INT_1510_IH2_IRQ and INT_1510_IH2_IRQ are defined
as 0, so use INT_1510_IH2_IRQ for both of them.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/include/mach/entry-macro.S | 18 +++---
arch/arm/mach-omap1/irq.c |4
arch/arm/plat-omap/include/plat/irqs.h |2 +-
3 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap1/include/mach/entry-macro.S
b/arch/arm/mach-omap1/include/mach/entry-macro.S
index df9060e..25b74f9 100644
--- a/arch/arm/mach-omap1/include/mach/entry-macro.S
+++ b/arch/arm/mach-omap1/include/mach/entry-macro.S
@@ -14,20 +14,6 @@
#include mach/irqs.h
#include asm/hardware/gic.h
-#if (defined(CONFIG_ARCH_OMAP730)||defined(CONFIG_ARCH_OMAP850)) \
- (defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX))
-#error FIXME: OMAP7XX doesn't support multiple-OMAP
-#elif defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
-#define INT_IH2_IRQINT_7XX_IH2_IRQ
-#elif defined(CONFIG_ARCH_OMAP15XX)
-#define INT_IH2_IRQINT_1510_IH2_IRQ
-#elif defined(CONFIG_ARCH_OMAP16XX)
-#define INT_IH2_IRQINT_1610_IH2_IRQ
-#else
-#warning IH2 IRQ defaulted
-#define INT_IH2_IRQINT_1510_IH2_IRQ
-#endif
-
.macro disable_fiq
.endm
@@ -47,9 +33,11 @@
beq 1510f
ldr \irqnr, [\base, #IRQ_SIR_FIQ_REG_OFFSET]
+ ldr \tmp, =asm_irq_flags@ irq flags address
+ ldr \tmp, [\tmp, #0]@ irq flags value
cmp \irqnr, #0
ldreq \irqnr, [\base, #IRQ_SIR_IRQ_REG_OFFSET]
- cmpeq \irqnr, #INT_IH2_IRQ
+ cmpeq \irqnr, \tmp
ldreq \base, =OMAP1_IO_ADDRESS(OMAP_IH2_BASE)
ldreq \irqnr, [\base, #IRQ_SIR_IRQ_REG_OFFSET]
addeqs \irqnr, \irqnr, #32
diff --git a/arch/arm/mach-omap1/irq.c b/arch/arm/mach-omap1/irq.c
index db913c3..e7f2166 100644
--- a/arch/arm/mach-omap1/irq.c
+++ b/arch/arm/mach-omap1/irq.c
@@ -180,22 +180,26 @@ void __init omap_init_irq(void)
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
+ asm_irq_flags = INT_7XX_IH2_IRQ;
irq_banks = omap7xx_irq_banks;
irq_bank_count = ARRAY_SIZE(omap7xx_irq_banks);
}
#endif
#ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap1510()) {
+ asm_irq_flags = INT_1510_IH2_IRQ;
irq_banks = omap1510_irq_banks;
irq_bank_count = ARRAY_SIZE(omap1510_irq_banks);
}
if (cpu_is_omap310()) {
+ asm_irq_flags = INT_1510_IH2_IRQ;
irq_banks = omap310_irq_banks;
irq_bank_count = ARRAY_SIZE(omap310_irq_banks);
}
#endif
#if defined(CONFIG_ARCH_OMAP16XX)
if (cpu_is_omap16xx()) {
+ asm_irq_flags = INT_1510_IH2_IRQ;
irq_banks = omap1610_irq_banks;
irq_bank_count = ARRAY_SIZE(omap1610_irq_banks);
}
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 65e20a6..2910de9 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -77,7 +77,7 @@
/*
* OMAP-1610 specific IRQ numbers for interrupt handler 1
*/
-#define INT_1610_IH2_IRQ 0
+#define INT_1610_IH2_IRQ INT_1510_IH2_IRQ
#define INT_1610_IH2_FIQ 2
#define INT_1610_McBSP2_TX 4
#define INT_1610_McBSP2_RX 5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] omap1: Use get_irqnr_preamble
This saves some cycles for multiple interrupts case. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap1/include/mach/entry-macro.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap1/include/mach/entry-macro.S b/arch/arm/mach-omap1/include/mach/entry-macro.S index 25b74f9..1bdcae1 100644 --- a/arch/arm/mach-omap1/include/mach/entry-macro.S +++ b/arch/arm/mach-omap1/include/mach/entry-macro.S @@ -18,13 +18,13 @@ .endm .macro get_irqnr_preamble, base, tmp + ldr \base, =OMAP1_IO_ADDRESS(OMAP_IH1_BASE) .endm .macro arch_ret_to_user, tmp1, tmp2 .endm .macro get_irqnr_and_base, irqnr, irqstat, base, tmp - ldr \base, =OMAP1_IO_ADDRESS(OMAP_IH1_BASE) ldr \irqnr, [\base, #IRQ_ITR_REG_OFFSET] ldr \tmp, [\base, #IRQ_MIR_REG_OFFSET] mov \irqstat, #0x -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Introduce hardware spinlock framework
On 12/03/2010 03:50 PM, Ohad Ben-Cohen wrote: OMAP4 introduces a Hardware Spinlock device, which provides hardware assistance for synchronization and mutual exclusion between heterogeneous processors and those not operating under a single, shared operating system (e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP). The intention of this hardware device is to allow remote processors, that have no alternative mechanism to accomplish synchronization and mutual exclusion operations, to share resources (such as memory and/or any other hardware resource). Does anything other than OMAP4 have one of these things? And are there any devices that are commonly encountered across more than one platform that might have these hardware spinlocks, thus making it advantageous to have a common framework? If not why a general purpose framework for a very chip specific feature? There are chips with hardware atomic memory, but the only time it makes sense to use it is in conjunction with specialize on-chip devices. So the implementation details are kept in the drivers rather than creating a general purpose hwatomic (with its hwatomic_add() et al.) type. David Daney This patchset adds hwspinlock framework that makes it possible for drivers to use those hwspinlock devices and stay platform-independent. Currently there are two users for this hwspinlock interface: 1. Inter-processor communications: on OMAP4, cpu-intensive multimedia tasks are offloaded by the host to the remote M3 and/or C64x+ slave processors. To achieve fast message-based communications, a minimal kernel support is needed to deliver messages arriving from a remote processor to the appropriate user process. This communication is based on a simple data structure that is shared between the remote processors, and access to it is synchronized using the hwspinlock module (remote processor directly places new messages in this shared data structure). 2. On some OMAP4 boards, the I2C bus is shared between the A9 and the M3, and the hwspinlock is used to synchronize access to it. While (2) can get away with an omap-specific hwspinlock implementation, (1) is by no means omap-specific, and a common hwspinlock interface is needed to keep it generic, in hopes that it will be useful for other platforms as well. Changes v2-v3: - Remove the timeout-less _lock API variant (Tony) - s/state-io_base/io_base/ (Ionut) - Remove the generic wording (David) - s/hwspinlock_/hwspin_lock_/ (Mugdha) - Use MAX_SCHEDULE_TIMEOUT to indicate no timeout (Mugdha) - Be more verbose on egregious API misuse (Olof) - locking API misuse is BUG_ON material (Russell) Note: Russell also suggested compiling out NULL checks on ARM. I've posted an initial proposal for this (see https://lkml.org/lkml/2010/11/29/96), which I'm going to resubmit separately. If accepted, I'll adopt hwspinlocks to use it. Patches are tested against linux-omap-2.6 master, which is 2.6.37-rc4 plus omap material. All, but the third (the hwmod omap patch), apply on top of mainline 2.6.37-rc4 as well Changes v1-v2: - Convert to a generic interface (Tony) - API should silently succeed if framework isn't built (Greg) - Don't use ERR_PTR pattern (Grant) - Use tristate, fix and extend commentary (Kevin) - Provide API flexibility regarding irq handling (Arnd, Grant) Note: after reviewing OMAP's L4 access times, and comparing them with external memory latencies, I can say that there is no notable difference. Because of that, we can safely treat the hwspinlock like we do with regular spinlocks: preemption should be disabled, but whether to disable interrupts or not is up to the caller. So despite the TRM's recommendation to always disable local interrupts when taking an OMAP Hardware Spinlock, I have decided to allow callers not to do that (by providing the full extent of hwspin_lock(), hwspin_lock_irq() and hwspin_lock_irqsave() API). Just like regular spinlocks, it's up to the callers to decide whether interrupts should be disabled or not. Sleeping, btw, is still prohibited of course. Contributions: Previous versions of an omap-specific hwspinlock driver circulated in linux-omap several times, and received substantial attention and contribution from many developers (see [1][2][3][4][5][6]): Simon Que did the initial implementation and pushed several iterations Benoit Cousson provided extensive review, help, improvements and hwmod support Hari Kanigeri helped out when Simon was away Sanjeev Premi, Santosh Shilimkar and Nishanth Menon did lots of review I'd like to thank Benoit Cousson, Steve Krueger, Hari Kanigeri, Nourredine Hamoudi and Richard Woodruff for useful discussions about the OMAP Spinlock requirements and use-cases. Relevant linux-omap threads: [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/38755 [2] http://thread.gmane.org/gmane.linux.ports.arm.omap/38917 [3] http://thread.gmane.org/gmane.linux.ports.arm.omap/39187 [4]
Re: OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled
Salut Jean On Thu, 2 Dec 2010, Jean Pihet wrote: On Thu, Dec 2, 2010 at 8:23 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 25 Nov 2010, Jean Pihet wrote: On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley p...@pwsan.com wrote: On Thu, 25 Nov 2010, Jean Pihet wrote: On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley p...@pwsan.com wrote: The console semaphore must be held while the OMAP UART devices are disabled, lest a console write cause an ARM abort (and a kernel crash) when the underlying console device is inaccessible. These crashes only occur when the console is on one of the OMAP internal serial ports. This does not fix the issue for me on Beagle (console on ttyO2). Doing: / # echo 5 /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout / # echo 5 /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout / # echo 5 /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout and waiting 5 seconds hangs the console. By the way, you write that the above situation hangs the console. Is it just the case that the console dies and the rest of the system is still alive, or does the whole system crash? The console hangs, the rest of the system still runs. Just out of curiosity, if you send a few breaks to the OMAP over serial, does that cause the console to pay attention again? CTRL-A F in minicom. Yes it helps. In most cases sending 2-3 breaks resumes the UART console. Could you try enabling DSS in your .config? I applied the following to my omap2plus_defconfig after make oldnoconfig, and the console is now working again for me. Hopefully adding DSS hwmod stuff will fix this... - Paul --- .config 2010-12-03 18:05:31.661889255 -0700 +++ .config.sleep.working 2010-12-03 18:03:57.733918058 -0700 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux/arm 2.6.37-rc4 Kernel Configuration -# Fri Dec 3 18:05:31 2010 +# Fri Dec 3 18:00:21 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -1465,9 +1465,28 @@ # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set -# CONFIG_FB_OMAP is not set CONFIG_FB_OMAP_LCD_VGA=y -# CONFIG_OMAP2_DSS is not set +CONFIG_OMAP2_DSS=y +CONFIG_OMAP2_VRAM_SIZE=0 +CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y +# CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set +CONFIG_OMAP2_DSS_DPI=y +# CONFIG_OMAP2_DSS_RFBI is not set +CONFIG_OMAP2_DSS_VENC=y +# CONFIG_OMAP2_DSS_SDI is not set +# CONFIG_OMAP2_DSS_DSI is not set +# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set +CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 +# CONFIG_FB_OMAP2 is not set + +# +# OMAP2/3 Display Device Drivers +# +# CONFIG_PANEL_GENERIC is not set +# CONFIG_PANEL_SHARP_LS037V7DW01 is not set +# CONFIG_PANEL_SHARP_LQ043T1DG01 is not set +# CONFIG_PANEL_TOPPOLY_TDO35S is not set +# CONFIG_PANEL_TPO_TD043MTEA1 is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y # CONFIG_LCD_L4F00242T03 is not set
Re: [PATCH v3 0/4] Introduce hardware spinlock framework
On Sat, Dec 4, 2010 at 2:29 AM, David Daney dda...@caviumnetworks.com wrote: Does anything other than OMAP4 have one of these things? I'm not aware of any, but David Brownell had some ideas about it in our previous v2 discussion (see http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39413.html). Btw, you might want to read throughout that entire discussion with David, since it was touching the same questions you raise here. And are there any devices that are commonly encountered across more than one platform that might have these hardware spinlocks, thus making it advantageous to have a common framework? Such devices are just multiple processors that have no alternative mechanism to accomplish synchronization. OMAP4 has a few non-coherent heterogeneous processors that do not support fancy synchronization primitives, so it needs this hwspinlock peripheral. Otherwise, I don't know how common that is (/might become), and I'd hate speculating, but I suspect that OMAP is not going to be the only platform with multiple coprocessors, that have no other means of achieving synchronization, and with which inter-processor communications is desired. If not why a general purpose framework for a very chip specific feature? We started out with an omap-specific driver (see first iteration at http://lwn.net/Articles/410375/), but were asked to make it a platform-agnostic framework, in order to keep the IPC drivers that will use it generic (and assuming that more users will show up for such framework). To me it sounds reasonable, but again, I prefer not to speculate how many users will show up for this, if any. Both ways (framework / omap-specific driver) will work for us just fine. There are chips with hardware atomic memory, but the only time it makes sense to use it is in conjunction with specialize on-chip devices. So the implementation details are kept in the drivers rather than creating a general purpose hwatomic (with its hwatomic_add() et al.) type. This case is a bit different IMHO: some of the potential users of hwspinlocks are just generic IPC drivers that are by no means platform-specific. It's not a special on-chip device: it's just one processor, trying to achieve mutual exclusion with another processor, before manipulating some shared data structure. -- 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 v1 0/9] OMAP: DMA: hwmod and DMA as platform device
Patch series to convert DMA library into platform driver using platform device model and adapting hwmod for omap2+. The original patch series : http://comments.gmane.org/gmane.linux.ports.arm.omap/46953 has been split into two patch series based on suggestion from Tony. (https://patchwork.kernel.org/patch/375831/) The first series will prepare existing DMA library for DMA hwmod and converting the same into platform driver. The second series will have: arch/arm/mach-omap1/dma.c omap1 specific platform init arch/arm/mach-omap2/dma.c omap2+ specific platform init drivers/dma/omap-dma.c driver using dmaengine.c Patch series1 Design: 1. The low level read/write macros are converted into static inline functions so that, these functions can be moved to respective mach-omap driver files later. (Thanks to Tony and Kevin for their suggestions on handling all omap register offset without adding extra enums) 2. Implements generic errata handling for all OMAP DMA errata. 3. DMA hwmod data is updated for respective hwmod db files. 4. The DMA library is split into two layers. a. The generic code is retained in plat-omap/dma.c b. The machine specific init code is moved to respective mach-omap dma files. Minimal machine specific code is moved to respective mach-omap dma files with this series. Rest of code movement and API cleanup's are handled in second series. Patch series applies on top of latest linux omap master branch: * git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Branch: master commit a04fd22204b13ce34a3f8a8157f83c44d64f8da9 Merge: e941bb0 afd2d11 Author: Tony Lindgren t...@atomide.com Linux-omap rebuilt: Merged in usb patches for testing * Test Report: Build: omap2plus_defconfig: Success omap_osk_5912_defconfig: Success Boot: OMAP3530Beagle : Success OMAP4430Blaze(ES2.1) : Success OMAP1(OSK5912) : Success Test cases executed: 1. All applicable TI DMA tests which are located at: git://dev.omapzoom.org/pub/scm/richo/device_driver_test.git Branch: master Report can be accessed at: Beagle board: http://pastebin.com/sDUChNLr The original patch series and change history can be found at: http://permalink.gmane.org/gmane.linux.ports.arm.omap/46953# Benoit Cousson (1): OMAP4: hwmod data: add system DMA G, Manjunath Kondaiah (8): OMAP: DMA: Replace read/write macros with functions OMAP: DMA: Introduce errata handling feature OMAP2420: hwmod data: add system DMA OMAP2430: hwmod data: add system DMA OMAP3: hwmod data: add system DMA OMAP1: DMA: Implement in platform device model OMAP2+: DMA: hwmod: Device registration OMAP: DMA: Convert DMA library into platform driver arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/dma.c | 390 arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/dma.c | 297 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 87 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 87 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 97 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 101 arch/arm/plat-omap/dma.c | 697 arch/arm/plat-omap/include/plat/dma.h | 232 -- 10 files changed, 1452 insertions(+), 540 deletions(-) create mode 100644 arch/arm/mach-omap1/dma.c create mode 100644 arch/arm/mach-omap2/dma.c Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.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 v1 1/9] OMAP: DMA: Replace read/write macros with functions
Prepare DMA library to get converted into DMA driver using platform
device model and hwmod infrastucture(for omap2+, resource structures
for omap1)
The low level read/write macros are replaced with static inline
functions and register offsets are handled through static register
offset tables mapped through enumeration constants.
These low level read/write functions along with static register offset
tables will be moved to respective mach-omap dma files in the later
patches of this series.
There are no functionality changes with these changes except change in
logic for handling 16bit registers of OMAP1.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dma.c | 517 -
arch/arm/plat-omap/include/plat/dma.h | 151 ++
2 files changed, 345 insertions(+), 323 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index a863f55..49a7cd4 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,96 @@
#undef DEBUG
+static u16 reg_map_omap1[] = {
+ [GCR] = 0x400,
+ [GSCR] = 0x404,
+ [GRST1] = 0x408,
+ [HW_ID] = 0x442,
+ [PCH2_ID] = 0x444,
+ [PCH0_ID] = 0x446,
+ [PCH1_ID] = 0x448,
+ [PCHG_ID] = 0x44a,
+ [PCHD_ID] = 0x44c,
+ [CAPS_0]= 0x44e,
+ [CAPS_1]= 0x452,
+ [CAPS_2]= 0x456,
+ [CAPS_3]= 0x458,
+ [CAPS_4]= 0x45a,
+ [PCH2_SR] = 0x460,
+ [PCH0_SR] = 0x480,
+ [PCH1_SR] = 0x482,
+ [PCHD_SR] = 0x4c0,
+
+ /* Common Registers */
+ [CSDP] = 0x00,
+ [CCR] = 0x02,
+ [CICR] = 0x04,
+ [CSR] = 0x06,
+ [CEN] = 0x10,
+ [CFN] = 0x12,
+ [CSFI] = 0x14,
+ [CSEI] = 0x16,
+ [CPC] = 0x18, /* 15xx only */
+ [CSAC] = 0x18,
+ [CDAC] = 0x1a,
+ [CDEI] = 0x1c,
+ [CDFI] = 0x1e,
+ [CLNK_CTRL] = 0x28,
+
+ /* Channel specific register offsets */
+ [CSSA] = 0x08,
+ [CDSA] = 0x0c,
+ [COLOR] = 0x20,
+ [CCR2] = 0x24,
+ [LCH_CTRL] = 0x2a,
+};
+
+static u16 reg_map_omap2[] = {
+ [REVISION] = 0x00,
+ [GCR] = 0x78,
+ [IRQSTATUS_L0] = 0x08,
+ [IRQSTATUS_L1] = 0x0c,
+ [IRQSTATUS_L2] = 0x10,
+ [IRQSTATUS_L3] = 0x14,
+ [IRQENABLE_L0] = 0x18,
+ [IRQENABLE_L1] = 0x1c,
+ [IRQENABLE_L2] = 0x20,
+ [IRQENABLE_L3] = 0x24,
+ [SYSSTATUS] = 0x28,
+ [OCP_SYSCONFIG] = 0x2c,
+ [CAPS_0]= 0x64,
+ [CAPS_2]= 0x6c,
+ [CAPS_3]= 0x70,
+ [CAPS_4]= 0x74,
+
+ /* Common register offsets */
+ [CCR] = 0x80,
+ [CLNK_CTRL] = 0x84,
+ [CICR] = 0x88,
+ [CSR] = 0x8c,
+ [CSDP] = 0x90,
+ [CEN] = 0x94,
+ [CFN] = 0x98,
+ [CSEI] = 0xa4,
+ [CSFI] = 0xa8,
+ [CDEI] = 0xac,
+ [CDFI] = 0xb0,
+ [CSAC] = 0xb4,
+ [CDAC] = 0xb8,
+
+ /* Channel specific register offsets */
+ [CSSA] = 0x9c,
+ [CDSA] = 0xa0,
+ [CCEN] = 0xbc,
+ [CCFN] = 0xc0,
+ [COLOR] = 0xc4,
+
+ /* OMAP4 specific registers */
+ [CDP] = 0xd0,
+ [CNDP] = 0xd4,
+ [CCDN] = 0xd8,
+};
+
#ifndef CONFIG_ARCH_OMAP1
enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE, DMA_CH_STARTED,
DMA_CH_QUEUED, DMA_CH_NOTSTARTED, DMA_CH_PAUSED, DMA_CH_LINK_ENABLED
@@ -138,6 +228,9 @@ static int omap_dma_reserve_channels;
static spinlock_t dma_chan_lock;
static struct omap_dma_lch *dma_chan;
static void __iomem *omap_dma_base;
+static u16 *reg_map;
+static u8 dma_stride;
+static enum omap_reg_offsets dma_common_ch_start, dma_common_ch_end;
static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = {
INT_DMA_CH0_6, INT_DMA_CH1_7, INT_DMA_CH2_8, INT_DMA_CH3,
@@ -154,23 +247,48 @@ static inline void omap_enable_channel_irq(int lch);
#define REVISIT_24XX() printk(KERN_ERR FIXME: no %s on 24xx\n, \
__func__);
-#define dma_read(reg)
[PATCH v1 2/9] OMAP: DMA: Introduce errata handling feature
Implement errata handling to use flags instead of cpu_is_* and
cpu_class_* in the code.
The errata flags are initialized at init time and during runtime we are
using the errata variable (via the IS_DMA_ERRATA macro) to execute the
required errata workaround.
Reused errata handling patch from: Peter Ujfalusi
peter.ujfal...@nokia.com
https://patchwork.kernel.org/patch/231191/
Changes to above patch:
1. Changes are done for converting all the existing errata work arounds
to use this feature.
2. Detailed description for each errata is added.
3. Fixed bug in SET_DMA_ERRATA macro
4. Bit shifting in macro definitions are replaced with BIT() macro
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dma.c | 152 ++---
arch/arm/plat-omap/include/plat/dma.h | 12 +++
2 files changed, 114 insertions(+), 50 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 49a7cd4..6f51bf3 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -144,6 +144,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
#define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
static int enable_1510_mode;
+static u32 errata;
static struct omap_dma_global_context_registers {
u32 dma_irqenable_l0;
@@ -1088,31 +1089,17 @@ void omap_start_dma(int lch)
cur_lch = next_lch;
} while (next_lch != -1);
- } else if (cpu_is_omap242x() ||
- (cpu_is_omap243x() omap_type() = OMAP2430_REV_ES1_0)) {
-
- /* Errata: Need to write lch even if not using chaining */
+ } else if (IS_DMA_ERRATA(DMA_ERRATA_PARALLEL_CHANNELS))
dma_write(lch, CLNK_CTRL, lch);
- }
omap_enable_channel_irq(lch);
l = dma_read(CCR, lch);
- /*
-* Errata: Inter Frame DMA buffering issue (All OMAP2420 and
-* OMAP2430ES1.0): DMA will wrongly buffer elements if packing and
-* bursting is enabled. This might result in data gets stalled in
-* FIFO at the end of the block.
-* Workaround: DMA channels must have BUFFERING_DISABLED bit set to
-* guarantee no data will stay in the DMA FIFO in case inter frame
-* buffering occurs.
-*/
- if (cpu_is_omap2420() ||
- (cpu_is_omap2430() (omap_type() == OMAP2430_REV_ES1_0)))
- l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
-
+ if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING))
+ l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
l |= OMAP_DMA_CCR_EN;
+
dma_write(l, CCR, lch);
dma_chan[lch].flags |= OMAP_DMA_ACTIVE;
@@ -1128,8 +1115,8 @@ void omap_stop_dma(int lch)
dma_write(0, CICR, lch);
l = dma_read(CCR, lch);
- /* OMAP3 Errata i541: sDMA FIFO draining does not finish */
- if (cpu_is_omap34xx() (l OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+ if (IS_DMA_ERRATA(DMA_ERRATA_i541)
+ (l OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
int i = 0;
u32 sys_cf;
@@ -1229,11 +1216,7 @@ dma_addr_t omap_get_dma_src_pos(int lch)
else
offset = dma_read(CSAC, lch);
- /*
-* omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
-* read before the DMA controller finished disabling the channel.
-*/
- if (!cpu_is_omap15xx() offset == 0)
+ if (IS_DMA_ERRATA(DMA_ERRATA_3_3) offset == 0)
offset = dma_read(CSAC, lch);
if (cpu_class_is_omap1())
@@ -1814,7 +1797,7 @@ int omap_stop_dma_chain_transfers(int chain_id)
{
int *channels;
u32 l, i;
- u32 sys_cf;
+ u32 sys_cf = 0;
/* Check for input params */
if (unlikely((chain_id 0 || chain_id = dma_lch_count))) {
@@ -1829,15 +1812,13 @@ int omap_stop_dma_chain_transfers(int chain_id)
}
channels = dma_linked_lch[chain_id].linked_dmach_q;
- /*
-* DMA Errata:
-* Special programming model needed to disable DMA before end of block
-*/
- sys_cf = dma_read(OCP_SYSCONFIG, 0);
- l = sys_cf;
- /* Middle mode reg set no Standby */
- l = ~((1 12)|(1 13));
- dma_write(l, OCP_SYSCONFIG, 0);
+ if (IS_DMA_ERRATA(DMA_ERRATA_i88)) {
+ sys_cf = dma_read(OCP_SYSCONFIG, 0);
+ l = sys_cf;
+ /* Middle mode reg set no Standby */
+ l = ~((1 12)|(1 13));
+ dma_write(l, OCP_SYSCONFIG, 0);
+ }
for (i = 0; i dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
@@ -1856,8 +1837,8 @@ int omap_stop_dma_chain_transfers(int chain_id)
/* Reset the Queue pointers */
OMAP_DMA_CHAIN_QINIT(chain_id);
-
[PATCH v1 3/9] OMAP2420: hwmod data: add system DMA
Add OMAP2420 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 87
arch/arm/plat-omap/include/plat/dma.h | 11
2 files changed, 98 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index d953425..c36070b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -42,6 +42,7 @@ static struct omap_hwmod omap2420_gpio1_hwmod;
static struct omap_hwmod omap2420_gpio2_hwmod;
static struct omap_hwmod omap2420_gpio3_hwmod;
static struct omap_hwmod omap2420_gpio4_hwmod;
+static struct omap_hwmod omap2420_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -779,6 +780,89 @@ static struct omap_hwmod omap2420_gpio4_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/* system dma */
+static struct omap_hwmod_class_sysconfig omap2420_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap2420_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32,
+ .lch_count = 32,
+};
+
+static struct omap_hwmod_irq_info omap2420_dma_system_irqs[] = {
+ { .name = 0, .irq = 12 }, /* INT_24XX_SDMA_IRQ0 */
+ { .name = 1, .irq = 13 }, /* INT_24XX_SDMA_IRQ1 */
+ { .name = 2, .irq = 14 }, /* INT_24XX_SDMA_IRQ2 */
+ { .name = 3, .irq = 15 }, /* INT_24XX_SDMA_IRQ3 */
+};
+
+static struct omap_hwmod_addr_space omap2420_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
+ .master = omap2420_dma_system_hwmod,
+ .slave = omap2420_l3_main_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_masters[] = {
+ omap2420_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dma_system = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap2420_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_slaves[] = {
+ omap2420_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2420_dma_system_hwmod = {
+ .name = dma,
+ .class = omap2420_dma_hwmod_class,
+ .mpu_irqs = omap2420_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .slaves = omap2420_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_dma_system_slaves),
+ .masters= omap2420_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
@@ -797,6 +881,9 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_gpio2_hwmod,
omap2420_gpio3_hwmod,
omap2420_gpio4_hwmod,
+
+ /* dma_system class*/
+ omap2420_dma_system_hwmod,
NULL,
};
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 2378399..c466566 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -295,6 +295,13 @@
#define DMA_ERRATA_3_3 BIT(0x5)
[PATCH v1 4/9] OMAP2430: hwmod data: add system DMA
Add OMAP2430 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 87
arch/arm/plat-omap/include/plat/dma.h |1 +
2 files changed, 88 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index f68409e..2aab908 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -43,6 +43,7 @@ static struct omap_hwmod omap2430_gpio2_hwmod;
static struct omap_hwmod omap2430_gpio3_hwmod;
static struct omap_hwmod omap2430_gpio4_hwmod;
static struct omap_hwmod omap2430_gpio5_hwmod;
+static struct omap_hwmod omap2430_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -840,6 +841,89 @@ static struct omap_hwmod omap2430_gpio5_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/* dma_system */
+static struct omap_hwmod_class_sysconfig omap2430_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap2430_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+ .lch_count = 32,
+};
+
+static struct omap_hwmod_irq_info omap2430_dma_system_irqs[] = {
+ { .name = 0, .irq = 12 }, /* INT_24XX_SDMA_IRQ0 */
+ { .name = 1, .irq = 13 }, /* INT_24XX_SDMA_IRQ1 */
+ { .name = 2, .irq = 14 }, /* INT_24XX_SDMA_IRQ2 */
+ { .name = 3, .irq = 15 }, /* INT_24XX_SDMA_IRQ3 */
+};
+
+static struct omap_hwmod_addr_space omap2430_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
+ .master = omap2430_dma_system_hwmod,
+ .slave = omap2430_l3_main_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_masters[] = {
+ omap2430_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dma_system = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap2430_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_slaves[] = {
+ omap2430_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2430_dma_system_hwmod = {
+ .name = dma,
+ .class = omap2430_dma_hwmod_class,
+ .mpu_irqs = omap2430_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .slaves = omap2430_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_dma_system_slaves),
+ .masters= omap2430_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap2430_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_l3_main_hwmod,
omap2430_l4_core_hwmod,
@@ -859,6 +943,9 @@ static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_gpio3_hwmod,
omap2430_gpio4_hwmod,
omap2430_gpio5_hwmod,
+
+ /* dma_system class*/
+ omap2430_dma_system_hwmod,
NULL,
};
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index c466566..4b51d2b 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -301,6 +301,7 @@
#define RESERVE_CHANNEL
[PATCH v1 5/9] OMAP3: hwmod data: add system DMA
Add OMAP3 DMA hwmod data
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 97
1 files changed, 97 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 2687be1..d5acb63 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -52,6 +52,8 @@ static struct omap_hwmod omap3xxx_gpio4_hwmod;
static struct omap_hwmod omap3xxx_gpio5_hwmod;
static struct omap_hwmod omap3xxx_gpio6_hwmod;
+static struct omap_hwmod omap3xxx_dma_system_hwmod;
+
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
.master = omap3xxx_l3_main_hwmod,
@@ -1090,6 +1092,98 @@ static struct omap_hwmod omap3xxx_gpio6_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap3xxx_dma_system__l3 = {
+ .master = omap3xxx_dma_system_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+ .lch_count = 32,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap3xxx_dma_sysc,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap3xxx_dma_system_irqs[] = {
+ { .name = 0, .irq = 12 }, /* INT_24XX_SDMA_IRQ0 */
+ { .name = 1, .irq = 13 }, /* INT_24XX_SDMA_IRQ1 */
+ { .name = 2, .irq = 14 }, /* INT_24XX_SDMA_IRQ2 */
+ { .name = 3, .irq = 15 }, /* INT_24XX_SDMA_IRQ3 */
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_masters[] = {
+ omap3xxx_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dma_system = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_dma_system_hwmod,
+ .clk= core_l4_ick,
+ .addr = omap3xxx_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_slaves[] = {
+ omap3xxx_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap3xxx_dma_system_hwmod = {
+ .name = dma,
+ .class = omap3xxx_dma_hwmod_class,
+ .mpu_irqs = omap3xxx_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_dma_system_irqs),
+ .main_clk = core_l3_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs= CORE_MOD,
+ .prcm_reg_id= 1,
+ .module_bit = OMAP3430_ST_SDMA_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit= OMAP3430_ST_SDMA_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_dma_system_slaves),
+ .masters= omap3xxx_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@ -1113,6 +1207,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_gpio4_hwmod,
omap3xxx_gpio5_hwmod,
omap3xxx_gpio6_hwmod,
+
+ /* dma_system class*/
+ omap3xxx_dma_system_hwmod,
[PATCH v1 6/9] OMAP4: hwmod data: add system DMA
From: Benoit Cousson b-cous...@ti.com
Add OMAP4 DMA hwmod data
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 101
1 files changed, 101 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index d258936..50c00d6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -23,6 +23,7 @@
#include plat/omap_hwmod.h
#include plat/cpu.h
#include plat/gpio.h
+#include plat/dma.h
#include omap_hwmod_common_data.h
@@ -36,6 +37,7 @@
#define OMAP44XX_DMA_REQ_START 1
/* Backward references (IPs with Bus Master capability) */
+static struct omap_hwmod omap44xx_dma_system_hwmod;
static struct omap_hwmod omap44xx_dmm_hwmod;
static struct omap_hwmod omap44xx_emif_fw_hwmod;
static struct omap_hwmod omap44xx_l3_instr_hwmod;
@@ -216,6 +218,14 @@ static struct omap_hwmod_ocp_if
omap44xx_l3_main_1__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* dma_system - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
+ .master = omap44xx_dma_system_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_cfg - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = {
.master = omap44xx_l4_cfg_hwmod,
@@ -227,6 +237,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2
= {
/* l3_main_2 slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
omap44xx_l3_main_1__l3_main_2,
+ omap44xx_dma_system__l3_main_2,
omap44xx_l4_cfg__l3_main_2,
};
@@ -1376,6 +1387,93 @@ static struct omap_hwmod omap44xx_gpio6_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_gpio6_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+
+/*
+ * 'dma' class
+ * dma controller for data exchange between memory to memory (i.e. internal or
+ * external memory) and gp peripherals to memory or memory to gp peripherals
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap44xx_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+ .lch_count = 32,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
+ { .name = 0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
+ { .name = 1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
+ { .name = 2, .irq = 14 + OMAP44XX_IRQ_GIC_START },
+ { .name = 3, .irq = 15 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dma_system_addrs[] = {
+ {
+ .pa_start = 0x4a056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_masters[] = {
+ omap44xx_dma_system__l3_main_2,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__dma_system = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_slaves[] = {
+ omap44xx_l4_cfg__dma_system,
+};
+
+static struct omap_hwmod omap44xx_dma_system_hwmod = {
+ .name = dma_system,
+ .class = omap44xx_dma_hwmod_class,
+ .mpu_irqs = omap44xx_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_SDMA_SDMA_CLKCTRL,
+ },
+
[PATCH v1 7/9] OMAP1: DMA: Implement in platform device model
Implement OMAP1 DMA as platform device and add support for
registering through platform device layer using resource
structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/dma.c | 179 +
1 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/dma.c
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
new file mode 100644
index 000..b56ee21
--- /dev/null
+++ b/arch/arm/mach-omap1/dma.c
@@ -0,0 +1,179 @@
+/*
+ * OMAP1/OMAP7xx - specific DMA driver
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah manj...@ti.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.
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+
+#include plat/dma.h
+#include plat/tc.h
+#include plat/irqs.h
+
+#define OMAP1_DMA_BASE (0xfffed800)
+
+static struct resource res[] __initdata = {
+ [0] = {
+ .start = OMAP1_DMA_BASE,
+ .end= OMAP1_DMA_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .name = 0,
+ .start = INT_DMA_CH0_6,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .name = 1,
+ .start = INT_DMA_CH1_7,
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ .name = 2,
+ .start = INT_DMA_CH2_8,
+ .flags = IORESOURCE_IRQ,
+ },
+ [4] = {
+ .name = 3,
+ .start = INT_DMA_CH3,
+ .flags = IORESOURCE_IRQ,
+ },
+ [5] = {
+ .name = 4,
+ .start = INT_DMA_CH4,
+ .flags = IORESOURCE_IRQ,
+ },
+ [6] = {
+ .name = 5,
+ .start = INT_DMA_CH5,
+ .flags = IORESOURCE_IRQ,
+ },
+ [7] = {
+ .name = 6,
+ .start = INT_DMA_LCD,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* irq's for omap16xx and omap7xx */
+ [8] = {
+ .name = 7,
+ .start = 53 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [9] = {
+ .name = 8,
+ .start = 54 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [10] = {
+ .name = 9,
+ .start = 55 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [11] = {
+ .name = 10,
+ .start = 56 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [12] = {
+ .name = 11,
+ .start = 57 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [13] = {
+ .name = 12,
+ .start = 58 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [14] = {
+ .name = 13,
+ .start = 59 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [15] = {
+ .name = 14,
+ .start = 60 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [16] = {
+ .name = 15,
+ .start = 61 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [17] = {
+ .name = 16,
+ .start = 62 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static int __init omap1_system_dma_init(void)
+{
+ struct omap_system_dma_plat_info*p;
+ struct platform_device *pdev;
+ int ret;
+
+ pdev = platform_device_alloc(omap_dma_system, 0);
+ if (!pdev) {
+ pr_err(%s: Unable to device alloc for dma\n,
+ __func__);
+ return -ENOMEM;
+ }
+
+ ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
+ if (ret) {
+ dev_err(pdev-dev, %s: Unable to add resources for %s%d\n,
+ __func__, pdev-name, pdev-id);
+
[PATCH v1 8/9] OMAP2+: DMA: hwmod: Device registration
Prepare OMAP2+ DMA to use hwmod infrastructure so that DMA can register
as platform device.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/dma.c | 74 +
1 files changed, 74 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/dma.c
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
new file mode 100644
index 000..e2c897a
--- /dev/null
+++ b/arch/arm/mach-omap2/dma.c
@@ -0,0 +1,74 @@
+/*
+ * OMAP2+ DMA driver
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah manj...@ti.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.
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/dma.h
+
+static struct omap_device_pm_latency omap2_dma_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+/* One time initializations */
+static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void
*unused)
+{
+ struct omap_device *od;
+ struct omap_system_dma_plat_info*p;
+ char*name = omap_dma_system;
+
+ p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
+ if (!p) {
+ pr_err(%s: Unable to allocate pdata for %s:%s\n,
+ __func__, name, oh-name);
+ return -ENOMEM;
+ }
+
+ od = omap_device_build(name, 0, oh, p, sizeof(*p),
+ omap2_dma_latency, ARRAY_SIZE(omap2_dma_latency), 0);
+ kfree(p);
+ if (IS_ERR(od)) {
+ pr_err(%s: Cant build omap_device for %s:%s.\n,
+ __func__, name, oh-name);
+ return IS_ERR(od);
+ }
+
+ return 0;
+}
+
+static int __init omap2_system_dma_init(void)
+{
+ return (omap_hwmod_for_each_by_class(dma,
+ omap2_system_dma_init_dev, NULL));
+}
+arch_initcall(omap2_system_dma_init);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Patches to make multi-soc handling in entry-armv.S easier
On Fri, 3 Dec 2010, Tony Lindgren wrote: Hi all, I've got some patches almost ready to go to merge the omap1 configs into a single omap1_defconfig. While working on getting that done, I had to come up with a better solution for entry-armv.S macros to detect the soc we're running on. I suggest we add asm_irq_base and asm_irq_flags as in the first patch in this series does. This way we can do the soc based detection in init_irq or similar place. This might help also the multi-arm work too. Did you see Eric Miao's patch series that introduces runtime IRQ demux handler support? http://www.spinics.net/linux/lists/arm-kernel/msg92836.html That is likely to be a better solution. Nicolas -- 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
