Re: [PATCH 1/1] omap: Ptr "isr_reg" tracked as NULL was dereferenced
On Tue, 2010-10-05 at 08:01 -0700, ext Kevin Hilman wrote:
> Felipe Balbi writes:
>
> > Hi,
> >
> > On Tue, Oct 05, 2010 at 03:42:10AM -0500, Evgeny Kuznetsov wrote:
> >>+ if (!isr_reg) {
> >>+ printk(KERN_ERR "FATAL: Incorrect GPIO method %i\n",
> >>+ bank->method);
> >>+ BUG();
> >>+ }
> >
> > this could be simply:
> >
> > BUG_ON(!isr_reg);
>
> WARN_ON is better.
>
> A BUG() will panic the kernel and stop everything. This is not an error
> condition that should prevent the entire kernel from running.
'isr_reg' is dereferenced later in code:
...
isr_saved = isr = __raw_readl(isr_reg) & enabled;
...
So this will stop kernel anyway.
I just hoped to help in understanding of issue by log line. WARN_ON
could be used for this.
As a variant compilation error could be added, to prevent situation when
kernel is incorrectly configured.
E.g.:
#if !defined(CONFIG_ARCH_OMAP1) &&
!defined(CONFIG_ARCH_OMAP15XX) &&
!defined(CONFIG_ARCH_OMAP16XX) &&
!defined(CONFIG_ARCH_OMAP730) &&
!defined(CONFIG_ARCH_OMAP850) &&
!defined(CONFIG_ARCH_OMAP2) &&
!defined(CONFIG_ARCH_OMAP3) &&
!defined(CONFIG_ARCH_OMAP4)
#error "Incorrect arch configuration"
#endif
But there are still cases when 'isr_reg' could have NULL value (if
'bank->method' is not equal to configured one).
Regards,
Evgeny
>
> From asm-generic/bug.h:
>
> /*
> * Don't use BUG() or BUG_ON() unless there's really no way out; one
> * example might be detecting data structure corruption in the middle
> * of an operation that can't be backed out of. If the (sub)system
> * can somehow continue operating, perhaps with reduced functionality,
> * it's probably not BUG-worthy.
> *
> * If you're tempted to BUG(), think again: is completely giving up
> * really the *only* solution? There are usually better options, where
> * users don't need to reboot ASAP and can mostly shut down cleanly.
> */
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
Steve Sakoman wrote: On Mon, Oct 4, 2010 at 10:33 AM, Madhusudhan wrote: -Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Monday, October 04, 2010 11:57 AM To: Madhusudhan Cc: Mike Rapoport; David Vrabel; Chris Ball; linux-...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) On Mon, Oct 4, 2010 at 9:45 AM, Madhusudhan wrote: -Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Monday, October 04, 2010 11:32 AM To: Mike Rapoport Cc: David Vrabel; Chris Ball; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; madhu...@ti.com Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) On Wed, Sep 1, 2010 at 11:02 PM, Mike Rapoport wrote: David Vrabel wrote: On 27/08/2010 20:22, Chris Ball wrote: Hi David, On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. Changes since v1: - (hopefully) get all cards working again by removing a second call to read MMCi_STAT in the interrupt handler. - flush posted writes after enabling/disabling SDIO interrupts. - tweak the FIXME commit on disabling FCLK to better match what really going on (at least I think so anyway). David Vrabel (2): mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts Looks like this patchset wasn't merged. Mike Rapoport replied with a fix for libertas. Would you like to resubmit it? I thought Madhu had picked this up and was going to submit it. Regardless of whether that is the case, I think it needs to be submitted by someone who can run mainline kernels (I can't) and ideally someone who can test it with SDIO cards. I'll try to update the patches in the next few days. Any update on the status of these patches? I'm happy to help test! Steve, I have not been able to test SDIO card interrupts. If you could help test that it's great. Where can I grab the most recent patches? The original set don't apply cleanly. Yes. They may not apply. I can rebase them and send it to you for testing. Are you using the two patches posted by David Vrabel? Yes, I've been using the original patches on 2.6.33 and 2.6.34. The SDIO interrupt patch doesn't apply on 2.6.35 or 36. If you send a revised patch for either I would be happy to test as soon as I get it. I've tried to update the patches on top of 2.6.36-rc3 and I've got stuck. The changes Adrian has made to the interrupt synchronization affect the way the SDIO irq should be implemented and I haven't found a way to resolve it :-( Steve -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe 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 4/7] [RFC] OMAP: hwmod implementation for MCBSP
> -Original Message- > From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] > Sent: Wednesday, October 06, 2010 11:32 AM > To: ABRAHAM, KISHON VIJAY > Cc: linux-omap@vger.kernel.org; Kamat, Nishant; Varadarajan, > Charulatha; Datta, Shubhrajyoti; Basak, Partha > Subject: Re: [PATCH 4/7] [RFC] OMAP: hwmod implementation for MCBSP > > On Tuesday 05 October 2010 19:37:39 ext Kishon Vijay Abraham I wrote: > > Signed-off-by: Kishon Vijay Abraham I > > Signed-off-by: Charulatha V > > Signed-off-by: Shubhrajyoti D > > Cc: Partha Basak > > --- > > arch/arm/mach-omap2/mcbsp.c | 251 > > +-- > arch/arm/plat-omap/include/plat/mcbsp.h | > > 6 +- > > arch/arm/plat-omap/mcbsp.c | 189 > +++- > > 3 files changed, 159 insertions(+), 287 deletions(-) > > So the plan is to kill OMAP1 support in McBSP (audio)? > We do have OMAP1 users, so IMHO dropping OMAP1 is not acceptable. This patch series would not break OMAP1 as they do not touch the omap_mcbsp_register_board_cfg() in mach-omap1. Usage of hwmod is applicable only for OMAP2plus cpus and it modifies the way in which the platform device is built & registered. It makes use of centralised database to fetch the addresses, irq, dma info etc., for OMAP2plus. OMAP1 cpus will still continue to have the old way of doing platform device registeration. pm_runtime APIs are already inplace to take care of enabling clocks in case of OMAP1. Hope this clarifies. > > -- > Péter > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] [RFC] OMAP: hwmod implementation for MCBSP
On Tuesday 05 October 2010 19:37:39 ext Kishon Vijay Abraham I wrote: > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Charulatha V > Signed-off-by: Shubhrajyoti D > Cc: Partha Basak > --- > arch/arm/mach-omap2/mcbsp.c | 251 > +-- arch/arm/plat-omap/include/plat/mcbsp.h | > 6 +- > arch/arm/plat-omap/mcbsp.c | 189 +++- > 3 files changed, 159 insertions(+), 287 deletions(-) So the plan is to kill OMAP1 support in McBSP (audio)? We do have OMAP1 users, so IMHO dropping OMAP1 is not acceptable. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/3] OMAP: McBSP: Fixes and cleanups after SCM conversion
On Wednesday 06 October 2010 08:50:39 ext Jarkko Nikula wrote: > This set does a few fixes and cleanups to the Paul Walmsley's OMAP System > Control Module function exports removal set: > > http://marc.info/?l=linux-arm-kernel&m=128597757826159&w=2 > > v2: > - Paul's ack added > - lakml cc'ed For all: Acked-by: Peter Ujfalusi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/3] OMAP: McBSP: Swap CLKS source definition
This is just a readability and debugging improvement. As selection bit in
DEVCONF register is cleared when using 96 MHz PRCM source and set when using
external CLKS pin, change definitions to be sync with these.
Signed-off-by: Jarkko Nikula
Acked-by: Paul Walmsley
---
arch/arm/plat-omap/include/plat/mcbsp.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 4da6f94..e19abf2 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -321,8 +321,8 @@
#define FSR_SRC_FSX1
/* McBSP functional clock sources */
-#define MCBSP_CLKS_PAD_SRC 0
-#define MCBSP_CLKS_PRCM_SRC1
+#define MCBSP_CLKS_PRCM_SRC0
+#define MCBSP_CLKS_PAD_SRC 1
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
--
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
[PATCHv2 3/3] OMAP: McBSP: Remove null omap44xx ops comment
It seems these comments where accidentally added so remove them.
Signed-off-by: Jarkko Nikula
Acked-by: Paul Walmsley
---
arch/arm/mach-omap2/mcbsp.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index f6b772e..f9c9df5 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -240,21 +240,18 @@ static struct omap_mcbsp_platform_data
omap44xx_mcbsp_pdata[] = {
.dma_rx_sync= OMAP44XX_DMA_MCBSP2_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP2_TX,
.tx_irq = OMAP44XX_IRQ_MCBSP2,
- /* XXX .ops ? */
},
{
.phys_base = OMAP44XX_MCBSP3_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP3_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP3_TX,
.tx_irq = OMAP44XX_IRQ_MCBSP3,
- /* XXX .ops ? */
},
{
.phys_base = OMAP44XX_MCBSP4_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP4_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP4_TX,
.tx_irq = OMAP44XX_IRQ_MCBSP4,
- /* XXX .ops ? */
},
};
#define OMAP44XX_MCBSP_PDATA_SZARRAY_SIZE(omap44xx_mcbsp_pdata)
--
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
[PATCHv2 0/3] OMAP: McBSP: Fixes and cleanups after SCM conversion
This set does a few fixes and cleanups to the Paul Walmsley's OMAP System Control Module function exports removal set: http://marc.info/?l=linux-arm-kernel&m=128597757826159&w=2 v2: - Paul's ack added - lakml cc'ed -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/3] OMAP: McBSP: Fix CLKR and FSR signal muxing
Fix bit clear. Now it clears all other bits than mask bit where it should clear only it. Signed-off-by: Jarkko Nikula Acked-by: Paul Walmsley --- arch/arm/mach-omap2/mcbsp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c index eba9fa1..f6b772e 100644 --- a/arch/arm/mach-omap2/mcbsp.c +++ b/arch/arm/mach-omap2/mcbsp.c @@ -34,7 +34,7 @@ void omap2_mcbsp1_mux_clkr_src(u8 mux) v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0); if (mux == CLKR_SRC_CLKR) - v &= OMAP2_MCBSP1_CLKR_MASK; + v &= ~OMAP2_MCBSP1_CLKR_MASK; else if (mux == CLKR_SRC_CLKX) v |= OMAP2_MCBSP1_CLKR_MASK; omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0); @@ -47,7 +47,7 @@ void omap2_mcbsp1_mux_fsr_src(u8 mux) v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0); if (mux == FSR_SRC_FSR) - v &= OMAP2_MCBSP1_FSR_MASK; + v &= ~OMAP2_MCBSP1_FSR_MASK; else if (mux == FSR_SRC_FSX) v |= OMAP2_MCBSP1_FSR_MASK; omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0); -- 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 2/3] OMAP: McBSP: Swap CLKS source definition
On Tuesday 05 October 2010 15:29:34 ext Jarkko Nikula wrote: > This is just a readability and debugging improvement. As selection bit in > DEVCONF register is cleared when using 96 MHz PRCM source and set when > using external CLKS pin, change definitions to be sync with these. > > Signed-off-by: Jarkko Nikula > Cc: Paul Walmsley Acked-by: Peter Ujfalusi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAP: McBSP: Remove null omap44xx ops comment
On Tuesday 05 October 2010 15:29:35 ext Jarkko Nikula wrote: > It seems these comments where accidentally added so remove them. > > Signed-off-by: Jarkko Nikula > Cc: Paul Walmsley Acked-by: Peter Ujfalusi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP: McBSP: Fix CLKR and FSR signal muxing
On Tuesday 05 October 2010 15:29:33 ext Jarkko Nikula wrote: > Fix bit clear. Now it clears all other bits than mask bit where it should > clear only it. > > Signed-off-by: Jarkko Nikula > Cc: Paul Walmsley Acked-by: Peter Ujfalusi -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP: SCM/McBSP/clock: branch integration patches for 2.6.37
On Tuesday 05 October 2010 21:40:17 ext Tony Lindgren wrote: ... > > For patches 6-7 you could have my ack. > > Acked-by: Jarkko Nikula > > > > As they are touching also sound/soc/omap/omap-mcbsp.c, an ack from Mark > > and Liam are needed. Links to patches 6 and 7 below and my fixes on top > > of them [1]. > > > > http://marc.info/?l=linux-omap&m=128596931117788&w=2 > > http://marc.info/?l=linux-omap&m=128596931417805&w=2 > > Sorry, I've already merged them as they fixed code that did not compile. > > Let me know if you guys want me to rebuild those parts of omap-for-linus > to add the acks. If you decide to rebuild, than you can add my (for patch 6-7): Acked-by: Peter Ujfalusi -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] ARM: l2x0: Optimise the range based operations
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Tuesday, October 05, 2010 10:25 AM
> To: Russell King - ARM Linux
> Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com;
> t...@linutronix.de; linux-omap@vger.kernel.org
> Subject: RE: [PATCH 6/6] ARM: l2x0: Optimise the range based operations
>
[]
> > mmcblk0: error -5 transferring data, sector 1, nr 7, card status 0x900
> > end_request: I/O error, dev mmcblk0, sector 1
> > Buffer I/O error on device mmcblk0, logical block 0
> > port 1 high speed
> >
> > -5 is -EIO, which is a FIFO overrun error, so somehow these changes are
> > causing the CPU or bus accesses to be slower.
> I don't see the problem on OMAP MMC.
> May be some how additional check is making these operations
> touch slower which lead to the under run.
>
> Will have a look at it again. May for this merge window you can
> drop 'Optimise the range based operations' and 'Determine cache size'
> patches.
>
The Pl310 cache way size given in KB and 'Determine cache size' missed
to include that. Have updated the git tree with refreshed patch. Here is
the updated patch..
--
>From 8b351fbc4da738a0727854cb88933c4051657384 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Sun, 11 Jul 2010 14:35:37 +0530
Subject: [PATCH 6/8 v2] ARM: l2x0: Determine the cache size
The cache size is needed for to optimise range based
maintainance operations
Signed-off-by: Santosh Shilimkar
Acked-by: Catalin Marinas
Acked-by: Linus Walleij
---
arch/arm/include/asm/hardware/cache-l2x0.h |1 +
arch/arm/mm/cache-l2x0.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h
b/arch/arm/include/asm/hardware/cache-l2x0.h
index d833355..4633d2a 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -55,6 +55,7 @@
#define L2X0_CACHE_ID_PART_MASK(0xf << 6)
#define L2X0_CACHE_ID_PART_L210(1 << 6)
#define L2X0_CACHE_ID_PART_L310(3 << 6)
+#define L2X0_AUX_CTRL_WAY_SIZE_MASK(0x3 << 17)
#ifndef __ASSEMBLY__
extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32
aux_mask);
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 9310d61..262c752 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -28,6 +28,7 @@
static void __iomem *l2x0_base;
static DEFINE_SPINLOCK(l2x0_lock);
static uint32_t l2x0_way_mask; /* Bitmask of active ways */
+static uint32_t l2x0_size;
static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
{
@@ -242,6 +243,7 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val,
__u32 aux_mask)
{
__u32 aux;
__u32 cache_id;
+ __u32 way_size = 0;
int ways;
const char *type;
@@ -276,6 +278,13 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val,
__u32 aux_mask)
l2x0_way_mask = (1 << ways) - 1;
/*
+* L2 cache Size = Way size * Number of ways
+*/
+ way_size = (aux & L2X0_AUX_CTRL_WAY_SIZE_MASK) >> 17;
+ way_size = 1 << (way_size + 3);
+ l2x0_size = ways * way_size * SZ_1K;
+
+ /*
* Check if l2x0 controller is already enabled.
* If you are booting from non-secure mode
* accessing the below registers will fault.
@@ -300,6 +309,6 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val,
__u32 aux_mask)
outer_cache.disable = l2x0_disable;
printk(KERN_INFO "%s cache controller enabled\n", type);
- printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x\n",
-ways, cache_id, aux);
+ printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x,
Cache size: %d B\n",
+ ways, cache_id, aux, l2x0_size);
}
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: multiple linux-next OMAP3 build errors
On 10/04/2010 03:43 PM, Yinghai Lu wrote:
> On 10/04/2010 03:30 PM, Benjamin Herrenschmidt wrote:
>> On Mon, 2010-10-04 at 09:29 +0300, Tomi Valkeinen wrote:
CC drivers/video/omap2/vram.o
drivers/video/omap2/vram.c: In function
>>> 'omap_vram_reserve_sdram_memblock':
drivers/video/omap2/vram.c:568: error: implicit declaration of
function 'memblock_region_is_memory'
>>>
>>> Benjamin, your patch "memblock/arm: Use memblock_region_is_memory()
>>> for
>>> omap fb" in linux-next seems to be broken. I believe the called
>>> function
>>> should be memblock_is_region_memory, not memblock_region_is_memory?
>>
>> I suspect either I didn't push my latest version before it got merged or
>> Yinghai didn't pull the right one, since I'm pretty sure I test built
>> it, but in any case, you're probably right :-)
>>
>> I'm not in control of this patch series at the moment however. Ingo and
>> Yinghai are. Yinghai, care to fix that up ? I'm currently travelling on
>> holidays and won't be able to do much until later next week.
>
Please check delta patch for core/memblock.
Yinghai
[PATCH] memblock/arm: Fix typo with memblock_region_is_memory()
Fix typo in
| commit dbe3039e64b1dd4cf26f782d45b524f85b444ad4
| [PATCH -v2] memblock/arm: Use memblock_region_is_memory() for omap fb
should be memblock_is_region_memory().
Reported-by: Tomi Valkeinen
Signed-off-by: Yinghai Lu
---
arch/arm/plat-omap/fb.c|2 +-
drivers/video/omap2/vram.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/arm/plat-omap/fb.c
===
--- linux-2.6.orig/arch/arm/plat-omap/fb.c
+++ linux-2.6/arch/arm/plat-omap/fb.c
@@ -173,7 +173,7 @@ static int check_fbmem_region(int region
static int valid_sdram(unsigned long addr, unsigned long size)
{
- return memblock_region_is_memory(addr, size);
+ return memblock_is_region_memory(addr, size);
}
static int reserve_sdram(unsigned long addr, unsigned long size)
Index: linux-2.6/drivers/video/omap2/vram.c
===
--- linux-2.6.orig/drivers/video/omap2/vram.c
+++ linux-2.6/drivers/video/omap2/vram.c
@@ -555,7 +555,7 @@ void __init omap_vram_reserve_sdram_memb
if (paddr) {
if ((paddr & ~PAGE_MASK) ||
- !memblock_region_is_memory(paddr, size)) {
+ !memblock_is_region_memory(paddr, size)) {
pr_err("Illegal SDRAM region for VRAM\n");
return;
}
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv2 1/7] pwm: Add pwm core driver
> On Tue, 5 Oct 2010 17:29:56 +0530
> Arun Murthy wrote:
>
> > The existing pwm based led and backlight driver makes use of the
> > pwm(include/linux/pwm.h). So all the board specific pwm drivers will
> > be exposing the same set of function name as in include/linux/pwm.h.
> > Consder a platform with multi Soc or having more than one pwm module,
> in
> > such a case, there exists more than one pwm driver for a platform.
> Each
> > of these pwm drivers export the same set of function and hence leads
> to
> > re-declaration build error.
> >
> > In order to overcome this issue all the pwm drivers must register to
> > some core pwm driver with function pointers for pwm operations (i.e
> > pwm_config, pwm_enable, pwm_disable).
> >
> > The clients of pwm device will have to call pwm_request, wherein
> > they will get the pointer to struct pwm_ops. This structure include
> > function pointers for pwm_config, pwm_enable and pwm_disable.
> >
>
> Have we worked out who will be merging this work, if it gets merged?
I request Samuel to merge this through MFD tree.
>
> >
> > ...
> >
> > +struct pwm_dev_info {
> > + struct pwm_device *pwm_dev;
> > + struct list_head list;
> > +};
> > +static struct pwm_dev_info *di;
>
> We could just do
>
> static struct pwm_dev_info {
> ...
> } *di;
>
> > +DECLARE_RWSEM(pwm_list_lock);
>
> This can/should be static.
>
> > +void __deprecated pwm_free(struct pwm_device *pwm)
> > +{
> > +}
>
> Why are we adding a new function and already deprecating it?
>
> Probably this was already addressed in earlier review, but I'm asking
> again, because there's no comment explaining the reasons. Lesson
> learned, please add a comment.
>
> Oh, I see that pwm_free() already exists. This patch adds a new copy
> and doesn't remove the old function. Does this all actually work?
>
> It still needs a comment explaining why it's deprecated.
The existing pwm drivers make use of this function and now I am in the process
of developing a new pwm core driver and align the existing pwm drivers with
this core driver. I was able to align all the existing pwm drivers except the
jz4740 pwm driver in mips. So in order to retain the support for this mips, I
have deprecated this function. This will be removed once jz4740 pwm driver is
aligned with pwm core driver.
Will add the same comments in code.
> > + struct pwm_dev_info *pwm;
> > +
> > + down_write(&pwm_list_lock);
> > + pwm = kzalloc(sizeof(struct pwm_dev_info), GFP_KERNEL);
> > + if (!pwm) {
> > + up_write(&pwm_list_lock);
> > + return -ENOMEM;
> > + }
>
> The allocation attempt can be moved outside the lock, making the code
> faster, cleaner and shorter.
Will correct this in v3 patch.
> > + up_write(&pwm_list_lock);
> > + return -ENOENT;
> > +}
> > +EXPORT_SYMBOL(pwm_device_unregister);
> > +
> > +struct pwm_device *pwm_request(int pwm_id, const char *name)
> > +{
> > + struct pwm_dev_info *pwm;
> > + struct list_head *pos;
> > +
> > + down_read(&pwm_list_lock);
> > + list_for_each(pos, &di->list) {
> > + pwm = list_entry(pos, struct pwm_dev_info, list);
> > + if ((!strcmp(pwm->pwm_dev->pops->name, name)) &&
> > + (pwm->pwm_dev->pwm_id == pwm_id)) {
> > + up_read(&pwm_list_lock);
> > + return pwm->pwm_dev;
> > + }
> > + }
> > + up_read(&pwm_list_lock);
> > + return ERR_PTR(-ENOENT);
> > +}
> > +EXPORT_SYMBOL(pwm_request);
>
> We have a new kernel-wide exported-to-modules formal API. We prefer
> that such things be fully documented, please. kerneldoc is a suitable
> way but please avoid falling into the kerneldoc trap of filling out
> fields with obvious boilerplate and not actually telling people
> anything interesting or useful.
Sure, Will document this as part of v3 patch.
>
> > +static int __init pwm_init(void)
> > +{
> > + struct pwm_dev_info *pwm;
> > +
> > + pwm = kzalloc(sizeof(struct pwm_dev_info), GFP_KERNEL);
> > + if (!pwm)
> > + return -ENOMEM;
> > + INIT_LIST_HEAD(&pwm->list);
> > + di = pwm;
> > + return 0;
> > +}
>
> OK, this looks wrong.
>
> AFACIT you've created a dummy pwm_dev_info as a singleton, kernel-wide
> anchor for a list of all pwm_dev_info's. So this "anchor" pwm_dev_info
> never actually gets used for anything.
>
> The way to do this is to remove `di' altogether and instead use a
> singleton, kernel-wide list_head as the anchor for all the
> dynamically-allocated pwm_dev_info's.
OK, will implement this in v3 patch.
>
> > +subsys_initcall(pwm_init);
> > +
> > +static void __exit pwm_exit(void)
> > +{
> > + kfree(di);
> > +}
> > +
> > +module_exit(pwm_exit);
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_AUTHOR("Arun R Murthy");
> > +MODULE_ALIAS("core:pwm");
> > +MODULE_DESCRIPTION("Core pwm driver");
> > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> > index 7c77575..6e7da1f 100644
> > --- a/include/li
RE: [PATCHv2 0/7] PWM core driver for pwm based led and backlight driver
> Arun Murthy writes: > > > PWM core driver for pwm based led and backlight driver. > > The intention of the pwm core driver is not to break the build if two > or more > > pwm drivers are enabled. > > Align the existing pwm drivers to make use of the pwm core driver > > Hi Arun, > > Because you have Bill Gatliff on Cc, I'm guessing you've already looked > at his RFC for a generic PWM framework? > > There's recently been a proposal on DaVinci that is similar to yours > that enables multiple PWM drivers, but it would be nice to have a > common > framework for this, and what Bill has proposed seems to be a good > solution. > Thanks for the information. This patch set of implementing pwm core driver is aligned with the one in Davinci. Davinci pwm devices can make use of this core driver framework. Thanks and Regards, Arun R Murthy - -- To unsubscribe from this list: send the line "unsubscribe 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: linux-next: manual merge of the staging-next tree with the omap tree
On Wed, Oct 06, 2010 at 02:21:10PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging-next tree got a conflict in
> arch/arm/plat-omap/devices.c between commit
> f2ce62312650211f6cf665cd6dc519c334c4071e ("OMAP: WDT: Split OMAP1 and
> OMAP2PLUS device registration") from the omap tree and commit
> 90173882ed15a8034d6d162da5f343a2c7d87587 ("omap: add dsp platform
> device") from the staging-next tree.
>
> Just overlapping removal/additions (I think). I fixed it up (see below)
> and can carry the changes as necessary.
Your fixup looks correct to me, thanks for carrying it.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: manual merge of the staging-next tree with the omap tree
Hi Greg,
Today's linux-next merge of the staging-next tree got a conflict in
arch/arm/plat-omap/devices.c between commit
f2ce62312650211f6cf665cd6dc519c334c4071e ("OMAP: WDT: Split OMAP1 and
OMAP2PLUS device registration") from the omap tree and commit
90173882ed15a8034d6d162da5f343a2c7d87587 ("omap: add dsp platform
device") from the staging-next tree.
Just overlapping removal/additions (I think). I fixed it up (see below)
and can carry the changes as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/plat-omap/devices.c
index 1e2383e,4c8f9b9..000
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@@ -231,6 -233,75 +232,35 @@@ static void omap_init_uwire(void
static inline void omap_init_uwire(void) {}
#endif
-/*-*/
-
-#if defined(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;
+
+ void __init omap_dsp_reserve_sdram_memblock(void)
+ {
+ phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
+ phys_addr_t paddr;
+
+ if (!size)
+ return;
+
+ paddr = __memblock_alloc_base(size, SZ_1M, MEMBLOCK_REAL_LIMIT);
+ if (!paddr) {
+ pr_err("%s: failed to reserve %x bytes\n",
+ __func__, size);
+ return;
+ }
+
+ omap_dsp_phys_mempool_base = paddr;
+ }
+
+ phys_addr_t omap_dsp_get_mempool_base(void)
+ {
+ return omap_dsp_phys_mempool_base;
+ }
+ EXPORT_SYMBOL(omap_dsp_get_mempool_base);
+ #endif
+
/*
* This gets called after board-specific INIT_MACHINE, and initializes most
* on-chip peripherals accessible on this board (except for few like USB):
--
To unsubscribe from this list: send the line "unsubscribe 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 05/11] omap3: Remove non-existent config option
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Marathe, Yogesh > Sent: Friday, October 01, 2010 6:29 AM > To: Felipe Contreras > Cc: Kanigeri, Hari; Premi, Sanjeev; Tony Lindgren; > linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org > Subject: RE: [PATCH 05/11] omap3: Remove non-existent config option > > > -Original Message- > > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > > Sent: Thursday, September 30, 2010 12:42 AM > > To: Marathe, Yogesh > > Cc: Kanigeri, Hari; Premi, Sanjeev; Tony Lindgren; linux-arm- > > ker...@lists.infradead.org; linux-omap@vger.kernel.org > > Subject: Re: [PATCH 05/11] omap3: Remove non-existent config option > > > > On Wed, Sep 29, 2010 at 4:28 PM, Marathe, Yogesh > > wrote: > > > dsplink and syslink (two drivers who use iommu) should not enable > > > CONFIG_MPU_BRIDGE_IOMMU as dspbridge and dsplink /syslink can not > > > co-exist as they are using same resources. Not applying > > patch > > > breaks dsplink/sylink any one which is being used. Defining this > > config > > > makes them co-exist. > > > > No, for dsp-link you would have: > > CONFIG_TIDSPBRIDGE=n > > CONFIG_OMAP_IOMMU_IVA2=y > > > > It would be exactly the same as applying your patch. > > > > And tidspbridge is not using iommu right now. > > I noticed that you have added OMAP_IOMMU_IVA2 to Kconfig. In > this case I need CONFIG_OMAP_IOMMU_IVA2=y by default on > master so that iommu is open to use for all other drivers by default. > > > And AFAIK syslink is not for omap3, so omap3_devices is not > relevant. > > > > > I'm ok with changing name to CONFIG_OMAP_IOMMU_IVA2 but > > ideally > > > then that will also break the dspbridge. > > > > No, grep for MPU_BRIDGE_IOMMU on the current tidspbridge in > mainline; > > it's not defined anywhere, so CONFIG_OMAP_IOMMU_IVA2, or > > CONFIG_FOOBAR, it doesn't matter for tidspbridge right now. And > > MPU_BRIDGE_IOMMU doesn't depend on tidspbridge on any way. > > Please explain, how removing CONFIG_MPU_BRIDGE_IOMMU Or any > other the config name in place, breaks tidspbridge? > My patch is removing the 'if defined'. Can I know the status of this patch? This patch is needed now that tidspbridge has migrated to use Iommu moudle. Will this patch be merged? Regards, Fernando. > > > > > > One more way would be to soure revert the patch and apply on > > dspbridge branch if it breaks the builds on that branch rather than > > > breaking others in master. > > > > There is no tidspbrige branch; it's in mainline: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- > > 2.6.git;a=tree;f=drivers/staging/tidspbridge > > > > But that doesn't matter, even if it was in a branch, iommu > should not > > break either tidspbridge, or dsp-link, and driver branches > should not > > modify anything outside their domain (ideally). > > > > All you need to do is 'select OMAP_IOMMU_IVA2', although > the attached > > patch would be needed. > > > > -- > > 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 > -- To unsubscribe from this list: send the line "unsubscribe 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] staging: tidspbridge - update Kconfig to select IOMMU module
IOMMU module most be selected when using tidspbridge, because now tidsbridge depends on iommu module. Signed-off-by: Fernando Guzman Lugo --- drivers/staging/tidspbridge/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig index 93de4f2..ff64d46 100644 --- a/drivers/staging/tidspbridge/Kconfig +++ b/drivers/staging/tidspbridge/Kconfig @@ -6,6 +6,7 @@ menuconfig TIDSPBRIDGE tristate "DSP Bridge driver" depends on ARCH_OMAP3 select OMAP_MBOX_FWK + select OMAP_IOMMU help DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more attached DSPs. The GPP is considered the master or -- 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
Re: [PATCH] usb: musb: fix build break due to partial rename
On Sat, Oct 02, 2010 at 02:04:24AM +0530, Anand Gadiyar wrote: > Patch "usb gadget: don't save bind callback in struct usb_gadget_driver" > in Greg's USB queue missed one conversion of > usb_gadget_register_driver to usb_gadget_probe_driver, > causing a build break when MUSB is built in gadget mode. > > Fix this. > > Reported-by: Grazvydas Ignotas > Signed-off-by: Anand Gadiyar > Cc: Uwe Kleine-Koenig > Cc: Michal Nazarewicz > Cc: Felipe Balbi > Cc: Greg Kroah-Hartman > --- > Greg, > > Since Uwe's original patch isn't yet in mainline, maybe you could > fold this patch into the original. I've folded it into the original, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Check for is_smp for tlb_ops and cache_ops boardcast
On Tue, Oct 05, 2010 at 03:19:52PM -0700, Tony Lindgren wrote: > * Tony Lindgren [100907 20:04]: > > This should not be needed when running on UP systems. > > > > Additionally we will also get an undefined instruction on ARM cores > > without the extended CPUID registers with CONFIG_SMP_ON_UP. > > > > Also, we can now remove the is_smp() test from mmu.c. > > Just FYI, I've updated this one more time with to use cpus_empty > instead of !smp_on_up() here as well. What's the rationale? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Check for is_smp for tlb_ops and cache_ops boardcast
* Tony Lindgren [100907 20:04]:
> This should not be needed when running on UP systems.
>
> Additionally we will also get an undefined instruction on ARM cores
> without the extended CPUID registers with CONFIG_SMP_ON_UP.
>
> Also, we can now remove the is_smp() test from mmu.c.
Just FYI, I've updated this one more time with to use cpus_empty
instead of !smp_on_up() here as well.
Regards,
Tony
From: Tony Lindgren
Date: Tue, 5 Oct 2010 08:28:32 -0700
Subject: [PATCH] ARM: Check for is_smp for tlb_ops and cache_ops broadcast
Broadcast should not be needed when running SMP kernel on UP systems.
Also, this fixes an undefined instruction for SMP_ON_UP on earlier ARM
cores without the extended CPUID_EXT_MMFR3 register.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 7de5aa5..c8f7a08 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -10,11 +10,23 @@
/* all SMP configurations have the extended CPUID registers */
static inline int tlb_ops_need_broadcast(void)
{
+ cpumask_t mask = cpu_online_map;
+
+ cpu_clear(smp_processor_id(), mask);
+ if (cpus_empty(mask))
+ return 0;
+
return ((read_cpuid_ext(CPUID_EXT_MMFR3) >> 12) & 0xf) < 2;
}
static inline int cache_ops_need_broadcast(void)
{
+ cpumask_t mask = cpu_online_map;
+
+ cpu_clear(smp_processor_id(), mask);
+ if (cpus_empty(mask))
+ return 0;
+
return ((read_cpuid_ext(CPUID_EXT_MMFR3) >> 12) & 0xf) < 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 4/5] arm/omap: remove duplicated include
* Nicolas Kaiser [101004 03:35]: > Remove duplicated include. Thanks, adding into omap-for-linus. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
* Kevin Hilman [101005 09:26]: > "Varadarajan, Charulatha" writes: > > > Inorder to avoid any assumptions from bootloader, the watchdog > > timer module is reset during init. This enables the watchdog > > timer. > > > > Therefore, it is required to disable WDT after it is reset > > during init. Otherwise the system would reboot as per the default > > watchdog timer registers settings. > > > > Later, when the watchdog driver is loaded, the watchdog timer settings > > is adjusted as per the default timer_margin set in the driver and the > > driver would supports the normal operations supported by OMAP watchdog > > timer. > > > > Link to related discussions: > > https://patchwork.kernel.org/patch/219072/ > > > > Issue reported by Kevin can be found at: > > https://patchwork.kernel.org/patch/217262/ > > > > Signed-off-by: Charulatha V > > Reported-by: Kevin Hilman > > Acked-by: Kevin Hilman > > Tony, this should queue up for .37 on top of my pm-hwmods branch. > It applies cleanly to current l-o master. OK, adding to omap-for-linus. 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] TWL IRQ: Fix fucntion declaration warnings
Fixes following sparse warnings for twl4030 and twl6030 irq files. drivers/mfd/twl4030-irq.c:783:5: warning: symbol 'twl4030_init_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:863:5: warning: symbol 'twl4030_exit_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:873:5: warning: symbol 'twl4030_init_chip_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:226:5: warning: symbol 'twl6030_init_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:290:5: warning: symbol 'twl6030_exit_irq' was not declared. Should it be static? Signed-off-by: G, Manjunath Kondaiah Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Ortiz Cc: Tony Lindgren Cc: Nishanth Menon --- Changes from v2 to v3: - Created twl-core.h in drivers/mfd and seperated the patch from sparse fixes based on tony's suggestion. Changes since v1 to v2: - no logical change for this patch but sparse fixes series got updated with review comments. drivers/mfd/twl-core.h| 10 ++ drivers/mfd/twl4030-irq.c |1 + drivers/mfd/twl6030-irq.c |2 ++ 3 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/twl-core.h diff --git a/drivers/mfd/twl-core.h b/drivers/mfd/twl-core.h new file mode 100644 index 000..8c50a55 --- /dev/null +++ b/drivers/mfd/twl-core.h @@ -0,0 +1,10 @@ +#ifndef __TWL_CORE_H__ +#define __TWL_CORE_H__ + +extern int twl6030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end); +extern int twl6030_exit_irq(void); +extern int twl4030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end); +extern int twl4030_exit_irq(void); +extern int twl4030_init_chip_irq(const char *chip); + +#endif /* __TWL_CORE_H__ */ diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c index 097f24d..2563750 100644 --- a/drivers/mfd/twl4030-irq.c +++ b/drivers/mfd/twl4030-irq.c @@ -35,6 +35,7 @@ #include +#include "twl-core.h" /* * TWL4030 IRQ handling has two stages in hardware, and thus in software. diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c index 10bf228..8876b97 100644 --- a/drivers/mfd/twl6030-irq.c +++ b/drivers/mfd/twl6030-irq.c @@ -37,6 +37,8 @@ #include #include +#include "twl-core.h" + /* * TWL6030 (unlike its predecessors, which had two level interrupt handling) * three interrupt registers INT_STS_A, INT_STS_B and INT_STS_C. -- 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] OMAP2: onenand: Fix static function warnings
Fixes below sparse warning.
drivers/mtd/onenand/omap2.c:577:5: warning: symbol 'omap2_onenand_rephase' was
not declared. Should it be static?
Signed-off-by: G, Manjunath Kondaiah
---
Changes since v1 and v2:
- no logical changes, patch seperated from series based on Tony's suggestion.
drivers/mtd/onenand/omap2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 9f322f1..608cc8d 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -574,7 +574,7 @@ static int __adjust_timing(struct device *dev, void *data)
return ret;
}
-int omap2_onenand_rephase(void)
+static int omap2_onenand_rephase(void)
{
return driver_for_each_device(&omap2_onenand_driver.driver, NULL,
NULL, __adjust_timing);
--
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] OMAP2/3: NAND: Convert write/read functions to raw read/write
Following sparse warnings exists due to use of writel/w and readl/w functions.
This patch fixes the sparse warnings by converting readl/w functions usage into
__raw_readl/__raw_readw functions.
drivers/mtd/nand/omap2.c:484:15: warning: symbol '__v' shadows an earlier one
drivers/mtd/nand/omap2.c:484:15: originally declared here
drivers/mtd/onenand/omap2.c:86:9: warning: symbol '__v' shadows an earlier one
drivers/mtd/onenand/omap2.c:86:9: originally declared here
Signed-off-by: G, Manjunath Kondaiah
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@lists.infradead.org
---
Changes since v1 and v2:
- no logical changes, patch seperated from series based on Tony's suggestion.
drivers/mtd/nand/omap2.c|2 +-
drivers/mtd/onenand/omap2.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 439e80d..23d2810 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -481,7 +481,7 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
len >>= 1;
while (len--) {
- if (*p++ != cpu_to_le16(readw(info->nand.IO_ADDR_R)))
+ if (*p++ != cpu_to_le16(__raw_readw(info->nand.IO_ADDR_R)))
return -EFAULT;
}
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 608cc8d..b6a2b9f 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -83,7 +83,7 @@ static irqreturn_t omap2_onenand_interrupt(int irq, void
*dev_id)
static inline unsigned short read_reg(struct omap2_onenand *c, int reg)
{
- return readw(c->onenand.base + reg);
+ return __raw_readw(c->onenand.base + reg);
}
static inline void write_reg(struct omap2_onenand *c, unsigned short value,
--
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] OMAP: NAND: Fix static declaration warning
This patch fixes sparse warning for static declaration of variable "use_dma"
drivers/mtd/nand/omap2.c:114:11: warning: symbol 'use_dma' was not declared.
Should it be static?
Signed-off-by: G, Manjunath Kondaiah
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@lists.infradead.org
Cc: Tony Lindgren
Cc: Nishanth Menon
---
Changes since v1:
- no logical changes, patch seperated from series based Tony's suggestion.
drivers/mtd/nand/omap2.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 133d515..439e80d 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -111,11 +111,11 @@ static int use_dma = 1;
module_param(use_dma, bool, 0);
MODULE_PARM_DESC(use_dma, "enable/disable use of DMA");
#else
-const int use_dma;
+static const int use_dma;
#endif
#else
const int use_prefetch;
-const int use_dma;
+static const int use_dma;
#endif
struct omap_nand_info {
--
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: [PATCH] PM: add synchronous runtime interface for interrupt handlers
Alan Stern writes: > On Fri, 1 Oct 2010, Rafael J. Wysocki wrote: > >> > > In my opinion the _irq operations should really be one-shot, without >> > > any looping, waking up parents etc. I mean, if the parent is not >> > > RPM_ACTIVE, >> > > the _irq resume should immediately fail and analogously for the _irq >> > > suspend. And so on. As simple as reasonably possible. >> > >> > But what if the device's own status is currently SUSPENDING or >> > RESUMING? Do you want to fail when that happens, instead of waiting >> > for the concurrent operation to finish? >> >> Yes. IMO an _irq() suspend should only be allowed if the status is >> RPM_ACTIVE >> and an _irq() resume should fail if the status is not RPM_SUSPENDED. The >> error code returned should depend on the situation, though. >> >> > There's no way to prevent this >> > on SMP systems, because a wakeup request can arrive while a >> > software-initiated resume is in progress. >> >> I know that. :-) > > I suspect Kevin will not want to live with this restriction, but I'd > like to hear from him. Kevin? [ Apologies for the delays... I've been running around preparing OMAP PM stuff for the upcoming merge window. ] I think I can live with the above restrictions (the _irq methods failing unless they can immediately run.) For the rare corner cases I've currently run into, this will work fine as they happen because of a wakeup IRQ, where we know the device is RPM_SUSPENDED. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] omap: dsp: make the driver actually work
On Tue, Oct 5, 2010 at 11:09 PM, Ramirez Luna, Omar wrote: > Felipe Contreras wrote: > ... >>> >>> phys_to_virt instead of ioremap should work fine, still need to try >>> it though. >> >> I tried that... Didn't work. I guess we need to flush at some points >> (since the memory is cacheable). > > Hmmm, because my other option was to move the reserved memory outside the > kernel, but that involves specifying bootargs again and using > dma_alloc_coherent with their restrictions. Huh, if there's no contiguous memory region reserved, then the driver is doing dma_alloc_coherent already, but that fails (apparently 5M is too much). Plus I've read that dma_alloc_coherent is "precious"; shouldn't be used for that. > If you are working on a different method and need any help let me know. So, first I wanted to try reserving some region with mem=X boot param, but that solution is ugly. If that worked, then I wanted ti see if flushing each time we access that shm memory block works, but in the process I wanted to reorganize the whole initialization code because right now it's very ugly and confusing. -- 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 v5] power: introduce library for device-specific OPPs
Kevin Hilman had written, on 10/05/2010 03:50 PM, the following: "Rafael J. Wysocki" writes: On Tuesday, October 05, 2010, Nishanth Menon wrote: Rafael J. Wysocki had written, on 10/04/2010 05:36 PM, the following: On Friday, October 01, 2010, Nishanth Menon wrote: [...] I'm not really sure why so many mutexes are needed here. I don't think you need a separate mutex in every struct device_opp object. I'd just use dev_opp_list_lock for everything. I did consider using dev_opp_list_lock to lock everything *but* here is the contention: dev_opp_list_lock locks modification for addition of domains device. This operation happens usually during init stage. each domain device has multiple opps, new opps can be added, but the more often usage will probably be opp_enable and disable. domain are usually modifiable independent of each other - device_opp->lock provides device level lock allowing for each domain device opp list to be modified independent of each other. e.g. on thermal overage we may choose to lower mpu domain while a coprocessor driver in parallel might choose to disable co-processor domain in parallel. Wondering why you'd like a single lock for all domains and restrict parallelization? Because of the simplicity, mostly. If there's only a relatively short period when the lock will be contended for, that still is not too bad and it's much easier to get the synchronization right with just one lock for starters. FWIW, I agree with Rafael These are not going be highly contended locks, and the lock durations are very short, so simplifying the locking is a big win for readability. Kevin Fair enough. we can relook if the lock becomes a contended lock in the future. I do agree that simplifying the locking will benefit readability. Will post a v6 with a singular lock and updated documentation for the same. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] power: introduce library for device-specific OPPs
"Rafael J. Wysocki" writes: > On Tuesday, October 05, 2010, Nishanth Menon wrote: >> Rafael J. Wysocki had written, on 10/04/2010 05:36 PM, the following: >> > On Friday, October 01, 2010, Nishanth Menon wrote: [...] >> > >> > I'm not really sure why so many mutexes are needed here. I don't think you >> > need a separate mutex in every struct device_opp object. I'd just use >> > dev_opp_list_lock for everything. >> >> I did consider using dev_opp_list_lock to lock everything *but* here is >> the contention: >> >> dev_opp_list_lock locks modification for addition of domains device. >> This operation happens usually during init stage. >> >> each domain device has multiple opps, new opps can be added, but the >> more often usage will probably be opp_enable and disable. domain are >> usually modifiable independent of each other - device_opp->lock provides >> device level lock allowing for each domain device opp list to be >> modified independent of each other. e.g. on thermal overage we may >> choose to lower mpu domain while a coprocessor driver in parallel might >> choose to disable co-processor domain in parallel. >> >> Wondering why you'd like a single lock for all domains and restrict >> parallelization? > > Because of the simplicity, mostly. If there's only a relatively short period > when the lock will be contended for, that still is not too bad and it's much > easier to get the synchronization right with just one lock for starters. FWIW, I agree with Rafael These are not going be highly contended locks, and the lock durations are very short, so simplifying the locking is a big win for readability. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Wednesday, October 06, 2010 2:14 AM > To: Nayak, Rajendra > Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; > linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, > Govindraj > Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, > UART, i2c > > "Nayak, Rajendra" writes: > > >> -Original Message- > >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > >> Sent: Wednesday, October 06, 2010 2:05 AM > >> To: Nayak, Rajendra > >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; > >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, > >> Govindraj > >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: > >> watchdog, UART, i2c > >> > >> "Nayak, Rajendra" writes: > >> > >> >> -Original Message- > >> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > >> >> Sent: Wednesday, October 06, 2010 1:19 AM > >> >> To: Nayak, Rajendra > >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; > >> >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; > Raja, > >> >> Govindraj > >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: > >> >> watchdog, UART, i2c > >> >> > >> >> "Nayak, Rajendra" writes: > >> >> > >> >> >> -Original Message- > >> >> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > >> >> >> Sent: Tuesday, October 05, 2010 10:34 PM > >> >> >> To: Nayak, Rajendra > >> >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; > >> >> >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; > >> Raja, > >> >> >> Govindraj > >> >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: > >> >> >> watchdog, UART, i2c > >> >> >> > >> >> >> "Nayak, Rajendra" writes: > >> >> >> > >> >> >> > .. > >> >> >> > > >> >> >> >> > > >> >> >> >> > Below is an untested patch to provide some mechanism to deal > >> >> >> >> > with this -- > >> >> >> >> > I'd appreciate everyone's comments on this, particularly the > >> >> >> >> > comments in > >> >> >> >> > the patch code on how to deal with this problem. > >> >> >> >> > >> >> >> >> Hi Paul, > >> >> >> >> > >> >> >> >> I'll test this patch to see if it solves the issue seen with i2c > >> >> >> >> on n800. > >> >> >> > > >> >> >> > Hi Paul, Benoit, Kevin, > >> >> >> > > >> >> >> > So looks like the issue with i2c on n800 isn't really because of > >> >> >> > additional > >> >> >> > delay needed after a clock enable, but related to the > >> >> >> > omap_readl/writel's > >> >> >> > done on the 16bit i2c registers as I was suspecting earlier. > >> >> >> > > >> >> >> > The below patch fixes the n800 issue for me. My mailer might mess > >> >> >> > up the alignment > >> >> >> > hence attaching it too. > >> >> >> > > >> >> >> > From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 > >> >> >> > 2001 > >> >> >> > From: Rajendra Nayak > >> >> >> > Date: Tue, 5 Oct 2010 16:36:30 +0530 > >> >> >> > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers > >> >> >> > > >> >> >> > Some modules which have 16bit registers can cause imprecise > >> >> >> > aborts if a __raw_readl/writel is used to read/write 32 bits. > >> >> >> > > >> >> >> > Add an additional flag to identify modules which have such > >> >> >> > hard requirement, and handle it in the hwmod framework. > >> >> >> > > >> >> >> > Signed-off-by: Rajendra Nayak > >> >> >> > >> >> >> Can you also send a corresponding patch to the i2c hwmod data. > >> >> > Hi Kevin, > >> >> > > >> >> > Ok, I'll repost the original patch which adds the omap2 hwmod data > >> >> > with > >> >> > these flags added for omap2420. Does that sound fine? > >> >> > >> >> Since I've alrady done some manual merge conflicts here, you can just > >> >> post an additional patch and I will fold it in. > >> > > >> > Ok, so here's the patch > >> > -- > >> > From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001 > >> > From: Rajendra Nayak > >> > Date: Wed, 6 Oct 2010 01:49:32 +0530 > >> > Subject: [PATCH] OMAP2: hmwod: Fix impresice aborts seen on n800/n810 > >> > > >> > I2C module on OMAP2420 has 16bit registers and causes imprecise > >> > aborts if 32bits are read/wriitten into. > >> > Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this > >> > hard requirement so that __raw_writew/readw is used to read /write > >> > the mdoule registers. > >> > > >> > Signed-off-by: Rajendra Nayak > >> > --- > >> > arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 ++ > >> > 1 files changed, 2 insertions(+), 0 deletions(-) > >> > >> Thanks. > >> > >> Shouldn't we do the same for 2430? I guess the imprecise aborts aren't > >> happening on 2430, but I think we should still use the 16-bit accesses > >> there too. > >> > >> What do you think? > > > > Yeah, actually i2c modules on all OMAPs including OMAP4 have had 16 bit > > registers. > > But somehow only 2420 seemed to
Re: [PATCH v5] power: introduce library for device-specific OPPs
On Tuesday, October 05, 2010, Nishanth Menon wrote:
> Rafael J. Wysocki had written, on 10/04/2010 05:36 PM, the following:
> > On Friday, October 01, 2010, Nishanth Menon wrote:
> >> SoCs have a standard set of tuples consisting of frequency and
> >> voltage pairs that the device will support per voltage domain. These
> >> are called Operating Performance Points or OPPs. The actual
> >> definitions of OPP varies over silicon versions. For a specific domain,
> >> we can have a set of {frequency, voltage} pairs. As the kernel boots
> >> and more information is available, a default set of these are activated
> >> based on the precise nature of device. Further on operation, based on
> >> conditions prevailing in the system (such as temperature), some OPP
> >> availability may be temporarily controlled by the SoC frameworks.
> >>
> >> To implement an OPP, some sort of power management support is necessary
> >> hence this library depends on CONFIG_PM.
> >
> > Well, I still have some comments.
> Thanks for the same. Few views below.
>
> >
> > ...
> >> +/**
> >> + * opp_add() - Add an OPP table from a table definitions
> >> + * @dev: device for which we do this operation
> >> + * @freq: Frequency in Hz for this OPP
> >> + * @u_volt: Voltage in uVolts for this OPP
> >> + *
> >> + * This function adds an opp definition to the opp list and returns
> >> status.
> >> + * The opp is made available by default and it can be controlled using
> >> + * opp_enable/disable functions.
> >> + *
> >> + * Locking: The internal device_opp and opp structures are RCU protected.
> >> + * Hence this function internally uses RCU and mutex locks to keep the
> >> + * integrity of the internal data structures. Callers should ensure that
> >> + * this function is *NOT* called under RCU protection or in contexts where
> >> + * mutex cannot be locked.
> >
> > I'm not really sure why so many mutexes are needed here. I don't think you
> > need a separate mutex in every struct device_opp object. I'd just use
> > dev_opp_list_lock for everything.
>
> I did consider using dev_opp_list_lock to lock everything *but* here is
> the contention:
>
> dev_opp_list_lock locks modification for addition of domains device.
> This operation happens usually during init stage.
>
> each domain device has multiple opps, new opps can be added, but the
> more often usage will probably be opp_enable and disable. domain are
> usually modifiable independent of each other - device_opp->lock provides
> device level lock allowing for each domain device opp list to be
> modified independent of each other. e.g. on thermal overage we may
> choose to lower mpu domain while a coprocessor driver in parallel might
> choose to disable co-processor domain in parallel.
>
> Wondering why you'd like a single lock for all domains and restrict
> parallelization?
Because of the simplicity, mostly. If there's only a relatively short period
when the lock will be contended for, that still is not too bad and it's much
easier to get the synchronization right with just one lock for starters.
> >> + */
> >> +int opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
> >> +{
> >> + struct device_opp *dev_opp = NULL;
> >> + struct opp *opp, *new_opp;
> >> + struct list_head *head;
> >> +
> >> + /* allocate new OPP node */
> >> + new_opp = kzalloc(sizeof(struct opp), GFP_KERNEL);
> >> + if (!new_opp) {
> >> + pr_warning("Unable to allocate new opp node\n");
> >> + return -ENOMEM;
> >> + }
> >> +
> >> + /* Check for existing list for 'dev' */
> >> + rcu_read_lock();
> >
> > If you acquire dev_opp_list_lock here, you won't need the rcu_read_lock(),
> > because every other updater will block on dev_opp_list_lock until you're
> > done.
> [contention on using a single lock dev_opp_list_lock as discussed above]
I don't think it's a big issue at this point.
> >> + dev_opp = find_device_opp(dev);
> >> + rcu_read_unlock();
> >> + if (!dev_opp) {
> >
> > Now you can drop dev_opp_list_lock temporarily, because the allocation
> > doesn't
> > need synchronization.
> [contention on using a single lock dev_opp_list_lock as discussed above]
Well, see above.
> >> + /* Allocate a new device OPP table */
> >> + dev_opp = kzalloc(sizeof(struct device_opp), GFP_KERNEL);
> >> + if (!dev_opp) {
> >> + kfree(new_opp);
> >> + pr_warning("Unable to allocate device structure\n");
> >> + return -ENOMEM;
> >> + }
> >> +
> >> + dev_opp->dev = dev;
> >> + INIT_LIST_HEAD(&dev_opp->opp_list);
> >> + mutex_init(&dev_opp->lock);
> >> +
> >
> > Reacquire dev_opp_list_lock at this point and hold it to the end of the
> > routine.
> [contention on using a single lock dev_opp_list_lock as discussed above]
See above.
> >> + /* Secure the device list modification */
> >> + mutex_lock(&dev_opp_list_lock);
> >
> > This w
Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
"Nayak, Rajendra" writes: >> -Original Message- >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> Sent: Wednesday, October 06, 2010 2:05 AM >> To: Nayak, Rajendra >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, >> Govindraj >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: >> watchdog, UART, i2c >> >> "Nayak, Rajendra" writes: >> >> >> -Original Message- >> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> >> Sent: Wednesday, October 06, 2010 1:19 AM >> >> To: Nayak, Rajendra >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; >> >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, >> >> Govindraj >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: >> >> watchdog, UART, i2c >> >> >> >> "Nayak, Rajendra" writes: >> >> >> >> >> -Original Message- >> >> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> >> >> Sent: Tuesday, October 05, 2010 10:34 PM >> >> >> To: Nayak, Rajendra >> >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; >> >> >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; >> Raja, >> >> >> Govindraj >> >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: >> >> >> watchdog, UART, i2c >> >> >> >> >> >> "Nayak, Rajendra" writes: >> >> >> >> >> >> > .. >> >> >> > >> >> >> >> > >> >> >> >> > Below is an untested patch to provide some mechanism to deal with >> >> >> >> > this -- >> >> >> >> > I'd appreciate everyone's comments on this, particularly the >> >> >> >> > comments in >> >> >> >> > the patch code on how to deal with this problem. >> >> >> >> >> >> >> >> Hi Paul, >> >> >> >> >> >> >> >> I'll test this patch to see if it solves the issue seen with i2c on >> >> >> >> n800. >> >> >> > >> >> >> > Hi Paul, Benoit, Kevin, >> >> >> > >> >> >> > So looks like the issue with i2c on n800 isn't really because of >> >> >> > additional >> >> >> > delay needed after a clock enable, but related to the >> >> >> > omap_readl/writel's >> >> >> > done on the 16bit i2c registers as I was suspecting earlier. >> >> >> > >> >> >> > The below patch fixes the n800 issue for me. My mailer might mess up >> >> >> > the alignment >> >> >> > hence attaching it too. >> >> >> > >> >> >> > From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 >> >> >> > 2001 >> >> >> > From: Rajendra Nayak >> >> >> > Date: Tue, 5 Oct 2010 16:36:30 +0530 >> >> >> > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers >> >> >> > >> >> >> > Some modules which have 16bit registers can cause imprecise >> >> >> > aborts if a __raw_readl/writel is used to read/write 32 bits. >> >> >> > >> >> >> > Add an additional flag to identify modules which have such >> >> >> > hard requirement, and handle it in the hwmod framework. >> >> >> > >> >> >> > Signed-off-by: Rajendra Nayak >> >> >> >> >> >> Can you also send a corresponding patch to the i2c hwmod data. >> >> > Hi Kevin, >> >> > >> >> > Ok, I'll repost the original patch which adds the omap2 hwmod data with >> >> > these flags added for omap2420. Does that sound fine? >> >> >> >> Since I've alrady done some manual merge conflicts here, you can just >> >> post an additional patch and I will fold it in. >> > >> > Ok, so here's the patch >> > -- >> > From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001 >> > From: Rajendra Nayak >> > Date: Wed, 6 Oct 2010 01:49:32 +0530 >> > Subject: [PATCH] OMAP2: hmwod: Fix impresice aborts seen on n800/n810 >> > >> > I2C module on OMAP2420 has 16bit registers and causes imprecise >> > aborts if 32bits are read/wriitten into. >> > Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this >> > hard requirement so that __raw_writew/readw is used to read /write >> > the mdoule registers. >> > >> > Signed-off-by: Rajendra Nayak >> > --- >> > arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 ++ >> > 1 files changed, 2 insertions(+), 0 deletions(-) >> >> Thanks. >> >> Shouldn't we do the same for 2430? I guess the imprecise aborts aren't >> happening on 2430, but I think we should still use the 16-bit accesses >> there too. >> >> What do you think? > > Yeah, actually i2c modules on all OMAPs including OMAP4 have had 16 bit > registers. > But somehow only 2420 seemed to cause issues. OK, then let's keep this as a targetted fix for this merge window, and we can discuss whether this needs to be done for all OMAPs later. I'll use you current patch, Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Wednesday, October 06, 2010 2:05 AM > To: Nayak, Rajendra > Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; > linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, > Govindraj > Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, > UART, i2c > > "Nayak, Rajendra" writes: > > >> -Original Message- > >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > >> Sent: Wednesday, October 06, 2010 1:19 AM > >> To: Nayak, Rajendra > >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; > >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, > >> Govindraj > >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: > >> watchdog, UART, i2c > >> > >> "Nayak, Rajendra" writes: > >> > >> >> -Original Message- > >> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > >> >> Sent: Tuesday, October 05, 2010 10:34 PM > >> >> To: Nayak, Rajendra > >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; > >> >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; > Raja, > >> >> Govindraj > >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: > >> >> watchdog, UART, i2c > >> >> > >> >> "Nayak, Rajendra" writes: > >> >> > >> >> > .. > >> >> > > >> >> >> > > >> >> >> > Below is an untested patch to provide some mechanism to deal with > >> >> >> > this -- > >> >> >> > I'd appreciate everyone's comments on this, particularly the > >> >> >> > comments in > >> >> >> > the patch code on how to deal with this problem. > >> >> >> > >> >> >> Hi Paul, > >> >> >> > >> >> >> I'll test this patch to see if it solves the issue seen with i2c on > >> >> >> n800. > >> >> > > >> >> > Hi Paul, Benoit, Kevin, > >> >> > > >> >> > So looks like the issue with i2c on n800 isn't really because of > >> >> > additional > >> >> > delay needed after a clock enable, but related to the > >> >> > omap_readl/writel's > >> >> > done on the 16bit i2c registers as I was suspecting earlier. > >> >> > > >> >> > The below patch fixes the n800 issue for me. My mailer might mess up > >> >> > the alignment > >> >> > hence attaching it too. > >> >> > > >> >> > From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001 > >> >> > From: Rajendra Nayak > >> >> > Date: Tue, 5 Oct 2010 16:36:30 +0530 > >> >> > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers > >> >> > > >> >> > Some modules which have 16bit registers can cause imprecise > >> >> > aborts if a __raw_readl/writel is used to read/write 32 bits. > >> >> > > >> >> > Add an additional flag to identify modules which have such > >> >> > hard requirement, and handle it in the hwmod framework. > >> >> > > >> >> > Signed-off-by: Rajendra Nayak > >> >> > >> >> Can you also send a corresponding patch to the i2c hwmod data. > >> > Hi Kevin, > >> > > >> > Ok, I'll repost the original patch which adds the omap2 hwmod data with > >> > these flags added for omap2420. Does that sound fine? > >> > >> Since I've alrady done some manual merge conflicts here, you can just > >> post an additional patch and I will fold it in. > > > > Ok, so here's the patch > > -- > > From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001 > > From: Rajendra Nayak > > Date: Wed, 6 Oct 2010 01:49:32 +0530 > > Subject: [PATCH] OMAP2: hmwod: Fix impresice aborts seen on n800/n810 > > > > I2C module on OMAP2420 has 16bit registers and causes imprecise > > aborts if 32bits are read/wriitten into. > > Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this > > hard requirement so that __raw_writew/readw is used to read /write > > the mdoule registers. > > > > Signed-off-by: Rajendra Nayak > > --- > > arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > Thanks. > > Shouldn't we do the same for 2430? I guess the imprecise aborts aren't > happening on 2430, but I think we should still use the 16-bit accesses > there too. > > What do you think? Yeah, actually i2c modules on all OMAPs including OMAP4 have had 16 bit registers. But somehow only 2420 seemed to cause issues. That's why I mentioned modules with 'hard requirement' :-) Maybe I'll post a patch adding this for all i2c's across OMAP's? > > Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: zoom2/3: fix build caused by wl1271 support
On Tue, 2010-10-05 at 15:19 +0200, ext Luciano Coelho wrote: > On Tue, 2010-10-05 at 14:07 +0200, ext Luciano Coelho wrote: > > On Tue, 2010-10-05 at 13:53 +0200, ext Luciano Coelho wrote: > > > On Sat, 2010-10-02 at 01:10 +0200, ext Tony Lindgren wrote: > > > > * Anand Gadiyar [101001 13:25]: > > > > > Patch "omap: zoom: add mmc3/wl1271 device support" in the > > > > > wireless tree still uses .wires in struct omap2_hsmmc_info. > > > > > .wires has now been replaced with .caps in patch "omap: mmc: > > > > > extended to pass host capabilities from board file" in the > > > > > OMAP tree. > > > > > > > > > > This causes linux-next as of 20101001 build to break as > > > > > below. Fix this. > > > > > > > > > > CC arch/arm/mach-omap2/board-zoom-peripherals.o > > > > > arch/arm/mach-omap2/board-zoom-peripherals.c:217: error: unknown > > > > > field 'wires' specified in initializer > > > > > make[1]: *** [arch/arm/mach-omap2/board-zoom-peripherals.o] Error 1 > > > > > make: *** [arch/arm/mach-omap2] Error 2 > > > > > > > > Can you guys please queue this via the wireless tree along with > > > > the other wl1271 patches? > > > > > > > > Acked-by: Tony Lindgren > > > > > > I can apply this to the wl12xx tree. I just need John's confirmation. > > > > > > The pull request I sent to John last week is still pending. I don't > > > know if it is possible to substitute it for a newer one with more > > > patches (and still try to make it to 2.6.37). What do you think, John? > > > > Damn, for some reason I had a bug in John's email in my contact book. > > Now sending to the correct email address. > > Applied to the wl12xx tree. I'll send a new replacement pull to John > today, including this patch. Thanks. Hmmm... We got a problem here. This patch breaks builds when we *don't* have "omap: mmc extended to pass host capabilities from board file". We don't have that on wireless-next yet, so builds with zoom boards selected are broken. Any ideas on how to solve this dilemma? I guess the proper way to handle this would be to make the changes proposed in this patch when merging instead of having a normal commit for it, wouldn't it? -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe 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: OMAP hwmod driver conversions: watchdog, UART, i2c
"Nayak, Rajendra" writes: >> -Original Message- >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> Sent: Wednesday, October 06, 2010 1:19 AM >> To: Nayak, Rajendra >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, >> Govindraj >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: >> watchdog, UART, i2c >> >> "Nayak, Rajendra" writes: >> >> >> -Original Message- >> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> >> Sent: Tuesday, October 05, 2010 10:34 PM >> >> To: Nayak, Rajendra >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; >> >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, >> >> Govindraj >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: >> >> watchdog, UART, i2c >> >> >> >> "Nayak, Rajendra" writes: >> >> >> >> > .. >> >> > >> >> >> > >> >> >> > Below is an untested patch to provide some mechanism to deal with >> >> >> > this -- >> >> >> > I'd appreciate everyone's comments on this, particularly the >> >> >> > comments in >> >> >> > the patch code on how to deal with this problem. >> >> >> >> >> >> Hi Paul, >> >> >> >> >> >> I'll test this patch to see if it solves the issue seen with i2c on >> >> >> n800. >> >> > >> >> > Hi Paul, Benoit, Kevin, >> >> > >> >> > So looks like the issue with i2c on n800 isn't really because of >> >> > additional >> >> > delay needed after a clock enable, but related to the >> >> > omap_readl/writel's >> >> > done on the 16bit i2c registers as I was suspecting earlier. >> >> > >> >> > The below patch fixes the n800 issue for me. My mailer might mess up >> >> > the alignment >> >> > hence attaching it too. >> >> > >> >> > From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001 >> >> > From: Rajendra Nayak >> >> > Date: Tue, 5 Oct 2010 16:36:30 +0530 >> >> > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers >> >> > >> >> > Some modules which have 16bit registers can cause imprecise >> >> > aborts if a __raw_readl/writel is used to read/write 32 bits. >> >> > >> >> > Add an additional flag to identify modules which have such >> >> > hard requirement, and handle it in the hwmod framework. >> >> > >> >> > Signed-off-by: Rajendra Nayak >> >> >> >> Can you also send a corresponding patch to the i2c hwmod data. >> > Hi Kevin, >> > >> > Ok, I'll repost the original patch which adds the omap2 hwmod data with >> > these flags added for omap2420. Does that sound fine? >> >> Since I've alrady done some manual merge conflicts here, you can just >> post an additional patch and I will fold it in. > > Ok, so here's the patch > -- > From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001 > From: Rajendra Nayak > Date: Wed, 6 Oct 2010 01:49:32 +0530 > Subject: [PATCH] OMAP2: hmwod: Fix impresice aborts seen on n800/n810 > > I2C module on OMAP2420 has 16bit registers and causes imprecise > aborts if 32bits are read/wriitten into. > Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this > hard requirement so that __raw_writew/readw is used to read /write > the mdoule registers. > > Signed-off-by: Rajendra Nayak > --- > arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) Thanks. Shouldn't we do the same for 2430? I guess the imprecise aborts aren't happening on 2430, but I think we should still use the 16-bit accesses there too. What do you think? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 00/11] staging tidspbridge: iommu migration
This set of patches remove the dspbridge custom mmu implementation and use iommu module instead. Version2: - Comments from FUJITA Tomonori and previous patch "tidspbridge: add map support for big buffers" was removed and instead a patch to define ARCH_HAS_SG_CHAIN in arm architecture will be sent. - Rebase to the latest tidspbridge. Version2 - Rebase to the latest staging-next tree commit: a747d4b817daf95c64ac6396e27fddc66c83a811 Fernando Guzman Lugo (11): staging: tidspbridge: replace iommu custom for opensource implementation staging: tidspbridge - move shared memory iommu maps to tiomap3430.c staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name staging: tidspbridge - remove custom mmu code from tiomap3430.c staging: tidspbridge - fix mmufault support staging: tidspbrge - remove hw directory staging: tidspbridge - move all iommu related code to a new file staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct staging: tidspbridge - remove reserved memory clean up staging: tidspbridge - deprecate reserve/unreserve_memory funtions staging: tidspbridge - remove dmm custom module drivers/staging/tidspbridge/Makefile |7 +- drivers/staging/tidspbridge/core/_deh.h|5 +- drivers/staging/tidspbridge/core/_tiomap.h | 19 +- drivers/staging/tidspbridge/core/dsp-mmu.c | 316 ++ drivers/staging/tidspbridge/core/io_sm.c | 180 +--- drivers/staging/tidspbridge/core/tiomap3430.c | 1070 ++-- drivers/staging/tidspbridge/core/tiomap3430_pwr.c |4 - drivers/staging/tidspbridge/core/tiomap_io.c | 17 +- drivers/staging/tidspbridge/core/ue_deh.c | 115 +--- drivers/staging/tidspbridge/hw/EasiGlobal.h| 41 - drivers/staging/tidspbridge/hw/MMUAccInt.h | 76 -- drivers/staging/tidspbridge/hw/MMURegAcM.h | 225 drivers/staging/tidspbridge/hw/hw_defs.h | 58 -- drivers/staging/tidspbridge/hw/hw_mmu.c| 562 -- drivers/staging/tidspbridge/hw/hw_mmu.h| 163 --- .../tidspbridge/include/dspbridge/cfgdefs.h|1 - .../staging/tidspbridge/include/dspbridge/dev.h| 24 - .../staging/tidspbridge/include/dspbridge/dmm.h| 75 -- .../staging/tidspbridge/include/dspbridge/drv.h| 10 - .../tidspbridge/include/dspbridge/dsp-mmu.h| 67 ++ .../tidspbridge/include/dspbridge/dspdefs.h| 44 - .../tidspbridge/include/dspbridge/dspioctl.h |7 - .../staging/tidspbridge/include/dspbridge/proc.h | 46 - drivers/staging/tidspbridge/pmgr/dev.c | 63 +-- drivers/staging/tidspbridge/pmgr/dmm.c | 533 -- drivers/staging/tidspbridge/pmgr/dspapi.c | 34 +- drivers/staging/tidspbridge/rmgr/drv.c | 15 - drivers/staging/tidspbridge/rmgr/drv_interface.c |2 - drivers/staging/tidspbridge/rmgr/node.c| 48 +- drivers/staging/tidspbridge/rmgr/proc.c| 197 + 30 files changed, 568 insertions(+), 3456 deletions(-) create mode 100644 drivers/staging/tidspbridge/core/dsp-mmu.c delete mode 100644 drivers/staging/tidspbridge/hw/EasiGlobal.h delete mode 100644 drivers/staging/tidspbridge/hw/MMUAccInt.h delete mode 100644 drivers/staging/tidspbridge/hw/MMURegAcM.h delete mode 100644 drivers/staging/tidspbridge/hw/hw_defs.h delete mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.c delete mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.h delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dmm.h create mode 100644 drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h delete mode 100644 drivers/staging/tidspbridge/pmgr/dmm.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
[PATCHv3 05/11] staging: tidspbridge - fix mmufault support
With changes for iommu migration mmufault report and dsp track
dump is broken, this patch fixes that.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_deh.h |2 +
drivers/staging/tidspbridge/core/tiomap3430.c |2 +
drivers/staging/tidspbridge/core/ue_deh.c | 93 ++---
3 files changed, 40 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_deh.h
b/drivers/staging/tidspbridge/core/_deh.h
index 16723cd..f1254f0 100644
--- a/drivers/staging/tidspbridge/core/_deh.h
+++ b/drivers/staging/tidspbridge/core/_deh.h
@@ -32,4 +32,6 @@ struct deh_mgr {
struct tasklet_struct dpc_tasklet;
};
+int mmu_fault_isr(struct iommu *mmu);
+
#endif /* _DEH_ */
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index e5f67be..86f 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -58,6 +58,7 @@
#include "_tiomap.h"
#include "_tiomap_pwr.h"
#include "tiomap_io.h"
+#include "_deh.h"
/* Offset in shared mem to write to in order to synchronize start with DSP */
#define SHMSYNCOFFSET 4/* GPP byte offset */
@@ -367,6 +368,7 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
}
if (!status) {
dev_context->dsp_mmu = mmu;
+ mmu->isr = mmu_fault_isr;
sm_sg = &dev_context->sh_s;
sg0_da = iommu_kmap(mmu, sm_sg->seg0_da, sm_sg->seg0_pa,
sm_sg->seg0_size, IOVMF_ENDIAN_LITTLE | IOVMF_ELSZ_32);
diff --git a/drivers/staging/tidspbridge/core/ue_deh.c
b/drivers/staging/tidspbridge/core/ue_deh.c
index 14f3191..2e1ac89 100644
--- a/drivers/staging/tidspbridge/core/ue_deh.c
+++ b/drivers/staging/tidspbridge/core/ue_deh.c
@@ -31,7 +31,7 @@
#include
#include
-static u32 fault_addr;
+#define MMU_CNTL_TWL_EN(1 << 2)
static void mmu_fault_dpc(unsigned long data)
{
@@ -43,43 +43,18 @@ static void mmu_fault_dpc(unsigned long data)
bridge_deh_notify(deh, DSP_MMUFAULT, 0);
}
-static irqreturn_t mmu_fault_isr(int irq, void *data)
+int mmu_fault_isr(struct iommu *mmu)
{
- struct deh_mgr *deh = data;
- struct cfg_hostres *resources;
- u32 event;
+ struct deh_mgr *dm;
- if (!deh)
- return IRQ_HANDLED;
+ dev_get_deh_mgr(dev_get_first(), &dm);
- resources = deh->hbridge_context->resources;
- if (!resources) {
- dev_dbg(bridge, "%s: Failed to get Host Resources\n",
- __func__);
- return IRQ_HANDLED;
- }
+ if (!dm)
+ return -EPERM;
- hw_mmu_event_status(resources->dw_dmmu_base, &event);
- if (event == HW_MMU_TRANSLATION_FAULT) {
- hw_mmu_fault_addr_read(resources->dw_dmmu_base, &fault_addr);
- dev_dbg(bridge, "%s: event=0x%x, fault_addr=0x%x\n", __func__,
- event, fault_addr);
- /*
-* Schedule a DPC directly. In the future, it may be
-* necessary to check if DSP MMU fault is intended for
-* Bridge.
-*/
- tasklet_schedule(&deh->dpc_tasklet);
-
- /* Disable the MMU events, else once we clear it will
-* start to raise INTs again */
- hw_mmu_event_disable(resources->dw_dmmu_base,
- HW_MMU_TRANSLATION_FAULT);
- } else {
- hw_mmu_event_disable(resources->dw_dmmu_base,
- HW_MMU_ALL_INTERRUPTS);
- }
- return IRQ_HANDLED;
+ iommu_write_reg(mmu, 0, MMU_IRQENABLE);
+ tasklet_schedule(&dm->dpc_tasklet);
+ return 0;
}
int bridge_deh_create(struct deh_mgr **ret_deh,
@@ -161,42 +136,45 @@ int bridge_deh_register_notify(struct deh_mgr *deh, u32
event_mask,
#ifdef CONFIG_TIDSPBRIDGE_BACKTRACE
static void mmu_fault_print_stack(struct bridge_dev_context *dev_context)
{
- struct cfg_hostres *resources;
- struct hw_mmu_map_attrs_t map_attrs = {
- .endianism = HW_LITTLE_ENDIAN,
- .element_size = HW_ELEM_SIZE16BIT,
- .mixed_size = HW_MMU_CPUES,
- };
- void *dummy_va_addr;
-
- resources = dev_context->resources;
- dummy_va_addr = (void*)__get_free_page(GFP_ATOMIC);
+ void *dummy_addr;
+ u32 fa, tmp;
+ struct iotlb_entry e;
+ struct iommu *mmu = dev_context->dsp_mmu;
+ dummy_addr = (void *)__get_free_page(GFP_ATOMIC);
/*
* Before acking the MMU fault, let's make sure MMU can only
* access entry #0. Then add a new entry so that the DSP OS
* can continue in order to dump the stack.
*/
- hw_mmu_twl_disable(resources->dw_dmmu_base);
- hw_mmu_tlb_flush_all(resource
[PATCHv3 02/11] staging: tidspbridge - move shared memory iommu maps to tiomap3430.c
Now iommu maps of shared memory segments are done in
bridge_brd_start and unmaped in bridge_brd_stop.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_tiomap.h| 13 +++
drivers/staging/tidspbridge/core/io_sm.c | 125 +++
drivers/staging/tidspbridge/core/tiomap3430.c | 135 +++-
drivers/staging/tidspbridge/core/tiomap_io.c | 12 +-
4 files changed, 139 insertions(+), 146 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index a42c393..c1bf95d 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -308,6 +308,18 @@ static const struct bpwr_clk_t bpwr_clks[] = {
#define CLEAR_BIT_INDEX(reg, index) (reg &= ~(1 << (index)))
+struct shm_segs {
+ u32 seg0_da;
+ u32 seg0_pa;
+ u32 seg0_va;
+ u32 seg0_size;
+ u32 seg1_da;
+ u32 seg1_pa;
+ u32 seg1_va;
+ u32 seg1_size;
+};
+
+
/* This Bridge driver's device context: */
struct bridge_dev_context {
struct dev_object *hdev_obj;/* Handle to Bridge device object. */
@@ -331,6 +343,7 @@ struct bridge_dev_context {
struct omap_mbox *mbox; /* Mail box handle */
struct iommu *dsp_mmu; /* iommu for iva2 handler */
+ struct shm_segs sh_s;
struct cfg_hostres *resources; /* Host Resources */
/*
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index 842b8db..56856ad 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -291,7 +291,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct cod_manager *cod_man;
struct chnl_mgr *hchnl_mgr;
struct msg_mgr *hmsg_mgr;
- struct iommu *mmu;
+ struct shm_segs *sm_sg;
u32 ul_shm_base;
u32 ul_shm_base_offset;
u32 ul_shm_limit;
@@ -317,14 +317,6 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
u32 shm0_end;
u32 ul_dyn_ext_base;
u32 ul_seg1_size = 0;
- u32 pa_curr = 0;
- u32 va_curr = 0;
- u32 gpp_va_curr = 0;
- u32 num_bytes = 0;
- u32 all_bits = 0;
- u32 page_size[] = { HW_PAGE_SIZE16MB, HW_PAGE_SIZE1MB,
- HW_PAGE_SIZE64KB, HW_PAGE_SIZE4KB
- };
status = dev_get_bridge_context(hio_mgr->hdev_obj, &pbridge_context);
if (!pbridge_context) {
@@ -337,19 +329,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
status = -EFAULT;
goto func_end;
}
- mmu = pbridge_context->dsp_mmu;
-
- if (mmu)
- iommu_put(mmu);
- mmu = iommu_get("iva2");
-
- if (IS_ERR_OR_NULL(mmu)) {
- dev_err(bridge, "iommu_get failed!\n");
- pbridge_context->dsp_mmu = NULL;
- status = -EFAULT;
- goto func_end;
- }
- pbridge_context->dsp_mmu = mmu;
+ sm_sg = &pbridge_context->sh_s;
status = dev_get_cod_mgr(hio_mgr->hdev_obj, &cod_man);
if (!cod_man) {
@@ -485,74 +465,14 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
if (status)
goto func_end;
- pa_curr = ul_gpp_pa;
- va_curr = ul_dyn_ext_base * hio_mgr->word_size;
- gpp_va_curr = ul_gpp_va;
- num_bytes = ul_seg1_size;
-
- va_curr = iommu_kmap(mmu, va_curr, pa_curr, num_bytes,
- IOVMF_ENDIAN_LITTLE | IOVMF_ELSZ_32);
- if (IS_ERR_VALUE(va_curr)) {
- status = (int)va_curr;
- goto func_end;
- }
-
- pa_curr += ul_pad_size + num_bytes;
- va_curr += ul_pad_size + num_bytes;
- gpp_va_curr += ul_pad_size + num_bytes;
-
- /* Configure the TLB entries for the next cacheable segment */
- num_bytes = ul_seg_size;
- va_curr = ul_dsp_va * hio_mgr->word_size;
- while (num_bytes) {
- /*
-* To find the max. page size with which both PA & VA are
-* aligned.
-*/
- all_bits = pa_curr | va_curr;
- dev_dbg(bridge, "all_bits for Seg1 %x, pa_curr %x, "
- "va_curr %x, num_bytes %x\n", all_bits, pa_curr,
- va_curr, num_bytes);
- for (i = 0; i < 4; i++) {
- if (!(num_bytes >= page_size[i]) ||
- !((all_bits & (page_size[i] - 1)) == 0))
- continue;
- if (ndx < MAX_LOCK_TLB_ENTRIES) {
- /*
-* This is the physical address written to
-* DSP MMU.
-*/
- ae_proc[ndx].ul_gpp_pa = pa_curr;
- /*
-
[PATCHv3 07/11] staging: tidspbridge - move all iommu related code to a new file
Create dsp-mmu module and moves all the iommu code related to
this module.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/Makefile |2 +-
drivers/staging/tidspbridge/core/_deh.h|3 -
drivers/staging/tidspbridge/core/_tiomap.h | 27 +--
drivers/staging/tidspbridge/core/dsp-mmu.c | 316
drivers/staging/tidspbridge/core/tiomap3430.c | 178 +---
drivers/staging/tidspbridge/core/ue_deh.c | 86 +--
.../tidspbridge/include/dspbridge/dsp-mmu.h| 67
7 files changed, 390 insertions(+), 289 deletions(-)
create mode 100644 drivers/staging/tidspbridge/core/dsp-mmu.c
create mode 100644 drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h
diff --git a/drivers/staging/tidspbridge/Makefile
b/drivers/staging/tidspbridge/Makefile
index e09547d..bd36651 100644
--- a/drivers/staging/tidspbridge/Makefile
+++ b/drivers/staging/tidspbridge/Makefile
@@ -2,7 +2,7 @@ obj-$(CONFIG_TIDSPBRIDGE) += bridgedriver.o
libgen = gen/gb.o gen/gs.o gen/gh.o gen/uuidutil.o
libcore = core/chnl_sm.o core/msg_sm.o core/io_sm.o core/tiomap3430.o \
- core/tiomap3430_pwr.o core/tiomap_io.o \
+ core/tiomap3430_pwr.o core/tiomap_io.o core/dsp-mmu.o \
core/ue_deh.o core/wdt.o core/dsp-clock.o core/sync.o
libpmgr = pmgr/chnl.o pmgr/io.o pmgr/msg.o pmgr/cod.o pmgr/dev.o pmgr/dspapi.o
\
pmgr/dmm.o pmgr/cmm.o pmgr/dbll.o
diff --git a/drivers/staging/tidspbridge/core/_deh.h
b/drivers/staging/tidspbridge/core/_deh.h
index f1254f0..8ae2633 100644
--- a/drivers/staging/tidspbridge/core/_deh.h
+++ b/drivers/staging/tidspbridge/core/_deh.h
@@ -27,9 +27,6 @@
struct deh_mgr {
struct bridge_dev_context *hbridge_context; /* Bridge context. */
struct ntfy_object *ntfy_obj; /* NTFY object */
-
- /* MMU Fault DPC */
- struct tasklet_struct dpc_tasklet;
};
int mmu_fault_isr(struct iommu *mmu);
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index cd7ff88..e0a801c 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -23,8 +23,7 @@
#include
#include
#include
-#include
-#include
+#include
#include
#include /* for bridge_ioctl_extproc defn */
#include
@@ -380,28 +379,4 @@ extern s32 dsp_debug;
*/
int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val);
-/**
- * user_to_dsp_map() - maps user to dsp virtual address
- * @mmu: Pointer to iommu handle.
- * @uva: Virtual user space address.
- * @da DSP address
- * @size Buffer size to map.
- * @usr_pgsstruct page array pointer where the user pages will be stored
- *
- * This function maps a user space buffer into DSP virtual address.
- *
- */
-u32 user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da, u32 size,
- struct page **usr_pgs);
-
-/**
- * user_to_dsp_unmap() - unmaps DSP virtual buffer.
- * @mmu: Pointer to iommu handle.
- * @da DSP address
- *
- * This function unmaps a user space buffer into DSP virtual address.
- *
- */
-int user_to_dsp_unmap(struct iommu *mmu, u32 da);
-
#endif /* _TIOMAP_ */
diff --git a/drivers/staging/tidspbridge/core/dsp-mmu.c
b/drivers/staging/tidspbridge/core/dsp-mmu.c
new file mode 100644
index 000..3c978f9
--- /dev/null
+++ b/drivers/staging/tidspbridge/core/dsp-mmu.c
@@ -0,0 +1,316 @@
+/*
+ * dsp-mmu.c
+ *
+ * DSP-BIOS Bridge driver support functions for TI OMAP processors.
+ *
+ * DSP iommu.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "_tiomap.h"
+
+#include
+
+#define MMU_CNTL_TWL_EN(1 << 2)
+
+static struct tasklet_struct mmu_tasklet;
+
+#ifdef CONFIG_TIDSPBRIDGE_BACKTRACE
+static void mmu_fault_print_stack(struct bridge_dev_context *dev_context)
+{
+ void *dummy_addr;
+ u32 fa, tmp;
+ struct iotlb_entry e;
+ struct iommu *mmu = dev_context->dsp_mmu;
+ dummy_addr = (void *)__get_free_page(GFP_ATOMIC);
+
+ /*
+* Before acking the MMU fault, let's make sure MMU can only
+* access entry #0. Then add a new entry so that the DSP OS
+* can continue in order to dump the stack.
+*/
+ tmp = iommu_read_reg(mmu, MMU_CNTL);
+ tmp &= ~MMU_CNTL_TWL_EN;
+ iommu_write_reg(mmu, tmp, MMU_CNTL);
+ fa = iom
[PATCHv3 09/11] staging: tidspbridge - remove reserved memory clean up
Now iommv module keeps track of iommu memory used,
we do not need resource cleanup for reserved
memories anymore.
Signed-off-by: Fernando Guzman Lugo
---
.../staging/tidspbridge/include/dspbridge/drv.h|4 --
drivers/staging/tidspbridge/rmgr/drv.c | 11 --
drivers/staging/tidspbridge/rmgr/drv_interface.c |2 -
drivers/staging/tidspbridge/rmgr/proc.c| 36
4 files changed, 0 insertions(+), 53 deletions(-)
diff --git a/drivers/staging/tidspbridge/include/dspbridge/drv.h
b/drivers/staging/tidspbridge/include/dspbridge/drv.h
index c1f363e..427f38b 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/drv.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/drv.h
@@ -165,10 +165,6 @@ struct process_context {
struct list_head dmm_map_list;
spinlock_t dmm_map_lock;
- /* DMM reserved memory resources */
- struct list_head dmm_rsv_list;
- spinlock_t dmm_rsv_lock;
-
/* DSP Heap resources */
struct dspheap_res_object *pdspheap_list;
diff --git a/drivers/staging/tidspbridge/rmgr/drv.c
b/drivers/staging/tidspbridge/rmgr/drv.c
index 0c857b9..91cc168 100644
--- a/drivers/staging/tidspbridge/rmgr/drv.c
+++ b/drivers/staging/tidspbridge/rmgr/drv.c
@@ -146,7 +146,6 @@ int drv_remove_all_dmm_res_elements(void *process_ctxt)
struct process_context *ctxt = (struct process_context *)process_ctxt;
int status = 0;
struct dmm_map_object *temp_map, *map_obj;
- struct dmm_rsv_object *temp_rsv, *rsv_obj;
/* Free DMM mapped memory resources */
list_for_each_entry_safe(map_obj, temp_map, &ctxt->dmm_map_list, link) {
@@ -156,16 +155,6 @@ int drv_remove_all_dmm_res_elements(void *process_ctxt)
pr_err("%s: proc_un_map failed!"
" status = 0x%xn", __func__, status);
}
-
- /* Free DMM reserved memory resources */
- list_for_each_entry_safe(rsv_obj, temp_rsv, &ctxt->dmm_rsv_list, link) {
- status = proc_un_reserve_memory(ctxt->hprocessor, (void *)
- rsv_obj->dsp_reserved_addr,
- ctxt);
- if (status)
- pr_err("%s: proc_un_reserve_memory failed!"
- " status = 0x%xn", __func__, status);
- }
return status;
}
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
b/drivers/staging/tidspbridge/rmgr/drv_interface.c
index 5d0670c..63052b0 100644
--- a/drivers/staging/tidspbridge/rmgr/drv_interface.c
+++ b/drivers/staging/tidspbridge/rmgr/drv_interface.c
@@ -509,8 +509,6 @@ static int bridge_open(struct inode *ip, struct file *filp)
pr_ctxt->res_state = PROC_RES_ALLOCATED;
spin_lock_init(&pr_ctxt->dmm_map_lock);
INIT_LIST_HEAD(&pr_ctxt->dmm_map_list);
- spin_lock_init(&pr_ctxt->dmm_rsv_lock);
- INIT_LIST_HEAD(&pr_ctxt->dmm_rsv_list);
pr_ctxt->node_id = kzalloc(sizeof(struct idr), GFP_KERNEL);
if (pr_ctxt->node_id) {
diff --git a/drivers/staging/tidspbridge/rmgr/proc.c
b/drivers/staging/tidspbridge/rmgr/proc.c
index 59c946b..e5fec57 100644
--- a/drivers/staging/tidspbridge/rmgr/proc.c
+++ b/drivers/staging/tidspbridge/rmgr/proc.c
@@ -1515,7 +1515,6 @@ int proc_reserve_memory(void *hprocessor, u32 ul_size,
struct dmm_object *dmm_mgr;
int status = 0;
struct proc_object *p_proc_object = (struct proc_object *)hprocessor;
- struct dmm_rsv_object *rsv_obj;
if (!p_proc_object) {
status = -EFAULT;
@@ -1529,22 +1528,6 @@ int proc_reserve_memory(void *hprocessor, u32 ul_size,
}
status = dmm_reserve_memory(dmm_mgr, ul_size, (u32 *) pp_rsv_addr);
- if (status != 0)
- goto func_end;
-
- /*
-* A successful reserve should be followed by insertion of rsv_obj
-* into dmm_rsv_list, so that reserved memory resource tracking
-* remains uptodate
-*/
- rsv_obj = kmalloc(sizeof(struct dmm_rsv_object), GFP_KERNEL);
- if (rsv_obj) {
- rsv_obj->dsp_reserved_addr = (u32) *pp_rsv_addr;
- spin_lock(&pr_ctxt->dmm_rsv_lock);
- list_add(&rsv_obj->link, &pr_ctxt->dmm_rsv_list);
- spin_unlock(&pr_ctxt->dmm_rsv_lock);
- }
-
func_end:
dev_dbg(bridge, "%s: hprocessor: 0x%p ul_size: 0x%x pp_rsv_addr: 0x%p "
"status 0x%x\n", __func__, hprocessor,
@@ -1756,7 +1739,6 @@ int proc_un_reserve_memory(void *hprocessor, void
*prsv_addr,
struct dmm_object *dmm_mgr;
int status = 0;
struct proc_object *p_proc_object = (struct proc_object *)hprocessor;
- struct dmm_rsv_object *rsv_obj;
if (!p_proc_object) {
status = -EFAULT;
@@ -1770,24 +1752,6 @@ int proc_un_reserve_me
[PATCHv3 01/11] staging: tidspbridge: replace iommu custom for opensource implementation
Now the tidspbridge uses the API's from
iovmm module.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_tiomap.h |4 +-
drivers/staging/tidspbridge/core/io_sm.c | 121 ++
drivers/staging/tidspbridge/core/tiomap3430.c | 522
drivers/staging/tidspbridge/core/ue_deh.c |8 -
.../tidspbridge/include/dspbridge/dspdefs.h|2 +-
drivers/staging/tidspbridge/rmgr/proc.c|2 +-
6 files changed, 138 insertions(+), 521 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index 1c1f157..a42c393 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include /* for bridge_ioctl_extproc defn */
@@ -328,7 +330,7 @@ struct bridge_dev_context {
u32 dw_internal_size; /* Internal memory size */
struct omap_mbox *mbox; /* Mail box handle */
-
+ struct iommu *dsp_mmu; /* iommu for iva2 handler */
struct cfg_hostres *resources; /* Host Resources */
/*
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index 5718645..842b8db 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -291,6 +291,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct cod_manager *cod_man;
struct chnl_mgr *hchnl_mgr;
struct msg_mgr *hmsg_mgr;
+ struct iommu *mmu;
u32 ul_shm_base;
u32 ul_shm_base_offset;
u32 ul_shm_limit;
@@ -313,7 +314,6 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct bridge_ioctl_extproc ae_proc[BRDIOCTL_NUMOFMMUTLB];
struct cfg_hostres *host_res;
struct bridge_dev_context *pbridge_context;
- u32 map_attrs;
u32 shm0_end;
u32 ul_dyn_ext_base;
u32 ul_seg1_size = 0;
@@ -337,6 +337,20 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
status = -EFAULT;
goto func_end;
}
+ mmu = pbridge_context->dsp_mmu;
+
+ if (mmu)
+ iommu_put(mmu);
+ mmu = iommu_get("iva2");
+
+ if (IS_ERR_OR_NULL(mmu)) {
+ dev_err(bridge, "iommu_get failed!\n");
+ pbridge_context->dsp_mmu = NULL;
+ status = -EFAULT;
+ goto func_end;
+ }
+ pbridge_context->dsp_mmu = mmu;
+
status = dev_get_cod_mgr(hio_mgr->hdev_obj, &cod_man);
if (!cod_man) {
status = -EFAULT;
@@ -476,55 +490,16 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
gpp_va_curr = ul_gpp_va;
num_bytes = ul_seg1_size;
- /*
-* Try to fit into TLB entries. If not possible, push them to page
-* tables. It is quite possible that if sections are not on
-* bigger page boundary, we may end up making several small pages.
-* So, push them onto page tables, if that is the case.
-*/
- map_attrs = 0x;
- map_attrs = DSP_MAPLITTLEENDIAN;
- map_attrs |= DSP_MAPPHYSICALADDR;
- map_attrs |= DSP_MAPELEMSIZE32;
- map_attrs |= DSP_MAPDONOTLOCK;
-
- while (num_bytes) {
- /*
-* To find the max. page size with which both PA & VA are
-* aligned.
-*/
- all_bits = pa_curr | va_curr;
- dev_dbg(bridge, "all_bits %x, pa_curr %x, va_curr %x, "
- "num_bytes %x\n", all_bits, pa_curr, va_curr,
- num_bytes);
- for (i = 0; i < 4; i++) {
- if ((num_bytes >= page_size[i]) && ((all_bits &
-(page_size[i] -
- 1)) == 0)) {
- status =
- hio_mgr->intf_fxns->
- pfn_brd_mem_map(hio_mgr->hbridge_context,
- pa_curr, va_curr,
- page_size[i], map_attrs,
- NULL);
- if (status)
- goto func_end;
- pa_curr += page_size[i];
- va_curr += page_size[i];
- gpp_va_curr += page_size[i];
- num_bytes -= page_size[i];
- /*
-* Don't try smaller sizes. Hopefully we have
-* reached an address aligned to a bigger page
-* size.
-
[PATCHv3 11/11] staging: tidspbridge - remove dmm custom module
Dmm custom module is not needed anymore.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/Makefile |2 +-
drivers/staging/tidspbridge/core/tiomap3430.c |1 -
.../staging/tidspbridge/include/dspbridge/dev.h| 24 -
.../staging/tidspbridge/include/dspbridge/dmm.h| 75 ---
.../staging/tidspbridge/include/dspbridge/drv.h|6 -
drivers/staging/tidspbridge/pmgr/dev.c | 61 +---
drivers/staging/tidspbridge/pmgr/dmm.c | 533
drivers/staging/tidspbridge/rmgr/node.c| 28 +-
drivers/staging/tidspbridge/rmgr/proc.c| 23 -
9 files changed, 6 insertions(+), 747 deletions(-)
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dmm.h
delete mode 100644 drivers/staging/tidspbridge/pmgr/dmm.c
diff --git a/drivers/staging/tidspbridge/Makefile
b/drivers/staging/tidspbridge/Makefile
index bd36651..7c122fa 100644
--- a/drivers/staging/tidspbridge/Makefile
+++ b/drivers/staging/tidspbridge/Makefile
@@ -5,7 +5,7 @@ libcore = core/chnl_sm.o core/msg_sm.o core/io_sm.o
core/tiomap3430.o \
core/tiomap3430_pwr.o core/tiomap_io.o core/dsp-mmu.o \
core/ue_deh.o core/wdt.o core/dsp-clock.o core/sync.o
libpmgr = pmgr/chnl.o pmgr/io.o pmgr/msg.o pmgr/cod.o pmgr/dev.o pmgr/dspapi.o
\
- pmgr/dmm.o pmgr/cmm.o pmgr/dbll.o
+ pmgr/cmm.o pmgr/dbll.o
librmgr = rmgr/dbdcd.o rmgr/disp.o rmgr/drv.o rmgr/mgr.o rmgr/node.o \
rmgr/proc.o rmgr/pwr.o rmgr/rmm.o rmgr/strm.o rmgr/dspdrv.o \
rmgr/nldr.o rmgr/drv_interface.o
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index a95ff2f..f22bc12 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -47,7 +47,6 @@
/* --- Platform Manager */
#include
#include
-#include
#include
/* --- Local */
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dev.h
b/drivers/staging/tidspbridge/include/dspbridge/dev.h
index 357458f..9bdd48f 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dev.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dev.h
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
/* --- This */
@@ -234,29 +233,6 @@ extern int dev_get_cmm_mgr(struct dev_object *hdev_obj,
struct cmm_object **mgr);
/*
- * dev_get_dmm_mgr
- * Purpose:
- * Retrieve the handle to the dynamic memory manager created for this
- * device.
- * Parameters:
- * hdev_obj: Handle to device object created with
- * dev_create_device().
- * *mgr: Ptr to location to store handle.
- * Returns:
- * 0:Success.
- * -EFAULT:Invalid hdev_obj.
- * Requires:
- * mgr != NULL.
- * DEV Initialized.
- * Ensures:
- * 0:*mgr contains a handle to a channel manager object,
- * or NULL.
- * else: *mgr is NULL.
- */
-extern int dev_get_dmm_mgr(struct dev_object *hdev_obj,
- struct dmm_object **mgr);
-
-/*
* dev_get_cod_mgr
* Purpose:
* Retrieve the COD manager create for this device.
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dmm.h
b/drivers/staging/tidspbridge/include/dspbridge/dmm.h
deleted file mode 100644
index 6c58335..000
--- a/drivers/staging/tidspbridge/include/dspbridge/dmm.h
+++ /dev/null
@@ -1,75 +0,0 @@
-/*
- * dmm.h
- *
- * DSP-BIOS Bridge driver support functions for TI OMAP processors.
- *
- * The Dynamic Memory Mapping(DMM) module manages the DSP Virtual address
- * space that can be directly mapped to any MPU buffer or memory region.
- *
- * Copyright (C) 2005-2006 Texas Instruments, Inc.
- *
- * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
- * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- */
-
-#ifndef DMM_
-#define DMM_
-
-#include
-
-struct dmm_object;
-
-/* DMM attributes used in dmm_create() */
-struct dmm_mgrattrs {
- u32 reserved;
-};
-
-#define DMMPOOLSIZE 0x400
-
-/*
- * dmm_get_handle
- * Purpose:
- * Return the dynamic memory manager object for this device.
- * This is typically called from the client process.
- */
-
-extern int dmm_get_handle(void *hprocessor,
-struct dmm_object **dmm_manager);
-
-extern int dmm_reserve_memory(struct dmm_object *dmm_mgr,
-
[PATCHv3 06/11] staging: tidspbridge - remove hw directory
hw directory was only being used for custom iommu implementation APIs, so after the iommu module migration this directory is not needed anymore. Signed-off-by: Fernando Guzman Lugo --- drivers/staging/tidspbridge/Makefile |3 +- drivers/staging/tidspbridge/core/_tiomap.h |1 - drivers/staging/tidspbridge/core/io_sm.c |4 - drivers/staging/tidspbridge/core/tiomap3430.c |4 - drivers/staging/tidspbridge/core/tiomap3430_pwr.c |4 - drivers/staging/tidspbridge/core/tiomap_io.c |2 +- drivers/staging/tidspbridge/hw/EasiGlobal.h| 41 -- drivers/staging/tidspbridge/hw/MMUAccInt.h | 76 --- drivers/staging/tidspbridge/hw/MMURegAcM.h | 225 drivers/staging/tidspbridge/hw/hw_defs.h | 58 -- drivers/staging/tidspbridge/hw/hw_mmu.c| 562 drivers/staging/tidspbridge/hw/hw_mmu.h| 163 -- .../tidspbridge/include/dspbridge/dspioctl.h |7 - 13 files changed, 2 insertions(+), 1148 deletions(-) delete mode 100644 drivers/staging/tidspbridge/hw/EasiGlobal.h delete mode 100644 drivers/staging/tidspbridge/hw/MMUAccInt.h delete mode 100644 drivers/staging/tidspbridge/hw/MMURegAcM.h delete mode 100644 drivers/staging/tidspbridge/hw/hw_defs.h delete mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.c delete mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.h diff --git a/drivers/staging/tidspbridge/Makefile b/drivers/staging/tidspbridge/Makefile index 8082d5c..e09547d 100644 --- a/drivers/staging/tidspbridge/Makefile +++ b/drivers/staging/tidspbridge/Makefile @@ -11,10 +11,9 @@ librmgr = rmgr/dbdcd.o rmgr/disp.o rmgr/drv.o rmgr/mgr.o rmgr/node.o \ rmgr/nldr.o rmgr/drv_interface.o libdload = dynload/cload.o dynload/getsection.o dynload/reloc.o \ dynload/tramp.o -libhw = hw/hw_mmu.o bridgedriver-objs = $(libgen) $(libservices) $(libcore) $(libpmgr) $(librmgr) \ - $(libdload) $(libhw) + $(libdload) #Machine dependent ccflags-y += -D_TI_ -D_DB_TIOMAP -DTMS32060 \ diff --git a/drivers/staging/tidspbridge/core/_tiomap.h b/drivers/staging/tidspbridge/core/_tiomap.h index 394a64a..cd7ff88 100644 --- a/drivers/staging/tidspbridge/core/_tiomap.h +++ b/drivers/staging/tidspbridge/core/_tiomap.h @@ -26,7 +26,6 @@ #include #include #include -#include #include /* for bridge_ioctl_extproc defn */ #include #include diff --git a/drivers/staging/tidspbridge/core/io_sm.c b/drivers/staging/tidspbridge/core/io_sm.c index 56856ad..194bada 100644 --- a/drivers/staging/tidspbridge/core/io_sm.c +++ b/drivers/staging/tidspbridge/core/io_sm.c @@ -39,10 +39,6 @@ #include #include -/* Hardware Abstraction Layer */ -#include -#include - /* Bridge Driver */ #include #include diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c index 86f..8496c83 100644 --- a/drivers/staging/tidspbridge/core/tiomap3430.c +++ b/drivers/staging/tidspbridge/core/tiomap3430.c @@ -35,10 +35,6 @@ #include #include -/* Hardware Abstraction Layer */ -#include -#include - /* --- Link Driver */ #include #include diff --git a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c index fb9026e..b57a9fd 100644 --- a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c +++ b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c @@ -31,10 +31,6 @@ #include #include -/* Hardware Abstraction Layer */ -#include -#include - #include /* --- Bridge Driver */ diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c b/drivers/staging/tidspbridge/core/tiomap_io.c index 5ba6795..b526532 100644 --- a/drivers/staging/tidspbridge/core/tiomap_io.c +++ b/drivers/staging/tidspbridge/core/tiomap_io.c @@ -143,7 +143,7 @@ int read_ext_dsp_data(struct bridge_dev_context *dev_ctxt, ul_shm_base_virt - ul_tlb_base_virt; ul_shm_offset_virt += PG_ALIGN_HIGH(ul_ext_end - ul_dyn_ext_base + - 1, HW_PAGE_SIZE64KB); + 1, PAGE_SIZE * 16); dw_ext_prog_virt_mem -= ul_shm_offset_virt; dw_ext_prog_virt_mem += (ul_ext_base - ul_dyn_ext_base); diff --git a/drivers/staging/tidspbridge/hw/EasiGlobal.h b/drivers/staging/tidspbridge/hw/EasiGlobal.h deleted file mode 100644 index e48d7f6..000 --- a/drivers/staging/tidspbridge/hw/EasiGlobal.h +++ /dev/null @@ -1,41 +0,0 @@ -/* - * EasiGlobal.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. -
RE: [PATCHv2 01/11] staging: tidspbridge: replace iommu custom for opensource implementation
> -Original Message- > From: Greg KH [mailto:g...@kroah.com] > Sent: Tuesday, October 05, 2010 10:56 AM > To: Guzman Lugo, Fernando > Cc: gre...@suse.de; felipe.contre...@nokia.com; > ameya.pala...@nokia.com; Menon, Nishanth; > hiroshi.d...@nokia.com; o...@wizery.com; > linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; > linux-omap@vger.kernel.org > Subject: Re: [PATCHv2 01/11] staging: tidspbridge: replace > iommu custom for opensource implementation > > On Thu, Sep 30, 2010 at 09:12:48PM -0500, Fernando Guzman Lugo wrote: > > Now the tidspbridge uses the API's from iovmm module. > > > > Signed-off-by: Fernando Guzman Lugo > > This patch applied, but number 2 and others didn't. Care to > respin those against the new linux-next tree and resend? Done, you should not have any problem now. Regards, Fernando. > > thanks, > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 10/11] staging: tidspbridge - deprecate reserve/unreserve_memory funtions
Now what iommu memory usage is kept track by iommu module
the functions reserve/unreserve_memory are not needed anymore.
Signed-off-by: Fernando Guzman Lugo
---
.../staging/tidspbridge/include/dspbridge/proc.h | 46
drivers/staging/tidspbridge/pmgr/dspapi.c | 34 +-
drivers/staging/tidspbridge/rmgr/node.c| 20 +
drivers/staging/tidspbridge/rmgr/proc.c| 114 ++--
4 files changed, 17 insertions(+), 197 deletions(-)
diff --git a/drivers/staging/tidspbridge/include/dspbridge/proc.h
b/drivers/staging/tidspbridge/include/dspbridge/proc.h
index 5e09fd1..2d12aab 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/proc.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/proc.h
@@ -551,29 +551,6 @@ extern int proc_map(void *hprocessor,
struct process_context *pr_ctxt);
/*
- * proc_reserve_memory
- * Purpose:
- * Reserve a virtually contiguous region of DSP address space.
- * Parameters:
- * hprocessor : The processor handle.
- * ul_size : Size of the address space to reserve.
- * pp_rsv_addr : Ptr to DSP side reserved u8 address.
- * Returns:
- * 0 : Success.
- * -EFAULT : Invalid processor handle.
- * -EPERM : General failure.
- * -ENOMEM : Cannot reserve chunk of this size.
- * Requires:
- * pp_rsv_addr is not NULL
- * PROC Initialized.
- * Ensures:
- * Details:
- */
-extern int proc_reserve_memory(void *hprocessor,
- u32 ul_size, void **pp_rsv_addr,
- struct process_context *pr_ctxt);
-
-/*
* proc_un_map
* Purpose:
* Removes a MPU buffer mapping from the DSP address space.
@@ -595,27 +572,4 @@ extern int proc_reserve_memory(void *hprocessor,
extern int proc_un_map(void *hprocessor, void *map_addr,
struct process_context *pr_ctxt);
-/*
- * proc_un_reserve_memory
- * Purpose:
- * Frees a previously reserved region of DSP address space.
- * Parameters:
- * hprocessor : The processor handle.
- * prsv_addr : Ptr to DSP side reservedBYTE address.
- * Returns:
- * 0 : Success.
- * -EFAULT : Invalid processor handle.
- * -EPERM : General failure.
- * -ENOENT : Cannot find a reserved region starting with this
- * : address.
- * Requires:
- * prsv_addr is not NULL
- * PROC Initialized.
- * Ensures:
- * Details:
- */
-extern int proc_un_reserve_memory(void *hprocessor,
-void *prsv_addr,
-struct process_context *pr_ctxt);
-
#endif /* PROC_ */
diff --git a/drivers/staging/tidspbridge/pmgr/dspapi.c
b/drivers/staging/tidspbridge/pmgr/dspapi.c
index faf8304..0187c47 100644
--- a/drivers/staging/tidspbridge/pmgr/dspapi.c
+++ b/drivers/staging/tidspbridge/pmgr/dspapi.c
@@ -989,27 +989,10 @@ u32 procwrap_register_notify(union trapped_args *args,
void *pr_ctxt)
/*
* procwrap_reserve_memory
*/
-u32 procwrap_reserve_memory(union trapped_args *args, void *pr_ctxt)
+u32 __deprecated procwrap_reserve_memory(union trapped_args *args,
+ void *pr_ctxt)
{
- int status;
- void *prsv_addr;
- void *hprocessor = ((struct process_context *)pr_ctxt)->hprocessor;
-
- if ((args->args_proc_rsvmem.ul_size <= 0) ||
- (args->args_proc_rsvmem.ul_size & (PG_SIZE4K - 1)) != 0)
- return -EINVAL;
-
- status = proc_reserve_memory(hprocessor,
-args->args_proc_rsvmem.ul_size, &prsv_addr,
-pr_ctxt);
- if (!status) {
- if (put_user(prsv_addr, args->args_proc_rsvmem.pp_rsv_addr)) {
- status = -EINVAL;
- proc_un_reserve_memory(args->args_proc_rsvmem.
- hprocessor, prsv_addr, pr_ctxt);
- }
- }
- return status;
+ return 0;
}
/*
@@ -1038,15 +1021,10 @@ u32 procwrap_un_map(union trapped_args *args, void
*pr_ctxt)
/*
* procwrap_un_reserve_memory
*/
-u32 procwrap_un_reserve_memory(union trapped_args *args, void *pr_ctxt)
+u32 __deprecated procwrap_un_reserve_memory(union trapped_args *args,
+ void *pr_ctxt)
{
- int status;
- void *hprocessor = ((struct process_context *)pr_ctxt)->hprocessor;
-
- status = proc_un_reserve_memory(hprocessor,
- args->args_proc_unrsvmem.prsv_addr,
- pr_ctxt);
- return status;
+ return 0;
}
/*
diff --git a/drivers/staging/tidspbri
[PATCHv3 04/11] staging: tidspbridge - remove custom mmu code from tiomap3430.c
This patch removes all the custom mmu code remaining in
tiomap3430.c which is not needed anymore.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_tiomap.h|2 -
drivers/staging/tidspbridge/core/tiomap3430.c | 425 -
2 files changed, 0 insertions(+), 427 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index 8777492..394a64a 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -330,7 +330,6 @@ struct bridge_dev_context {
*/
u32 dw_dsp_ext_base_addr; /* See the comment above */
u32 dw_api_reg_base;/* API mem map'd registers */
- void __iomem *dw_dsp_mmu_base; /* DSP MMU Mapped registers */
u32 dw_api_clk_base;/* CLK Registers */
u32 dw_dsp_clk_m2_base; /* DSP Clock Module m2 */
u32 dw_public_rhea; /* Pub Rhea */
@@ -356,7 +355,6 @@ struct bridge_dev_context {
/* TC Settings */
bool tc_word_swap_on; /* Traffic Controller Word Swap */
- struct pg_table_attrs *pt_attrs;
u32 dsp_per_clks;
};
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 0e5b805..e5f67be 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -104,56 +104,8 @@ static int bridge_dev_create(struct bridge_dev_context
static int bridge_dev_ctrl(struct bridge_dev_context *dev_context,
u32 dw_cmd, void *pargs);
static int bridge_dev_destroy(struct bridge_dev_context *dev_ctxt);
-static int pte_update(struct bridge_dev_context *dev_ctxt, u32 pa,
-u32 va, u32 size,
-struct hw_mmu_map_attrs_t *map_attrs);
-static int pte_set(struct pg_table_attrs *pt, u32 pa, u32 va,
- u32 size, struct hw_mmu_map_attrs_t *attrs);
-static int mem_map_vmalloc(struct bridge_dev_context *dev_context,
- u32 ul_mpu_addr, u32 virt_addr,
- u32 ul_num_bytes,
- struct hw_mmu_map_attrs_t *hw_attrs);
-
bool wait_for_start(struct bridge_dev_context *dev_context, u32 dw_sync_addr);
-/* --- Globals */
-
-/* Attributes of L2 page tables for DSP MMU */
-struct page_info {
- u32 num_entries;/* Number of valid PTEs in the L2 PT */
-};
-
-/* Attributes used to manage the DSP MMU page tables */
-struct pg_table_attrs {
- spinlock_t pg_lock; /* Critical section object handle */
-
- u32 l1_base_pa; /* Physical address of the L1 PT */
- u32 l1_base_va; /* Virtual address of the L1 PT */
- u32 l1_size;/* Size of the L1 PT */
- u32 l1_tbl_alloc_pa;
- /* Physical address of Allocated mem for L1 table. May not be aligned */
- u32 l1_tbl_alloc_va;
- /* Virtual address of Allocated mem for L1 table. May not be aligned */
- u32 l1_tbl_alloc_sz;
- /* Size of consistent memory allocated for L1 table.
-* May not be aligned */
-
- u32 l2_base_pa; /* Physical address of the L2 PT */
- u32 l2_base_va; /* Virtual address of the L2 PT */
- u32 l2_size;/* Size of the L2 PT */
- u32 l2_tbl_alloc_pa;
- /* Physical address of Allocated mem for L2 table. May not be aligned */
- u32 l2_tbl_alloc_va;
- /* Virtual address of Allocated mem for L2 table. May not be aligned */
- u32 l2_tbl_alloc_sz;
- /* Size of consistent memory allocated for L2 table.
-* May not be aligned */
-
- u32 l2_num_pages; /* Number of allocated L2 PT */
- /* Array [l2_num_pages] of L2 PT info structs */
- struct page_info *pg_info;
-};
-
/*
* This Bridge driver's function interface table.
*/
@@ -202,27 +154,6 @@ static struct bridge_drv_interface drv_interface_fxns = {
bridge_msg_set_queue_id,
};
-static inline void flush_all(struct bridge_dev_context *dev_context)
-{
- if (dev_context->dw_brd_state == BRD_DSP_HIBERNATION ||
- dev_context->dw_brd_state == BRD_HIBERNATION)
- wake_dsp(dev_context, NULL);
-
- hw_mmu_tlb_flush_all(dev_context->dw_dsp_mmu_base);
-}
-
-static void bad_page_dump(u32 pa, struct page *pg)
-{
- pr_emerg("DSPBRIDGE: MAP function: COUNT 0 FOR PA 0x%x\n", pa);
- pr_emerg("Bad page state in process '%s'\n"
-"page:%p flags:0x%0*lx mapping:%p mapcount:%d count:%d\n"
-"Backtrace:\n",
-current->comm, pg, (int)(2 * sizeof(unsigned long)),
-(unsigned long)pg->flags, pg->mapping,
-page_mapcount(pg), page_count(pg));
- dump_stack();
-}
-
/*
* bridge_drv_entry
* purpose:
@@ -628,
[PATCHv3 03/11] staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name
Now these functions only map user space addresses to dsp virtual
addresses, so now the functions have a more meaningful name.
Also now user_to_dsp_map returns the mapped address.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_tiomap.h | 24 +++
drivers/staging/tidspbridge/core/tiomap3430.c | 153 ++--
.../tidspbridge/include/dspbridge/dspdefs.h| 44 --
drivers/staging/tidspbridge/pmgr/dev.c |2 -
drivers/staging/tidspbridge/rmgr/proc.c| 34 +++--
5 files changed, 116 insertions(+), 141 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index c1bf95d..8777492 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -383,4 +383,28 @@ extern s32 dsp_debug;
*/
int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val);
+/**
+ * user_to_dsp_map() - maps user to dsp virtual address
+ * @mmu: Pointer to iommu handle.
+ * @uva: Virtual user space address.
+ * @da DSP address
+ * @size Buffer size to map.
+ * @usr_pgsstruct page array pointer where the user pages will be stored
+ *
+ * This function maps a user space buffer into DSP virtual address.
+ *
+ */
+u32 user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da, u32 size,
+ struct page **usr_pgs);
+
+/**
+ * user_to_dsp_unmap() - unmaps DSP virtual buffer.
+ * @mmu: Pointer to iommu handle.
+ * @da DSP address
+ *
+ * This function unmaps a user space buffer into DSP virtual address.
+ *
+ */
+int user_to_dsp_unmap(struct iommu *mmu, u32 da);
+
#endif /* _TIOMAP_ */
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 3749cd5..0e5b805 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -97,12 +97,6 @@ static int bridge_brd_mem_copy(struct bridge_dev_context
*dev_ctxt,
static int bridge_brd_mem_write(struct bridge_dev_context *dev_ctxt,
u8 *host_buff, u32 dsp_addr,
u32 ul_num_bytes, u32 mem_type);
-static int bridge_brd_mem_map(struct bridge_dev_context *dev_ctxt,
- u32 ul_mpu_addr, u32 virt_addr,
- u32 ul_num_bytes, u32 ul_map_attr,
- struct page **mapped_pages);
-static int bridge_brd_mem_un_map(struct bridge_dev_context *dev_ctxt,
-u32 da);
static int bridge_dev_create(struct bridge_dev_context
**dev_cntxt,
struct dev_object *hdev_obj,
@@ -110,9 +104,6 @@ static int bridge_dev_create(struct bridge_dev_context
static int bridge_dev_ctrl(struct bridge_dev_context *dev_context,
u32 dw_cmd, void *pargs);
static int bridge_dev_destroy(struct bridge_dev_context *dev_ctxt);
-static int get_io_pages(struct mm_struct *mm, u32 uva, unsigned pages,
- struct page **usr_pgs);
-static u32 user_va2_pa(struct mm_struct *mm, u32 address);
static int pte_update(struct bridge_dev_context *dev_ctxt, u32 pa,
u32 va, u32 size,
struct hw_mmu_map_attrs_t *map_attrs);
@@ -182,8 +173,6 @@ static struct bridge_drv_interface drv_interface_fxns = {
bridge_brd_set_state,
bridge_brd_mem_copy,
bridge_brd_mem_write,
- bridge_brd_mem_map,
- bridge_brd_mem_un_map,
/* The following CHNL functions are provided by chnl_io.lib: */
bridge_chnl_create,
bridge_chnl_destroy,
@@ -1154,22 +1143,77 @@ static int bridge_brd_mem_write(struct
bridge_dev_context *dev_ctxt,
}
/*
- * bridge_brd_mem_map
- * This function maps MPU buffer to the DSP address space. It performs
- * linear to physical address translation if required. It translates each
- * page since linear addresses can be physically non-contiguous
- * All address & size arguments are assumed to be page aligned (in proc.c)
+ * user_va2_pa
+ * Purpose:
+ * This function walks through the page tables to convert a userland
+ * virtual address to physical address
+ */
+static u32 user_va2_pa(struct mm_struct *mm, u32 address)
+{
+ pgd_t *pgd;
+ pmd_t *pmd;
+ pte_t *ptep, pte;
+
+ pgd = pgd_offset(mm, address);
+ if (!(pgd_none(*pgd) || pgd_bad(*pgd))) {
+ pmd = pmd_offset(pgd, address);
+ if (!(pmd_none(*pmd) || pmd_bad(*pmd))) {
+ ptep = pte_offset_map(pmd, address);
+ if (ptep) {
+ pte = *ptep;
+
[PATCHv3 08/11] staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct
We don't need to map iva2 iommu register base address
anymore.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/tiomap3430.c |3 ---
drivers/staging/tidspbridge/core/tiomap_io.c |3 +--
.../tidspbridge/include/dspbridge/cfgdefs.h|1 -
drivers/staging/tidspbridge/rmgr/drv.c |4
4 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 4927ec3..a95ff2f 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -833,8 +833,6 @@ static int bridge_dev_destroy(struct bridge_dev_context
*dev_ctxt)
iounmap((void *)host_res->dw_mem_base[3]);
if (host_res->dw_mem_base[4])
iounmap((void *)host_res->dw_mem_base[4]);
- if (host_res->dw_dmmu_base)
- iounmap(host_res->dw_dmmu_base);
if (host_res->dw_per_base)
iounmap(host_res->dw_per_base);
if (host_res->dw_per_pm_base)
@@ -848,7 +846,6 @@ static int bridge_dev_destroy(struct bridge_dev_context
*dev_ctxt)
host_res->dw_mem_base[2] = (u32) NULL;
host_res->dw_mem_base[3] = (u32) NULL;
host_res->dw_mem_base[4] = (u32) NULL;
- host_res->dw_dmmu_base = NULL;
host_res->dw_sys_ctrl_base = NULL;
kfree(host_res);
diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c
b/drivers/staging/tidspbridge/core/tiomap_io.c
index b526532..66dbf02 100644
--- a/drivers/staging/tidspbridge/core/tiomap_io.c
+++ b/drivers/staging/tidspbridge/core/tiomap_io.c
@@ -393,7 +393,6 @@ int sm_interrupt_dsp(struct bridge_dev_context
*dev_context, u16 mb_val)
omap_dspbridge_dev->dev.platform_data;
struct cfg_hostres *resources = dev_context->resources;
int status = 0;
- u32 temp;
if (!dev_context->mbox)
return 0;
@@ -437,7 +436,7 @@ int sm_interrupt_dsp(struct bridge_dev_context
*dev_context, u16 mb_val)
omap_mbox_restore_ctx(dev_context->mbox);
/* Access MMU SYS CONFIG register to generate a short wakeup */
- temp = readl(resources->dw_dmmu_base + 0x10);
+ iommu_read_reg(dev_context->dsp_mmu, MMU_SYSCONFIG);
dev_context->dw_brd_state = BRD_RUNNING;
} else if (dev_context->dw_brd_state == BRD_RETENTION) {
diff --git a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
index 38122db..dfb55cc 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
@@ -68,7 +68,6 @@ struct cfg_hostres {
void __iomem *dw_per_base;
u32 dw_per_pm_base;
u32 dw_core_pm_base;
- void __iomem *dw_dmmu_base;
void __iomem *dw_sys_ctrl_base;
};
diff --git a/drivers/staging/tidspbridge/rmgr/drv.c
b/drivers/staging/tidspbridge/rmgr/drv.c
index 81b1b90..0c857b9 100644
--- a/drivers/staging/tidspbridge/rmgr/drv.c
+++ b/drivers/staging/tidspbridge/rmgr/drv.c
@@ -743,7 +743,6 @@ static int request_bridge_resources(struct cfg_hostres *res)
host_res->dw_sys_ctrl_base = ioremap(OMAP_SYSC_BASE, OMAP_SYSC_SIZE);
dev_dbg(bridge, "dw_mem_base[0] 0x%x\n", host_res->dw_mem_base[0]);
dev_dbg(bridge, "dw_mem_base[3] 0x%x\n", host_res->dw_mem_base[3]);
- dev_dbg(bridge, "dw_dmmu_base %p\n", host_res->dw_dmmu_base);
/* for 24xx base port is not mapping the mamory for DSP
* internal memory TODO Do a ioremap here */
@@ -797,8 +796,6 @@ int drv_request_bridge_res_dsp(void **phost_resources)
OMAP_PER_PRM_SIZE);
host_res->dw_core_pm_base = (u32) ioremap(OMAP_CORE_PRM_BASE,
OMAP_CORE_PRM_SIZE);
- host_res->dw_dmmu_base = ioremap(OMAP_DMMU_BASE,
-OMAP_DMMU_SIZE);
dev_dbg(bridge, "dw_mem_base[0] 0x%x\n",
host_res->dw_mem_base[0]);
@@ -810,7 +807,6 @@ int drv_request_bridge_res_dsp(void **phost_resources)
host_res->dw_mem_base[3]);
dev_dbg(bridge, "dw_mem_base[4] 0x%x\n",
host_res->dw_mem_base[4]);
- dev_dbg(bridge, "dw_dmmu_base %p\n", host_res->dw_dmmu_base);
shm_size = drv_datap->shm_size;
if (shm_size >= 0x1) {
--
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
RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Wednesday, October 06, 2010 1:19 AM
> To: Nayak, Rajendra
> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren;
> linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> Govindraj
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog,
> UART, i2c
>
> "Nayak, Rajendra" writes:
>
> >> -Original Message-
> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> >> Sent: Tuesday, October 05, 2010 10:34 PM
> >> To: Nayak, Rajendra
> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren;
> >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> >> Govindraj
> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions:
> >> watchdog, UART, i2c
> >>
> >> "Nayak, Rajendra" writes:
> >>
> >> > ..
> >> >
> >> >> >
> >> >> > Below is an untested patch to provide some mechanism to deal with
> >> >> > this --
> >> >> > I'd appreciate everyone's comments on this, particularly the comments
> >> >> > in
> >> >> > the patch code on how to deal with this problem.
> >> >>
> >> >> Hi Paul,
> >> >>
> >> >> I'll test this patch to see if it solves the issue seen with i2c on
> >> >> n800.
> >> >
> >> > Hi Paul, Benoit, Kevin,
> >> >
> >> > So looks like the issue with i2c on n800 isn't really because of
> >> > additional
> >> > delay needed after a clock enable, but related to the omap_readl/writel's
> >> > done on the 16bit i2c registers as I was suspecting earlier.
> >> >
> >> > The below patch fixes the n800 issue for me. My mailer might mess up the
> >> > alignment
> >> > hence attaching it too.
> >> >
> >> > From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
> >> > From: Rajendra Nayak
> >> > Date: Tue, 5 Oct 2010 16:36:30 +0530
> >> > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers
> >> >
> >> > Some modules which have 16bit registers can cause imprecise
> >> > aborts if a __raw_readl/writel is used to read/write 32 bits.
> >> >
> >> > Add an additional flag to identify modules which have such
> >> > hard requirement, and handle it in the hwmod framework.
> >> >
> >> > Signed-off-by: Rajendra Nayak
> >>
> >> Can you also send a corresponding patch to the i2c hwmod data.
> > Hi Kevin,
> >
> > Ok, I'll repost the original patch which adds the omap2 hwmod data with
> > these flags added for omap2420. Does that sound fine?
>
> Since I've alrady done some manual merge conflicts here, you can just
> post an additional patch and I will fold it in.
Ok, so here's the patch
--
>From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak
Date: Wed, 6 Oct 2010 01:49:32 +0530
Subject: [PATCH] OMAP2: hmwod: Fix impresice aborts seen on n800/n810
I2C module on OMAP2420 has 16bit registers and causes imprecise
aborts if 32bits are read/wriitten into.
Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this
hard requirement so that __raw_writew/readw is used to read /write
the mdoule registers.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 ++
1 files changed, 2 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 25d6da2..c588854 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -263,6 +263,7 @@ static struct omap_hwmod omap2420_i2c1_hwmod = {
.class = &i2c_class,
.dev_attr = &i2c_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_16BIT_REG,
};
/* I2C2 */
@@ -301,6 +302,7 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.class = &i2c_class,
.dev_attr = &i2c_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_16BIT_REG,
};
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
--
1.7.0.4
>
> Thanks,
>
> Kevin
0001-OMAP2-hmwod-Fix-impresice-aborts-seen-on-n800-n810.patch
Description: 0001-OMAP2-hmwod-Fix-impresice-aborts-seen-on-n800-n810.patch
RE: [PATCH 0/2] omap: dsp: make the driver actually work
Felipe Contreras wrote: ... >> >> phys_to_virt instead of ioremap should work fine, still need to try >> it though. > > I tried that... Didn't work. I guess we need to flush at some points > (since the memory is cacheable). Hmmm, because my other option was to move the reserved memory outside the kernel, but that involves specifying bootargs again and using dma_alloc_coherent with their restrictions. If you are working on a different method and need any help let me know. Regards, Omar-- To unsubscribe from this list: send the line "unsubscribe 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] usb: omap: fix the warning return type defaults to 'int'
On Mon, Oct 04, 2010 at 03:49:53PM -0500, Munegowda, Keshava wrote: This patch fix the follwing warning when compiling usb code for OMAP defconfigs. arch/arm/plat-omap/include/plat/usb.h:109: warning: return type defaults to 'int' $SUBJECT is mis-leading. I thought, initially, this was related to omap_udc.c (until I actually read the patch, of course). Generaly, you'd use "arm: omap:" as a prefix. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] arm/omap: remove duplicated include
* Nicolas Kaiser [101004 03:35]: > Remove duplicated include. Thanks, adding to omap-for-linus. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: omap: fix the warning unused variable 'status'
On Mon, Oct 04, 2010 at 04:20:13PM -0500, Munegowda, Keshava wrote: This patch fix the follwing warning when compiling usb code for OMAP defconfigs. arch/arm/mach-omap2/board-omap4panda.c:277: warning: unused variable 'status' $SUBJECT is definitely wrong. This is no related to USB at all. Patches to arch/arm/*omap* should start with something like: arm: omap: ***description here*** -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] omap: dsp: make the driver actually work
On Tue, Oct 5, 2010 at 10:52 PM, Ramirez Luna, Omar wrote: > Felipe Contreras wrote: > ... >> >> Well, I thought it would be nice if the driver actually worked on >> .36, but anyway, I'll rebase the rest of my cleanup patches and send >> them. Hopefully I find a way to get rid of the ioremap() issue. >> > > phys_to_virt instead of ioremap should work fine, still need to try it though. I tried that... Didn't work. I guess we need to flush at some points (since the memory is cacheable). -- 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 0/2] omap: dsp: make the driver actually work
Felipe Contreras wrote: ... > > Well, I thought it would be nice if the driver actually worked on > .36, but anyway, I'll rebase the rest of my cleanup patches and send > them. Hopefully I find a way to get rid of the ioremap() issue. > phys_to_virt instead of ioremap should work fine, still need to try it though. Regards, omar -- To unsubscribe from this list: send the line "unsubscribe 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: OMAP hwmod driver conversions: watchdog, UART, i2c
"Nayak, Rajendra" writes: >> -Original Message- >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> Sent: Tuesday, October 05, 2010 10:34 PM >> To: Nayak, Rajendra >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; >> linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, >> Govindraj >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: >> watchdog, UART, i2c >> >> "Nayak, Rajendra" writes: >> >> > .. >> > >> >> > >> >> > Below is an untested patch to provide some mechanism to deal with this >> >> > -- >> >> > I'd appreciate everyone's comments on this, particularly the comments in >> >> > the patch code on how to deal with this problem. >> >> >> >> Hi Paul, >> >> >> >> I'll test this patch to see if it solves the issue seen with i2c on n800. >> > >> > Hi Paul, Benoit, Kevin, >> > >> > So looks like the issue with i2c on n800 isn't really because of additional >> > delay needed after a clock enable, but related to the omap_readl/writel's >> > done on the 16bit i2c registers as I was suspecting earlier. >> > >> > The below patch fixes the n800 issue for me. My mailer might mess up the >> > alignment >> > hence attaching it too. >> > >> > From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001 >> > From: Rajendra Nayak >> > Date: Tue, 5 Oct 2010 16:36:30 +0530 >> > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers >> > >> > Some modules which have 16bit registers can cause imprecise >> > aborts if a __raw_readl/writel is used to read/write 32 bits. >> > >> > Add an additional flag to identify modules which have such >> > hard requirement, and handle it in the hwmod framework. >> > >> > Signed-off-by: Rajendra Nayak >> >> Can you also send a corresponding patch to the i2c hwmod data. > Hi Kevin, > > Ok, I'll repost the original patch which adds the omap2 hwmod data with > these flags added for omap2420. Does that sound fine? Since I've alrady done some manual merge conflicts here, you can just post an additional patch and I will fold it in. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/7] pwm: Add pwm core driver
On Tue, 5 Oct 2010 17:29:56 +0530
Arun Murthy wrote:
> The existing pwm based led and backlight driver makes use of the
> pwm(include/linux/pwm.h). So all the board specific pwm drivers will
> be exposing the same set of function name as in include/linux/pwm.h.
> Consder a platform with multi Soc or having more than one pwm module, in
> such a case, there exists more than one pwm driver for a platform. Each
> of these pwm drivers export the same set of function and hence leads to
> re-declaration build error.
>
> In order to overcome this issue all the pwm drivers must register to
> some core pwm driver with function pointers for pwm operations (i.e
> pwm_config, pwm_enable, pwm_disable).
>
> The clients of pwm device will have to call pwm_request, wherein
> they will get the pointer to struct pwm_ops. This structure include
> function pointers for pwm_config, pwm_enable and pwm_disable.
>
Have we worked out who will be merging this work, if it gets merged?
>
> ...
>
> +struct pwm_dev_info {
> + struct pwm_device *pwm_dev;
> + struct list_head list;
> +};
> +static struct pwm_dev_info *di;
We could just do
static struct pwm_dev_info {
...
} *di;
> +DECLARE_RWSEM(pwm_list_lock);
This can/should be static.
> +void __deprecated pwm_free(struct pwm_device *pwm)
> +{
> +}
Why are we adding a new function and already deprecating it?
Probably this was already addressed in earlier review, but I'm asking
again, because there's no comment explaining the reasons. Lesson
learned, please add a comment.
Oh, I see that pwm_free() already exists. This patch adds a new copy
and doesn't remove the old function. Does this all actually work?
It still needs a comment explaining why it's deprecated.
> +int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
> +{
> + if (!pwm->pops)
> + -EFAULT;
> + return pwm->pops->pwm_config(pwm, duty_ns, period_ns);
> +}
> +EXPORT_SYMBOL(pwm_config);
> +
> +int pwm_enable(struct pwm_device *pwm)
> +{
> + if (!pwm->pops)
> + -EFAULT;
> + return pwm->pops->pwm_enable(pwm);
> +}
> +EXPORT_SYMBOL(pwm_enable);
> +
> +void pwm_disable(struct pwm_device *pwm)
> +{
> + if (!pwm->pops)
> + -EFAULT;
> + pwm->pops->pwm_disable(pwm);
> +}
> +EXPORT_SYMBOL(pwm_disable);
> +
> +int pwm_device_register(struct pwm_device *pwm_dev)
> +{
> + struct pwm_dev_info *pwm;
> +
> + down_write(&pwm_list_lock);
> + pwm = kzalloc(sizeof(struct pwm_dev_info), GFP_KERNEL);
> + if (!pwm) {
> + up_write(&pwm_list_lock);
> + return -ENOMEM;
> + }
The allocation attempt can be moved outside the lock, making the code
faster, cleaner and shorter.
> + pwm->pwm_dev = pwm_dev;
> + list_add_tail(&pwm->list, &di->list);
> + up_write(&pwm_list_lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(pwm_device_register);
> +
> +int pwm_device_unregister(struct pwm_device *pwm_dev)
> +{
> + struct pwm_dev_info *tmp;
> + struct list_head *pos, *tmp_lst;
> +
> + down_write(&pwm_list_lock);
> + list_for_each_safe(pos, tmp_lst, &di->list) {
> + tmp = list_entry(pos, struct pwm_dev_info, list);
> + if (tmp->pwm_dev == pwm_dev) {
> + list_del(pos);
> + kfree(tmp);
> + up_write(&pwm_list_lock);
> + return 0;
> + }
> + }
> + up_write(&pwm_list_lock);
> + return -ENOENT;
> +}
> +EXPORT_SYMBOL(pwm_device_unregister);
> +
> +struct pwm_device *pwm_request(int pwm_id, const char *name)
> +{
> + struct pwm_dev_info *pwm;
> + struct list_head *pos;
> +
> + down_read(&pwm_list_lock);
> + list_for_each(pos, &di->list) {
> + pwm = list_entry(pos, struct pwm_dev_info, list);
> + if ((!strcmp(pwm->pwm_dev->pops->name, name)) &&
> + (pwm->pwm_dev->pwm_id == pwm_id)) {
> + up_read(&pwm_list_lock);
> + return pwm->pwm_dev;
> + }
> + }
> + up_read(&pwm_list_lock);
> + return ERR_PTR(-ENOENT);
> +}
> +EXPORT_SYMBOL(pwm_request);
We have a new kernel-wide exported-to-modules formal API. We prefer
that such things be fully documented, please. kerneldoc is a suitable
way but please avoid falling into the kerneldoc trap of filling out
fields with obvious boilerplate and not actually telling people
anything interesting or useful.
> +static int __init pwm_init(void)
> +{
> + struct pwm_dev_info *pwm;
> +
> + pwm = kzalloc(sizeof(struct pwm_dev_info), GFP_KERNEL);
> + if (!pwm)
> + return -ENOMEM;
> + INIT_LIST_HEAD(&pwm->list);
> + di = pwm;
> + return 0;
> +}
OK, this looks wrong.
AFACIT you've created a dummy pwm_dev_info as a singleton, kernel-wide
anchor for a list of all pwm_dev_info's. So this "anchor" pwm_dev_info
never actually gets used for anything.
The way to
Re: [PATCH 0/2] omap: dsp: make the driver actually work
On Tue, Oct 5, 2010 at 10:07 PM, Greg KH wrote: > On Mon, Oct 04, 2010 at 07:09:13PM +0300, Felipe Contreras wrote: >> It seems the platform device was dropped from the migration of tidspbridge >> into >> staging, plus the sdram meblock (previously bootmem) required for it work are >> gone. >> >> Withouth these patches the driver loads, but doesn't do anything. >> >> A second issue with ioremap() still remains, but that can be solved by >> reverting 309caa9. >> >> I think these might be worth to get into 2.6.36, if not, I have versions with >> more changes; cleanups and so on. > > I've applied this to my staging-next tree, for .37, as it's not a big > deal for .36. Well, I thought it would be nice if the driver actually worked on .36, but anyway, I'll rebase the rest of my cleanup patches and send them. Hopefully I find a way to get rid of the ioremap() issue. 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 0/2] omap: dsp: make the driver actually work
On Mon, Oct 04, 2010 at 07:09:13PM +0300, Felipe Contreras wrote: > Hi, > > It seems the platform device was dropped from the migration of tidspbridge > into > staging, plus the sdram meblock (previously bootmem) required for it work are > gone. > > Withouth these patches the driver loads, but doesn't do anything. > > A second issue with ioremap() still remains, but that can be solved by > reverting 309caa9. > > I think these might be worth to get into 2.6.36, if not, I have versions with > more changes; cleanups and so on. I've applied this to my staging-next tree, for .37, as it's not a big deal for .36. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe 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] omap: add dsp platform device
On Tue, Oct 05, 2010 at 09:28:30AM -0700, Tony Lindgren wrote: > * Greg KH [101005 09:01]: > > On Mon, Oct 04, 2010 at 07:09:14PM +0300, Felipe Contreras wrote: > > > Otherwise tidspbridge cannot work. > > > > > > It looks like this was dropped in the conversion to staging. I took the > > > liberty of doing some cleaning up. > > > > > > Signed-off-by: Felipe Contreras > > > --- > > > arch/arm/mach-omap2/Makefile |4 ++ > > > arch/arm/mach-omap2/dsp.c | 85 > > > + > > > arch/arm/plat-omap/common.c |2 + > > > arch/arm/plat-omap/devices.c | 30 > > > arch/arm/plat-omap/include/plat/dsp.h | 31 > > > > I need an ack from some omap maintainers before I can take this into the > > staging tree. > > Looks good to me > > Acked-by: Tony Lindgren Thanks, I'll go queue it up now. greg k-h -- To unsubscribe from this list: send the line "unsubscribe 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: OMAP hwmod driver conversions: watchdog, UART, i2c
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Tuesday, October 05, 2010 10:34 PM > To: Nayak, Rajendra > Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; > linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, > Govindraj > Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, > UART, i2c > > "Nayak, Rajendra" writes: > > > .. > > > >> > > >> > Below is an untested patch to provide some mechanism to deal with this -- > >> > I'd appreciate everyone's comments on this, particularly the comments in > >> > the patch code on how to deal with this problem. > >> > >> Hi Paul, > >> > >> I'll test this patch to see if it solves the issue seen with i2c on n800. > > > > Hi Paul, Benoit, Kevin, > > > > So looks like the issue with i2c on n800 isn't really because of additional > > delay needed after a clock enable, but related to the omap_readl/writel's > > done on the 16bit i2c registers as I was suspecting earlier. > > > > The below patch fixes the n800 issue for me. My mailer might mess up the > > alignment > > hence attaching it too. > > > > From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001 > > From: Rajendra Nayak > > Date: Tue, 5 Oct 2010 16:36:30 +0530 > > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers > > > > Some modules which have 16bit registers can cause imprecise > > aborts if a __raw_readl/writel is used to read/write 32 bits. > > > > Add an additional flag to identify modules which have such > > hard requirement, and handle it in the hwmod framework. > > > > Signed-off-by: Rajendra Nayak > > Can you also send a corresponding patch to the i2c hwmod data. Hi Kevin, Ok, I'll repost the original patch which adds the omap2 hwmod data with these flags added for omap2420. Does that sound fine? Regards, Rajendra > > I'll rebase the rest of the series against current l-o master, and maybe > we can still get this in for .37. > > Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Tuesday, October 05, 2010 10:28 PM > To: Nayak, Rajendra > Cc: Cousson, Benoit; Kevin Hilman; Tony Lindgren; linux-omap@vger.kernel.org; > Varadarajan, Charulatha; Raja, > Govindraj > Subject: RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, > UART, i2c > > On Tue, 5 Oct 2010, Nayak, Rajendra wrote: > > > So looks like the issue with i2c on n800 isn't really because of additional > > delay needed after a clock enable, but related to the omap_readl/writel's > > done on the 16bit i2c registers as I was suspecting earlier. > > > > The below patch fixes the n800 issue for me. My mailer might mess up the > > alignment > > hence attaching it too. > > > > >From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001 > > From: Rajendra Nayak > > Date: Tue, 5 Oct 2010 16:36:30 +0530 > > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers > > > > Some modules which have 16bit registers can cause imprecise > > aborts if a __raw_readl/writel is used to read/write 32 bits. > > > > Add an additional flag to identify modules which have such > > hard requirement, and handle it in the hwmod framework. > > > > Signed-off-by: Rajendra Nayak > > Nice work, looks good to me. Hopefully we won't need that enable_delay > patch! Yeah, unless Benoit thinks it's needed for OMAP4 where he's seeing some issues with FDIF and ISS. > > I was initially concerned that your patch tried to store a 32-bit quantity > into a 16-bit register. But I guess the cast to unsigned short in > the __raw_writew macro takes care of this: > > __raw_writew(v, oh->_mpu_rt_va + reg_offs); > 28: 16ff3070uxthne r3, r0 > 2c: 118130b2strhne r3, [r1, r2] > > gcc for some reason decides to zero-extend it first, but that is not your > bug to fix. > > This patch is targeted for merging via 2.6.37 via Tony's tree. > > Acked-by: Paul Walmsley > > > - 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 00/10] OMAP: SCM/McBSP/clock: branch integration patches for 2.6.37
* Jarkko Nikula [101005 05:43]: > On Fri, 01 Oct 2010 15:34:45 -0600 > Paul Walmsley wrote: > > > mach-omap2 (as the SCM only exists on OMAP2+ systems). The McBSP > > parent fclk and signal muxing changes have received only light > > testing, so any help from OMAP ASoc experts here is appreciated. > > > Looks good to me. I pointed out one bug but as these are already in > linux-omap I sent a fix for it and two minor cleanups [1]. > > > Paul Walmsley (10): > > OMAP2+: Kconfig: disallow builds for boards that don't use the > > currently-selected SoC > > OMAP2420: CTRL: fix OMAP242X_CTRL_REGADDR macro > > OMAP2420: clock: add MCBSP_CLKS node and clkdev aliases > > OMAP2430: clock: add MCBSP_CLKS node and clkdev aliases > > OMAP3xxx: clock: add clkdev aliases for McBSP fclk source switching > > OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via > > mach-omap2/mcbsp.c > > OMAP: McBSP: implement functional clock switching via clock framework > > OMAP: split plat-omap/common.c > > OMAP: control: move plat-omap/control.h to mach-omap2/control.h > > OMAP2+: clock: reduce the amount of standard debugging while > > disabling unused clocks > > > Patches 3-5 are doing the right thing AFAIK the OMAP clock framework. > > For patches 6-7 you could have my ack. > Acked-by: Jarkko Nikula > > As they are touching also sound/soc/omap/omap-mcbsp.c, an ack from Mark > and Liam are needed. Links to patches 6 and 7 below and my fixes on top > of them [1]. > > http://marc.info/?l=linux-omap&m=128596931117788&w=2 > http://marc.info/?l=linux-omap&m=128596931417805&w=2 Sorry, I've already merged them as they fixed code that did not compile. Let me know if you guys want me to rebuild those parts of omap-for-linus to add the acks. 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] arm/omap: simplify conditional
Simplify conditional: (a || (!a && !b)) => (a || !b)
Signed-off-by: Nicolas Kaiser
---
arch/arm/plat-omap/fb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index 0054b95..5c09095 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -126,7 +126,7 @@ static int set_fbmem_region_type(struct omapfb_mem_region
*rg, int mem_type,
* type = 0 && paddr = 0, a default don't care case maps to
* the SDRAM type.
*/
- if (rg->type || (!rg->type && !rg->paddr))
+ if (rg->type || !rg->paddr)
return 0;
if (ranges_overlap(rg->paddr, rg->size, mem_start, mem_size)) {
rg->type = mem_type;
--
1.7.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3 v5] AM35x: Add musb support
* Felipe Balbi [101004 22:32]: > On Mon, Oct 04, 2010 at 12:28:14PM -0500, Tony Lindgren wrote: > >* Felipe Balbi [100930 22:52]: > >>Hi, > >> > >>On Thu, Sep 30, 2010 at 12:19:07AM -0500, Gupta, Ajay Kumar wrote: > >>>AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine. > >>>It has USB phy built inside the IP itself. > >>> > >>>Signed-off-by: Ajay Kumar Gupta > >> > >>besides the one small question below: > >> > >>Acked-by: Felipe Balbi > > > >Felipe, I'm assuming you're queuing up the omap USB platform data > >patches. So not picking up these patches. > > > >Also, please also note that the arch/arm/*omap*/ patches should > >be posted with both linux-omap and linux-arm-kernel mailing lists > >Cc'd. > > I'll queue it throught Greg. Can I get your Acked-by ? Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/1] omap3: Add minimal OMAP3 IGEP module support.
* Enric Balletbo i Serra [101002 14:58]: > The OMAP3 IGEP module is a low-power, high performance production-ready > system-on-module (SOM) based on TI's OMAP3 family. More about this > board at www.igep.es. Adding this to omap-for-linus. Updated it for to use MMC caps instead of wires and to be selected by default in Kconfig. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/6] omap3: Various fixes and improvements for IGEP v2 board.
* Enric Balletbo i Serra [101005 07:07]: > > Hello, > > This is the version 4 of patch series to fix and improve the IGEP v2 board > support. Thanks, adding these into omap-for-linus. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes
* Peter Ujfalusi [101004 23:37]: > Hello, > > This v5 series is based on the v3. > The first two patch is the actual fix for the original problems without any > major change in the code (only handling the corresponding erratas in the > legacy > way). > The third patch in the series is optional, and it is implementing (in one > patch) > the errata handling via flags. This patch converts all errata cases to use the > introduced dma_errata variable via macros. > > Tony: the first two patch need to go for 2.6.36, and if it is possible it > shall > be backported to .33, .34, and .35 as well. OK, I'll the first two into omap-fixes. > The final patch in this series is optional, if you feel like you can take it > (or drop it). AFAIK the upcoming hwmod changes to dma code will also have > similar feature to handle the erratas. > I'm not sure what is the schedule for the hwmod conversion of dma... Let's queue this clean-up with the hwmod patches then. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
On Tue, 5 Oct 2010, Paul Walmsley wrote:
> __raw_writew(v, oh->_mpu_rt_va + reg_offs);
> 28: 16ff3070uxthne r3, r0
> 2c: 118130b2strhne r3, [r1, r2]
>
> gcc for some reason decides to zero-extend it first, but that is not your
> bug to fix.
Unlikely anyone cares too much about this, but just to follow up, this
appears to be caused by using -march=armv6 or -march=armv7-a on the gcc
command line. Dropping the -march or using -march=armv5 avoids the uxt.
That's with arm-linux-gcc (Sourcery G++ Lite 2008q3-72) 4.3.2. Minimal
case follows. This appears to be gcc bug 40893:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40893
- Paul
void foo(unsigned int v)
{
*(volatile unsigned short *)0xabcdefab = (v);
}
arm-linux-gcc -O2 -march=armv7-a -c test.c; arm-linux-objdump -DS test.o
| less
:
0: e30e3fffmovwr3, #61439 ; 0xefff
4: e34a3bcdmovtr3, #43981 ; 0xabcd
8: e6ff0070uxthr0, r0
c: e14305b4strhr0, [r3, #-84]
10: e12fff1ebx lr
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv2 01/11] staging: tidspbridge: replace iommu custom for opensource implementation
Hi, > -Original Message- > From: Greg KH [mailto:g...@kroah.com] > Sent: Tuesday, October 05, 2010 10:56 AM > To: Guzman Lugo, Fernando > Cc: gre...@suse.de; felipe.contre...@nokia.com; > ameya.pala...@nokia.com; Menon, Nishanth; > hiroshi.d...@nokia.com; o...@wizery.com; > linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; > linux-omap@vger.kernel.org > Subject: Re: [PATCHv2 01/11] staging: tidspbridge: replace > iommu custom for opensource implementation > > On Thu, Sep 30, 2010 at 09:12:48PM -0500, Fernando Guzman Lugo wrote: > > Now the tidspbridge uses the API's from iovmm module. > > > > Signed-off-by: Fernando Guzman Lugo > > This patch applied, but number 2 and others didn't. Care to > respin those against the new linux-next tree and resend? I will rebase and send then as soon as possible. Regards, Fernando. > > thanks, > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP: McBSP: Fix CLKR and FSR signal muxing
* Paul Walmsley [101005 08:03]: > On Tue, 5 Oct 2010, Jarkko Nikula wrote: > > > Fix bit clear. Now it clears all other bits than mask bit where it should > > clear only it. > > > > Signed-off-by: Jarkko Nikula > > Cc: Paul Walmsley > > Doh. Thanks Jarkko. > > Obviously this is an important patch and should go in ASAP. > > Acked-by: Paul Walmsley Jarkko, please repost this one more time with linux-arm-kernel list Cc'd so I don't need to repost it before applying. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beagle hangs in uart3 disabling clocks
Paul Walmsley writes: > On Tue, 5 Oct 2010, Pramod wrote: > >> On Tuesday 05 October 2010 03:33 PM, Paul Walmsley wrote: >> > >> > Looks to me like it boots fine. If you had hwmod debugging enabled, your >> > kernel should have crashed after >> > >> > omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 >> > omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 >> > omap-hsuart.2: ttyO2 at MMIO 0x4902 (irq = 74) is a OMAP UART2 >> > >> > ... but it didn't crash there. I'm not seeing any hwmod debug messages >> > though, so you probably don't have DEBUG defined in omap_hwmod.c. >> > >> > So, I suspect whatever problem you're seeing is unrelated to the problem >> > that the patch was intended to solve. >> > >> > >> > - Paul >> >> The hwmod debug messages will be seen when I enable them on the go with: >> echo -n 'file omap_hwmod.c +p' > /debug/dynamic_debug/control >> >> This will show lots of logs as below ending with UART3 clock disabling and a >> hang. >> >> omap_hwmod:omap_hwmod: uart1: idling >> omap_hwmod:omap_hwmod: uart1: disabling clocks >> omap_hwmod:omap_hwmod: uart2: idling >> omap_hwmod:omap_hwmod: uart2: disabling clocks >> omap_hwmod:omap_hwmod: uart1: enabling >> omap_hwmod:omap_hwmod: uart1: enabling clocks >> omap_hwmod:omap_hwmod: uart2: enabling >> omap_hwmod:omap_hwmod: uart2: enabling clocks >> omap_hwmod:omap_hwmod: uart3: idling >> omap_hwmod:omap_hwmod: uart3: disabling clock > > OK, the problem here is probably with the real serial console generating > messages while the hwmod is idle, not earlyconsole/bootconsole. The patch > could be extended to fix that, but it doesn't address that right now. Why > don't you take a shot at doing that? > > In this context, the real serial console is only part of the problem. > For a complete fix, I suspect that one would have to tinker with the OMAP > UART driver or serial core, since other drivers beyond the real console > may be using the serial port (e.g. Bluetooth). > > Also, thinking about this issue further, there needs to be an additional > fix at least in omap_serial_init_port() to ensure that the UART TX FIFO is > completely drained before it starts messing around with the underlying > hwmod. Similarly, whenever the PM runtime conversion is done for > drivers/serial/omap-serial.c, it will need to ensure that the TX FIFO has > drained before going to idle. Now that the base omap-serial driver is queued for mainline, the next step is to move all the PM hackery from mach-omap2/serial.c into the driver itself by using the runtime PM API. This should ensure that any users of the real serial driver will have an active UART. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beagle hangs in uart3 disabling clocks
On Tue, 5 Oct 2010, Pramod wrote: > On Tuesday 05 October 2010 03:33 PM, Paul Walmsley wrote: > > > > Looks to me like it boots fine. If you had hwmod debugging enabled, your > > kernel should have crashed after > > > > omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 > > omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 > > omap-hsuart.2: ttyO2 at MMIO 0x4902 (irq = 74) is a OMAP UART2 > > > > ... but it didn't crash there. I'm not seeing any hwmod debug messages > > though, so you probably don't have DEBUG defined in omap_hwmod.c. > > > > So, I suspect whatever problem you're seeing is unrelated to the problem > > that the patch was intended to solve. > > > > > > - Paul > > The hwmod debug messages will be seen when I enable them on the go with: > echo -n 'file omap_hwmod.c +p' > /debug/dynamic_debug/control > > This will show lots of logs as below ending with UART3 clock disabling and a > hang. > > omap_hwmod:omap_hwmod: uart1: idling > omap_hwmod:omap_hwmod: uart1: disabling clocks > omap_hwmod:omap_hwmod: uart2: idling > omap_hwmod:omap_hwmod: uart2: disabling clocks > omap_hwmod:omap_hwmod: uart1: enabling > omap_hwmod:omap_hwmod: uart1: enabling clocks > omap_hwmod:omap_hwmod: uart2: enabling > omap_hwmod:omap_hwmod: uart2: enabling clocks > omap_hwmod:omap_hwmod: uart3: idling > omap_hwmod:omap_hwmod: uart3: disabling clock OK, the problem here is probably with the real serial console generating messages while the hwmod is idle, not earlyconsole/bootconsole. The patch could be extended to fix that, but it doesn't address that right now. Why don't you take a shot at doing that? In this context, the real serial console is only part of the problem. For a complete fix, I suspect that one would have to tinker with the OMAP UART driver or serial core, since other drivers beyond the real console may be using the serial port (e.g. Bluetooth). Also, thinking about this issue further, there needs to be an additional fix at least in omap_serial_init_port() to ensure that the UART TX FIFO is completely drained before it starts messing around with the underlying hwmod. Similarly, whenever the PM runtime conversion is done for drivers/serial/omap-serial.c, it will need to ensure that the TX FIFO has drained before going to idle. regards, - 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: hwmod: Handle modules with 16bit registers
Paul Walmsley writes: > From: Rajendra Nayak > > Some modules which have 16bit registers can cause imprecise > aborts if a __raw_readl/writel is used to read/write 32 bits. > > Add an additional flag to identify modules which have such > hard requirement, and handle it in the hwmod framework. > > Signed-off-by: Rajendra Nayak > Acked-by: Paul Walmsley Tested-by: Kevin Hilman Added the flag to the 2420 hwmods and tested this patch on n810 using the i2c hwmods and it now boots without the imprecise abort. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
"Nayak, Rajendra" writes: > .. > >> > >> > Below is an untested patch to provide some mechanism to deal with this -- >> > I'd appreciate everyone's comments on this, particularly the comments in >> > the patch code on how to deal with this problem. >> >> Hi Paul, >> >> I'll test this patch to see if it solves the issue seen with i2c on n800. > > Hi Paul, Benoit, Kevin, > > So looks like the issue with i2c on n800 isn't really because of additional > delay needed after a clock enable, but related to the omap_readl/writel's > done on the 16bit i2c registers as I was suspecting earlier. > > The below patch fixes the n800 issue for me. My mailer might mess up the > alignment > hence attaching it too. > > From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001 > From: Rajendra Nayak > Date: Tue, 5 Oct 2010 16:36:30 +0530 > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers > > Some modules which have 16bit registers can cause imprecise > aborts if a __raw_readl/writel is used to read/write 32 bits. > > Add an additional flag to identify modules which have such > hard requirement, and handle it in the hwmod framework. > > Signed-off-by: Rajendra Nayak Can you also send a corresponding patch to the i2c hwmod data. I'll rebase the rest of the series against current l-o master, and maybe we can still get this in for .37. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: hwmod: Handle modules with 16bit registers
From: Rajendra Nayak
Some modules which have 16bit registers can cause imprecise
aborts if a __raw_readl/writel is used to read/write 32 bits.
Add an additional flag to identify modules which have such
hard requirement, and handle it in the hwmod framework.
Signed-off-by: Rajendra Nayak
Acked-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 24 +++-
arch/arm/plat-omap/include/plat/omap_hwmod.h |6 --
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 955861a..5a30658 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -184,7 +184,7 @@ static int _update_sysc_cache(struct omap_hwmod *oh)
/* XXX ensure module interface clock is up */
- oh->_sysc_cache = omap_hwmod_readl(oh, oh->class->sysc->sysc_offs);
+ oh->_sysc_cache = omap_hwmod_read(oh, oh->class->sysc->sysc_offs);
if (!(oh->class->sysc->sysc_flags & SYSC_NO_CACHE))
oh->_int_flags |= _HWMOD_SYSCONFIG_LOADED;
@@ -211,7 +211,7 @@ static void _write_sysconfig(u32 v, struct omap_hwmod *oh)
if (oh->_sysc_cache != v) {
oh->_sysc_cache = v;
- omap_hwmod_writel(v, oh, oh->class->sysc->sysc_offs);
+ omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
}
}
@@ -1133,12 +1133,12 @@ static int _reset(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
if (oh->class->sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
- omap_test_timeout((omap_hwmod_readl(oh,
+ omap_test_timeout((omap_hwmod_read(oh,
oh->class->sysc->syss_offs)
& SYSS_RESETDONE_MASK),
MAX_MODULE_SOFTRESET_WAIT, c);
else if (oh->class->sysc->sysc_flags & SYSC_HAS_RESET_STATUS)
- omap_test_timeout(!(omap_hwmod_readl(oh,
+ omap_test_timeout(!(omap_hwmod_read(oh,
oh->class->sysc->sysc_offs)
& SYSC_TYPE2_SOFTRESET_MASK),
MAX_MODULE_SOFTRESET_WAIT, c);
@@ -1378,14 +1378,20 @@ static int _setup(struct omap_hwmod *oh, void *data)
/* Public functions */
-u32 omap_hwmod_readl(struct omap_hwmod *oh, u16 reg_offs)
+u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs)
{
- return __raw_readl(oh->_mpu_rt_va + reg_offs);
+ if (oh->flags & HWMOD_16BIT_REG)
+ return __raw_readw(oh->_mpu_rt_va + reg_offs);
+ else
+ return __raw_readl(oh->_mpu_rt_va + reg_offs);
}
-void omap_hwmod_writel(u32 v, struct omap_hwmod *oh, u16 reg_offs)
+void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs)
{
- __raw_writel(v, oh->_mpu_rt_va + reg_offs);
+ if (oh->flags & HWMOD_16BIT_REG)
+ __raw_writew(v, oh->_mpu_rt_va + reg_offs);
+ else
+ __raw_writel(v, oh->_mpu_rt_va + reg_offs);
}
/**
@@ -1732,7 +1738,7 @@ void omap_hwmod_ocp_barrier(struct omap_hwmod *oh)
* Forces posted writes to complete on the OCP thread handling
* register writes
*/
- omap_hwmod_readl(oh, oh->class->sysc->sysc_offs);
+ omap_hwmod_read(oh, oh->class->sysc->sysc_offs);
}
/**
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index c1835af..7eaa8ed 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -370,6 +370,7 @@ struct omap_hwmod_omap4_prcm {
* This is needed for devices like DSS that require optional clocks enabled
* in order to complete the reset. Optional clocks will be disabled
* again after the reset.
+ * HWMOD_16BIT_REG: Module has 16bit registers
*/
#define HWMOD_SWSUP_SIDLE (1 << 0)
#define HWMOD_SWSUP_MSTANDBY (1 << 1)
@@ -379,6 +380,7 @@ struct omap_hwmod_omap4_prcm {
#define HWMOD_SET_DEFAULT_CLOCKACT (1 << 5)
#define HWMOD_NO_IDLEST(1 << 6)
#define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1 << 7)
+#define HWMOD_16BIT_REG(1 << 8)
/*
* omap_hwmod._int_flags definitions
@@ -527,8 +529,8 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8
idlemode);
int omap_hwmod_reset(struct omap_hwmod *oh);
void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
-void omap_hwmod_writel(u32 v, struct omap_hwmod *oh, u16 reg_offs);
-u32 omap_hwmod_readl(struct omap_hwmod *oh, u16 reg_offs);
+void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs);
+u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs);
int omap_hwmod_count_resources(struct omap_hwmod *oh);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource
RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
On Tue, 5 Oct 2010, Nayak, Rajendra wrote: > So looks like the issue with i2c on n800 isn't really because of additional > delay needed after a clock enable, but related to the omap_readl/writel's > done on the 16bit i2c registers as I was suspecting earlier. > > The below patch fixes the n800 issue for me. My mailer might mess up the > alignment > hence attaching it too. > > >From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001 > From: Rajendra Nayak > Date: Tue, 5 Oct 2010 16:36:30 +0530 > Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers > > Some modules which have 16bit registers can cause imprecise > aborts if a __raw_readl/writel is used to read/write 32 bits. > > Add an additional flag to identify modules which have such > hard requirement, and handle it in the hwmod framework. > > Signed-off-by: Rajendra Nayak Nice work, looks good to me. Hopefully we won't need that enable_delay patch! I was initially concerned that your patch tried to store a 32-bit quantity into a 16-bit register. But I guess the cast to unsigned short in the __raw_writew macro takes care of this: __raw_writew(v, oh->_mpu_rt_va + reg_offs); 28: 16ff3070uxthne r3, r0 2c: 118130b2strhne r3, [r1, r2] gcc for some reason decides to zero-extend it first, but that is not your bug to fix. This patch is targeted for merging via 2.6.37 via Tony's tree. Acked-by: Paul Walmsley - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] [RFC] OMAP: pm_runtime support for MCBSP
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Signed-off-by: Shubhrajyoti D
Cc: Partha Basak
---
arch/arm/mach-omap2/mcbsp.c |7 ---
arch/arm/plat-omap/include/plat/mcbsp.h |1 -
arch/arm/plat-omap/mcbsp.c | 27 +++
3 files changed, 11 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 25c6703..e9082ff 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -7,7 +7,7 @@
* 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.
- *
+*
* Multichannel mode not supported.
*/
#include
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "control.h"
@@ -87,7 +88,7 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
return -EINVAL;
}
- clk_disable(mcbsp->fclk);
+ pm_runtime_put_sync(mcbsp->dev);
r = clk_set_parent(mcbsp->fclk, fck_src);
if (IS_ERR_VALUE(r)) {
@@ -97,7 +98,7 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
return -EINVAL;
}
- clk_enable(mcbsp->fclk);
+ pm_runtime_get_sync(mcbsp->dev);
clk_put(fck_src);
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 1ff283c..b989d0c 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -462,7 +462,6 @@ struct omap_mcbsp {
/* Protect the field .free, while checking if the mcbsp is in use */
spinlock_t lock;
struct omap_mcbsp_platform_data *pdata;
- struct clk *iclk;
struct clk *fclk;
struct omap_mcbsp_st_data *st_data;
int dma_op_mode;
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 6b705e1..2a1dce1 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "../mach-omap2/cm-regbits-34xx.h"
@@ -777,8 +778,7 @@ int omap_mcbsp_request(unsigned int id)
if (mcbsp->pdata && mcbsp->pdata->ops && mcbsp->pdata->ops->request)
mcbsp->pdata->ops->request(id);
- clk_enable(mcbsp->iclk);
- clk_enable(mcbsp->fclk);
+ pm_runtime_get_sync(mcbsp->dev);
/* Do procedure specific to omap34xx arch, if applicable */
omap34xx_mcbsp_request(mcbsp);
@@ -826,8 +826,7 @@ err_clk_disable:
/* Do procedure specific to omap34xx arch, if applicable */
omap34xx_mcbsp_free(mcbsp);
- clk_disable(mcbsp->fclk);
- clk_disable(mcbsp->iclk);
+ pm_runtime_put_sync(mcbsp->dev);
spin_lock(&mcbsp->lock);
mcbsp->free = 1;
@@ -857,8 +856,7 @@ void omap_mcbsp_free(unsigned int id)
/* Do procedure specific to omap34xx arch, if applicable */
omap34xx_mcbsp_free(mcbsp);
- clk_disable(mcbsp->fclk);
- clk_disable(mcbsp->iclk);
+ pm_runtime_put_sync(mcbsp->dev);
if (mcbsp->io_type == OMAP_MCBSP_IRQ_IO) {
/* Free IRQs */
@@ -1737,24 +1735,18 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
}
mcbsp->dma_tx_sync = res->start;
- mcbsp->iclk = clk_get(&pdev->dev, "ick");
- if (IS_ERR(mcbsp->iclk)) {
- ret = PTR_ERR(mcbsp->iclk);
- dev_err(&pdev->dev, "unable to get ick: %d\n", ret);
- goto err_res;
- }
-
mcbsp->fclk = clk_get(&pdev->dev, "fck");
if (IS_ERR(mcbsp->fclk)) {
ret = PTR_ERR(mcbsp->fclk);
dev_err(&pdev->dev, "unable to get fck: %d\n", ret);
- goto err_fclk;
+ goto err_res;
}
mcbsp->pdata = pdata;
mcbsp->dev = &pdev->dev;
mcbsp_ptr[id] = mcbsp;
platform_set_drvdata(pdev, mcbsp);
+ pm_runtime_enable(mcbsp->dev);
omap_additional_add(mcbsp->dev);
if (pdata->dma_op_mode != -EINVAL) {
@@ -1800,8 +1792,6 @@ err_io_st:
kfree(mcbsp->st_data);
err_st_data:
clk_put(mcbsp->fclk);
-err_fclk:
- clk_put(mcbsp->iclk);
err_res:
iounmap(mcbsp->io_base);
err_ioremap:
@@ -1830,15 +1820,12 @@ static int __devexit omap_mcbsp_remove(struct
platform_device *pdev)
kfree(mcbsp->st_data);
}
- clk_disable(mcbsp->fclk);
- clk_disable(mcbsp->iclk);
clk_put(mcbsp->fclk);
- clk_put(mcbsp->iclk);
+ pm_runtime_put_sync(mcbsp->dev);
iounmap(mcbsp->io_base);
mcbsp->fclk = NULL;
- mcbsp->iclk = NULL;
mcbsp->free = 0;
mcbsp->dev = NULL;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "u
[PATCH 5/7] [RFC] OMAP: hwmod: New API to modify the autoidle bit of sysconfig register
This patch was already posted in lo as RFC. But since no conclusion was
drawn, I'm again posting this patch.
The previous patch and discussion can be found at
https://patchwork.kernel.org/patch/134371/
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Signed-off-by: Shubhrajyoti D
Cc: Paul Walmsley
Cc: Benoit Cousson
Cc: Partha Basak
---
arch/arm/mach-omap2/omap_hwmod.c | 29 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 955861a..631286b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1250,6 +1250,35 @@ int _omap_hwmod_idle(struct omap_hwmod *oh)
return 0;
}
+/*
+ * omap_hwmod_set_module_autoidle - set the hwmod's OCP slave autoidle
+ * @oh: struct omap_hwmod *
+ * @autoidle: desired AUTOIDLE bitfield value (0 or 1)
+ *
+ * Sets the IP block's OCP slave autoidle in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the AUTOIDLE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_module_autoidle().
+ */
+int omap_hwmod_set_module_autoidle(struct omap_hwmod *oh, u8 autoidle)
+{
+ u32 v;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ v = oh->_sysc_cache;
+
+ retval = _set_module_autoidle(oh, autoidle, &v);
+
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ return retval;
+}
+
/**
* _shutdown - shutdown an omap_hwmod
* @oh: struct omap_hwmod *
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index c1835af..0d31317 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -523,6 +523,7 @@ int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
int omap_hwmod_disable_clocks(struct omap_hwmod *oh);
int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode);
+int omap_hwmod_set_module_autoidle(struct omap_hwmod *oh, u8 autoidle);
int omap_hwmod_reset(struct omap_hwmod *oh);
void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
--
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 6/7] [RFC] OMAP: hwmod: SYSCONFIG register modification for MCBSP
MCBSP 2 and 3 in OMAP3 has sidetone feature which requires
autoidle to be disabled before starting the sidetone. Also SYSCONFIG
register has to be set with smart idle or no idle depending on the
dma op mode (threshold or element sync). For doing these operations
dynamically at runtime, hwmod API'S are used to modify SYSCONFIG register
directly.
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Signed-off-by: Shubhrajyoti D
Cc: Partha Basak
---
arch/arm/plat-omap/mcbsp.c | 69 ++--
1 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index c7c6a83..6b705e1 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -228,10 +228,21 @@ void omap_mcbsp_config(unsigned int id, const struct
omap_mcbsp_reg_cfg *config)
EXPORT_SYMBOL(omap_mcbsp_config);
#ifdef CONFIG_ARCH_OMAP3
+static struct omap_hwmod **find_hwmods_by_dev(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+ pdev = container_of(dev, struct platform_device, dev);
+ od = container_of(pdev, struct omap_device, pdev);
+ return od->hwmods;
+}
+
static void omap_st_on(struct omap_mcbsp *mcbsp)
{
unsigned int w;
+ struct omap_hwmod **oh;
+ oh = find_hwmods_by_dev(mcbsp->dev);
/*
* Sidetone uses McBSP ICLK - which must not idle when sidetones
* are enabled or sidetones start sounding ugly.
@@ -244,8 +255,7 @@ static void omap_st_on(struct omap_mcbsp *mcbsp)
w = MCBSP_READ(mcbsp, SSELCR);
MCBSP_WRITE(mcbsp, SSELCR, w | SIDETONEEN);
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w & ~(ST_AUTOIDLE));
+ omap_hwmod_set_module_autoidle(oh[1], 0);
/* Enable Sidetone from Sidetone Core */
w = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -255,12 +265,14 @@ static void omap_st_on(struct omap_mcbsp *mcbsp)
static void omap_st_off(struct omap_mcbsp *mcbsp)
{
unsigned int w;
+ struct omap_hwmod **oh;
+
+ oh = find_hwmods_by_dev(mcbsp->dev);
w = MCBSP_ST_READ(mcbsp, SSELCR);
MCBSP_ST_WRITE(mcbsp, SSELCR, w & ~(ST_SIDETONEEN));
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w | ST_AUTOIDLE);
+ omap_hwmod_set_module_autoidle(oh[1], 1);
w = MCBSP_READ(mcbsp, SSELCR);
MCBSP_WRITE(mcbsp, SSELCR, w & ~(SIDETONEEN));
@@ -273,9 +285,11 @@ static void omap_st_off(struct omap_mcbsp *mcbsp)
static void omap_st_fir_write(struct omap_mcbsp *mcbsp, s16 *fir)
{
u16 val, i;
+ struct omap_hwmod **oh;
- val = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, val & ~(ST_AUTOIDLE));
+ oh = find_hwmods_by_dev(mcbsp->dev);
+
+ omap_hwmod_set_module_autoidle(oh[1], 0);
val = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -303,9 +317,11 @@ static void omap_st_chgain(struct omap_mcbsp *mcbsp)
{
u16 w;
struct omap_mcbsp_st_data *st_data = mcbsp->st_data;
+ struct omap_hwmod **oh;
+
+ oh = find_hwmods_by_dev(mcbsp->dev);
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w & ~(ST_AUTOIDLE));
+ omap_hwmod_set_module_autoidle(oh[1], 0);
w = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -648,49 +664,46 @@ EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp)
{
+ struct omap_hwmod **oh;
+
+ oh = find_hwmods_by_dev(mcbsp->dev);
/*
* Enable wakup behavior, smart idle and all wakeups
* REVISIT: some wakeups may be unnecessary
*/
if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
- u16 syscon;
-
- syscon = MCBSP_READ(mcbsp, SYSCON);
- syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
- syscon |= (ENAWAKEUP | SIDLEMODE(0x02) |
- CLOCKACTIVITY(0x02));
- MCBSP_WRITE(mcbsp, WAKEUPEN, XRDYEN | RRDYEN);
+ omap_hwmod_enable_wakeup(oh[0]);
+ omap_hwmod_set_slave_idlemode(oh[0],
+ HWMOD_IDLEMODE_SMART);
} else {
- syscon |= SIDLEMODE(0x01);
+ omap_hwmod_disable_wakeup(oh[0]);
+ omap_hwmod_set_slave_idlemode(oh[0],
+ HWMOD_IDLEMODE_NO);
}
-
- MCBSP_WRITE(mcbsp, SYSCON, syscon);
}
}
static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp)
{
+ struct omap_hwmod **oh;
+
+ oh = find_hwmods_by_dev(mcbsp->dev);
/*
* Disable wakup behavior, smart idle and a
[PATCH 3/7] [RFC] OMAP: MCBSP: hwmod database for 4xxx devices
From: Benoit Cousson
MCBSP hwmod data values are auto-generated. The order of omap44xx_mcbsp3_slaves
contents are changed since the driver uses the base address of
omap44xx_l4_abe__mcbsp3_dma.
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Signed-off-by: Shubhrajyoti D
Cc: Partha Basak
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 293
1 files changed, 293 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 7274db4..1467840 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -811,6 +811,294 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_mcbsp_sysc = {
+ .sysc_offs = 0x008c,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mcbsp_hwmod_class = {
+ .name = "mcbsp",
+ .sysc = &omap44xx_mcbsp_sysc,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod omap44xx_mcbsp1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcbsp1_irqs[] = {
+ { .name = "tx", .irq = 17 + OMAP44XX_IRQ_GIC_START },
+ { .name = "rx", .irq = 0 },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcbsp1_sdma_reqs[] = {
+ { .name = "tx", .dma_req = 32 + OMAP44XX_DMA_REQ_START },
+ { .name = "rx", .dma_req = 33 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcbsp1_addrs[] = {
+ {
+ .pa_start = 0x40122000,
+ .pa_end = 0x401220ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe -> mcbsp1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp1 = {
+ .master = &omap44xx_l4_abe_hwmod,
+ .slave = &omap44xx_mcbsp1_hwmod,
+ .clk= "ocp_abe_iclk",
+ .addr = omap44xx_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcbsp1_addrs),
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcbsp1_dma_addrs[] = {
+ {
+ .pa_start = 0x49022000,
+ .pa_end = 0x490220ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe -> mcbsp1 (dma) */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp1_dma = {
+ .master = &omap44xx_l4_abe_hwmod,
+ .slave = &omap44xx_mcbsp1_hwmod,
+ .clk= "ocp_abe_iclk",
+ .addr = omap44xx_mcbsp1_dma_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcbsp1_dma_addrs),
+ .user = OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mcbsp1_slaves[] = {
+ &omap44xx_l4_abe__mcbsp1_dma,
+ &omap44xx_l4_abe__mcbsp1,
+};
+
+static struct omap_hwmod omap44xx_mcbsp1_hwmod = {
+ .name = "mcbsp1",
+ .class = &omap44xx_mcbsp_hwmod_class,
+ .mpu_irqs = omap44xx_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mcbsp1_irqs),
+ .sdma_reqs = omap44xx_mcbsp1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_mcbsp1_sdma_reqs),
+ .main_clk = "mcbsp1_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM1_ABE_MCBSP1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod omap44xx_mcbsp2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcbsp2_irqs[] = {
+ { .name = "tx", .irq = 22 + OMAP44XX_IRQ_GIC_START },
+ { .name = "rx", .irq = 0 },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcbsp2_sdma_reqs[] = {
+ { .name = "tx", .dma_req = 16 + OMAP44XX_DMA_REQ_START },
+ { .name = "rx", .dma_req = 17 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcbsp2_addrs[] = {
+ {
+ .pa_start = 0x40124000,
+ .pa_end = 0x401240ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe -> mcbsp2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp2 = {
+ .master = &omap44xx_l4_abe_hwmod,
+ .slave = &omap44xx_mcbsp2_hwmod,
+ .clk= "ocp_abe_iclk",
+ .addr = omap44xx_mcbsp2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcbsp2_addrs),
+ .user
[PATCH 4/7] [RFC] OMAP: hwmod implementation for MCBSP
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Signed-off-by: Shubhrajyoti D
Cc: Partha Basak
---
arch/arm/mach-omap2/mcbsp.c | 251 +--
arch/arm/plat-omap/include/plat/mcbsp.h |6 +-
arch/arm/plat-omap/mcbsp.c | 189 +++-
3 files changed, 159 insertions(+), 287 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index eba9fa1..25c6703 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -22,9 +22,13 @@
#include
#include
#include
+#include
+#include
#include "control.h"
+static struct omap_hwmod *oh_st_device[] = {NULL, NULL};
+static int no_of_st;
/* McBSP internal signal muxing functions */
@@ -101,199 +105,90 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
}
EXPORT_SYMBOL(omap2_mcbsp_set_clks_src);
-
-/* Platform data */
-
-#ifdef CONFIG_ARCH_OMAP2420
-static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
- {
- .phys_base = OMAP24XX_MCBSP1_BASE,
- .dma_rx_sync= OMAP24XX_DMA_MCBSP1_RX,
- .dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
- .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- },
+struct omap_device_pm_latency omap2_mcbsp_latency[] = {
{
- .phys_base = OMAP24XX_MCBSP2_BASE,
- .dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
- .dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
- .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
-#define OMAP2420_MCBSP_PDATA_SZARRAY_SIZE(omap2420_mcbsp_pdata)
-#define OMAP2420_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
-#else
-#define omap2420_mcbsp_pdata NULL
-#define OMAP2420_MCBSP_PDATA_SZ0
-#define OMAP2420_MCBSP_REG_NUM 0
-#endif
-#ifdef CONFIG_ARCH_OMAP2430
-static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
- {
- .phys_base = OMAP24XX_MCBSP1_BASE,
- .dma_rx_sync= OMAP24XX_DMA_MCBSP1_RX,
- .dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
- .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- },
- {
- .phys_base = OMAP24XX_MCBSP2_BASE,
- .dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
- .dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
- .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
- },
- {
- .phys_base = OMAP2430_MCBSP3_BASE,
- .dma_rx_sync= OMAP24XX_DMA_MCBSP3_RX,
- .dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
- .rx_irq = INT_24XX_MCBSP3_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP3_IRQ_TX,
- },
- {
- .phys_base = OMAP2430_MCBSP4_BASE,
- .dma_rx_sync= OMAP24XX_DMA_MCBSP4_RX,
- .dma_tx_sync= OMAP24XX_DMA_MCBSP4_TX,
- .rx_irq = INT_24XX_MCBSP4_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP4_IRQ_TX,
- },
- {
- .phys_base = OMAP2430_MCBSP5_BASE,
- .dma_rx_sync= OMAP24XX_DMA_MCBSP5_RX,
- .dma_tx_sync= OMAP24XX_DMA_MCBSP5_TX,
- .rx_irq = INT_24XX_MCBSP5_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP5_IRQ_TX,
- },
-};
-#define OMAP2430_MCBSP_PDATA_SZARRAY_SIZE(omap2430_mcbsp_pdata)
-#define OMAP2430_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
-#else
-#define omap2430_mcbsp_pdata NULL
-#define OMAP2430_MCBSP_PDATA_SZ0
-#define OMAP2430_MCBSP_REG_NUM 0
-#endif
+static int omap_init_mcbsp(struct omap_hwmod *oh, void *user)
+{
+ int id, count = 1, i;
+ char *name = "omap-mcbsp";
+ char dev_name[16];
+ struct omap_hwmod *oh_device[2];
+ struct omap_mcbsp_platform_data *pdata;
+ struct omap_device *od;
+
+ if (!oh) {
+ pr_err("%s:NULL hwmod pointer (oh)\n", __func__);
+ return -EINVAL;
+ }
-#ifdef CONFIG_ARCH_OMAP3
-static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = {
- {
- .phys_base = OMAP34XX_MCBSP1_BASE,
- .dma_rx_sync= OMAP24XX_DMA_MCBSP1_RX,
- .dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
- .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .buffer_size= 0x80, /* Th
[PATCH 2/7] [RFC] OMAP: MCBSP: hwmod database for 3xxx devices
From: Charulatha V
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Signed-off-by: Shubhrajyoti D
Cc: Partha Basak
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 426
1 files changed, 426 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 cb97ecf..c399783 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -39,6 +39,13 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp1_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp2_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp3_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -509,6 +516,418 @@ static struct omap_hwmod omap3xxx_uart4_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_mcbsp_sysc = {
+ .sysc_offs = 0x008c,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+ .clockact = 0x2,
+};
+
+static struct omap_hwmod_class omap3xxx_mcbsp_hwmod_class = {
+ .name = "mcbsp",
+ .sysc = &omap3xxx_mcbsp_sysc,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap3xxx_mcbsp1_irqs[] = {
+ { .name = "irq", .irq = 16 },
+ { .name = "tx", .irq = 59 },
+ { .name = "rx", .irq = 60 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_mcbsp1_sdma_chs[] = {
+ { .name = "rx", .dma_req = 32 },
+ { .name = "tx", .dma_req = 31 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_mcbsp1_addrs[] = {
+ {
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core -> mcbsp1 */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__mcbsp1 = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap3xxx_mcbsp1_hwmod,
+ .clk= "mcbsp1_ick",
+ .addr = omap3xxx_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_mcbsp1_slaves[] = {
+ &omap3xxx_l4_core__mcbsp1,
+};
+
+static struct omap_hwmod omap3xxx_mcbsp1_hwmod = {
+ .name = "mcbsp1",
+ .class = &omap3xxx_mcbsp_hwmod_class,
+ .mpu_irqs = omap3xxx_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_irqs),
+ .sdma_reqs = omap3xxx_mcbsp1_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_sdma_chs),
+ .main_clk = "mcbsp1_fck",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_MCBSP1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_EN_MCBSP1_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_irq_info omap3xxx_mcbsp2_irqs[] = {
+ { .name = "irq", .irq = 17 },
+ { .name = "tx", .irq = 62 },
+ { .name = "rx", .irq = 63 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_mcbsp2_sdma_chs[] = {
+ { .name = "rx", .dma_req = 34 },
+ { .name = "tx", .dma_req = 33 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_mcbsp2_addrs[] = {
+ {
+ .pa_start = 0x49022000,
+ .pa_end = 0x490220ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per -> mcbsp2 */
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__mcbsp2 = {
+ .master = &omap3xxx_l4_per_hwmod,
+ .slave = &omap3xxx_mcbsp2_hwmod,
+ .clk= "mcbsp2_ick",
+ .addr = omap3xxx_mcbsp2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_mcbsp2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp2 slave ports */
+static struct omap_hw
[PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices
From: Charulatha V
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Signed-off-by: Shubhrajyoti D
Cc: Partha Basak
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 125 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 313
2 files changed, 438 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 adf6e36..289ef86 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -36,6 +36,8 @@ static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_mcbsp1_hwmod;
+static struct omap_hwmod omap2420_mcbsp2_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -418,6 +420,127 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class omap2420_mcbsp_hwmod_class = {
+ .name = "mcbsp",
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap2420_mcbsp1_irqs[] = {
+ { .name = "tx", .irq = 59 },
+ { .name = "rx", .irq = 60 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp1_sdma_chs[] = {
+ { .name = "rx", .dma_req = 31 },
+ { .name = "tx", .dma_req = 30 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp1_addrs[] = {
+ {
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core -> mcbsp1 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp1 = {
+ .master = &omap2420_l4_core_hwmod,
+ .slave = &omap2420_mcbsp1_hwmod,
+ .clk= "mcbsp1_ick",
+ .addr = omap2420_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcbsp1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mcbsp1_slaves[] = {
+ &omap2420_l4_core__mcbsp1,
+};
+
+static struct omap_hwmod omap2420_mcbsp1_hwmod = {
+ .name = "mcbsp1",
+ .class = &omap2420_mcbsp_hwmod_class,
+ .mpu_irqs = omap2420_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mcbsp1_irqs),
+ .sdma_reqs = omap2420_mcbsp1_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_mcbsp1_sdma_chs),
+ .main_clk = "mcbsp1_fck",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+ },
+ },
+ .slaves = omap2420_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_irq_info omap2420_mcbsp2_irqs[] = {
+ { .name = "tx", .irq = 62 },
+ { .name = "rx", .irq = 63 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp2_sdma_chs[] = {
+ { .name = "rx", .dma_req = 33 },
+ { .name = "tx", .dma_req = 32 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp2_addrs[] = {
+ {
+ .pa_start = 0x48076000,
+ .pa_end = 0x480760ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core -> mcbsp2 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp2 = {
+ .master = &omap2420_l4_core_hwmod,
+ .slave = &omap2420_mcbsp2_hwmod,
+ .clk= "mcbsp2_ick",
+ .addr = omap2420_mcbsp2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcbsp2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcbsp2 slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mcbsp2_slaves[] = {
+ &omap2420_l4_core__mcbsp2,
+};
+
+static struct omap_hwmod omap2420_mcbsp2_hwmod = {
+ .name = "mcbsp2",
+ .class = &omap2420_mcbsp_hwmod_class,
+ .mpu_irqs = omap2420_mcbsp2_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mcbsp2_irqs),
+ .sdma_reqs = omap2420_mcbsp2_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_mcbsp2_sdma_chs),
+ .main_clk = "mcbsp2_fck",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MCBSP2_SHIFT,
+ .module_offs = CORE_MOD,
+
Re: [PATCH v2] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
"Varadarajan, Charulatha" writes: > Inorder to avoid any assumptions from bootloader, the watchdog > timer module is reset during init. This enables the watchdog > timer. > > Therefore, it is required to disable WDT after it is reset > during init. Otherwise the system would reboot as per the default > watchdog timer registers settings. > > Later, when the watchdog driver is loaded, the watchdog timer settings > is adjusted as per the default timer_margin set in the driver and the > driver would supports the normal operations supported by OMAP watchdog > timer. > > Link to related discussions: > https://patchwork.kernel.org/patch/219072/ > > Issue reported by Kevin can be found at: > https://patchwork.kernel.org/patch/217262/ > > Signed-off-by: Charulatha V > Reported-by: Kevin Hilman Acked-by: Kevin Hilman Tony, this should queue up for .37 on top of my pm-hwmods branch. It applies cleanly to current l-o master. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap: add dsp platform device
* Greg KH [101005 09:01]: > On Mon, Oct 04, 2010 at 07:09:14PM +0300, Felipe Contreras wrote: > > Otherwise tidspbridge cannot work. > > > > It looks like this was dropped in the conversion to staging. I took the > > liberty of doing some cleaning up. > > > > Signed-off-by: Felipe Contreras > > --- > > arch/arm/mach-omap2/Makefile |4 ++ > > arch/arm/mach-omap2/dsp.c | 85 > > + > > arch/arm/plat-omap/common.c |2 + > > arch/arm/plat-omap/devices.c | 30 > > arch/arm/plat-omap/include/plat/dsp.h | 31 > > I need an ack from some omap maintainers before I can take this into the > staging tree. Looks good to me Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe 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] omap: add dsp platform device
On Mon, Oct 04, 2010 at 07:09:14PM +0300, Felipe Contreras wrote: > Otherwise tidspbridge cannot work. > > It looks like this was dropped in the conversion to staging. I took the > liberty of doing some cleaning up. > > Signed-off-by: Felipe Contreras > --- > arch/arm/mach-omap2/Makefile |4 ++ > arch/arm/mach-omap2/dsp.c | 85 > + > arch/arm/plat-omap/common.c |2 + > arch/arm/plat-omap/devices.c | 30 > arch/arm/plat-omap/include/plat/dsp.h | 31 I need an ack from some omap maintainers before I can take this into the staging tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv2 01/11] staging: tidspbridge: replace iommu custom for opensource implementation
On Thu, Sep 30, 2010 at 09:12:48PM -0500, Fernando Guzman Lugo wrote: > Now the tidspbridge uses the API's from > iovmm module. > > Signed-off-by: Fernando Guzman Lugo This patch applied, but number 2 and others didn't. Care to respin those against the new linux-next tree and resend? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe 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] mfd: twl4030: add twl4030_bci platform_data back
* Grazvydas Ignotas [101001 03:09]: > Now that we have twl4030 charger driver, add back it's platform_data > (which was removed by f7ea2dc59ed46dcd0f1cfaccda02211f4507207b > as unused). > > Signed-off-by: Grazvydas Ignotas Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe 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] mfd: fix TWL4030 COR bit polarity for BCI SIH block
* Grazvydas Ignotas [100928 06:14]: > The chip TRM documentation contradicts itself about this bit, page 174 > of swcu050e says bit should be 0 for clear-on-read behavior, while > page 487 says it should be 1. Testing shows it should be 1, so set > the .set_cor flag accordingly. This is needed for upcoming BCI > charging driver to function. > > Signed-off-by: Grazvydas Ignotas Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe 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: OMAP hwmod driver conversions: watchdog, UART, i2c
Hi Paul,
On 10/5/2010 8:01 AM, Paul Walmsley wrote:
Hello Benoît, Rajendra, Kevin,
On Fri, 1 Oct 2010, Cousson, Benoit wrote:
The issue is that 2420 idlest does not reflect the real status of the OCP bus
clock, but just the fact that the idle_req is asserted or not.
So potentially, the IP is still not accessible when you think it is.
This imprecise external abort always happen when you try to access an IP that
is not properly clock.
BTW, this is exactly the same kind of issue we have with FDIF and ISS on
OMAP4.
Won't the new idle protocol resolve this for OMAP4 ?
In theory yes :-(
The easy quick and dirty fix is to comment out the sysconfig structure in the
hwmod definition. You will then prevent any access to the sysconfig.
Otherwise, I'm quite sure that a small udelay(1000) can help fixing such issue
as well.
Do not forget that 2420 is the very first implementation of the PRCM +
smartidle mechanism... It was broken for most IPs at that time :-)
Below is an untested patch to provide some mechanism to deal with this --
I'd appreciate everyone's comments on this, particularly the comments in
the patch code on how to deal with this problem.
I'll try it on OMAP4.
Thanks,
Benoit
- Paul
From: Paul Walmsley
Date: Mon, 4 Oct 2010 23:15:23 -0600
Subject: [PATCH] OMAP: hwmod: add configurable device enable delay after PRCM
IdleAck deasserts
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Some IP blocks may require extra time to become ready for register
reads/writes after the PRCM deasserts its IdleAck signal to the
module. If an imprecise external abort happens during or shortly
after the hwmod is enabled, extra time is needed[1]. For those
modules, add a new struct omap_hwmod field, .enable_delay. This field
represents the number of microseconds that the hwmod code should delay
before attempting to access the IP block's registers or relinquishing
control to the calling code.
Copious guidance is also provided to aid developers in determining the
appropriate hwmod value.
This problem was identified by Kevin Hilman and Rajendra Nayak.
Benoît Cousson identified the solution.
1. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36300.html
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Rajendra Nayak
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c |3 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 33 -
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 955861a..fbcfe14 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1204,6 +1204,9 @@ int _omap_hwmod_enable(struct omap_hwmod *oh)
r = _wait_target_ready(oh);
if (!r) {
+ if (oh->enable_delay)
+ udelay(oh->enable_delay);
+
oh->_state = _HWMOD_STATE_ENABLED;
/* Access the sysconfig only if the target is ready */
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index c1835af..5a1e058 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -434,6 +434,7 @@ struct omap_hwmod_class {
* @main_clk: main clock: OMAP clock name
* @_clk: pointer to the main struct clk (filled in at runtime)
* @opt_clks: other device clocks that drivers can request (0..*)
+ * @enable_delay: number of microseconds to wait after IdleReq is deasserted
* @masters: ptr to array of OCP ifs that this hwmod can initiate on
* @slaves: ptr to array of OCP ifs that this hwmod can respond on
* @dev_attr: arbitrary device attributes that can be passed to the driver
@@ -460,8 +461,35 @@ struct omap_hwmod_class {
* accesses to complete." Modules may not have a main clock if the
* interface clock also serves as a main clock.
*
- * Parameter names beginning with an underscore are managed internally by
- * the omap_hwmod code and should not be set during initialization.
+ * On OMAP SoCs prior to OMAP4, some hwmods may require a non-zero
+ * @enable_delay value. A hwmod needs a non-zero @enable_delay if an
+ * imprecise external abort occurs while the hwmod is being enabled.
+ * This can happen if the hwmod takes a significant time to become
+ * ready for OCP transactions after the PRCM deasserts IdleAck to the
+ * module. @enable_delay specifies the number of microseconds for the
+ * hwmod code to udelay() between the time that the PRCM deasserts the
+ * IdleAck, and the time when the module is ready to handle register
+ * reads/writes. Most hwmods shouldn't need anything here and can
+ * leave @enable_delay blank. For hwmods that do need a value here,
+ * to estimate the required value, the best thing to do is to set the
+ * IP block to run at the slowest interface and functional clock rates
+ * and the lowest voltages.
Re: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset
On Tue, 5 Oct 2010, Vishwanath BS wrote: > This patch adds comments on precatution to be taken if Global Warm reset is > used as the means to trigger sysem reset. > > Signed-off-by: Vishwanath BS > Cc: Paul Walmsley Thanks, queued for 2.6.38 with Sanjeev's spelling fix. - 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 3/3] OMAP: McBSP: Remove null omap44xx ops comment
On Tue, 5 Oct 2010, Jarkko Nikula wrote: > It seems these comments where accidentally added so remove them. > > Signed-off-by: Jarkko Nikula > Cc: Paul Walmsley Acked-by: Paul Walmsley - 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 1/3] OMAP: McBSP: Fix CLKR and FSR signal muxing
On Tue, 5 Oct 2010, Jarkko Nikula wrote: > Fix bit clear. Now it clears all other bits than mask bit where it should > clear only it. > > Signed-off-by: Jarkko Nikula > Cc: Paul Walmsley Doh. Thanks Jarkko. Obviously this is an important patch and should go in ASAP. Acked-by: Paul Walmsley - 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 2/3] OMAP: McBSP: Swap CLKS source definition
On Tue, 5 Oct 2010, Jarkko Nikula wrote: > This is just a readability and debugging improvement. As selection bit in > DEVCONF register is cleared when using 96 MHz PRCM source and set when using > external CLKS pin, change definitions to be sync with these. > > Signed-off-by: Jarkko Nikula > Cc: Paul Walmsley Acked-by: Paul Walmsley - 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
