Re: [v3.6 3/3] iommu/tegra: smmu: Fix unsleepable memory allocation at alloc_pdir()
joerg.roe...@amd.com joerg.roe...@amd.com wrote @ Tue, 17 Jul 2012 15:23:00 +0200: On Tue, Jul 17, 2012 at 02:25:24PM +0200, Hiroshi Doyu wrote: The above spin_lock is always necessary. as-lock should be held to protect as-pdir_page. Only when as-pdir_page is NULL, as-pdir_page would be allocated in alloc_pdir(). Without this lock, the following race could happen: Without as-lock: A: B: i == 3 pdir_page == NULL i == 3 pdir_page == NULL pdir_page = a; pdir_page = b; !! OVERWRITTEN !! Unless I am missing something, this is not the correct situation with my patch. It would look more like this: A: B: i == 3 pdir_page == NULL i == 3 pdir_page == NULL take as-lock /* race check */ pdir_page == NULL - proceed /* spinning on as-lock */ pdir_page = a; release as-lock take as-lock /* race check */ pdir_page != NULL - return This should be fine, no? Do I miss something? You are right. I didn't get the point of your patch. In the case that you can return -EAGAIN, the complicated lock,unlock,lock,check race is not necessary as you did. Verified the patch w/ Tegra3 based board. Please put this into next queue. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3.6 3/3] iommu/tegra: smmu: Fix unsleepable memory allocation at alloc_pdir()
Hi Joerg,
Joerg Roedel joerg.roe...@amd.com wrote @ Tue, 17 Jul 2012 12:09:01 +0200:
On Mon, Jul 02, 2012 at 02:26:38PM +0300, Hiroshi DOYU wrote:
Signed-off-by: Hiroshi DOYU hd...@nvidia.com
Reported-by: Chris Wright chr...@sous-sol.org
Cc: Chris Wright chr...@sous-sol.org
Acked-by: Stephen Warren swar...@wwwdotorg.org
Applied patch 2 and 3 but not patch 1. The resulting conflicts are
solved while merging the next branch. Also I am not happy with the way
the as-lock is taken and released multiple times in patch 3. So I added
another commit on-top. Please have a look at it as I can only
compile-test that change:
From f9a4f063a88297e361fd6676986cf3e39b22de72 Mon Sep 17 00:00:00 2001
From: Joerg Roedel joerg.roe...@amd.com
Date: Tue, 17 Jul 2012 11:47:14 +0200
Subject: [PATCH] iommu/tegra: Don't call alloc_pdir with as-lock
Instead of taking as-lock before calling alloc_pdir() and
releasing it in that function to allocate memory, just take
the lock only in the alloc_pdir function and run the loop
without any lock held. This simplifies the complicated
lock-unlock-alloc-lock-unlock sequence into
alloc-lock-unlock.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
drivers/iommu/tegra-smmu.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 68a15a0..541d210 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -553,11 +553,11 @@ static inline void put_signature(struct smmu_as *as,
#endif
/*
- * Caller must lock/unlock as
+ * Caller must not hold as-lock
*/
-static int alloc_pdir(struct smmu_as *as, unsigned long *flags)
+static int alloc_pdir(struct smmu_as *as)
{
- unsigned long *pdir;
+ unsigned long *pdir, flags;
int pdn, err = 0;
u32 val;
struct smmu_device *smmu = as-smmu;
@@ -565,13 +565,14 @@ static int alloc_pdir(struct smmu_as *as, unsigned long
*flags)
unsigned int *cnt;
/*
- * do the allocation outside the as-lock
+ * do the allocation, then grab as-lock
*/
- spin_unlock_irqrestore(as-lock, *flags);
cnt = devm_kzalloc(smmu-dev,
-sizeof(cnt[0]) * SMMU_PDIR_COUNT, GFP_KERNEL);
+sizeof(cnt[0]) * SMMU_PDIR_COUNT,
+GFP_KERNEL);
page = alloc_page(GFP_KERNEL | __GFP_DMA);
- spin_lock_irqsave(as-lock, *flags);
+
+ spin_lock_irqsave(as-lock, flags);
if (as-pdir_page) {
/* We raced, free the redundant */
@@ -603,9 +604,13 @@ static int alloc_pdir(struct smmu_as *as, unsigned long
*flags)
smmu_write(smmu, val, SMMU_TLB_FLUSH);
FLUSH_SMMU_REGS(as-smmu);
+ spin_unlock_irqrestore(as-lock, flags);
+
return 0;
err_out:
+ spin_unlock_irqrestore(as-lock, flags);
+
devm_kfree(smmu-dev, cnt);
if (page)
__free_page(page);
@@ -809,13 +814,11 @@ static int smmu_iommu_domain_init(struct iommu_domain
*domain)
/* Look for a free AS with lock held */
for (i = 0; i smmu-num_as; i++) {
as = smmu-as[i];
- spin_lock_irqsave(as-lock, flags);
if (!as-pdir_page) {
- err = alloc_pdir(as, flags);
+ err = alloc_pdir(as);
if (!err)
goto found;
The above spin_lock is always necessary. as-lock should be held to
protect as-pdir_page. Only when as-pdir_page is NULL,
as-pdir_page would be allocated in alloc_pdir(). Without this
lock, the following race could happen:
Without as-lock:
A: B:
i == 3
pdir_page == NULL
i == 3
pdir_page == NULL
pdir_page = a;
pdir_page = b; !! OVERWRITTEN !!
With as-lock:
A: B:
i == 3
lock(as-lock)
pdir_page == NULL
i == 3
Waiting lock released
Waiting lock released
pdir_page = a;
unlock(as-lock)
lock(as-lock)
pdir_page != NULL continue
unlock(as-lock)
i == 4
.
This lock, unlock, alloc, lock, check race method was originally
introduced by Russell King a few years ago(*1). And the same mechanism
has been used in omap iommu for years(*2) at least as below:
drivers/iommu/omap-iommu.c:
.
505 * do the allocation outside the page table lock
506 */
507 spin_unlock(obj-page_table_lock);
508 iopte = kmem_cache_zalloc(iopte_cachep, GFP_KERNEL);
509 spin_lock(obj-page_table_lock);
510
511 if (!*iopgd) {
512 if (!iopte)
513 return ERR_PTR(-ENOMEM);
514
515
Re: [PATCH 5/7] omap: iovmm: remove unused functionality
Hi Ohad, From: ext Ohad Ben-Cohen o...@wizery.com Subject: [PATCH 5/7] omap: iovmm: remove unused functionality Date: Thu, 18 Aug 2011 02:10:06 +0300 Remove unused functionality from OMAP's iovmm module. The intention is to eventually completely replace iovmm with the generic DMA-API, so new code that'd need this iovmm functionality will have to extend the DMA-API instead. Maybe it's better to remove the comments explaining unnecessary functions too. Now the function comparison table doesn't make sense From c42c675f62241099a10e4610640e6a60fb111f1f Mon Sep 17 00:00:00 2001 From: Hiroshi DOYU hiroshi.d...@nokia.com Date: Thu, 18 Aug 2011 13:13:53 +0300 Subject: [PATCH 1/1] omap: iommu: remove obsolete comments Remove ones referring to non-existing functions. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- drivers/iommu/omap-iovmm.c | 36 +--- 1 files changed, 1 insertions(+), 35 deletions(-) diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c index 81b713a..2db655c 100644 --- a/drivers/iommu/omap-iovmm.c +++ b/drivers/iommu/omap-iovmm.c @@ -1,7 +1,7 @@ /* * omap iommu: simple virtual address space management * - * Copyright (C) 2008-2009 Nokia Corporation + * Copyright (C) 2008-2009, 2011 Nokia Corporation * * Written by Hiroshi DOYU hiroshi.d...@nokia.com * @@ -25,40 +25,6 @@ #include plat/iopgtable.h -/* - * A device driver needs to create address mappings between: - * - * - iommu/device address - * - physical address - * - mpu virtual address - * - * There are 4 possible patterns for them: - * - *|iova/ mapping iommu_ page - *| da pa va (d)-(p)-(v) functiontype - * --- - * 1 | c c c1 - 1 - 1_kmap() / _kunmap() s - * 2 | c c,a c1 - 1 - 1 _kmalloc()/ _kfree()s - * 3 | c d c1 - n - 1_vmap() / _vunmap() s - * 4 | c d,a c1 - n - 1 _vmalloc()/ _vfree()n* - * - * - * 'iova': device iommu virtual address - * 'da': alias of 'iova' - * 'pa': physical address - * 'va': mpu virtual address - * - * 'c':contiguous memory area - * 'd':discontiguous memory area - * 'a':anonymous memory allocation - * '()': optional feature - * - * 'n':a normal page(4KB) size is used. - * 's':multiple iommu superpage(16MB, 1MB, 64KB, 4KB) size is used. - * - * '*':not yet, but feasible. - */ - static struct kmem_cache *iovm_area_cachep; /* return total bytes of sg buffers */ -- 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 6/7] omap: iommu: remove unused exported API
Hi Ohad,
Just small question inlined
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: [PATCH 6/7] omap: iommu: remove unused exported API
Date: Thu, 18 Aug 2011 02:10:07 +0300
Remove unused public APIs from OMAP's iommu driver.
IOMMU functionality should be exposed only via the generic IOMMU API;
this way drivers stay generic, and different IOMMU drivers
don't need to duplicate similar functionalities.
The rest of the API still exposed by OMAP's iommu will be evaluated
and eventually either added to the generic IOMMU API (if relevant),
or completely removed.
The intention is that OMAP's iommu driver will eventually not expose
any public API.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/include/plat/iommu.h |3 --
drivers/iommu/omap-iommu.c | 59
---
2 files changed, 0 insertions(+), 62 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 961b64f..eed5bdc 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -153,12 +153,9 @@ struct iommu_platform_data {
extern u32 iommu_arch_version(void);
extern void iotlb_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e);
-extern void iommu_set_twl(struct iommu *obj, bool on);
This function was introduced by Hari Kanigeri for some OMAP4 case,
which is only using TLB, not H/W table walk.
-extern void flush_iotlb_range(struct iommu *obj, u32 start, u32 end);
-extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
This function was introduced by David Cohen to specify the available
ISP virtual address range.
Both requirements were quite reasonable at that time. Not necessary anymore?
extern int iommu_set_isr(const char *name,
int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
void *priv),
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 7280e5b..d6b77c4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -357,26 +357,6 @@ static void flush_iotlb_page(struct iommu *obj, u32 da)
}
/**
- * flush_iotlb_range - Clear an iommu tlb entries
- * @obj: target iommu
- * @start: iommu device virtual address(start)
- * @end: iommu device virtual address(end)
- *
- * Clear an iommu tlb entry which includes 'da' address.
- **/
-void flush_iotlb_range(struct iommu *obj, u32 start, u32 end)
-{
- u32 da = start;
-
- while (da end) {
- flush_iotlb_page(obj, da);
- /* FIXME: Optimize for multiple page size */
- da += IOPTE_SIZE;
- }
-}
-EXPORT_SYMBOL_GPL(flush_iotlb_range);
-
-/**
* flush_iotlb_all - Clear all iommu tlb entries
* @obj: target iommu
**/
@@ -395,23 +375,6 @@ static void flush_iotlb_all(struct iommu *obj)
clk_disable(obj-clk);
}
-/**
- * iommu_set_twl - enable/disable table walking logic
- * @obj: target iommu
- * @on: enable/disable
- *
- * Function used to enable/disable TWL. If one wants to work
- * exclusively with locked TLB entries and receive notifications
- * for TLB miss then call this function to disable TWL.
- */
-void iommu_set_twl(struct iommu *obj, bool on)
-{
- clk_enable(obj-clk);
- arch_iommu-set_twl(obj, on);
- clk_disable(obj-clk);
-}
-EXPORT_SYMBOL_GPL(iommu_set_twl);
-
#if defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t bytes)
@@ -848,28 +811,6 @@ static int device_match_by_alias(struct device *dev,
void *data)
}
/**
- * iommu_set_da_range - Set a valid device address range
- * @obj: target iommu
- * @startStart of valid range
- * @end End of valid range
- **/
-int iommu_set_da_range(struct iommu *obj, u32 start, u32 end)
-{
-
- if (!obj)
- return -EFAULT;
-
- if (end start || !PAGE_ALIGN(start | end))
- return -EINVAL;
-
- obj-da_start = start;
- obj-da_end = end;
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(iommu_set_da_range);
-
-/**
* omap_find_iommu_device() - find an omap iommu device by name
* @name:name of the iommu device
*
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] omap: iommu migration, relocation and cleanups
Hi Ohad, From: ext Laurent Pinchart laurent.pinch...@ideasonboard.com Subject: Re: [PATCH 0/7] omap: iommu migration, relocation and cleanups Date: Thu, 18 Aug 2011 11:12:55 +0200 Hi Ohad, On Thursday 18 August 2011 01:10:01 Ohad Ben-Cohen wrote: 1. Migrate OMAP's iommu driver to the generic IOMMU API, and move it to the dedicated iommu folder. 2. Fix omap3isp appropriately so it doesn't break. 3. Adapt OMAP's iovmm appropriately as well, because omap3isp still relies on it. The plan is eventually to remove iovmm and replace it with the upcoming IOMMU-based generic DMA-API. Move iovmm to the iommu folder too; it belongs there more than it belongs in the OMAP folders. 4. Start cleaning up OMAP's iommu components towards the end goal, where 1) omap-iommu no longer exports public API (and instead provides its entire functionality via the generic IOMMU API). 2) omap-iovmm is removed. Good migration path! Changes: 1. Migrate iommu, iovmm and omap3isp in a single patch for bisectibility sake. 2. Apply Laurent Pinchart's comments (thanks Laurent!) You're welcome. 3. Rebase to 3.1-rc2 For the OMAP3 ISP driver changes, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com For the rest of omap iommu/iovmm patches, they look good: Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] omap: iovmm: remove unused functionality
From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH 5/7] omap: iovmm: remove unused functionality Date: Thu, 18 Aug 2011 13:23:44 +0300 On Thu, Aug 18, 2011 at 1:19 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: Maybe it's better to remove the comments explaining unnecessary functions too. Now the function comparison table doesn't make sense Sure, will do. From: Hiroshi DOYU hiroshi.d...@nokia.com Date: Thu, 18 Aug 2011 13:13:53 +0300 Subject: [PATCH 1/1] omap: iommu: remove obsolete comments Remove ones referring to non-existing functions. I think it might be better to squash it with the original patch though - are you ok with it ? Sure. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe 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] omap: iommu: PREFETCH_IOTLB cleanup
Hi Ohad,
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: [PATCH 4/7] omap: iommu: PREFETCH_IOTLB cleanup
Date: Thu, 18 Aug 2011 02:10:05 +0300
Use PREFETCH_IOTLB to control the content of the called function,
instead of inlining it in the code.
This improves readability of the code, and also prevents an unused
function warning to show up when PREFETCH_IOTLB isn't set.
Great, much better.
While we're at it, rename load_iotlb_entry to prefetch_iotlb_entry
to better reflect the purpose of that function.
Considering that, originally this function is the counterpart of
flush_iotlb_page() among load_iotlb_/flush_iotlb_*() family and
OMAP1 doesn't use H/W page table but only uses TLB(only
prefetch/load_tlb), what about keeping the original function
load_iotlb_entry(), and make inline function
prefetch_iotlb_entry() has it?
Something like below?
static int inline prefetch_iotlb_entry(struct iommu *obj, struct iotlb_entry *e)
{
return load_iotlb_entry(obj, e);
}
The above may keep a little bit more sense both for TLB only case too,
also for some function name consistency?
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/omap-iommu.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index ed81977..7280e5b 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -248,11 +248,12 @@ static struct cr_regs __iotlb_read_cr(struct iommu
*obj, int n)
}
/**
- * load_iotlb_entry - Set an iommu tlb entry
+ * prefetch_iotlb_entry - Set an iommu tlb entry
* @obj: target iommu
* @e: an iommu tlb entry info
**/
-static int load_iotlb_entry(struct iommu *obj, struct iotlb_entry *e)
+#ifdef PREFETCH_IOTLB
+static int prefetch_iotlb_entry(struct iommu *obj, struct iotlb_entry *e)
{
int err = 0;
struct iotlb_lock l;
@@ -309,6 +310,15 @@ out:
return err;
}
+#else /* !PREFETCH_IOTLB */
+
+static int prefetch_iotlb_entry(struct iommu *obj, struct iotlb_entry *e)
+{
+ return 0;
+}
+
+#endif /* !PREFETCH_IOTLB */
+
/**
* flush_iotlb_page - Clear an iommu tlb entry
* @obj: target iommu
@@ -662,10 +672,8 @@ int iopgtable_store_entry(struct iommu *obj, struct
iotlb_entry *e)
flush_iotlb_page(obj, e-da);
err = iopgtable_store_entry_core(obj, e);
-#ifdef PREFETCH_IOTLB
if (!err)
- load_iotlb_entry(obj, e);
-#endif
+ prefetch_iotlb_entry(obj, e);
return err;
}
EXPORT_SYMBOL_GPL(iopgtable_store_entry);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3 IOMMU fixes
From: Laurent Pinchart laurent.pinch...@ideasonboard.com Subject: [PATCH 0/2] OMAP3 IOMMU fixes Date: Mon, 30 May 2011 14:47:07 +0200 Hi everybody, Here are two OMAP3 IOMMU fixes required to support big and/or unaligned memory buffers. Laurent Pinchart (2): omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU omap3: iovmm: Support non page-aligned buffers in iommu_vmap Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com arch/arm/plat-omap/iovmm.c | 46 ++- 1 files changed, 36 insertions(+), 10 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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: iommu: fix pte attributes for super section
From: ext Anna, Suman s-a...@ti.com Subject: [PATCH] omap: iommu: fix pte attributes for super section Date: Tue, 10 May 2011 10:25:17 -0700 From 5796d8d8a0ea5aee342b78ca6ead229971cff6c5 Mon Sep 17 00:00:00 2001 From: Suman Anna s-a...@ti.com Date: Wed, 4 May 2011 17:45:37 -0500 Subject: [PATCH] omap: iommu: fix pte attributes for super section The PTE programming causes a 16MB entry to be interpreted as a 4K entry because of the bitwise check, and therefore does not set the attributes properly in the first-level descriptor table. The bitwise check has been replaced appropriately. Signed-off-by: Suman Anna s-a...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com Thanks, checked with OMAP2/3 TRM. -- To unsubscribe from this list: send the line unsubscribe 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: [URGENT - PATCH FOR 2.6.39] omap: iommu: Return IRQ_HANDLED in fault handler when no fault occured
From: ext Laurent Pinchart laurent.pinch...@ideasonboard.com Subject: Re: [URGENT - PATCH FOR 2.6.39] omap: iommu: Return IRQ_HANDLED in fault handler when no fault occured Date: Tue, 10 May 2011 14:39:56 +0200 Hi Tony, On Friday 29 April 2011 12:03:10 Laurent Pinchart wrote: Hi Tony, On Wednesday 27 April 2011 16:03:02 Laurent Pinchart wrote: The iommu shares an interrupt line with the OMAP3 ISP. The iommu interrupt handler must check the fault status and return IRQ_HANDLED when no fault occured. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Could you please pick this one up for 2.6.39 ? As far as I know David is on holidays so he might not be able to review the patch before the 2.6.39 release. Ping. Please. Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: iovmm: fix SW flags passed by user
From: ext Ramirez Luna, Omar omar.rami...@ti.com Subject: Re: [PATCH v2] OMAP: iovmm: fix SW flags passed by user Date: Fri, 15 Apr 2011 10:49:42 -0500 Hi Hiroshi, On Fri, Mar 25, 2011 at 3:04 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: Commit d038aee24dcd5a2a0d8547f5396f67ae9698ac8e omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag, changes iovmm to receive flags specified by user, however the upper 16 bits of the flags are wiped by iovmm itself. This fixes IOVMF_DA_FIXED flags from being lost, and lets the user map its desired device addresses. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- v2: Include missing reference (commit and name) to patch in description. If no comments, could you ack this patch? Tony, please put this in your queue too. -- To unsubscribe from this list: send the line unsubscribe 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: plat-omap: iommu: fix request_mem_region() error path
Hi Aaro, From: Aaro Koskinen aaro.koski...@nokia.com Subject: [PATCH] arm: plat-omap: iommu: fix request_mem_region() error path Date: Mon, 14 Mar 2011 14:28:32 +0200 request_mem_region() error exit will leak ioremapped memory. Fix this by moving the ioremap() after request_mem_region(), which is the proper order to do this anyway. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com --- arch/arm/plat-omap/iommu.c | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) True. Thank you for catching this. -- To unsubscribe from this list: send the line unsubscribe 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: iommu: disallow mapping NULL address
From: ext David Cohen daco...@gmail.com Subject: Re: [PATCH] omap: iommu: disallow mapping NULL address Date: Mon, 7 Mar 2011 21:41:21 +0200 On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones michael.jo...@matrix-vision.de wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Hm. Looks like the iommu should not restrict any da. The valid da range should rely only on pdata. Michael, what about just update ISP's da_start on omap-iommu.c file? Set it to 0x1000. Hiroshi, any opinion? We have assumed that 'da == 0' is NULL so far. According to Fernando's explanation, 'da == 0' should be allowed in iovmm layer by default. -- To unsubscribe from this list: send the line unsubscribe 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: iommu: disallow mapping NULL address
From: ext David Cohen daco...@gmail.com Subject: Re: [PATCH] omap: iommu: disallow mapping NULL address Date: Mon, 7 Mar 2011 23:35:31 +0200 On Mon, Mar 7, 2011 at 11:19 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi David, Hi Laurent, On Monday 07 March 2011 20:41:21 David Cohen wrote: On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 1:19 PM, David Cohen wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Hm. Looks like the iommu should not restrict any da. The valid da range should rely only on pdata. Michael, what about just update ISP's da_start on omap-iommu.c file? Set it to 0x1000. What about patching the OMAP3 ISP driver to use a non-zero value (maybe -1) as an invalid/freed pointer ? I wouldn't be comfortable to use 0 (or NULL) value as valid address on ISP driver. The 'da' range (da_start and da_end) is defined per VM and specified as platform data. IMO, to set da_start = 0x1000 seems to be a correct approach for ISP as it's the only client for its IOMMU instance. Sounds reasonable to me too. Considering 'da == 0' as invalid can be reasonably acceptable intuitively in most cases, and just let it allowed theoretically. -- To unsubscribe from this list: send the line unsubscribe 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/3] omap: iovmm: Fix IOVMM check for fixed 'da'
From: ext David Cohen daco...@gmail.com Subject: [PATCH 0/3] omap: iovmm: Fix IOVMM check for fixed 'da' Date: Tue, 8 Mar 2011 14:46:02 +0200 IOVMM driver checks input 'da == 0' when mapping address to determine whether user wants fixed 'da' or not. At the same time, it doesn't disallow address 0x0 to be used, what creates an ambiguous situation. This patch set moves fixed 'da' check to the input flags. It also fixes da_start value for ISP IOMMU instance. David Cohen (2): omap3: change ISP's IOMMU da_start address omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED/IOVMF_DA_ANON flags Michael Jones (1): omap: iovmm: disallow mapping NULL address arch/arm/mach-omap2/omap-iommu.c |2 +- arch/arm/plat-omap/iovmm.c | 28 ++-- 2 files changed, 19 insertions(+), 11 deletions(-) Based on the previous discussion, those look ok for me. -- To unsubscribe from this list: send the line unsubscribe 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: iovmm: don't check 'da' to set IOVMF_DA_FIXED/IOVMF_DA_ANON flags
From: ext Guzman Lugo, Fernando fernando.l...@ti.com Subject: Re: [PATCH 3/3] omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED/IOVMF_DA_ANON flags Date: Tue, 8 Mar 2011 11:59:43 -0600 On Tue, Mar 8, 2011 at 6:46 AM, David Cohen daco...@gmail.com wrote: Currently IOVMM driver sets IOVMF_DA_FIXED/IOVMF_DA_ANON flags according to input 'da' address when mapping memory: da == 0: IOVMF_DA_ANON da != 0: IOVMF_DA_FIXED It prevents IOMMU to map first page with fixed 'da'. To avoid such issue, IOVMM will not automatically set IOVMF_DA_FIXED. It should now come from the user. IOVMF_DA_ANON will be automatically set if IOVMF_DA_FIXED isn't set. Signed-off-by: David Cohen daco...@gmail.com --- arch/arm/plat-omap/iovmm.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 11c9b76..dde9cb0 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -654,7 +654,8 @@ u32 iommu_vmap(struct iommu *obj, u32 da, const struct sg_table *sgt, flags = IOVMF_HW_MASK; flags |= IOVMF_DISCONT; flags |= IOVMF_MMIO; - flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON); + if (~flags IOVMF_DA_FIXED) + flags |= IOVMF_DA_ANON; could we use only one? both are mutual exclusive, what happen if flag is IOVMF_DA_FIXED | IOVMF_DA_ANON? so, I suggest to get rid of IOVMF_DA_ANON. Then, what about introducing some MACRO? Better names? #define set_iovmf_da_anon(flags) #define set_iovmf_da_fix(flags) #define set_iovmf_mmio(flags) .. -- To unsubscribe from this list: send the line unsubscribe 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: omap3isp cache error when unloading
From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Subject: Re: omap3isp cache error when unloading Date: Fri, 4 Mar 2011 09:38:22 +0200 Hi Michael, Michael Jones wrote: On 03/02/2011 08:18 PM, Laurent Pinchart wrote: Hi Michael, On Tuesday 01 March 2011 17:41:01 Michael Jones wrote: Hi all, I get a warning about a cache error with the following steps: 0. load omap3-isp 1. set up media broken media pipeline. (e.g. set different formats on opposite ends of a link, as will be the case for using the lane shifter) 2. try to capture images. isp_video_streamon() returns -EPIPE from the failed isp_video_validate_pipeline() call. 3. unload omap3-isp module then I get the following from kmem_cache_destroy(): slab error in kmem_cache_destroy(): cache `iovm_area_cache': Can't free all objects [c0040318] (unwind_backtrace+0x0/0xec) from [c00bfe14] (kmem_cache_destroy+0x88/0xf4) [c00bfe14] (kmem_cache_destroy+0x88/0xf4) from [c00861f8] (sys_delete_module+0x1c4/0x230) [c00861f8] (sys_delete_module+0x1c4/0x230) from [c003b680] (ret_fast_syscall+0x0/0x30) Then, when reloading the module: SLAB: cache with size 32 has lost its name Can somebody else confirm that they also observe this behavior? I can't reproduce that (tried both 2.6.32 and 2.6.37). Could you give me some more details about your exact test procedure (such as how you configure the pipeline) ? Sorry, I should've mentioned: I'm using your media-0005-omap3isp branch based on 2.6.38-rc5. I didn't have the problem with 2.6.37, either. It's actually not related to mis-configuring the ISP pipeline like I thought at first- it also happens after I have successfully captured images. I've since tracked down the problem, although I don't understand the cache management well enough to be sure it's a proper fix, so hopefully some new recipients on this can make suggestions/comments. The patch below solves the problem, which modifies a commit by Fernando Guzman Lugo from December. Thanks for the patch. It looks like this patch from Fernando, perhaps unintentionally, also makes the first page mappable so the NULL address is also valid. The NULL address isn't considered valid by the ISP driver which thus does not iommu_vunmap() the NULL address. Hiroshi, David, what do you think? I think the patch is correct so it could be applied with description changed to mention it disallows mapping the first page again. Or is there a reason to allow mapping the first page automatically? I personally don't see any. I think that was done unintentionally. The invalid first page may be quite reasonable generally. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen daco...@gmail.com
Subject: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault
handling
Date: Wed, 16 Feb 2011 21:35:51 +0200
Add support to register an isr for IOMMU fault situations and adapt it
to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
module might want to be informed when errors happen in order to debug it
or react.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c| 17 +-
arch/arm/plat-omap/include/plat/iommu.h | 14 -
arch/arm/plat-omap/iommu.c | 52
++-
3 files changed, 65 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 49a1e5e..adb083e 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -146,18 +146,31 @@ static void omap2_iommu_set_twl(struct iommu *obj, bool
on)
static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
{
u32 stat, da;
+ u32 errs = 0;
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat = MMU_IRQ_MASK;
- if (!stat)
+ if (!stat) {
+ *ra = 0;
return 0;
+ }
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
+ if (stat MMU_IRQ_TLBMISS)
+ errs |= OMAP_IOMMU_ERR_TLB_MISS;
+ if (stat MMU_IRQ_TRANSLATIONFAULT)
+ errs |= OMAP_IOMMU_ERR_TRANS_FAULT;
+ if (stat MMU_IRQ_EMUMISS)
+ errs |= OMAP_IOMMU_ERR_EMU_MISS;
+ if (stat MMU_IRQ_TABLEWALKFAULT)
+ errs |= OMAP_IOMMU_ERR_TBLWALK_FAULT;
+ if (stat MMU_IRQ_MULTIHITFAULT)
+ errs |= OMAP_IOMMU_ERR_MULTIHIT_FAULT;
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
- return stat;
+ return errs;
}
static void omap2_tlb_read_cr(struct iommu *obj, struct cr_regs *cr)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 19cbb5e..174f1b9 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -31,6 +31,7 @@ struct iommu {
struct clk *clk;
void __iomem*regbase;
struct device *dev;
+ void*isr_priv;
Ideally I'd like to avoid having isr_priv in iommu since it's not
used for iommu but client needs the place to pass its info to its
custom handler. Any better idea?
unsigned intrefcount;
struct mutexiommu_lock; /* global for this whole object */
@@ -47,7 +48,7 @@ struct iommu {
struct list_headmmap;
struct mutexmmap_lock; /* protect mmap */
- int (*isr)(struct iommu *obj);
+ int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs, void *priv);
void *ctx; /* iommu context: registres saved area */
u32 da_start;
@@ -109,6 +110,13 @@ struct iommu_platform_data {
u32 da_end;
};
+/* IOMMU errors */
+#define OMAP_IOMMU_ERR_TLB_MISS (1 0)
+#define OMAP_IOMMU_ERR_TRANS_FAULT (1 1)
+#define OMAP_IOMMU_ERR_EMU_MISS (1 2)
+#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 3)
+#define OMAP_IOMMU_ERR_MULTIHIT_FAULT(1 4)
+
#if defined(CONFIG_ARCH_OMAP1)
#error iommu for this processor not implemented yet
#else
@@ -161,6 +169,10 @@ extern size_t iopgtable_clear_entry(struct iommu *obj,
u32 iova);
extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
extern struct iommu *iommu_get(const char *name);
extern void iommu_put(struct iommu *obj);
+extern int iommu_set_isr(const char *name,
+ int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
+ void *priv),
+ void *isr_priv);
extern void iommu_save_ctx(struct iommu *obj);
extern void iommu_restore_ctx(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index f55f458..b0e0efc 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -780,25 +780,19 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
*/
static irqreturn_t iommu_fault_handler(int irq, void *data)
{
- u32 stat, da;
+ u32 da, errs;
u32 *iopgd, *iopte;
- int err = -EIO;
struct iommu *obj = data;
if (!obj-refcount)
return IRQ_NONE;
- /* Dynamic loading TLB or PTE */
- if (obj-isr)
- err = obj-isr(obj);
-
- if (!err)
- return IRQ_HANDLED;
-
clk_enable(obj-clk);
- stat = iommu_report_fault(obj, da);
+ errs = iommu_report_fault(obj, da);
clk_disable(obj-clk);
- if (!stat)
+
+ /* Fault callback or TLB/PTE Dynamic loading */
+ if (obj-isr !obj-isr(obj, da, errs, obj-isr_priv))
return IRQ_HANDLED;
iommu_disable(obj);
@@ -806,15 +800,16 @@ static irqreturn_t
Re: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: ext David Cohen daco...@gmail.com
Subject: Re: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault
handling
Date: Mon, 21 Feb 2011 11:07:01 +0200
On Mon, Feb 21, 2011 at 10:18 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: David Cohen daco...@gmail.com
Subject: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault
handling
Date: Wed, 16 Feb 2011 21:35:51 +0200
Add support to register an isr for IOMMU fault situations and adapt it
to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
module might want to be informed when errors happen in order to debug it
or react.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c | 17 +-
arch/arm/plat-omap/include/plat/iommu.h | 14 -
arch/arm/plat-omap/iommu.c | 52
++-
3 files changed, 65 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 49a1e5e..adb083e 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -146,18 +146,31 @@ static void omap2_iommu_set_twl(struct iommu *obj,
bool on)
static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
{
u32 stat, da;
+ u32 errs = 0;
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat = MMU_IRQ_MASK;
- if (!stat)
+ if (!stat) {
+ *ra = 0;
return 0;
+ }
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
+ if (stat MMU_IRQ_TLBMISS)
+ errs |= OMAP_IOMMU_ERR_TLB_MISS;
+ if (stat MMU_IRQ_TRANSLATIONFAULT)
+ errs |= OMAP_IOMMU_ERR_TRANS_FAULT;
+ if (stat MMU_IRQ_EMUMISS)
+ errs |= OMAP_IOMMU_ERR_EMU_MISS;
+ if (stat MMU_IRQ_TABLEWALKFAULT)
+ errs |= OMAP_IOMMU_ERR_TBLWALK_FAULT;
+ if (stat MMU_IRQ_MULTIHITFAULT)
+ errs |= OMAP_IOMMU_ERR_MULTIHIT_FAULT;
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
- return stat;
+ return errs;
}
static void omap2_tlb_read_cr(struct iommu *obj, struct cr_regs *cr)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 19cbb5e..174f1b9 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -31,6 +31,7 @@ struct iommu {
struct clk *clk;
void __iomem *regbase;
struct device *dev;
+ void *isr_priv;
Ideally I'd like to avoid having isr_priv in iommu since it's not
used for iommu but client needs the place to pass its info to its
custom handler. Any better idea?
(*isr)() relies in the same situation, as it belongs to the client.
Without this priv_data, it's necessary to create a global variable to
store client's private data on client side. IMO, it is worse.
Ok, I see. Let's go with this. Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] OMAP: IOMMU fault callback support
From: David Cohen daco...@gmail.com Subject: [PATCH v3 0/2] OMAP: IOMMU fault callback support Date: Wed, 16 Feb 2011 21:35:49 +0200 Hi, This patch set adapts current (*isr)() to be used as fault callback. IOMMU faults might be very difficult to reproduce and then to figure out the source of the problem. Currently IOMMU driver prints not so useful debug message and does not notice user about such issue. With a fault callback, IOMMU user may debug much more useful information and/or react to go back to a valid state. Tony, please put them in your queue too. Thanks. Br, David --- David Cohen (2): OMAP2+: IOMMU: don't print fault warning on specific layer OMAP: IOMMU: add support to callback during fault handling Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com arch/arm/mach-omap2/iommu2.c| 33 +--- arch/arm/plat-omap/include/plat/iommu.h | 14 - arch/arm/plat-omap/iommu.c | 52 ++- 3 files changed, 65 insertions(+), 34 deletions(-) -- 1.7.2.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 v2] OMAP: IOMMU: add missing function declaration
From: David Cohen daco...@gmail.com Subject: [PATCH v2] OMAP: IOMMU: add missing function declaration Date: Tue, 15 Feb 2011 13:31:13 +0200 Declaration of exported function 'iopgtable_lookup_entry' is missing from header file. Currently we have a sparse warning as it's not being used externally. Adding its declaration to avoid such warning and allow its usage in future. Signed-off-by: David Cohen daco...@gmail.com --- arch/arm/plat-omap/include/plat/iommu.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Thanks. Tony, Please put this into your queue. -- To unsubscribe from this list: send the line unsubscribe 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 1/1] OMAP: IOMMU: add support to callback during fault handling
Hi David,
Sorry for a bit late reply
From: David Cohen daco...@gmail.com
Subject: [PATCH v2 1/1] OMAP: IOMMU: add support to callback during fault
handling
Date: Tue, 15 Feb 2011 16:36:31 +0200
Add support to register a callback for IOMMU fault situations. Drivers using
IOMMU module might want to be informed when such errors happen in order to
debug it or react.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/iommu2.c| 21 +--
arch/arm/plat-omap/include/plat/iommu.h | 15 ++-
arch/arm/plat-omap/iommu.c | 41
---
3 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..504310d 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -143,10 +143,10 @@ static void omap2_iommu_set_twl(struct iommu *obj, bool
on)
__iommu_set_twl(obj, false);
}
-static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
+static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra, u32 *iommu_errs)
{
int i;
- u32 stat, da;
+ u32 stat, da, errs;
const char *err_msg[] = {
tlb miss,
translation fault,
@@ -157,8 +157,10 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32
*ra)
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat = MMU_IRQ_MASK;
- if (!stat)
+ if (!stat) {
+ *iommu_errs = 0;
return 0;
+ }
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
@@ -171,6 +173,19 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32
*ra)
}
printk(\n);
+ errs = 0;
+ if (stat MMU_IRQ_TLBMISS)
+ errs |= OMAP_IOMMU_ERR_TLB_MISS;
+ if (stat MMU_IRQ_TRANSLATIONFAULT)
+ errs |= OMAP_IOMMU_ERR_TRANS_FAULT;
+ if (stat MMU_IRQ_EMUMISS)
+ errs |= OMAP_IOMMU_ERR_EMU_MISS;
+ if (stat MMU_IRQ_TABLEWALKFAULT)
+ errs |= OMAP_IOMMU_ERR_TBLWALK_FAULT;
+ if (stat MMU_IRQ_MULTIHITFAULT)
+ errs |= OMAP_IOMMU_ERR_MULTIHIT_FAULT;
+ *iommu_errs = errs;
+
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
return stat;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 19cbb5e..5a2475f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -31,6 +31,7 @@ struct iommu {
struct clk *clk;
void __iomem*regbase;
struct device *dev;
+ void*fault_cb_priv;
unsigned intrefcount;
struct mutexiommu_lock; /* global for this whole object */
@@ -48,6 +49,7 @@ struct iommu {
struct mutexmmap_lock; /* protect mmap */
int (*isr)(struct iommu *obj);
+ void (*fault_cb)(struct iommu *obj, u32 da, u32 iommu_errs, void *priv);
What about making use of (*isr)() for fault call back as well?
Basic concept is that, client can decide how to deal with iommu
fault. For example, for advanced case, client wants daynamic loading of
TLB(or PTE), or for ISP case, clients just want more appropriate fault
reporting. This (*isr)() could be used in such flexibility.
785 * Device IOMMU generic operations
786 */
787 static irqreturn_t iommu_fault_handler(int irq, void *data)
788 {
789 u32 stat, da;
790 u32 *iopgd, *iopte;
791 int err = -EIO;
792 struct iommu *obj = data;
793
794 if (!obj-refcount)
795 return IRQ_NONE;
796
797 /* Dynamic loading TLB or PTE */
798 if (obj-isr)
799 err = obj-isr(obj);
800
801 if (!err)
802 return IRQ_HANDLED;
803
804 clk_enable(obj-clk);
805 stat = iommu_report_fault(obj, da);
806 clk_disable(obj-clk);
807 if (!stat)
808 return IRQ_HANDLED;
809
810 iommu_disable(obj);
I guess that this modifying the above code could make (*isr)()
flexible to be used for any purpose for clients? For me, having both
following may be a bit residual.
int (*isr)(struct iommu *obj);
+ void (*fault_cb)(struct iommu *obj, u32 da, u32 iommu_errs, void *priv);
--
To unsubscribe from this list: send the line unsubscribe 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 iommu: print module name on error messages
From: ext David Cohen daco...@gmail.com Subject: [PATCH] omap iommu: print module name on error messages Date: Sat, 12 Feb 2011 12:02:29 +0200 OMAP IOMMU generic layer doesn't need ot print function name during error messages. Print module name instead which is more useful. Agree. This makes more sense. Signed-off-by: David Cohen daco...@gmail.com --- arch/arm/plat-omap/iommu.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/5] omap: mailbox: hwmod support
From: ext Tony Lindgren t...@atomide.com Subject: Re: [PATCH v5 0/5] omap: mailbox: hwmod support Date: Wed, 9 Feb 2011 10:32:19 -0800 * Omar Ramirez Luna omar.rami...@ti.com [110202 11:37]: Mailbox hwmod support for OMAP 2,3,4. Hiroshi, any comments on these? Well, I haven't followed hwmod much. If Kevin is ok, ok for me. -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv5 0/4] omap: iovmm - fixes for iovmm module
From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCHv5 0/4] omap: iovmm - fixes for iovmm module Date: Mon, 25 Oct 2010 21:10:02 +0200 Version 5: * Changes in iommu: create new api to set valid da range - Change range variables to platform data structure. Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/4] iommu: create new api to set valid da range
From: ext felipe.contre...@gmail.com felipe.contre...@gmail.com Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range Date: Wed, 20 Oct 2010 10:35:50 +0200 On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo x0095...@ti.com wrote: Some IOMMUs cannot use the whole 0x0 - 0x range. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com I don't see the point in having an API. It could be done through platform data, and the usage of 0xF000 instead of ULONG_MAX is independent of this. Using platform data is better, but why dropping da_end? -- To unsubscribe from this list: send the line unsubscribe 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 4/4] iommu: create new api to set valid da range
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range Date: Wed, 20 Oct 2010 10:58:16 +0200 On Wed, Oct 20, 2010 at 11:45 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext felipe.contre...@gmail.com felipe.contre...@gmail.com Subject: Re: [PATCHv4 4/4] iommu: create new api to set valid da range Date: Wed, 20 Oct 2010 10:35:50 +0200 On Wed, Oct 20, 2010 at 5:48 AM, Fernando Guzman Lugo x0095...@ti.com wrote: Some IOMMUs cannot use the whole 0x0 - 0x range. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com I don't see the point in having an API. It could be done through platform data, and the usage of 0xF000 instead of ULONG_MAX is independent of this. Using platform data is better, but why dropping da_end? Because it's always 0xF000. Do you know of any instance where it's not? We should try to avoid forcing unnecessary limitations and dependencies. The usage of device virtual address space range depends on dsp(coprocessor) side S/W implimentation or configuration. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap
Hi Fernando, From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Date: Thu, 14 Oct 2010 04:27:36 +0200 Omap platform is omap_iounmap function. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 93a34d9..5489ca9 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da) struct sg_table *sgt; typedef void (*func_t)(const void *); - sgt = unmap_vm_area(obj, da, (func_t)__iounmap, + sgt = unmap_vm_area(obj, da, (func_t)iounmap, Woundn't the above be enough? Eventually this iounmap() calls __arch_iounmap() - omap_iounmap(). I don't see any special reason to call omap_iounmap() here for now. + sgt = unmap_vm_area(obj, da, (func_t)omap_iounmap, IOVMF_LINEAR | IOVMF_MMIO); if (!sgt) dev_dbg(obj-dev, %s: No sgt\n, __func__); -- 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 3/4] iovmm: replace __iounmap with omap_iounmap
From: ext Guzman Lugo, Fernando fernando.l...@ti.com Subject: RE: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Date: Thu, 14 Oct 2010 10:18:30 +0200 From: Hiroshi DOYU [hiroshi.d...@nokia.com] Sent: Thursday, October 14, 2010 1:45 AM To: Guzman Lugo, Fernando Cc: felipe.contre...@nokia.com; t...@atomide.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Hi Fernando, From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Date: Thu, 14 Oct 2010 04:27:36 +0200 Omap platform is omap_iounmap function. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 93a34d9..5489ca9 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da) struct sg_table *sgt; typedef void (*func_t)(const void *); - sgt = unmap_vm_area(obj, da, (func_t)__iounmap, + sgt = unmap_vm_area(obj, da, (func_t)iounmap, Woundn't the above be enough? Eventually this iounmap() calls __arch_iounmap() - omap_iounmap(). I don't see any special reason to call omap_iounmap() here for now. iounmap and __arch_iounmap are macros they cannot not be used there. If so, it gives a undeclared compile error. Ok. I'll add this explanation as a note on this commit. -- To unsubscribe from this list: send the line unsubscribe 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: iommu: make iva2 iommu selectable
From: ext Felipe Contreras felipe.contre...@gmail.com
Subject: [PATCH 1/2] omap: iommu: make iva2 iommu selectable
Date: Mon, 11 Oct 2010 11:53:49 +0200
From: Felipe Contreras felipe.contre...@nokia.com
It seems dsp-link will do this, and tidspbridge too at some point, but
right now it's not possible to select CONFIG_MPU_BRIDGE_IOMMU.
Why does it have to be selectable?
Please Cc: linux-arm-ker...@lists.infradead.org too.
Cc: Fernando Guzman Lugo fernando.l...@ti.com
Cc: Yogesh Marathe yogesh_mara...@ti.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
arch/arm/mach-omap2/omap-iommu.c |2 +-
arch/arm/plat-omap/Kconfig |3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c
b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..adc0904 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -35,7 +35,7 @@ static struct iommu_device omap3_devices[] = {
.clk_name = cam_ick,
},
},
-#if defined(CONFIG_MPU_BRIDGE_IOMMU)
+#if defined(CONFIG_OMAP_IOMMU_IVA2)
{
.base = 0x5d00,
.irq = 28,
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index e39a417..e0b41b6 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -109,6 +109,9 @@ config OMAP_IOMMU_DEBUG
Say N unless you know you need this.
+config OMAP_IOMMU_IVA2
+ bool
+
choice
prompt System timer
default OMAP_32K_TIMER if !ARCH_OMAP15XX
--
1.7.3.1.2.g7fe2b
--
To unsubscribe from this list: send the line unsubscribe 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] iovmm: IVA2 MMU range is from 0x11000000 to 0xFFFFFFFF
From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCH] iovmm: IVA2 MMU range is from 0x1100 to 0x Date: Thu, 7 Oct 2010 20:43:41 +0200 IV2 MMU capable addresses start from 0x1100 Wouldn't it be better to add an general API to configure the valid 'da' range in advance? I don't think that it's a good idea to introduce the iommu instance(iva2:iommu) specific code here. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] arm: remove cast from void*
Hi Matt, From: ext matt mooney m...@muteddisk.com Subject: [PATCH 3/4] arm: remove cast from void* Date: Tue, 14 Sep 2010 07:30:16 +0200 Unnecessary cast from void* in assignment. Signed-off-by: matt mooney m...@muteddisk.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig
On Thu, 9 Sep 2010 07:58:55 +0200 ext Felipe Balbi ba...@ti.com wrote: On Thu, Sep 09, 2010 at 12:04:45AM -0500, Hiroshi DOYU wrote: Hi Sanjeev, From: ext Sanjeev Premi pr...@ti.com Subject: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Wed, 8 Sep 2010 16:51:21 +0200 The menu option to select CONFIG_OMAP_IOMMU was not visible in the menuconfig due to missing description. There's no point to make OMAP_IOMMU visible since this is a kind of feature used by other device implicitly. OMAP_IOMMU on menu might confuse users at kernel menuconfig. Instead this should be automatically selected by its clients when it is selected. For exmaple, the case that DSP or Tesla is selected. There was a discussion about this before. in that case... @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + tristate OMAP IOMMU support it doesn't have to be tristate as select will always mark it 'y' Right;p -- To unsubscribe from this list: send the line unsubscribe 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: OMAP_IOMMU not visible in menuconfig
Hi Sanjeev, From: ext Sanjeev Premi pr...@ti.com Subject: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Wed, 8 Sep 2010 16:51:21 +0200 The menu option to select CONFIG_OMAP_IOMMU was not visible in the menuconfig due to missing description. There's no point to make OMAP_IOMMU visible since this is a kind of feature used by other device implicitly. OMAP_IOMMU on menu might confuse users at kernel menuconfig. Instead this should be automatically selected by its clients when it is selected. For exmaple, the case that DSP or Tesla is selected. There was a discussion about this before. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e39a417..2a114a9 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + tristate OMAP IOMMU support config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS -- 1.6.2.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 -- To unsubscribe from this list: send the line unsubscribe 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: OMAP_IOMMU not visible in menuconfig
From: ext Premi, Sanjeev pr...@ti.com Subject: RE: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Thu, 9 Sep 2010 07:10:05 +0200 -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Thursday, September 09, 2010 10:35 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Hi Sanjeev, From: ext Sanjeev Premi pr...@ti.com Subject: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Wed, 8 Sep 2010 16:51:21 +0200 The menu option to select CONFIG_OMAP_IOMMU was not visible in the menuconfig due to missing description. There's no point to make OMAP_IOMMU visible since this is a kind of feature used by other device implicitly. OMAP_IOMMU on menu might confuse users at kernel menuconfig. Instead this should be automatically selected by its clients when it is selected. For exmaple, the case that DSP or Tesla is selected. There was a discussion about this before. [sp] You would have noticed that there are mnay OMAP3 variants and some of them are ARM only - detection being runtime, not compile time. All these processors share same defconfig. Setting dependency correctly could solve this? Modified drivers/staging/tidspbridge/Kconfig 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 Keeping/ maintaining specific defconfigs for each processor will be too difficult. ~sanjeev Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e39a417..2a114a9 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + tristate OMAP IOMMU support config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS -- 1.6.2.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 -- To unsubscribe from this list: send the line unsubscribe 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: OMAP_IOMMU not visible in menuconfig
From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Thu, 09 Sep 2010 08:24:05 +0300 (EEST) From: ext Premi, Sanjeev pr...@ti.com Subject: RE: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Thu, 9 Sep 2010 07:10:05 +0200 -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Thursday, September 09, 2010 10:35 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Hi Sanjeev, From: ext Sanjeev Premi pr...@ti.com Subject: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Wed, 8 Sep 2010 16:51:21 +0200 The menu option to select CONFIG_OMAP_IOMMU was not visible in the menuconfig due to missing description. There's no point to make OMAP_IOMMU visible since this is a kind of feature used by other device implicitly. OMAP_IOMMU on menu might confuse users at kernel menuconfig. Instead this should be automatically selected by its clients when it is selected. For exmaple, the case that DSP or Tesla is selected. There was a discussion about this before. [sp] You would have noticed that there are mnay OMAP3 variants and some of them are ARM only - detection being runtime, not compile time. For the runtime detection, can this be done at platform_device registration time? All these processors share same defconfig. Setting dependency correctly could solve this? Modified drivers/staging/tidspbridge/Kconfig 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 Keeping/ maintaining specific defconfigs for each processor will be too difficult. ~sanjeev Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e39a417..2a114a9 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + tristate OMAP IOMMU support config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS -- 1.6.2.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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Hi Catalin,
From: Hiroshi DOYU hiroshi.d...@nokia.com
Subject: Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Date: Tue, 10 Aug 2010 18:49:03 +0300 (EEST)
snip
The performance impact is indeed pretty high, though some parts of the
code look over-engineered to me (the __scan_block function with a loop
going through an array of two function pointers - I think the compiler
cannot figure out what to inline). You could just extend the
find_and_get_object() to search both trees under a single spinlock
region (as locking also takes time).
Ok, a good point.
Now there's not much difference with the attached patch, a new version
of alias.
/ # modprobe kmemleak-special-test use_alias=0
/ # time echo scan /sys/kernel/debug/kmemleak
real0m 2.30s
user0m 0.00s
sys 0m 2.30s
/ # modprobe kmemleak-special-test use_alias=1
/ # time echo scan /sys/kernel/debug/kmemleak
real0m 3.91s
user0m 0.00s
sys 0m 3.91s
It would be nice if you could have some time to take a look at this
patch and give some comments.
From a5670d69b2cafe85f6f26f6951097210d3b9917f Mon Sep 17 00:00:00 2001
From: Hiroshi DOYU hiroshi.d...@nokia.com
Date: Thu, 17 Jun 2010 13:36:45 +0300
Subject: [PATCH 1/1] kmemleak: Fix false positive with address alias
There is a false positive case that a pointer is calculated by other
methods than the usual container_of macro. kmemleak_ignore can cover
such a false positive, but it would loose the advantage of memory leak
detection. This patch allows kmemleak to work with such false
positives by aliasing of address. A client module can register an
alias address to an original pointer.
A typical use case could be the IOMMU pagetable allocation which
stores pointers to the second level of page tables with some
conversion, for example, a physical address with attribute bits. Right
now I don't have other use cases but I hope that there could be some
that this special scan works with.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
---
include/linux/kmemleak.h |8 ++
mm/kmemleak.c| 208
+++---
2 files changed, 204 insertions(+), 12 deletions(-)
diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index 99d9a67..9e2af3a 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -34,6 +34,8 @@ extern void kmemleak_not_leak(const void *ptr) __ref;
extern void kmemleak_ignore(const void *ptr) __ref;
extern void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp)
__ref;
extern void kmemleak_no_scan(const void *ptr) __ref;
+extern void kmemleak_add_alias(const void *ptr, const void *new) __ref;
+extern void kmemleak_unalias(const void *alias) __ref;
static inline void kmemleak_alloc_recursive(const void *ptr, size_t size,
int min_count, unsigned long flags,
@@ -92,6 +94,12 @@ static inline void kmemleak_erase(void **ptr)
static inline void kmemleak_no_scan(const void *ptr)
{
}
+static inline void kmemleak_add_alias(const void *ptr, const void *new)
+{
+}
+static inline void kmemleak_unalias(const void *alias)
+{
+}
#endif /* CONFIG_DEBUG_KMEMLEAK */
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 2c0d032..3875cb7 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -157,6 +157,13 @@ struct kmemleak_object {
unsigned long jiffies; /* creation timestamp */
pid_t pid; /* pid of the current task */
char comm[TASK_COMM_LEN]; /* executable name */
+ struct kmemleak_alias *alias; /* if a pointer is modified */
+};
+
+struct kmemleak_alias {
+ struct list_head alias_list;
+ struct prio_tree_node tree_node;
+ struct kmemleak_object *object;
};
/* flag representing the memory block allocation status */
@@ -179,13 +186,18 @@ struct kmemleak_object {
static LIST_HEAD(object_list);
/* the list of gray-colored objects (see color_gray comment below) */
static LIST_HEAD(gray_list);
+/* the list of objects with alias (see alias comment below) */
+static LIST_HEAD(alias_list);
/* prio search tree for object boundaries */
static struct prio_tree_root object_tree_root;
+/* prio search tree for alias object boundaries */
+static struct prio_tree_root alias_tree_root;
/* rw_lock protecting the access to object_list and prio_tree_root */
static DEFINE_RWLOCK(kmemleak_lock);
/* allocation caches for kmemleak internal data */
static struct kmem_cache *object_cache;
+static struct kmem_cache *alias_cache;
static struct kmem_cache *scan_area_cache;
/* set if tracing memory operations is enabled */
@@ -269,6 +281,8 @@ static void kmemleak_disable(void);
kmemleak_disable(); \
} while (0)
+#define to_address(obj) ((obj)-tree_node.start)
+
/*
* Printing of the objects hex dump
Re: [PATCH] omap:iommu-load cam register before flushing the entry
Hi Hari,
From: ext Hari Kanigeri h-kanige...@ti.com
Subject: [PATCH] omap:iommu-load cam register before flushing the entry
Date: Fri, 20 Aug 2010 15:50:18 +0200
The flush_iotlb_page is not loading the cam register before flushing
the cam entry. This causes wrong entry to be flushed out from the TLB, and
if the entry happens to be a locked TLB entry it would lead to MMU faults.
The fix is to load the cam register with the address to be flushed before
flushing the TLB entry.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Ok for me. Thanks.
---
arch/arm/plat-omap/iommu.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 2e603fe..c534280 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -315,6 +315,7 @@ void flush_iotlb_page(struct iommu *obj, u32 da)
if ((start = da) (da start + bytes)) {
dev_dbg(obj-dev, %s: %08x=%08x(%x)\n,
__func__, start, da, bytes);
+ iotlb_load_cr(obj, cr);
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
--
1.7.0
--
To unsubscribe from this list: send the line unsubscribe 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] iommu: fix end address of vm area comparation in alloc_iovm_area
From: ext Guzman Lugo, Fernando fernando.l...@ti.com Subject: RE: [PATCH] iommu: fix end address of vm area comparation in alloc_iovm_area Date: Tue, 17 Aug 2010 06:48:14 +0200 From: linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] On Behalf Of Guzman Lugo, Fernando [fernando.l...@ti.com] Sent: Monday, August 16, 2010 10:51 PM To: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org Cc: hiroshi.d...@nokia.com; Kanigeri, Hari Subject: [PATCH] iommu: fix end address of vm area comparation in alloc_iovm_area From cc48c0adaee97c8385a356aefa5b64a51818b4fd Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo x0095...@ti.com Date: Mon, 16 Aug 2010 22:28:24 -0500 Subject: [PATCH] iommu: fix end address of vm area comparation in alloc_iovm_area End address of the vm area is “start + bytes -1”, not “start + byte”. This patch fixes that issue by doing an inclusive comparison with tmp-da_start. This issue was preventing allocate an area of size exactly the same than the free area. I did no change the value of da_end of each vm area because it is used to get area size in several places. Ok for me. Is this patch against the latest? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Hi Catalin,
From: Hiroshi DOYU hiroshi.d...@nokia.com
Subject: Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Date: Tue, 29 Jun 2010 07:44:23 +0300 (EEST)
From: ext Catalin Marinas catalin.mari...@arm.com
Subject: Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Date: Mon, 28 Jun 2010 16:46:12 +0200
Hi,
(and sorry for the delay)
On Fri, 2010-06-18 at 07:04 +0100, Hiroshi DOYU wrote:
This is another version of kmemleak: Fix false positive, which
introduces another alias tree to keep track of all alias address of
each objects, based on the discussion(*1)
You can also find the previous one(*2), which uses special scan area
for alias addresses with a conversion function.
Compared with both methods, it seems that the current one takes a bit
longer to scan as below, tested with 512 elementes of (*3).
kmemleak: Fix false positive with alias:
# time echo scan /mnt/kmemleak
real0m 8.40s
user0m 0.00s
sys 0m 8.40s
kmemleak: Fix false positive with special scan:
# time echo scan /mnt/kmemleak
real0m 3.96s
user0m 0.00s
sys 0m 3.96s
Have you tried without your patches (just the test module but without
aliasing the pointers)? I'm curious what's the impact of your first set
of patches.
IIRC, not much difference against the one with the first patches. I'll
measure it again later.
For our case(*4) to reduce false positives for the 2nd level IOMMU
pagetable allocation, the previous special scan seems to be enough
lightweight, although there might be possiblity to improve alias
one and also I might misunderstand the original proposal of aliasing.
The performance impact is indeed pretty high, though some parts of the
code look over-engineered to me (the __scan_block function with a loop
going through an array of two function pointers - I think the compiler
cannot figure out what to inline). You could just extend the
find_and_get_object() to search both trees under a single spinlock
region (as locking also takes time).
Ok, a good point.
Now there's not much difference with the attached patch, a new version
of alias.
/ # modprobe kmemleak-special-test use_alias=0
/ # time echo scan /sys/kernel/debug/kmemleak
real0m 2.30s
user0m 0.00s
sys 0m 2.30s
/ # modprobe kmemleak-special-test use_alias=1
/ # time echo scan /sys/kernel/debug/kmemleak
real0m 3.91s
user0m 0.00s
sys 0m 3.91s
From a5670d69b2cafe85f6f26f6951097210d3b9917f Mon Sep 17 00:00:00 2001
From: Hiroshi DOYU hiroshi.d...@nokia.com
Date: Thu, 17 Jun 2010 13:36:45 +0300
Subject: [PATCH 1/1] kmemleak: Fix false positive with address alias
There is a false positive case that a pointer is calculated by other
methods than the usual container_of macro. kmemleak_ignore can cover
such a false positive, but it would loose the advantage of memory leak
detection. This patch allows kmemleak to work with such false
positives by aliasing of address. A client module can register an
alias address to an original pointer.
A typical use case could be the IOMMU pagetable allocation which
stores pointers to the second level of page tables with some
conversion, for example, a physical address with attribute bits. Right
now I don't have other use cases but I hope that there could be some
that this special scan works with.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
---
include/linux/kmemleak.h |8 ++
mm/kmemleak.c| 208 +++---
2 files changed, 204 insertions(+), 12 deletions(-)
diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index 99d9a67..9e2af3a 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -34,6 +34,8 @@ extern void kmemleak_not_leak(const void *ptr) __ref;
extern void kmemleak_ignore(const void *ptr) __ref;
extern void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp) __ref;
extern void kmemleak_no_scan(const void *ptr) __ref;
+extern void kmemleak_add_alias(const void *ptr, const void *new) __ref;
+extern void kmemleak_unalias(const void *alias) __ref;
static inline void kmemleak_alloc_recursive(const void *ptr, size_t size,
int min_count, unsigned long flags,
@@ -92,6 +94,12 @@ static inline void kmemleak_erase(void **ptr)
static inline void kmemleak_no_scan(const void *ptr)
{
}
+static inline void kmemleak_add_alias(const void *ptr, const void *new)
+{
+}
+static inline void kmemleak_unalias(const void *alias)
+{
+}
#endif /* CONFIG_DEBUG_KMEMLEAK */
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 2c0d032..3875cb7 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -157,6 +157,13 @@ struct kmemleak_object {
unsigned long jiffies; /* creation timestamp */
pid_t pid; /* pid of the current task */
char comm[TASK_COMM_LEN]; /* executable name */
+ struct
Re: [PATCH] mailbox: change full flag per mailbox queue instead of global
From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH] mailbox: change full flag per mailbox queue instead of global Date: Tue, 10 Aug 2010 16:36:42 +0200 Hi Hiroshi, On Mon, Jun 14, 2010 at 7:51 PM, Fernando Guzman Lugo x0095...@ti.com wrote: As pointed by Ben Ohand, the variable rq_full flag is a global variable, so if there are multiple mailbox users there will be conflics. Now there is a full flag per mailbox queue. Reported-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Fernando Guzman Lugo x0095...@ti.com It looks like this fix didn't get thru - can you please review and ack/nack ? Sure. Fernando, could you rebase this patch against the latest omap/master? -- To unsubscribe from this list: send the line unsubscribe 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] mailbox: change full flag per mailbox queue instead of global
From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCHv2] mailbox: change full flag per mailbox queue instead of global Date: Wed, 11 Aug 2010 03:12:49 +0200 As pointed by Ohad Ben-Cohen, the variable rq_full flag is a global variable, so if there are multiple mailbox users there will be conflics. Now there is a full flag per mailbox queue. Version 2: - Rebase to the latest. Reported-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Fernando Guzman Lugo x0095...@ti.com Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Ok for me. Tony, could you take this in? since it's a single patch for fix. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Remove non-existent config option
Hi Hari, On Thu, 5 Aug 2010 17:12:11 +0200 ext Kanigeri, Hari h-kanige...@ti.com wrote: Hiroshi, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU Sent: Wednesday, August 04, 2010 6:20 AM To: t...@atomide.com Cc: Marathe, Yogesh; linux-omap@vger.kernel.org; Premi, Sanjeev Subject: Re: [PATCH] omap3: Remove non-existent config option From: ext Tony Lindgren t...@atomide.com Subject: Re: [PATCH] omap3: Remove non-existent config option Date: Wed, 4 Aug 2010 13:11:47 +0200 * Marathe, Yogesh yogesh_mara...@ti.com [100803 11:03]: ping.. Hiroshi ack/nak? Nak. http://www.spinics.net/lists/linux-omap/msg32869.html tidspbridge is in staging now. Can you please elaborate what this means ? Yogesh patch enables the IOMMU for BRIDGE by default and we need this as IOMMU is going to get use in 3430. Ok, I misunderstood this intention, sorry. Tony, please put this into your queue for next merge. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Remove non-existent config option
From: ext Tony Lindgren t...@atomide.com Subject: Re: [PATCH] omap3: Remove non-existent config option Date: Wed, 4 Aug 2010 13:11:47 +0200 * Marathe, Yogesh yogesh_mara...@ti.com [100803 11:03]: ping.. Hiroshi ack/nak? Nak. http://www.spinics.net/lists/linux-omap/msg32869.html tidspbridge is in staging now. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap mailbox: for-next for v2.6.35
Hi Tony, The following changes since commit 9fe6206f400646a2322096b56c59891d530e8d51: Linux 2.6.35 (2010-08-01 15:11:14 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-omap-mailbox-for-next Felipe Contreras (13): omap: mailbox: trivial cleanups omap: mailbox: reorganize structures omap: mailbox: 2420 should be detected at run-time omap: mailbox: use correct config for omap1 omap: mailbox: update omap1 probing omap: mailbox: don't export unecessary symbols omap: mailbox: remove unecessary fields omap: mailbox: add IRQ names omap: mailbox: reorganize registering omap: mailbox: simplify omap_mbox_register() omap: mailbox: only compile for configured archs omap: mailbox: standarize on 'omap-mailbox' omap: mailbox: reorganize headers Fernando Guzman Lugo (4): Mailbox: free mailbox interrupt before freeing blk queue Mailbox: flush pending deferred works before freeing blk queue Mailbox: Check valid registered callback before calling Mailbox: disable mailbox interrupt when request queue Hiroshi DOYU (2): Mailbox: new mutext lock for h/w mailbox configuration omap mailbox: Set a device in logical mbox instance for traceability Ohad Ben-Cohen (4): omap: mailbox: convert rwlocks to spinlock omap: mailbox cleanup: split MODULE_AUTHOR line omap: mailbox: remove (un)likely macros from cold paths omap: mailbox: convert block api to kfifo arch/arm/mach-omap1/devices.c | 11 +- arch/arm/mach-omap1/mailbox.c | 55 +++ arch/arm/mach-omap2/devices.c |6 +- arch/arm/mach-omap2/mailbox.c | 182 ++ arch/arm/plat-omap/Kconfig|9 + arch/arm/plat-omap/include/plat/mailbox.h | 20 +-- arch/arm/plat-omap/mailbox.c | 248 ++--- 7 files changed, 246 insertions(+), 285 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap mailbox: for-next for v2.6.35
From: ext Tony Lindgren t...@atomide.com Subject: Re: [GIT PULL] omap mailbox: for-next for v2.6.35 Date: Wed, 4 Aug 2010 15:28:10 +0200 * Hiroshi DOYU hiroshi.d...@nokia.com [100804 15:50]: Hi Tony, The following changes since commit 9fe6206f400646a2322096b56c59891d530e8d51: Linux 2.6.35 (2010-08-01 15:11:14 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-omap-mailbox-for-next Pulled this, but please, next time we need to have things ready to be pulled for Linus by -rc6 or so. Otherwise we don't have much time for the patches to sit in for-next. Ok, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] DSPBRIDGE: cache operation against kernel address instead of user's
Hi Felipe,
On Sun, 25 Jul 2010 22:10:32 +0200
ext Felipe Contreras felipe.contre...@gmail.com wrote:
Hi,
While investigating a bug in maemo[1] I found that this patch triggers
it, I think I found the reason.
It probably doesn't matter for upstream anymore.
On Fri, Nov 6, 2009 at 3:34 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
@@ -690,14 +732,19 @@ static int memory_check_vma(unsigned long start, u32
len)
if (end = start)
return -EINVAL;
- down_read(current-mm-mmap_sem);
-
while ((vma = find_vma(current-mm, start)) != NULL) {
+ ssize_t size;
- if (vma-vm_start start) {
- err = -EINVAL;
+ if (vma-vm_flags (VM_IO | VM_PFNMAP))
+ return -EINVAL;
+
+ if (vma-vm_start start)
+ return -EINVAL;
+
+ size = min_t(ssize_t, vma-vm_end - start, len);
This 'len' is the total length, which is not what we want; in each
iteration the length should be decreased so that it's always the
remaining length. Right?
len -= size;
Great finding and I'm so sorry for this bug...
+ err = memory_sync_page(vma, start, size, ftype);
+ if (err)
break;
- }
if (end = vma-vm_end)
break;
[1] https://bugs.maemo.org/show_bug.cgi?id=10813
--
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: [RFC][PATCH 1/1] ARM: Add initial hibernation support
From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Fri, 16 Jul 2010 09:52:44 +0200 On Thu, Jul 15, 2010 at 12:08:07PM +0300, Hiroshi DOYU wrote: From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 10:41:18 +0200 On Thu, Jul 15, 2010 at 08:34:50AM +0300, Hiroshi DOYU wrote: Russell, would it be possible to put this into your next merge queue? I think it needs quite a bit of rework - I certainly don't like all those CP15 register accesses there - that's asking for lots of ifdefs to spring up as more CPUs are supported. Eg, what about ensuring that state such as iWMMXt on PXA CPUs is properly restored? Right. This arch specific part can be something like suspend-v[3-7].S to accomodate those differences It's not quite that simple - things like iWMMXt aren't part of the ARM arch specs. We already have code which knows what needs to be saved across a power-off transition - its what we use for our normal suspend/resume functionality, so we should look at re-using that code for hibernate as well. We really don't want to be maintaining two sets of code doing the same thing. Could you explain which code you're refering for the existing one? The code which handles saving state for the existing suspend/resume support. This code already saves the necessary state from CP15 and any other state which needs to be saved prior to putting the system into low power mode. Every machine class which supports suspend today has their own chunk of code which does this, normally called something like sleep.S Ok, it seems to be the way to try to make use of the existing one for suspend-to-ram with some modifications. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
From: ext Shilimkar, Santosh santosh.shilim...@ti.com Subject: RE: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Fri, 16 Jul 2010 10:48:00 +0200 Hiroshi, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux Sent: Friday, July 16, 2010 1:23 PM To: Hiroshi DOYU Cc: linux-arm-ker...@lists.infradead.org; pa...@ucw.cz; khil...@deeprootsystems.com; Reddy, Teerth; linux...@lists.linux- foundation.org; yoshiya.hir...@nokia.com; linux-omap@vger.kernel.org Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support On Thu, Jul 15, 2010 at 12:08:07PM +0300, Hiroshi DOYU wrote: From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 10:41:18 +0200 On Thu, Jul 15, 2010 at 08:34:50AM +0300, Hiroshi DOYU wrote: Russell, would it be possible to put this into your next merge queue? I think it needs quite a bit of rework - I certainly don't like all those CP15 register accesses there - that's asking for lots of ifdefs to spring up as more CPUs are supported. Eg, what about ensuring that state such as iWMMXt on PXA CPUs is properly restored? Right. This arch specific part can be something like suspend-v[3-7].S to accomodate those differences It's not quite that simple - things like iWMMXt aren't part of the ARM arch specs. We already have code which knows what needs to be saved across a power-off transition - its what we use for our normal suspend/resume functionality, so we should look at re-using that code for hibernate as well. We really don't want to be maintaining two sets of code doing the same thing. Could you explain which code you're refering for the existing one? The code which handles saving state for the existing suspend/resume support. This code already saves the necessary state from CP15 and any other state which needs to be saved prior to putting the system into low power mode. Every machine class which supports suspend today has their own chunk of code which does this, normally called something like sleep.S When this getting developed in TI, we had one more concern about handling the trustzone part for the CP15 resgiters. This patch will hang on restoration on some devices implementing trustzone. Thanks for the info. I think that this trustzone issue and PXA part can be revisited later once the basic stuff is accepted. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
From: ext Marek Vasut marek.va...@gmail.com Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 07:56:11 +0200 Dne Čt 15. července 2010 07:39:31 Hiroshi DOYU napsal(a): From: ext Marek Vasut marek.va...@gmail.com Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 06:48:50 +0200 Dne St 30. června 2010 16:28:01 Hiroshi DOYU napsal(a): From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Hey, can this also run on pre-v7 arms ? Or is there something I missed that'd make that impossible? What I verified is with OMAP3(Cortex A8) based board. cp15 part has to be modified, but it might work without this part itself, I guess. I see ... do I need any special support on the bootloader or userland side ? No, I don't think so. The resuming boot could set up most of states basically. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 10:41:18 +0200 On Thu, Jul 15, 2010 at 08:34:50AM +0300, Hiroshi DOYU wrote: Russell, would it be possible to put this into your next merge queue? I think it needs quite a bit of rework - I certainly don't like all those CP15 register accesses there - that's asking for lots of ifdefs to spring up as more CPUs are supported. Eg, what about ensuring that state such as iWMMXt on PXA CPUs is properly restored? Right. This arch specific part can be something like suspend-v[3-7].S to accomodate those differences We already have code which knows what needs to be saved across a power-off transition - its what we use for our normal suspend/resume functionality, so we should look at re-using that code for hibernate as well. We really don't want to be maintaining two sets of code doing the same thing. Could you explain which code you're refering for the existing one? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
From: ext Pavel Machek pa...@ucw.cz Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Wed, 14 Jul 2010 15:22:55 +0200 Hi! From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Looks ok to me. ACK. Pavel, Thanks. Russell, would it be possible to put this into your next merge queue? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
From: ext Marek Vasut marek.va...@gmail.com Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 06:48:50 +0200 Dne St 30. června 2010 16:28:01 Hiroshi DOYU napsal(a): From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Hey, can this also run on pre-v7 arms ? Or is there something I missed that'd make that impossible? What I verified is with OMAP3(Cortex A8) based board. cp15 part has to be modified, but it might work without this part itself, I guess. -- To unsubscribe from this list: send the line unsubscribe 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 5/9] dspbridge: add mmufault support
Hi Fernando,
From: ext Fernando Guzman Lugo x0095...@ti.com
Subject: [PATCH 5/9] dspbridge: add mmufault support
Date: Thu, 1 Jul 2010 02:20:56 +0200
With changes for iommu migration mmu fault report and dsp track
dump is broken, this patch fixes that.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/core/mmu_fault.c | 93 ++---
drivers/dsp/bridge/core/mmu_fault.h |5 +-
drivers/dsp/bridge/core/tiomap3430.c |2 +
drivers/dsp/bridge/core/ue_deh.c | 31 +---
4 files changed, 34 insertions(+), 97 deletions(-)
diff --git a/drivers/dsp/bridge/core/mmu_fault.c
b/drivers/dsp/bridge/core/mmu_fault.c
index 5c0124f..d991c6a 100644
--- a/drivers/dsp/bridge/core/mmu_fault.c
+++ b/drivers/dsp/bridge/core/mmu_fault.c
@@ -23,9 +23,12 @@
/* --- Trace Debug */
#include dspbridge/host_os.h
#include dspbridge/dbc.h
+#include plat/iommu.h
/* --- OS Adaptation Layer */
#include dspbridge/drv.h
+#include dspbridge/dev.h
+
/* --- Link Driver */
#include dspbridge/dspdeh.h
@@ -40,11 +43,6 @@
#include _tiomap.h
#include mmu_fault.h
-static u32 dmmu_event_mask;
-u32 fault_addr;
-
-static bool mmu_check_if_fault(struct bridge_dev_context *dev_context);
-
/*
* mmu_fault_dpc
* Deferred procedure call to handle DSP MMU fault.
@@ -62,78 +60,21 @@ void mmu_fault_dpc(IN unsigned long pRefData)
* mmu_fault_isr
* ISR to be triggered by a DSP MMU fault interrupt.
*/
-irqreturn_t mmu_fault_isr(int irq, IN void *pRefData)
-{
- struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)pRefData;
- struct bridge_dev_context *dev_context;
- struct cfg_hostres *resources;
-
- DBC_REQUIRE(irq == INT_DSP_MMU_IRQ);
- DBC_REQUIRE(deh_mgr_obj);
-
- if (deh_mgr_obj) {
-
- dev_context =
- (struct bridge_dev_context *)deh_mgr_obj-hbridge_context;
-
- resources = dev_context-resources;
-
- if (!resources) {
- dev_dbg(bridge, %s: Failed to get Host Resources\n,
- __func__);
- return IRQ_HANDLED;
- }
- if (mmu_check_if_fault(dev_context)) {
- printk(KERN_INFO * DSPMMU FAULT * IRQStatus
-0x%x\n, dmmu_event_mask);
- printk(KERN_INFO * DSPMMU FAULT * fault_addr
-0x%x\n, 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_mgr_obj-dpc_tasklet);
-
- /* Reset err_info structure before use. */
- deh_mgr_obj-err_info.dw_err_mask = DSP_MMUFAULT;
- deh_mgr_obj-err_info.dw_val1 = fault_addr 16;
- deh_mgr_obj-err_info.dw_val2 = fault_addr 0x;
- deh_mgr_obj-err_info.dw_val3 = 0L;
- /* 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;
-}
+int mmu_fault_isr(struct iommu *mmu)
-/*
- * mmu_check_if_fault
- * Check to see if MMU Fault is valid TLB miss from DSP
- * Note: This function is called from an ISR
- */
-static bool mmu_check_if_fault(struct bridge_dev_context *dev_context)
{
+ struct deh_mgr *dm;
+ u32 da;
+
+ dev_get_deh_mgr(dev_get_first(), dm);
+
+ if (!dm)
+ return -EPERM;
+
+ da = iommu_read_reg(mmu, MMU_FAULT_AD);
+ iommu_write_reg(mmu, 0, MMU_IRQENABLE);
+ dm-err_info.dw_val1 = da;
+ tasklet_schedule(dm-dpc_tasklet);
I think that the following iommu_disable() does disabling MMU.
Modified arch/arm/plat-omap/iommu.c
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index a202a2c..17407f1 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -800,7 +800,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
if (!stat)
return IRQ_HANDLED;
- iommu_disable(obj);
+ iommu_disable(obj); - HERE!
iopgd = iopgd_offset(obj, da);
You can find the latest omap iommu code from:
Re: [PATCH 1/9] dspbridge: replace iommu custom for opensource implementation
Hi Fernando,
From: ext Fernando Guzman Lugo x0095...@ti.com
Subject: [PATCH 1/9] dspbridge: replace iommu custom for opensource
implementation
Date: Thu, 1 Jul 2010 02:20:52 +0200
This patch replace the call to custom dsp mmu implemenation
for the once on iommu module.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/core/_tiomap.h| 16 +
drivers/dsp/bridge/core/io_sm.c | 114 ++--
drivers/dsp/bridge/core/tiomap3430.c | 501
+-
drivers/dsp/bridge/core/ue_deh.c | 10 -
4 files changed, 118 insertions(+), 523 deletions(-)
diff --git a/drivers/dsp/bridge/core/_tiomap.h
b/drivers/dsp/bridge/core/_tiomap.h
index bf0164e..d13677a 100644
--- a/drivers/dsp/bridge/core/_tiomap.h
+++ b/drivers/dsp/bridge/core/_tiomap.h
@@ -23,6 +23,8 @@
#include plat/clockdomain.h
#include mach-omap2/prm-regbits-34xx.h
#include mach-omap2/cm-regbits-34xx.h
+#include plat/iommu.h
+#include plat/iovmm.h
#include dspbridge/devdefs.h
#include hw_defs.h
#include dspbridge/dspioctl.h/* for bridge_ioctl_extproc defn */
@@ -330,6 +332,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 */
@@ -374,4 +377,17 @@ extern s32 dsp_debug;
*/
int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val);
+static inline void dsp_iotlb_init(struct iotlb_entry *e, u32 da, u32 pa,
+ u32 pgsz)
+{
+ e-da = da;
+ e-pa = pa;
+ e-valid = 1;
+ e-prsvd = 1;
+ e-pgsz = pgsz MMU_CAM_PGSZ_MASK;
+ e-endian = MMU_RAM_ENDIAN_LITTLE;
+ e-elsz = MMU_RAM_ELSZ_32;
+ e-mixed = 0;
+}
+
#endif /* _TIOMAP_ */
diff --git a/drivers/dsp/bridge/core/io_sm.c b/drivers/dsp/bridge/core/io_sm.c
index 7fb840d..1f47f8b 100644
--- a/drivers/dsp/bridge/core/io_sm.c
+++ b/drivers/dsp/bridge/core/io_sm.c
@@ -290,6 +290,8 @@ 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 iotlb_entry e;
u32 ul_shm_base;
u32 ul_shm_base_offset;
u32 ul_shm_limit;
@@ -312,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;
@@ -336,6 +337,21 @@ 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);
+ mmu = iommu_get(iva2, mmu_fault_isr);
I'm considering that it might be better to pass a mmu fault callback
at this iommu_get.
What do you think?
--
To unsubscribe from this list: send the line unsubscribe 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] omap iommu: for-next for 2.6.35-rc1
From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Tue, 29 Jun 2010 07:57:44 +0300 (EEST) Hi Tony, From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Wed, 02 Jun 2010 10:50:54 +0300 (EEST) Hi Tony, Patches for for-next for omap iommu module. The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc1-iommu Hiroshi DOYU (3): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer Kanigeri, Hari (2): omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt arch/arm/mach-omap2/iommu2.c| 44 -- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 27 --- arch/arm/plat-omap/iopgtable.h |8 +++-- 4 files changed, 65 insertions(+), 16 deletions(-) Any chance to merge? I have added 2 patches which were dropped from omap iommu fix as below. Please pull the following branch. Hi Tony, Do you have any plan for pulling for-next patches? I have some omap iommu and omap mailbox patches for for-next. Now the merge window seems so small and I don't want to miss it. The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-iommu-for-next Hiroshi DOYU (4): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer omap iommu: Make omap-iommu.o built-in Kanigeri, Hari (3): omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt omap iommu: update ducati mmu irq define name arch/arm/mach-omap2/Makefile|5 +++- arch/arm/mach-omap2/iommu2.c| 44 -- arch/arm/mach-omap2/omap-iommu.c|2 +- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 27 --- arch/arm/plat-omap/iopgtable.h |8 +++-- 6 files changed, 70 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1
From: ext Tony Lindgren t...@atomide.com Subject: Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Fri, 2 Jul 2010 11:04:11 +0200 * Hiroshi DOYU hiroshi.d...@nokia.com [100702 09:29]: Do you have any plan for pulling for-next patches? I have some omap iommu and omap mailbox patches for for-next. Now the merge window seems so small and I don't want to miss it. Pulled now into omap-for-linus for the next merge window. Sorry for the delay. BTW, I did not add that Makefile fix into omap-fixes-for-linus, I figured we should first make sure to get the pending fixes in, and then maybe do another set of fixes. But looks like that's in your for-next, so we might as well keep it there. If there's urgent need to get that in as a fix, let me know ASAP, I can still rebuild omap-for-linus as that's the only set merged there. Ok, Thanks. I'll send another pull request for omap mailbox for-next. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] omap mailbox: prevent multiple concurrent receivers race
From: ext Ohad Ben-Cohen o...@wizery.com
We currently maintain only a single mailbox receiver callback.
To prevent multiple receivers race scenarios (in which receivers
will end up overwriting each other's callback pointers), we make
sure that mailbox instances cannot be taken by more than
one receiver at the same time.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c | 12 +++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 0b45664..5df35b4 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -57,6 +57,7 @@ struct omap_mbox {
struct omap_mbox_ops*ops;
struct device *dev;
void*priv;
+ atomic_tcount;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 14b716d..aafa63f 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -320,9 +320,17 @@ struct omap_mbox *omap_mbox_get(const char *name, int
(*callback)(void *))
if (!mbox)
return ERR_PTR(-ENOENT);
+ if (atomic_inc_return(mbox-count) 1) {
+ pr_err(%s: mbox %s already in use\n, __func__, name);
+ atomic_dec(mbox-count);
+ return ERR_PTR(-EBUSY);
+ }
+
ret = omap_mbox_startup(mbox);
- if (ret)
+ if (ret) {
+ atomic_dec(mbox-count);
return ERR_PTR(-ENODEV);
+ }
mbox-rxq-callback = callback;
@@ -333,6 +341,7 @@ EXPORT_SYMBOL(omap_mbox_get);
void omap_mbox_put(struct omap_mbox *mbox)
{
omap_mbox_fini(mbox);
+ atomic_dec(mbox-count);
}
EXPORT_SYMBOL(omap_mbox_put);
@@ -349,6 +358,7 @@ int omap_mbox_register(struct device *parent, struct
omap_mbox **list)
for (i = 0; mboxes[i]; i++) {
struct omap_mbox *mbox = mboxes[i];
+ atomic_set(mbox-count, 0);
mbox-dev = device_create(omap_mbox_class,
parent, 0, mbox, %s, mbox-name);
if (IS_ERR(mbox-dev)) {
--
1.7.1.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] omap mailbox: remove mbox_configured scheme
From: ext Ohad Ben-Cohen o...@wizery.com
mbox_configured is global and therefore does not support
concurrent usage of multiple mailbox instances.
Instead of fixing this, we can just eliminate mbox_configured
(and its locking) entirely, since any given mailbox instance
can only be taken by a single receiver now.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/mailbox.c | 24
1 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index aafa63f..6a9dfe5 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -35,9 +35,6 @@ static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
static bool rq_full;
-static int mbox_configured;
-static DEFINE_MUTEX(mbox_configured_lock);
-
static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
module_param(mbox_kfifo_size, uint, S_IRUGO);
MODULE_PARM_DESC(mbox_kfifo_size, Size of omap's mailbox kfifo (bytes));
@@ -240,16 +237,9 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
struct omap_mbox_queue *mq;
if (mbox-ops-startup) {
- mutex_lock(mbox_configured_lock);
- if (!mbox_configured)
- ret = mbox-ops-startup(mbox);
-
- if (ret) {
- mutex_unlock(mbox_configured_lock);
+ ret = mbox-ops-startup(mbox);
+ if (ret)
return ret;
- }
- mbox_configured++;
- mutex_unlock(mbox_configured_lock);
}
ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
@@ -295,14 +285,8 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
mbox_queue_free(mbox-txq);
mbox_queue_free(mbox-rxq);
- if (mbox-ops-shutdown) {
- mutex_lock(mbox_configured_lock);
- if (mbox_configured 0)
- mbox_configured--;
- if (!mbox_configured)
- mbox-ops-shutdown(mbox);
- mutex_unlock(mbox_configured_lock);
- }
+ if (mbox-ops-shutdown)
+ mbox-ops-shutdown(mbox);
}
struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *))
--
1.7.1.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] omap mailbox: extend API to take a callback param
From: ext Ohad Ben-Cohen o...@wizery.com
Let mailbox users set the callback pointer via the
omap_mbox_get API, instead of having users directly
manipulating the mailbox structures.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/include/plat/mailbox.h |2 +-
arch/arm/plat-omap/mailbox.c |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..0b45664 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -62,7 +62,7 @@ struct omap_mbox {
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *));
void omap_mbox_put(struct omap_mbox *);
int omap_mbox_register(struct device *parent, struct omap_mbox **);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..14b716d 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -305,7 +305,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
}
}
-struct omap_mbox *omap_mbox_get(const char *name)
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *))
{
struct omap_mbox *mbox;
int ret;
@@ -324,6 +324,8 @@ struct omap_mbox *omap_mbox_get(const char *name)
if (ret)
return ERR_PTR(-ENODEV);
+ mbox-rxq-callback = callback;
+
return mbox;
}
EXPORT_SYMBOL(omap_mbox_get);
--
1.7.1.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
On Wed, 23 Jun 2010 02:29:00 +0200 ext Ohad Ben-Cohen o...@wizery.com wrote: On Wed, Jun 16, 2010 at 8:50 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Ohad Ben-Cohen o...@wizery.com Thanks, I'll prepare them and resubmit You can use the following branch which has accumulateed unmerged mailbox patches. git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-mailbox Done. Thansk. [PATCH 1-3/4] are queued on the above branch and will be pulled soon. The following should be taken care of dspbridge: [PATCH 4/4] dspbridge: use mailbox API to set rx callback -- To unsubscribe from this list: send the line unsubscribe 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 mailbox: extend API to take a callback param
From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH 1/3] omap mailbox: extend API to take a callback param Date: Fri, 2 Jul 2010 14:16:29 +0200 Hi Hiroshi, Please consider waiting with pulling of these three patches. After discussions in l-o, we realized some more work is needed to support OMAP4 multiple senders scenarios. Such work can completely replace these 3 patches (retaining their functionality but adding multiple senders/receivers support). Ok. It would be nice if you send patches to LOML and LAKML too for next time. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 1/1] ARM: Add initial hibernation support
From: Hiroshi DOYU hiroshi.d...@nokia.com
Hibernation (a.k.a: Suspend-To-Disk) support for ARM
Based on the original work from Romit and Raghu at TI. The original
patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com
*1: https://patchwork.kernel.org/patch/96442/
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/Kconfig|4 +
arch/arm/include/asm/memory.h |1 +
arch/arm/include/asm/suspend.h |6 +
arch/arm/kernel/Makefile|1 +
arch/arm/kernel/hibernate.c | 234 +++
arch/arm/kernel/hibernate_asm.S | 135 ++
arch/arm/kernel/vmlinux.lds.S |3 +-
7 files changed, 383 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/include/asm/suspend.h
create mode 100644 arch/arm/kernel/hibernate.c
create mode 100644 arch/arm/kernel/hibernate_asm.S
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1f254bd..c19a206 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -189,6 +189,10 @@ config VECTORS_BASE
help
The base address of exception vectors.
+config ARCH_HIBERNATION_POSSIBLE
+ def_bool y
+ depends on CPU_V7 !SMP
+
source init/Kconfig
source kernel/Kconfig.freezer
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 4312ee5..cd49706 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -194,6 +194,7 @@ static inline void *phys_to_virt(unsigned long x)
*/
#define __pa(x)__virt_to_phys((unsigned long)(x))
#define __va(x)((void *)__phys_to_virt((unsigned
long)(x)))
+#define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x),0))
#define pfn_to_kaddr(pfn) __va((pfn) PAGE_SHIFT)
/*
diff --git a/arch/arm/include/asm/suspend.h b/arch/arm/include/asm/suspend.h
new file mode 100644
index 000..8857c79
--- /dev/null
+++ b/arch/arm/include/asm/suspend.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_ARM_SUSPEND_H
+#define __ASM_ARM_SUSPEND_H
+
+static inline int arch_prepare_suspend(void) { return 0; }
+
+#endif /* __ASM_ARM_SUSPEND_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 26d302c..38a0b10 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_ARM_THUMBEE) += thumbee.o
obj-$(CONFIG_KGDB) += kgdb.o
obj-$(CONFIG_ARM_UNWIND) += unwind.o
obj-$(CONFIG_HAVE_TCM) += tcm.o
+obj-$(CONFIG_HIBERNATION) += hibernate.o hibernate_asm.o
obj-$(CONFIG_CRUNCH) += crunch.o crunch-bits.o
AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
diff --git a/arch/arm/kernel/hibernate.c b/arch/arm/kernel/hibernate.c
new file mode 100644
index 000..692c720
--- /dev/null
+++ b/arch/arm/kernel/hibernate.c
@@ -0,0 +1,234 @@
+/*
+ * Hibernation support specific for ARM
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2006 Rafael J. Wysocki r...@sisk.pl
+ *
+ * Contact: Hiroshi DOYU hiroshi.d...@nokia.com
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include linux/module.h
+#include linux/mm.h
+
+/*
+ * Image of the saved processor state
+ *
+ * coprocessor 15 registers(RW)
+ */
+struct saved_context {
+/*
+ * FIXME: Only support for Cortex A8 now
+ */
+ /* CR0 */
+ u32 cssr; /* Cache Size Selection */
+ /* CR1 */
+ u32 cr; /* Control */
+ u32 cacr; /* Coprocessor Access Control */
+ /* CR2 */
+ u32 ttb_0r; /* Translation Table Base 0 */
+ u32 ttb_1r; /* Translation Table Base 1 */
+ u32 ttbcr; /* Translation Talbe Base Control */
+ /* CR3 */
+ u32 dacr; /* Domain Access Control */
+ /* CR5 */
+ u32 d_fsr; /* Data Fault Status */
+ u32 i_fsr; /* Instruction Fault Status */
+ u32 d_afsr; /* Data Auxilirary Fault Status */ ;
+ u32 i_afsr; /* Instruction Auxilirary Fault Status */;
+ /* CR6 */
+ u32 d_far; /* Data Fault Address */
+ u32 i_far; /* Instruction Fault Address */
+ /* CR7 */
+ u32 par;/* Physical Address */
+ /* CR9 */ /* FIXME: Are they necessary? */
+ u32 pmcontrolr; /* Performance Monitor Control */
+ u32 cesr; /* Count Enable Set */
+ u32 cecr; /* Count Enable Clear */
+ u32 ofsr; /* Overflow Flag Status */
+ u32 sir;/* Software Increment */
+ u32 pcsr; /* Performance Counter Selection */
+ u32 ccr;/* Cycle Count */
+ u32 esr;/* Event Selection */
+ u32 pmcountr; /* Performance Monitor Count */
+ u32 uer;/* User Enable */
+ u32 iesr; /* Interrupt Enable Set */
+ u32 iecr; /* Interrupt Enable Clear */
+ u32 l2clr; /* L2 Cache Lockdown */
+ /* CR10 */
+ u32
[RFC][PATCH 0/1] ARM: Add initial hibernation support
This is the experimental patch to add hibernation (a.k.a: Suspend-To-Disk) support for ARM architecutre. Presently it seems to work with OMAP3, and apparently it still needs more efforts to make it enough stable and to support other ARM platforms cleanly but I am sending this patch to get some feedbacks at its early phase to find out the further direction. It would be really appreciated if you give some comment on this. This patch is based on the one sent to loml(*1) by Teerth Reddy, which was originally from Romit and Raghu at TI. *1: https://patchwork.kernel.org/patch/96442/ Hiroshi DOYU (1): ARM: Add initial hibernation support arch/arm/Kconfig|4 + arch/arm/include/asm/memory.h |1 + arch/arm/include/asm/suspend.h |6 + arch/arm/kernel/Makefile|1 + arch/arm/kernel/hibernate.c | 234 +++ arch/arm/kernel/hibernate_asm.S | 135 ++ arch/arm/kernel/vmlinux.lds.S |3 +- 7 files changed, 383 insertions(+), 1 deletions(-) create mode 100644 arch/arm/include/asm/suspend.h create mode 100644 arch/arm/kernel/hibernate.c create mode 100644 arch/arm/kernel/hibernate_asm.S -- To unsubscribe from this list: send the line unsubscribe 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 22/33] Removing dead MPU_{BRIDGE,TESLA}_IOMMU
From: ext Christoph Egger sicce...@cs.fau.de
Subject: [PATCH 22/33] Removing dead MPU_{BRIDGE,TESLA}_IOMMU
Date: Wed, 30 Jun 2010 18:01:01 +0200
MPU_{BRIDGE,TESLA}_IOMMU doesn't exist in Kconfig, therefore removing
all references for it from the source code.
Coming soon, I guess. Hari?
Signed-off-by: Christoph Egger sicce...@cs.fau.de
---
arch/arm/mach-omap2/omap-iommu.c | 22 --
1 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c
b/arch/arm/mach-omap2/omap-iommu.c
index eb9bee7..3aa3fe9 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -35,17 +35,6 @@ static struct iommu_device omap3_devices[] = {
.clk_name = cam_ick,
},
},
-#if defined(CONFIG_MPU_BRIDGE_IOMMU)
- {
- .base = 0x5d00,
- .irq = 28,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- },
- },
-#endif
};
#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
@@ -66,17 +55,6 @@ static struct iommu_device omap4_devices[] = {
.clk_name = ducati_ick,
},
},
-#if defined(CONFIG_MPU_TESLA_IOMMU)
- {
- .base = OMAP4_MMU2_BASE,
- .irq = INT_44XX_DSP_MMU,
- .pdata = {
- .name = tesla,
- .nr_tlb_entries = 32,
- .clk_name = tesla_ick,
- },
- },
-#endif
};
#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
--
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: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
From: ext Catalin Marinas catalin.mari...@arm.com Subject: Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias Date: Mon, 28 Jun 2010 16:46:12 +0200 Hi, (and sorry for the delay) On Fri, 2010-06-18 at 07:04 +0100, Hiroshi DOYU wrote: This is another version of kmemleak: Fix false positive, which introduces another alias tree to keep track of all alias address of each objects, based on the discussion(*1) You can also find the previous one(*2), which uses special scan area for alias addresses with a conversion function. Compared with both methods, it seems that the current one takes a bit longer to scan as below, tested with 512 elementes of (*3). kmemleak: Fix false positive with alias: # time echo scan /mnt/kmemleak real0m 8.40s user0m 0.00s sys 0m 8.40s kmemleak: Fix false positive with special scan: # time echo scan /mnt/kmemleak real0m 3.96s user0m 0.00s sys 0m 3.96s Have you tried without your patches (just the test module but without aliasing the pointers)? I'm curious what's the impact of your first set of patches. IIRC, not much difference against the one with the first patches. I'll measure it again later. For our case(*4) to reduce false positives for the 2nd level IOMMU pagetable allocation, the previous special scan seems to be enough lightweight, although there might be possiblity to improve alias one and also I might misunderstand the original proposal of aliasing. The performance impact is indeed pretty high, though some parts of the code look over-engineered to me (the __scan_block function with a loop going through an array of two function pointers - I think the compiler cannot figure out what to inline). You could just extend the find_and_get_object() to search both trees under a single spinlock region (as locking also takes time). Ok, a good point. Anyway, you still get to search two trees for any pointer so there would always be some performance impact. I just hoped they weren't be as bad. In a normal system (not test module), how many elements would the alias tree have? Just in our case, it's 512 at most. Another approach - if we assume that there is a single alias per object and such aliases don't overlap, we could just move (delete + re-insert) the corresponding kmemleak_object in the tree to the alias position. This way we only keep a single tree and a single object for an allocated block. But in your use-case, the physical address of an object may actually match the virtual address of a different object, so lookup_object() needs to be iterative. You need two new kmemleak API functions, e.g. kmemleak_alias() and kmemleak_unalias(), to be called after allocation and before freeing a memory block. If we can't make the performance hit acceptable, we could go for the first approach and maybe just extend kmemleak_scan_area with a function pointer structure rather than adding a new one. But as I said previously, my main issue with your original approach is that I would prefer to call the kmemleak API at the point where the false positive is allocated rather than where the parent object was. I'll try both and measure their impact again. Thank you for your comment. -- To unsubscribe from this list: send the line unsubscribe 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] omap iommu: for-next for 2.6.35-rc1
Hi Tony, From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Wed, 02 Jun 2010 10:50:54 +0300 (EEST) Hi Tony, Patches for for-next for omap iommu module. The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc1-iommu Hiroshi DOYU (3): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer Kanigeri, Hari (2): omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt arch/arm/mach-omap2/iommu2.c| 44 -- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 27 --- arch/arm/plat-omap/iopgtable.h |8 +++-- 4 files changed, 65 insertions(+), 16 deletions(-) Any chance to merge? I have added 2 patches which were dropped from omap iommu fix as below. Please pull the following branch. The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-iommu-for-next Hiroshi DOYU (4): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer omap iommu: Make omap-iommu.o built-in Kanigeri, Hari (3): omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt omap iommu: update ducati mmu irq define name arch/arm/mach-omap2/Makefile|5 +++- arch/arm/mach-omap2/iommu2.c| 44 -- arch/arm/mach-omap2/omap-iommu.c|2 +- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 27 --- arch/arm/plat-omap/iopgtable.h |8 +++-- 6 files changed, 70 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Hi, This is another version of kmemleak: Fix false positive, which introduces another alias tree to keep track of all alias address of each objects, based on the discussion(*1) You can also find the previous one(*2), which uses special scan area for alias addresses with a conversion function. Compared with both methods, it seems that the current one takes a bit longer to scan as below, tested with 512 elementes of (*3). kmemleak: Fix false positive with alias: # time echo scan /mnt/kmemleak real0m 8.40s user0m 0.00s sys 0m 8.40s kmemleak: Fix false positive with special scan: # time echo scan /mnt/kmemleak real0m 3.96s user0m 0.00s sys 0m 3.96s For our case(*4) to reduce false positives for the 2nd level IOMMU pagetable allocation, the previous special scan seems to be enough lightweight, although there might be possiblity to improve alias one and also I might misunderstand the original proposal of aliasing. Any comment would be appreciated. *1: http://lkml.org/lkml/2010/6/2/282 *2: kmemleak: Fix false positive with special scan http://lkml.org/lkml/2010/6/1/137 *3: kmemleak: Add special scan test case http://lkml.org/lkml/2010/6/1/134 *4: http://lkml.org/lkml/2010/6/1/136 Hiroshi DOYU (1): kmemleak: Fix false positive with alias include/linux/kmemleak.h |4 + mm/kmemleak.c| 198 ++ 2 files changed, 168 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] kmemleak: Fix false positive with alias
There is a false positive case that a pointer is calculated by other
methods than the usual container_of macro. kmemleak_ignore can cover
such a false positive, but it would loose the advantage of memory leak
detection. This patch allows kmemleak to work with such false
positives by aliasing of address. A client module can register an
alias address to an original pointer.
A typical use case could be the IOMMU pagetable allocation which
stores pointers to the second level of page tables with some
conversion, for example, a physical address with attribute bits. Right
now I don't have other use cases but I hope that there could be some
that this special scan works with.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
---
include/linux/kmemleak.h |4 +
mm/kmemleak.c| 198 ++
2 files changed, 168 insertions(+), 34 deletions(-)
diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index 99d9a67..0a4ccee 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -34,6 +34,7 @@ extern void kmemleak_not_leak(const void *ptr) __ref;
extern void kmemleak_ignore(const void *ptr) __ref;
extern void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp) __ref;
extern void kmemleak_no_scan(const void *ptr) __ref;
+extern void kmemleak_add_alias(const void *ptr, const void *new) __ref;
static inline void kmemleak_alloc_recursive(const void *ptr, size_t size,
int min_count, unsigned long flags,
@@ -92,6 +93,9 @@ static inline void kmemleak_erase(void **ptr)
static inline void kmemleak_no_scan(const void *ptr)
{
}
+static inline void kmemleak_add_alias(const void *ptr, const void *new)
+{
+}
#endif /* CONFIG_DEBUG_KMEMLEAK */
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 2c0d032..fa20304 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -157,6 +157,13 @@ struct kmemleak_object {
unsigned long jiffies; /* creation timestamp */
pid_t pid; /* pid of the current task */
char comm[TASK_COMM_LEN]; /* executable name */
+ struct kmemleak_alias *alias; /* if a pointer is modified */
+};
+
+struct kmemleak_alias {
+ struct list_head alias_list;
+ struct prio_tree_node tree_node;
+ struct kmemleak_object *object;
};
/* flag representing the memory block allocation status */
@@ -179,13 +186,18 @@ struct kmemleak_object {
static LIST_HEAD(object_list);
/* the list of gray-colored objects (see color_gray comment below) */
static LIST_HEAD(gray_list);
+/* the list of objects with alias (see alias comment below) */
+static LIST_HEAD(alias_list);
/* prio search tree for object boundaries */
static struct prio_tree_root object_tree_root;
+/* prio search tree for alias object boundaries */
+static struct prio_tree_root alias_tree_root;
/* rw_lock protecting the access to object_list and prio_tree_root */
static DEFINE_RWLOCK(kmemleak_lock);
/* allocation caches for kmemleak internal data */
static struct kmem_cache *object_cache;
+static struct kmem_cache *alias_cache;
static struct kmem_cache *scan_area_cache;
/* set if tracing memory operations is enabled */
@@ -269,6 +281,8 @@ static void kmemleak_disable(void);
kmemleak_disable(); \
} while (0)
+#define to_address(obj) ((obj)-tree_node.start)
+
/*
* Printing of the objects hex dump to the seq file. The number of lines to be
* printed is limited to HEX_MAX_LINES to prevent seq file spamming. The
@@ -369,7 +383,7 @@ static void dump_object_info(struct kmemleak_object *object)
trace.entries = object-trace;
pr_notice(Object 0x%08lx (size %zu):\n,
- object-tree_node.start, object-size);
+ to_address(object), object-size);
pr_notice( comm \%s\, pid %d, jiffies %lu\n,
object-comm, object-pid, object-jiffies);
pr_notice( min_count = %d\n, object-min_count);
@@ -436,6 +450,8 @@ static void free_object_rcu(struct rcu_head *rcu)
hlist_del(elem);
kmem_cache_free(scan_area_cache, area);
}
+ if (object-alias)
+ kmem_cache_free(alias_cache, object-alias);
kmem_cache_free(object_cache, object);
}
@@ -479,6 +495,41 @@ static struct kmemleak_object
*find_and_get_object(unsigned long ptr, int alias)
return object;
}
+static struct kmemleak_object *find_and_get_object_by_alias(unsigned long ptr,
+ int alias)
+{
+ struct kmemleak_object *object = NULL;
+ struct kmemleak_alias *ao = NULL;
+ struct prio_tree_node *node;
+ struct prio_tree_iter iter;
+ unsigned long flags;
+
+ if (likely(prio_tree_empty(alias_tree_root)))
+ return NULL;
+
+ rcu_read_lock();
+ read_lock_irqsave(kmemleak_lock
Re: [PATCH v4 00/14] omap: mailbox: bunch of cleanups
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: [PATCH v4 00/14] omap: mailbox: bunch of cleanups Date: Fri, 11 Jun 2010 17:51:35 +0200 From: Felipe Contreras --global Hi, These are hopefully non-functional changes. Just shuffling code around, and removing unecessary stuff. This v4 includes minor changes suggested by Felipe Balbi, Hiroshi, and Russell. Comments from Felipe Balbi, Tony Lindgren, Hiroshi DOYU, and Russell King. Applied against: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-mailbox Only [PATCH 1/14] isn't used since the original patch is correct but messed up at applying just in my branch. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
From: ext C.A, Subramaniam subramaniam...@ti.com Subject: RE: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Date: Mon, 14 Jun 2010 17:56:35 +0200 Hi Ohad/Hiroshi, Good to see the new mailbox requirements. While we are at it can we add some more :)? * Make the mailbox as a generic driver. Meaning, users can request for a pair of mailbox rather than using a set of pre-defined ones. For eg: Instead of doing an omap_mbox_get(mailbox-1) we can have the user specify the mailbox pair that he needs ( omap_mbox_get(int tx_mbox, int rx_mbox) or similar API ). This also means that we remove the bulk of the data structures like omap2_mbox_1_priv and mbox_1_info and so on. Additional checks needs to be done so that consequtive requests to the driver does not re-configure the rx-tx pairs. Rationale: The pre-configured structures does make sense in case of DSP Bridge, since it is the only user of mailbox. However, for Syslink for example, (or for any other IPC or user of mailbox) it would be good for the user of the mailbox to request the pair (or just tx/rx) from user/kernel side. Fair enough. * Provide debug support for the mailboxes (relevant for OMAP4) Since OMAP4 has support to read the RAW registers we might as well add an API for the user to read the status from RAW registers. This could be debugfs. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
Hi Ohad, From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Date: Tue, 15 Jun 2010 06:43:21 +0200 Hi Hiroshi, On Mon, Jun 14, 2010 at 3:58 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: Does dspbridge really need its own defered work for sending mailbox messages? We do, according to http://permalink.gmane.org/gmane.linux.ports.arm.omap/38240 I am wondering that this defered work may not be necessary just for the serialization. (thanks Rene for the explanation). For recieving, its defered work(tasklet) can be trigered directly in the above proposed callback, that callback can triger its own workqueue if necessary, then. Agree I think that, for recieving, some PM command may has to be sent back immedieately inside of tasklet. omap_mbox_msg_send_sync() may handle this case. Not sure how much QoS is an issue with mailbox (do we really have latency issues ?), but I guess adding such interface can't hurt. This solves the one case of lockdep issue. I think that workqueue is only necessary when it has to sleep, otherwise tasklet is prefered. I must say I disagree; tasklets are really not friendly to the whole system's responsiveness and should be used only if really needed (there was even an attempt to remove them entirely in the past: http://lwn.net/Articles/239633/). Evoking a workqueue may be overkilling just for putting several bytes into registers since large part of contents is usually passed through shared memory. I'd like to allow mutiple listners in some way, as the flexibility of mailbox functionalty. This can be achieved using notifier chains of multiple listeners callback, but I agree with Felipe: do we really want this functionality ? I just rather not add code that no one is going to use. What do you say we start with enforcing only 1 listener and later, if the use case of several listeners shows up, we'd add that support (promise! :) ? Fair enough. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
Hi Ohad, From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Date: Wed, 16 Jun 2010 07:09:13 +0200 On Tue, Jun 15, 2010 at 3:04 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: Fair enough. Thanks, I'll prepare them and resubmit You can use the following branch which has accumulateed unmerged mailbox patches. git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-mailbox -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
Hi Ohad, From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Date: Mon, 14 Jun 2010 01:52:16 +0200 On Wed, Jun 9, 2010 at 12:07 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 87e0cde..1b79b32 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -188,7 +188,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox) /* no more messages in the fifo. clear IRQ source. */ ack_mbox_irq(mbox, IRQ_RX); nomem: - queue_work(mboxd, mbox-rxq-work); + mbox-callback(mbox); } I like this ! It will allow us to easily plug in new IPC mechanisms in the future. Agree. (btw, if we do this, and also introduce omap_mbox_msg_send_sync, do we still need a mailbox queuing mechanism at all ? :) I think that queuing(can be called as S/W fifo/buffer?) is basically necessary it can compensate the shortage of H/W fifo slots under high load or emergency case. It has only 4 slots. I guess that, DSP usually responds quickly and 4 H/W slots may be enough, but it might be safer/more robust to avoid the assumption which depends on other entity/DSP. From latecy perspective, s/w fifo + tasklet would be enough short. omap_mbox_msg_send_sync() can handle the case for a special message, like PM, which has to respond at the higher priority than the normal ones. Having said that, this is not going to solve the lockdep warning reported by Deepak - that was caused because of dspbridge's sending context (and not because of the receiving context). To eliminate that Does dspbridge really need its own defered work for sending mailbox messages? For me, the problem here is the unneccesary duplication of tasklet, or can be said, the unnecessary use of tasklet for _sending_ mailbox messages in dspbridge. http://marc.info/?l=linux-omapm=127601655325416w=2 I thought that bridge_msg_put()/bridge_msg_get() can use omap mbox APIs directly, with getting rid of its use of its own defered work/tasklet as pointed out in the above link. Fernando? For recieving, its defered work(tasklet) can be trigered directly in the above proposed callback, that callback can triger its own workqueue if necessary, then. I think that, for recieving, some PM command may has to be sent back immedieately inside of tasklet. omap_mbox_msg_send_sync() may handle this case. What do you think? issue, I prefer fixing dspbridge to use work queues rather than using spin_lock_bh in omap_mbox_msg_send. Disabling system bottom halves just to send a mbox msg sounds unjustified (unless bridge really needs to use tasklets instead of work queues, which I slightly doubt). What do you think ? I think that workqueue is only necessary when it has to sleep, otherwise tasklet is prefered. For _sending_ a message inside of dspbridge, I haven't found any reasonable reason to use any defered work(softirq, tasklet, workqueue) so far. Speaking of mailbox I'd like to address some issues that are code related: * Let's add mailbox API to set the callback pointer (it feels wrong to let users directly manipulate the mbox structure). * We can also safely move the callback field to the main mbox structure, since it has no usage in the TX mq; it's pretty global to the whole mbox. * Let's make sure no one accidentally registers two receivers on the same time (which would result in one overwriting the other's callback field). I'd like to allow mutiple listners in some way, as the flexibility of mailbox functionalty. * mbox_configured is a global variable and that breaks support of multiple concurrent mailbox instances. Let's move this logic into the instance of mbox. * If we make sure there are no two user of the same mailbox instance (see 3rd *), we can eliminate mbox_configured and its locking (not that doesn't mean there can't be two concurrent sending contexts, it just means they are somewhat related, they have a common receiver, which was registered using only a single call to get). Something like this, pls tell me what you think: For the above 5 proposals, excpet the multiple listeners issue, they seems ok. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Date: Tue, 8 Jun 2010 11:43:28 +0200 On Tue, Jun 8, 2010 at 6:46 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Guzman Lugo, Fernando fernando.l...@ti.com I think the best thing to do here is remove the spinlock, if not, you are preventing that omap_mbox_msg_send be executed from a tasklet or isr context. That maybe in this moment it is not called but it could be needed in the future. The caller of omap_mbox_msg_send should be take care of that function can not be call simultaneously. What about adding another function, omap_mbox_msg_send_sync()? That's exactly what I was thinking about when I heard the problem. Would this function send all the msgs already queued, and then wait for the current one actually be sent? Could be as you said. I haven't thought that much. What I just thought was to bypass kfifo and tasklet and to put a message directly to H/W fifo. Maily just for the above case which Fernando described above. Fernando, what do you think on Felipes? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Date: Tue, 8 Jun 2010 04:54:55 +0200 On Mon, Jun 7, 2010 at 6:14 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: I think the best thing to do here is remove the spinlock I'm afraid we can't do that: we need it to support OMAP4 syslink IPC use cases which have multiple simultaneous sending contexts. , if not, you are preventing that omap_mbox_msg_send be executed from a tasklet or isr context. Right. But this is pretty standard - you can't call every kernel API from every possible context - the allowed calling context is part of the API. If later we decide we need to add additional calling contexts, it's ok - it's just like changing the API. Why not remove the workqueue at all and let the mailbox module user be the judge for using tasklet, workqueue or do the job in the same isr (if it is small task and need to be fast)? hmm I'm not following here - will you please elaborate on this a bit more ? The abvoe could be something like below: Modified arch/arm/plat-omap/mailbox.c diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 87e0cde..1b79b32 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -188,7 +188,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox) /* no more messages in the fifo. clear IRQ source. */ ack_mbox_irq(mbox, IRQ_RX); nomem: - queue_work(mboxd, mbox-rxq-work); + mbox-callback(mbox); } static irqreturn_t mbox_interrupt(int irq, void *p) The user/client of mbox can register its own callback function in advance and do its own job(tasklet, workqueue, just func whatever) later by itself. It makes more sense to me than the current workqueue as default. -- To unsubscribe from this list: send the line unsubscribe 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] omap iommu: fixes for 2.6.35-rc1
From: ext Tony Lindgren t...@atomide.com Subject: Re: [GIT PULL] omap iommu: fixes for 2.6.35-rc1 Date: Mon, 7 Jun 2010 13:17:48 +0200 Since Linus only wants regression fixes nowadays during the -rc cycle, few more questions below. * Hiroshi DOYU hiroshi.d...@nokia.com [100602 10:45]: Hi Tony, Patches only for fixes for omap iommu module during -rc cycle. The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc1-iommu-fixes Hiroshi DOYU (1): omap iommu: Make omap-iommu.o built-in Does the above actually fix some problem? If it fixes some problem, it should be in the description. If not, maybe move this one for the next merge window? This is a fix for the previously overwriting obj-y/m as blow, and updated the description as well. -obj-$(CONFIG_OMAP_IOMMU) := iommu2.o omap-iommu.o +obj-$(CONFIG_OMAP_IOMMU) += iommu2.o Kanigeri, Hari (1): omap iommu: update ducati mmu irq define name This description does not seem to make sense as the ducati irq define was added with e927f8d04ec8aff249beab2f7e1832c67623d0f5 and has not changed. The description is for some non-mainline tree talking about 2.6.34-rc6 so it should be updated. Updated the description. Satish (1): omap iommu: Fix Memory leak This one looks like a genuine fix :) I've also updated the branch against -rc2. Please merge it if no problem. The following changes since commit e44a21b7268a022c7749f521c06214145bd161e4: Linux 2.6.35-rc2 (2010-06-05 20:43:24 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc2-iommu-fixes Hiroshi DOYU (1): omap iommu: fix: Make omap-iommu.o built-in Kanigeri, Hari (1): omap iommu: fix ducati mmu irq define name Satish (1): omap iommu: Fix Memory leak arch/arm/mach-omap2/Makefile |5 - arch/arm/mach-omap2/omap-iommu.c |2 +- arch/arm/plat-omap/iovmm.c |4 +++- 3 files changed, 8 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
From: ext Guzman Lugo, Fernando fernando.l...@ti.com Subject: RE: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Date: Tue, 8 Jun 2010 01:14:41 +0200 Hi, -Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Monday, June 07, 2010 4:41 PM To: Chitriki Rudramuni, Deepak; Guzman Lugo, Fernando; Ramirez Luna, Omar; Kanigeri, Hari Cc: linux-omap@vger.kernel.org; Hiroshi Doyu Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Hi Deepak, On Mon, Jun 7, 2010 at 1:52 PM, Deepak Chitriki deepak.chitr...@ti.com wrote: With this patch I observed inconsistent lock state warning. Thanks for the report! Kfifo is acccessed in omap_mbox_msg_send() and mbox_tx_tasklet() functions.In order to protect this critical section we need to protect by using spin_lock_bh() so that the tasklet cannot preempt omap_mobx_msg_send(). This is actually not the problem: it's ok if mbox_tx_tasklet preempts omap_mbox_msg_send. In fact, such a use case is even ok if we don't take a spinlock at all: kfifo is designed in a way that if you have only 1 consumer and 1 producer, they can both access kfifo simultaneously without any locking. That's why we don't take the spinlock in the mbox_tx_tasklet. The reason, btw, that we take a spinlock in omap_mbox_msg_send is to allow multiple simultaneous sending contexts (taking a spinlock there ensures serialization of those multiple simultaneous sending contexts). The problem here lies in the fact (that I've just learnt) that dspbridge also sends mbox messages from a tasklet context (dpc_tasklet). Lockdep identifies that the spinlock is taken in a softirq context (dspbridge's dpc_tasklet) after it was previously taken in a softirq-enabled context. Your proposed fix will solve the lockdep issue here, but: I think the best thing to do here is remove the spinlock, if not, you are preventing that omap_mbox_msg_send be executed from a tasklet or isr context. That maybe in this moment it is not called but it could be needed in the future. The caller of omap_mbox_msg_send should be take care of that function can not be call simultaneously. What about adding another function, omap_mbox_msg_send_sync()? I don't want to limit the ability of having multiple senders. The above would send the message with bypassing tasklet. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Date: Tue, 8 Jun 2010 05:11:50 +0200 Hi Deepak, On Mon, Jun 7, 2010 at 6:27 PM, Deepak Chitriki deepak.chitr...@ti.com wrote: Ohad Ben-Cohen wrote: Somewhat relevant note about mailbox performance: omap_mbox_msg_send often (i.e. when the kfifo is empty) can just send the message directly, without triggering the tasklet to do that. Applying such a change will substantially improve the mailbox performance, and will make the shift to workqueues even more reasonable. I've got a patch for that, I'll post it soon. tasklet is run in atomic context,so I wonder how mailbox performance will increase if you switch from tasklet to workqueue? In general moving from tasklet to workqueues will probably increase some scheduling latencies. Nevertheless, if we'll send mailbox messages directly whenever possible, without triggering any deferred context, we'll be improving mailbox performance on average, because most of the time we will get rid of the scheduling latencies entirely. I think that this depends on the situation. 1) too many messages are coming, buffering and tasklet works efficiently at onece, for good throughput. 2) too few messages, the latency won't be a problem? Or some PM case may be concerned. I guess that most of the case, we just care about the throughput of encoding and decoding, but I am afraid that data themselves are sent via shared memory and the traffic of mailbox message may not be so big. I'd like to see the actual data for practical usecases. Does TI have some typical test pattern to measure throughput? Or Felipe? -- To unsubscribe from this list: send the line unsubscribe 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 10/10] omap mailbox: Set a device in logical mbox instance for traceability
From: Hiroshi DOYU hiroshi.d...@nokia.com
With this patch, you'll get the following sysfs directories. This
structure implies that a single platform device, omap2-mailbox holds
multiple logical mbox instances. This could be the base to add sysfs
files for each logical mboxes. Then userland application can access a
mbox through sysfs entries if necessary(ex: setting kfifo size
dynamically)
~# tree -d -L 2 /sys/devices/platform/omap2-mailbox/
/sys/devices/platform/omap2-mailbox/
|-- driver - ../../../bus/platform/drivers/omap2-mailbox
|-- mbox
| |-- dsp - they are each instances of logical mailbox.
| |-- ducati
| |-- iva2
| |-- mbox01
| |-- mbox02
| |-- mbox03
| |-- .
| `-- tesla
|-- power
`-- subsystem - ../../../bus/platform
This was wrongly dropped by:
commit c7c158e57bce6220644f2bcd65d82e1468aa40ec
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/mailbox.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index ec0e159..87e0cde 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -347,6 +347,8 @@ void omap_mbox_put(struct omap_mbox *mbox)
}
EXPORT_SYMBOL(omap_mbox_put);
+static struct class omap_mbox_class = { .name = mbox, };
+
int omap_mbox_register(struct device *parent, struct omap_mbox *mbox)
{
int ret = 0;
@@ -357,6 +359,11 @@ int omap_mbox_register(struct device *parent, struct
omap_mbox *mbox)
if (mbox-next)
return -EBUSY;
+ mbox-dev = device_create(omap_mbox_class,
+ parent, 0, mbox, %s, mbox-name);
+ if (IS_ERR(mbox-dev))
+ return PTR_ERR(mbox-dev);
+
spin_lock(mboxes_lock);
tmp = find_mboxes(mbox-name);
if (*tmp) {
@@ -385,6 +392,7 @@ int omap_mbox_unregister(struct omap_mbox *mbox)
*tmp = mbox-next;
mbox-next = NULL;
spin_unlock(mboxes_lock);
+ device_unregister(mbox-dev);
return 0;
}
tmp = (*tmp)-next;
@@ -397,6 +405,12 @@ EXPORT_SYMBOL(omap_mbox_unregister);
static int __init omap_mbox_init(void)
{
+ int err;
+
+ err = class_register(omap_mbox_class);
+ if (err)
+ return err;
+
mboxd = create_workqueue(mboxd);
if (!mboxd)
return -ENOMEM;
@@ -407,11 +421,12 @@ static int __init omap_mbox_init(void)
return 0;
}
-module_init(omap_mbox_init);
+subsys_initcall(omap_mbox_init);
static void __exit omap_mbox_exit(void)
{
destroy_workqueue(mboxd);
+ class_unregister(omap_mbox_class);
}
module_exit(omap_mbox_exit);
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] Mailbox: flush pending deferred works before freeing blk queue
From: Fernando Guzman Lugo x0095...@ti.com
flush pending deferred works before freeing blk_queue to prevent
any attempt of access to blk_queue after it was freed
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/mailbox.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 252a586..77c23f5 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -299,6 +299,8 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
static void omap_mbox_fini(struct omap_mbox *mbox)
{
free_irq(mbox-irq, mbox);
+ tasklet_kill(mbox-txq-tasklet);
+ flush_work(mbox-rxq-work);
mbox_queue_free(mbox-txq);
mbox_queue_free(mbox-rxq);
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] omap: mailbox cleanup: split MODULE_AUTHOR line
From: Ohad Ben-Cohen o...@wizery.com use multiple MODULE_AUTHOR lines for multiple authors Signed-off-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/mach-omap2/mailbox.c |3 ++- arch/arm/plat-omap/mailbox.c |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 318f363..763272c 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -486,5 +486,6 @@ module_exit(omap2_mbox_exit); MODULE_LICENSE(GPL v2); MODULE_DESCRIPTION(omap mailbox: omap2/3/4 architecture specific functions); -MODULE_AUTHOR(Hiroshi DOYU hiroshi.d...@nokia.com, Paul Mundt); +MODULE_AUTHOR(Hiroshi DOYU hiroshi.d...@nokia.com); +MODULE_AUTHOR(Paul Mundt); MODULE_ALIAS(platform:DRV_NAME); diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index fafe47b..66c6e87 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -430,4 +430,5 @@ module_exit(omap_mbox_exit); MODULE_LICENSE(GPL v2); MODULE_DESCRIPTION(omap mailbox: interrupt driven messaging); -MODULE_AUTHOR(Toshihiro Kobayashi and Hiroshi DOYU); +MODULE_AUTHOR(Toshihiro Kobayashi); +MODULE_AUTHOR(Hiroshi DOYU); -- 1.7.1.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] Mailbox: Check valid registered callback before calling
From: Fernando Guzman Lugo x0095...@ti.com This patch checks if the mailbox user has assinged a valid callback fuction before calling it. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/plat-omap/mailbox.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 77c23f5..72efbe5 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -146,7 +146,8 @@ static void mbox_rx_work(struct work_struct *work) msg = (mbox_msg_t)rq-special; blk_end_request_all(rq, 0); - mbox-rxq-callback((void *)msg); + if (mbox-rxq-callback) + mbox-rxq-callback((void *)msg); } } -- 1.7.1.rc1 -- To unsubscribe from this list: send the line unsubscribe 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 04/10] Mailbox: new mutext lock for h/w mailbox configuration
mailbox startup and shutdown are being executed against
a single H/W module, and a mailbox H/W module is totally
__independent__ of the registration of logical mailboxes.
So, an independent mutext should be used for startup and
shutdown.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/mailbox.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 72efbe5..986002b 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -34,6 +34,7 @@ static struct omap_mbox *mboxes;
static DEFINE_RWLOCK(mboxes_lock);
static int mbox_configured;
+static DEFINE_MUTEX(mbox_configured_lock);
/* Mailbox FIFO handle functions */
static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
@@ -250,16 +251,16 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
struct omap_mbox_queue *mq;
if (likely(mbox-ops-startup)) {
- write_lock(mboxes_lock);
+ mutex_lock(mbox_configured_lock);
if (!mbox_configured)
ret = mbox-ops-startup(mbox);
if (unlikely(ret)) {
- write_unlock(mboxes_lock);
+ mutex_unlock(mbox_configured_lock);
return ret;
}
mbox_configured++;
- write_unlock(mboxes_lock);
+ mutex_unlock(mbox_configured_lock);
}
ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
@@ -306,12 +307,12 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
mbox_queue_free(mbox-rxq);
if (unlikely(mbox-ops-shutdown)) {
- write_lock(mboxes_lock);
+ mutex_lock(mbox_configured_lock);
if (mbox_configured 0)
mbox_configured--;
if (!mbox_configured)
mbox-ops-shutdown(mbox);
- write_unlock(mboxes_lock);
+ mutex_unlock(mbox_configured_lock);
}
}
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe 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 09/10] omap: mailbox: convert block api to kfifo
From: Ohad Ben-Cohen o...@wizery.com
The underlying buffering implementation of mailbox
is converted from block API to kfifo due to the simplicity
and speed of kfifo.
The default size of the kfifo buffer is set to 256 bytes.
This value is configurable at compile time (via
CONFIG_OMAP_MBOX_KFIFO_SIZE), and can be changed at
runtime (via the mbox_kfifo_size module parameter).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/Kconfig|9 ++
arch/arm/plat-omap/include/plat/mailbox.h |4 +-
arch/arm/plat-omap/mailbox.c | 119 +
3 files changed, 64 insertions(+), 68 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 78b49a6..111d39a 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -106,6 +106,15 @@ config OMAP_MBOX_FWK
Say Y here if you want to use OMAP Mailbox framework support for
DSP, IVA1.0 and IVA2 in OMAP1/2/3.
+config OMAP_MBOX_KFIFO_SIZE
+ int Mailbox kfifo default buffer size (bytes)
+ depends on OMAP_MBOX_FWK
+ default 256
+ help
+ Specify the default size of mailbox's kfifo buffers (bytes).
+ This can also be changed at runtime (via the mbox_kfifo_size
+ module parameter).
+
config OMAP_IOMMU
tristate
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 729166b..0c3c4a5 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -5,8 +5,8 @@
#include linux/wait.h
#include linux/workqueue.h
-#include linux/blkdev.h
#include linux/interrupt.h
+#include linux/kfifo.h
typedef u32 mbox_msg_t;
struct omap_mbox;
@@ -42,7 +42,7 @@ struct omap_mbox_ops {
struct omap_mbox_queue {
spinlock_t lock;
- struct request_queue*queue;
+ struct kfifofifo;
struct work_struct work;
struct tasklet_struct tasklet;
int (*callback)(void *);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 81076b5..ec0e159 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -21,11 +21,14 @@
*
*/
+#include linux/kernel.h
#include linux/module.h
#include linux/interrupt.h
#include linux/device.h
#include linux/delay.h
#include linux/slab.h
+#include linux/kfifo.h
+#include linux/err.h
#include plat/mailbox.h
@@ -37,6 +40,10 @@ static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
+static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
+module_param(mbox_kfifo_size, uint, S_IRUGO);
+MODULE_PARM_DESC(mbox_kfifo_size, Size of omap's mailbox kfifo (bytes));
+
/* Mailbox FIFO handle functions */
static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
{
@@ -69,7 +76,7 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
/*
* message sender
*/
-static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
+static int __mbox_poll_for_space(struct omap_mbox *mbox)
{
int ret = 0, i = 1000;
@@ -80,49 +87,50 @@ static int __mbox_msg_send(struct omap_mbox *mbox,
mbox_msg_t msg)
return -1;
udelay(1);
}
- mbox_fifo_write(mbox, msg);
return ret;
}
-
int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
{
+ struct omap_mbox_queue *mq = mbox-txq;
+ int ret = 0, len;
- struct request *rq;
- struct request_queue *q = mbox-txq-queue;
+ spin_lock(mq-lock);
- rq = blk_get_request(q, WRITE, GFP_ATOMIC);
- if (unlikely(!rq))
- return -ENOMEM;
+ if (kfifo_avail(mq-fifo) sizeof(msg)) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
+ WARN_ON(len != sizeof(msg));
- blk_insert_request(q, rq, 0, (void *) msg);
tasklet_schedule(mbox-txq-tasklet);
- return 0;
+out:
+ spin_unlock(mq-lock);
+ return ret;
}
EXPORT_SYMBOL(omap_mbox_msg_send);
static void mbox_tx_tasklet(unsigned long tx_data)
{
- int ret;
- struct request *rq;
struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
- struct request_queue *q = mbox-txq-queue;
-
- while (1) {
-
- rq = blk_fetch_request(q);
-
- if (!rq)
- break;
+ struct omap_mbox_queue *mq = mbox-txq;
+ mbox_msg_t msg;
+ int ret;
- ret = __mbox_msg_send(mbox, (mbox_msg_t)rq-special);
- if (ret) {
+ while (kfifo_len(mq-fifo)) {
+ if (__mbox_poll_for_space(mbox)) {
omap_mbox_enable_irq(mbox, IRQ_TX
[PATCH 06/10] omap: mailbox: convert rwlocks to spinlock
From: Ohad Ben-Cohen o...@wizery.com
rwlocks are slower and have potential starvation issues
therefore spinlocks are generally preferred.
see also: http://lwn.net/Articles/364583/
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Kanigeri Hari h-kanige...@ti.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/mailbox.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index c340216..fafe47b 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -31,7 +31,7 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox *mboxes;
-static DEFINE_RWLOCK(mboxes_lock);
+static DEFINE_SPINLOCK(mboxes_lock);
static bool rq_full;
static int mbox_configured;
@@ -341,14 +341,14 @@ struct omap_mbox *omap_mbox_get(const char *name)
struct omap_mbox *mbox;
int ret;
- read_lock(mboxes_lock);
+ spin_lock(mboxes_lock);
mbox = *(find_mboxes(name));
if (mbox == NULL) {
- read_unlock(mboxes_lock);
+ spin_unlock(mboxes_lock);
return ERR_PTR(-ENOENT);
}
- read_unlock(mboxes_lock);
+ spin_unlock(mboxes_lock);
ret = omap_mbox_startup(mbox);
if (ret)
@@ -374,15 +374,15 @@ int omap_mbox_register(struct device *parent, struct
omap_mbox *mbox)
if (mbox-next)
return -EBUSY;
- write_lock(mboxes_lock);
+ spin_lock(mboxes_lock);
tmp = find_mboxes(mbox-name);
if (*tmp) {
ret = -EBUSY;
- write_unlock(mboxes_lock);
+ spin_unlock(mboxes_lock);
goto err_find;
}
*tmp = mbox;
- write_unlock(mboxes_lock);
+ spin_unlock(mboxes_lock);
return 0;
@@ -395,18 +395,18 @@ int omap_mbox_unregister(struct omap_mbox *mbox)
{
struct omap_mbox **tmp;
- write_lock(mboxes_lock);
+ spin_lock(mboxes_lock);
tmp = mboxes;
while (*tmp) {
if (mbox == *tmp) {
*tmp = mbox-next;
mbox-next = NULL;
- write_unlock(mboxes_lock);
+ spin_unlock(mboxes_lock);
return 0;
}
tmp = (*tmp)-next;
}
- write_unlock(mboxes_lock);
+ spin_unlock(mboxes_lock);
return -EINVAL;
}
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] Mailbox: free mailbox interrupt before freeing blk queue
From: Fernando Guzman Lugo x0095...@ti.com
Free interrupt before freeing blk_queue to avoid
any attempt of access to blk_queue after it was freed.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/mailbox.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 08a2df7..252a586 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -298,11 +298,10 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
static void omap_mbox_fini(struct omap_mbox *mbox)
{
+ free_irq(mbox-irq, mbox);
mbox_queue_free(mbox-txq);
mbox_queue_free(mbox-rxq);
- free_irq(mbox-irq, mbox);
-
if (unlikely(mbox-ops-shutdown)) {
write_lock(mboxes_lock);
if (mbox_configured 0)
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] omap: mailbox: remove (un)likely macros from cold paths
From: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/mailbox.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 66c6e87..81076b5 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -258,12 +258,12 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
int ret = 0;
struct omap_mbox_queue *mq;
- if (likely(mbox-ops-startup)) {
+ if (mbox-ops-startup) {
mutex_lock(mbox_configured_lock);
if (!mbox_configured)
ret = mbox-ops-startup(mbox);
- if (unlikely(ret)) {
+ if (ret) {
mutex_unlock(mbox_configured_lock);
return ret;
}
@@ -273,7 +273,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
mbox-name, mbox);
- if (unlikely(ret)) {
+ if (ret) {
printk(KERN_ERR
failed to register mailbox interrupt:%d\n, ret);
goto fail_request_irq;
@@ -300,7 +300,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
fail_alloc_txq:
free_irq(mbox-irq, mbox);
fail_request_irq:
- if (unlikely(mbox-ops-shutdown))
+ if (mbox-ops-shutdown)
mbox-ops-shutdown(mbox);
return ret;
@@ -314,7 +314,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
mbox_queue_free(mbox-txq);
mbox_queue_free(mbox-rxq);
- if (unlikely(mbox-ops-shutdown)) {
+ if (mbox-ops-shutdown) {
mutex_lock(mbox_configured_lock);
if (mbox_configured 0)
mbox_configured--;
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] Mailbox: disable mailbox interrupt when request queue
From: Fernando Guzman Lugo x0095...@ti.com
when blk_get_request fails to get the request it is returning
without read the message from the mailbox fifo, then when it
leaves the isr and interruption is trigger again and again and
the workqueue which get elements from the request queue is never
executed and the kernel is stuck and shows a softlockup message.
Now the mailbox interrupt is disabled when request queue is full
and enabled when it pop a elememt form the request queue.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/mailbox.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 986002b..c340216 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -32,6 +32,7 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox *mboxes;
static DEFINE_RWLOCK(mboxes_lock);
+static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -141,6 +142,10 @@ static void mbox_rx_work(struct work_struct *work)
while (1) {
spin_lock_irqsave(q-queue_lock, flags);
rq = blk_fetch_request(q);
+ if (rq_full) {
+ omap_mbox_enable_irq(mbox, IRQ_RX);
+ rq_full = false;
+ }
spin_unlock_irqrestore(q-queue_lock, flags);
if (!rq)
break;
@@ -178,8 +183,11 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
rq = blk_get_request(q, WRITE, GFP_ATOMIC);
- if (unlikely(!rq))
+ if (unlikely(!rq)) {
+ omap_mbox_disable_irq(mbox, IRQ_RX);
+ rq_full = true;
goto nomem;
+ }
msg = mbox_fifo_read(mbox);
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] omap mailbox: Paches for -next
Hi, The following patches are for -next for omap mailbox module. Fernando Guzman Lugo (4): Mailbox: free mailbox interrupt before freeing blk queue Mailbox: flush pending deferred works before freeing blk queue Mailbox: Check valid registered callback before calling Mailbox: disable mailbox interrupt when request queue Hiroshi DOYU (2): Mailbox: new mutext lock for h/w mailbox configuration omap mailbox: Set a device in logical mbox instance for traceability Ohad Ben-Cohen (4): omap: mailbox: convert rwlocks to spinlock omap: mailbox cleanup: split MODULE_AUTHOR line omap: mailbox: remove (un)likely macros from cold paths omap: mailbox: convert block api to kfifo arch/arm/mach-omap2/mailbox.c |3 +- arch/arm/plat-omap/Kconfig|9 ++ arch/arm/plat-omap/include/plat/mailbox.h |4 +- arch/arm/plat-omap/mailbox.c | 182 - 4 files changed, 111 insertions(+), 87 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/14] omap: mailbox: bunch of cleanups
Hi Felipe, From: ext Felipe Contreras felipe.contre...@gmail.com Subject: [PATCH v3 00/14] omap: mailbox: bunch of cleanups Date: Sat, 22 May 2010 19:14:11 +0200 Hi, These are hopefully non-functional changes. Just shuffling code around, and removing unecessary stuff. In v2 I tried to split platform_device and also make mailbox_mach built-in. Not any more. Comments from Felipe Balbi, Tony Lindgren, Hiroshi DOYU, and Russell King. Have you had a chance to update them? Felipe Contreras (14): omap: mailbox: trivial whitespace cleanups omap: mailbox: trivial cleanups omap: mailbox: reorganize structures omap: mailbox: 2420 should be detected at run-time omap: mailbox: use correct config for omap1 omap: mailbox: update omap1 probing omap: mailbox: don't export unecessary symbols omap: mailbox: remove unecessary fields omap: mailbox: add IRQ names omap: mailbox: reorganize registering omap: mailbox: only compile for configured archs omap: mailbox: standarize on 'omap-mailbox' omap: mailbox: simplify omap_mbox_register() omap: mailbox: reorganize headers arch/arm/mach-omap1/devices.c | 11 +- arch/arm/mach-omap1/mailbox.c | 52 - arch/arm/mach-omap2/devices.c |6 +- arch/arm/mach-omap2/mailbox.c | 177 + arch/arm/plat-omap/include/plat/mailbox.h | 16 +-- arch/arm/plat-omap/mailbox.c | 136 +- 6 files changed, 168 insertions(+), 230 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan
From: ext Catalin Marinas catalin.mari...@arm.com
Subject: Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan
Date: Wed, 2 Jun 2010 16:12:29 +0200
On Wed, 2010-06-02 at 12:34 +0100, Hiroshi DOYU wrote:
From: ext Catalin Marinas catalin.mari...@arm.com
Can we not add a new prio tree (or just use the existing one) for
pointer aliases? The advantage is that you only have a single function
to call, something like kmemleak_add_alias() and you do it at the point
the value was converted.
Actually I considered the above aliasing a little bit but I gave up
soon.
I was afraid that this method might consume way more memory since this
just adds another member for struct kmemleak_object, but adding a
single member for all objects. The number of kmemleak_object is
usually numerous.
We could use a different tree with a struct kmemleak_alias structure
which is much smaller. Something like below:
struct kmemleak_alias {
struct list_head alias_list;
struct prio_tree_node tree_node;
struct kmemleak_object *object;
}
The above seems to be better than I thought. I'll give this a try.
And an alias_list member would be added to kmemleak_object as well.
Would the alias tree need to allow overlapping? Like different IOMMU
mappings with the same address (but pointing to different physical
memory).
Not for omap iommu.
omap iommu can have multiple instances, multiple devices can have each
own address spaces respectively. This doesn't affect this kmemleak
false positive.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/14] omap: mailbox: bunch of cleanups
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [PATCH v3 00/14] omap: mailbox: bunch of cleanups Date: Thu, 3 Jun 2010 12:23:43 +0200 On Thu, Jun 3, 2010 at 9:40 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: Have you had a chance to update them? Sorry, no. I've been busy with user-space stuff. Probably this weekend. There's no merge-window rush or anything, right? No rush. Sorry for just ping. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap iommu: fixes for 2.6.35-rc1
Hi Tony, Patches only for fixes for omap iommu module during -rc cycle. The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc1-iommu-fixes Hiroshi DOYU (1): omap iommu: Make omap-iommu.o built-in Kanigeri, Hari (1): omap iommu: update ducati mmu irq define name Satish (1): omap iommu: Fix Memory leak arch/arm/mach-omap2/Makefile |5 - arch/arm/mach-omap2/omap-iommu.c |2 +- arch/arm/plat-omap/iovmm.c |4 +++- 3 files changed, 8 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1
Hi Felipe, From: Balbi Felipe (Nokia-D/Helsinki) felipe.ba...@nokia.com Subject: Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Wed, 2 Jun 2010 12:01:00 +0200 On Wed, Jun 02, 2010 at 09:50:54AM +0200, Doyu Hiroshi (Nokia-D/Helsinki) wrote: omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr should these two be here or should they go to 2.6.36 merge window ? at least from the description it doesn't look like they are fixing any bugs. omap iommu: add functionality to get TLB miss interrupt for this add functionality to get TLB miss interrupt the other two look suspicious looking only at the description. This subject might be misleading. These patches are for for-next, which means for v2.6.36. v2.6.35-rc1 on subject implies the base TAG for these patches. For fixes: http://marc.info/?l=linux-omapm=127546506730794w=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 v2 0/3] kmemleak: Fix false positive with special scan
From: ext Catalin Marinas catalin.mari...@arm.com Subject: Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan Date: Wed, 2 Jun 2010 12:01:24 +0200 Hi, Sorry for the delay, I eventually got the time to look at your patches. Thank you for your review. On Tue, 2010-06-01 at 11:25 +0100, Hiroshi DOYU wrote: There is a false positive case that a pointer is calculated by other methods than the usual container_of macro. kmemleak_ignore can cover such a false positive, but it would loose the advantage of memory leak detection. This patch allows kmemleak to work with such false positives by introducing a new special memory block with a specified calculation formula. A client module can register its area with a conversion function, with which function kmemleak scan could calculate a correct pointer. While something needs to be done to cover these situations, I'm not so convinced about the method as it complicates the code requiring such conversion by having to insert two kmemleak hooks and a callback function. Can we not add a new prio tree (or just use the existing one) for pointer aliases? The advantage is that you only have a single function to call, something like kmemleak_add_alias() and you do it at the point the value was converted. Actually I considered the above aliasing a little bit but I gave up soon. I was afraid that this method might consume way more memory since this just adds another member for struct kmemleak_object, but adding a single member for all objects. The number of kmemleak_object is usually numerous. Do you think that this increase of memory consumption is acceptable? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan
From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan Date: Wed, 02 Jun 2010 14:34:58 +0300 (EEST) From: ext Catalin Marinas catalin.mari...@arm.com Subject: Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan Date: Wed, 2 Jun 2010 12:01:24 +0200 Hi, Sorry for the delay, I eventually got the time to look at your patches. Thank you for your review. On Tue, 2010-06-01 at 11:25 +0100, Hiroshi DOYU wrote: There is a false positive case that a pointer is calculated by other methods than the usual container_of macro. kmemleak_ignore can cover such a false positive, but it would loose the advantage of memory leak detection. This patch allows kmemleak to work with such false positives by introducing a new special memory block with a specified calculation formula. A client module can register its area with a conversion function, with which function kmemleak scan could calculate a correct pointer. While something needs to be done to cover these situations, I'm not so convinced about the method as it complicates the code requiring such conversion by having to insert two kmemleak hooks and a callback function. Can we not add a new prio tree (or just use the existing one) for pointer aliases? The advantage is that you only have a single function to call, something like kmemleak_add_alias() and you do it at the point the value was converted. Ok, I understand now. Please ignore my previous. I'll try the above. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] kmemleak: Fix false positive with special scan
Hi, There is a false positive case that a pointer is calculated by other methods than the usual container_of macro. kmemleak_ignore can cover such a false positive, but it would loose the advantage of memory leak detection. This patch allows kmemleak to work with such false positives by introducing a new special memory block with a specified calculation formula. A client module can register its area with a conversion function, with which function kmemleak scan could calculate a correct pointer. For this version 2, to avoid client kernel module being unloaded before unregistering special conversion, module reference count is used. This was pointed by Phil Carmody. A typical use case could be the IOMMU pagetable allocation which stores pointers to the second level of page tables with some conversion, for example, a physical address with attribution bits. Right now I don't have other use cases but I hope that there could be some that this special scan works with. Test: # echo scan kmemleak # modprobe kmemleak-special-test [ 1328.260162] Stored 1...@dfc5ac00 - 9fc5ac01 [ 1328.264984] Stored 1...@dfc5b800 - 9fc5b801 [ 1328.269500] Stored 1...@dfc5b400 - 9fc5b401 [ 1328.273895] Stored 1...@dfc5b000 - 9fc5b001 [ 1328.278381] Stored 1...@deb9bc00 - 9eb9bc01 [ 1328.282714] Stored 1...@deea6c00 - 9eea6c01 [ 1328.287139] Stored 1...@deea7c00 - 9eea7c01 [ 1328.291473] Stored 1...@deea7800 - 9eea7801 # echo scan kmemleak [ 1344.062591] kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak) # rmmod kmemleak-special-test # echo scan kmemleak # modprobe kmemleak-special-test timeout=60 [ 71.758850] Stored 1...@dfc5b000 - 9fc5b001 [ 71.763702] Stored 1...@dfc5b400 - 9fc5b401 [ 71.768066] Stored 1...@dfc5b800 - 9fc5b801 [ 71.772583] Stored 1...@dfc5bc00 - 9fc5bc01 [ 71.776977] Stored 1...@deea6000 - 9eea6001 [ 71.781341] Stored 1...@deea6400 - 9eea6401 [ 71.785736] Stored 1...@deea6800 - 9eea6801 [ 71.790069] Stored 1...@deea6c00 - 9eea6c01 [ 71.794433] kmemleak_special_init: Registered special scan: bf000360 # echo scan kmemleak [ 79.588836] custom_conversion: Converted 9fc5b001 - dfc5b000 [ 79.594696] custom_conversion: Converted 9fc5b401 - dfc5b400 [ 79.600494] custom_conversion: Converted 9fc5b801 - dfc5b800 [ 79.606292] custom_conversion: Converted 9fc5bc01 - dfc5bc00 [ 79.612060] custom_conversion: Converted 9eea6001 - deea6000 [ 79.617889] custom_conversion: Converted 9eea6401 - deea6400 [ 79.623687] custom_conversion: Converted 9eea6801 - deea6800 [ 79.629486] custom_conversion: Converted 9eea6c01 - deea6c00 # rmmod kmemleak-special-test rmmod: cannot unload 'kmemleak_special_test': Resource temporarily unavailable # lsmod kmemleak-special-test Module Size Used byNot tainted kmemleak_special_test 1467 1 # [ 131.800354] no_special_func: Unregistered special scan bf000360 # lsmod kmemleak-special-test Module Size Used byNot tainted kmemleak_special_test 1467 0 # rmmod kmemleak-special-test Hiroshi DOYU (3): kmemleak: Fix false positives with special scan kmemleak: Add special scan test case omap iommu: kmemleak: Fix false positive with special scan arch/arm/plat-omap/iommu.c | 19 +++ include/linux/kmemleak.h |5 ++ mm/Makefile|2 +- mm/kmemleak-special-test.c | 94 mm/kmemleak.c | 114 ++- 5 files changed, 230 insertions(+), 4 deletions(-) create mode 100644 mm/kmemleak-special-test.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] kmemleak: Add special scan test case
From: Hiroshi DOYU hiroshi.d...@nokia.com
For this test case, a pointer is converted to a physical address with
attribution bits. This test can be executed either with special scan
or without special scan. For special scan case, specifying the testing
period second with the kernel module parameter timeout. Afther that
timeout, special scan is unregistered automatically. Without this
timeout, you will get false positives with kmemleak scan.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
mm/Makefile|2 +-
mm/kmemleak-special-test.c | 94
2 files changed, 95 insertions(+), 1 deletions(-)
create mode 100644 mm/kmemleak-special-test.c
diff --git a/mm/Makefile b/mm/Makefile
index 8982504..5d08581 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -44,4 +44,4 @@ obj-$(CONFIG_CGROUP_MEM_RES_CTLR) += memcontrol.o
page_cgroup.o
obj-$(CONFIG_MEMORY_FAILURE) += memory-failure.o
obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o
obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
-obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
+obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o kmemleak-special-test.o
diff --git a/mm/kmemleak-special-test.c b/mm/kmemleak-special-test.c
new file mode 100644
index 000..ed6788c
--- /dev/null
+++ b/mm/kmemleak-special-test.c
@@ -0,0 +1,94 @@
+/*
+ * kmemleak: special scan test
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU hiroshi.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/kmemleak.h
+
+static int timeout;
+module_param(timeout, int, 0644);
+MODULE_PARM_DESC(timeout, special scan mode timeout);
+
+#define MAXELEM 8
+static u32 elem[MAXELEM];
+
+static void no_special_func(struct work_struct *unused)
+{
+ kmemleak_no_special(elem);
+ pr_info(%s: Unregistered special scan %p\n, __func__, elem);
+}
+static DECLARE_DELAYED_WORK(no_special_work, no_special_func);
+
+static unsigned long custom_conversion(void *unused, unsigned long orig)
+{
+ u32 addr = orig;
+
+ addr = ~1;
+ addr = (u32)phys_to_virt(addr);
+
+ pr_info(%s: Converted %08lx - %08x\n, __func__, orig, addr);
+
+ return addr;
+}
+
+static int __init kmemleak_special_init(void)
+{
+ int i, err;
+
+ for (i = 0; i ARRAY_SIZE(elem); i++) {
+ void *virt;
+
+ virt = kmalloc(SZ_1K, GFP_KERNEL);
+ if (!virt)
+ continue;
+
+ memset(virt, 0xa5, SZ_1K); /* fill out some markers */
+ *(char *)virt = i;
+
+ elem[i] = virt_to_phys(virt) | 1;
+ pr_info(Stored %...@%p - %08x\n, SZ_1K, virt, elem[i]);
+ }
+
+ if (!timeout)
+ return 0;
+
+ err = kmemleak_special_scan(elem, sizeof(elem),
+ custom_conversion, NULL, THIS_MODULE);
+ if (err) {
+ pr_warning(%s: Couldn't register special scan\n,
+ __func__);
+ return -ENOMEM;
+ }
+ pr_info(%s: Registered special scan: %p\n, __func__, elem);
+
+ schedule_delayed_work(no_special_work,
+ msecs_to_jiffies(timeout * 1000));
+ return 0;
+}
+module_init(kmemleak_special_init);
+
+static void __exit kmemleak_special_exit(void)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(elem); i++) {
+ u32 val;
+
+ val = elem[i];
+ val = ~1;
+ kfree(phys_to_virt(val));
+ }
+}
+module_exit(kmemleak_special_exit);
+
+MODULE_DESCRIPTION(kmemleak: special scan test);
+MODULE_AUTHOR(Hiroshi DOYU hiroshi.d...@nokia.com);
+MODULE_LICENSE(GPL v2);
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] omap iommu: kmemleak: Fix false positive with special scan
From: Hiroshi DOYU hiroshi.d...@nokia.com
The fist level iommu page table address is registered with the address
conversion function for kmemleak special scan.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iommu.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index a202a2c..5a19e86 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -894,6 +894,19 @@ void iommu_put(struct iommu *obj)
}
EXPORT_SYMBOL_GPL(iommu_put);
+static unsigned long kmemleak_special_conv(void *data, unsigned long orig)
+{
+ u32 *iopgd;
+ struct iommu *obj = (struct iommu *)data;
+
+ iopgd = iopgd_offset(obj, orig);
+
+ if (!iopgd_is_table(*iopgd))
+ return 0;
+
+ return (u32)iopgd_page_vaddr(iopgd);
+}
+
/*
* OMAP Device MMU(IOMMU) detection
*/
@@ -967,6 +980,11 @@ static int __devinit omap_iommu_probe(struct
platform_device *pdev)
BUG_ON(!IS_ALIGNED((unsigned long)obj-iopgd, IOPGD_TABLE_SIZE));
+ err = kmemleak_special_scan(p, IOPGD_TABLE_SIZE, kmemleak_special_conv,
+ obj, THIS_MODULE);
+ if (err)
+ dev_warn(pdev-dev, kmemleak: failed to add special scan\n);
+
dev_info(pdev-dev, %s registered\n, obj-name);
return 0;
@@ -991,6 +1009,7 @@ static int __devexit omap_iommu_remove(struct
platform_device *pdev)
platform_set_drvdata(pdev, NULL);
iopgtable_clear_entry_all(obj);
+ kmemleak_no_special(obj-iopgd);
free_pages((unsigned long)obj-iopgd, get_order(IOPGD_TABLE_SIZE));
irq = platform_get_irq(pdev, 0);
--
1.7.1.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
