* [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: David Cohen @ 2011-02-15 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215142923.GC11199@n2100.arm.linux.org.uk>
On Tue, Feb 15, 2011 at 4:29 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 15, 2011 at 04:38:32PM +0300, Sergei Shtylyov wrote:
>>> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
>>> index 14ee686..4244a07 100644
>>> --- a/arch/arm/mach-omap2/iommu2.c
>>> +++ b/arch/arm/mach-omap2/iommu2.c
>>> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
>>> ? ? ?da = iommu_read_reg(obj, MMU_FAULT_AD);
>>> ? ? ?*ra = da;
>>>
>>> - ? ?dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
>>> + ? ?dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
>>
>> ? ?Note that dev_dbg() will only print something if either DEBUG or
>> CONFIG_DYNAMIC_DEBUG are defined...
>>
>>>
>>> ? ? ?for (i = 0; i< ?ARRAY_SIZE(err_msg); i++) {
>>> ? ? ? ? ? ? ?if (stat & (1<< ?i))
>>> - ? ? ? ? ? ? ? ? ? ?printk("%s ", err_msg[i]);
>>> + ? ? ? ? ? ? ? ? ? ?printk(KERN_DEBUG "%s ", err_msg[i]);
>>
>> ? ?... unlike printk(KERN_DEBUG...). You probably want to use pr_debug() instead.
>
> No - this isn't starting a new line. ?pr_cont() here.
But pr_cont() would be wrong in case of DEBUG isn't set, isn't it?
>
>>> ? ? ?}
>>> - ? ?printk("\n");
>>> + ? ?printk(KERN_DEBUG "\n");
>>
>> ? ?Here too... Although wait, it should be KERN_CONT instead! Debug
>> levels are only attributed to the whole lines.
>
> And pr_cont() here too. ?If you care about using KERN_CONT which is
> just a static marker to allow automated printk level checking easier.
The same situation here.
But this patch was dropped in the next version.
Br,
David
>
^ permalink raw reply
* [PATCH v2 0/1] OMAP: IOMMU fault callback support
From: David Cohen @ 2011-02-15 14:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
v2:
Previous patch 1/2 on v1 was dropped.
---
v1:
This patch set adds fault callback support to allow IOMMU users to debug or
react when a fault happens.
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.
Br,
David
---
David Cohen (1):
OMAP: IOMMU: add support to callback during fault handling
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(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH v2 1/1] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen @ 2011-02-15 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297780591-15613-1-git-send-email-dacohen@gmail.com>
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 <dacohen@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 int refcount;
struct mutex iommu_lock; /* global for this whole object */
@@ -48,6 +49,7 @@ struct iommu {
struct mutex mmap_lock; /* protect mmap */
int (*isr)(struct iommu *obj);
+ void (*fault_cb)(struct iommu *obj, u32 da, u32 iommu_errs, void *priv);
void *ctx; /* iommu context: registres saved area */
u32 da_start;
@@ -83,7 +85,7 @@ struct iommu_functions {
int (*enable)(struct iommu *obj);
void (*disable)(struct iommu *obj);
void (*set_twl)(struct iommu *obj, bool on);
- u32 (*fault_isr)(struct iommu *obj, u32 *ra);
+ u32 (*fault_isr)(struct iommu *obj, u32 *ra, u32 *iommu_errs);
void (*tlb_read_cr)(struct iommu *obj, struct cr_regs *cr);
void (*tlb_load_cr)(struct iommu *obj, struct cr_regs *cr);
@@ -109,6 +111,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 +170,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_fault_callback(const char *name,
+ void (*fault_cb)(struct iommu *obj, u32 da,
+ u32 errs, void *priv),
+ void *fault_cb_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 b1107c0..7f780ee 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -163,9 +163,9 @@ static u32 get_iopte_attr(struct iotlb_entry *e)
return arch_iommu->get_pte_attr(e);
}
-static u32 iommu_report_fault(struct iommu *obj, u32 *da)
+static u32 iommu_report_fault(struct iommu *obj, u32 *da, u32 *iommu_errs)
{
- return arch_iommu->fault_isr(obj, da);
+ return arch_iommu->fault_isr(obj, da, iommu_errs);
}
static void iotlb_lock_get(struct iommu *obj, struct iotlb_lock *l)
@@ -780,7 +780,7 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
*/
static irqreturn_t iommu_fault_handler(int irq, void *data)
{
- u32 stat, da;
+ u32 stat, da, errs;
u32 *iopgd, *iopte;
int err = -EIO;
struct iommu *obj = data;
@@ -796,13 +796,19 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
return IRQ_HANDLED;
clk_enable(obj->clk);
- stat = iommu_report_fault(obj, &da);
+ stat = iommu_report_fault(obj, &da, &errs);
clk_disable(obj->clk);
if (!stat)
return IRQ_HANDLED;
iommu_disable(obj);
+ if (obj->fault_cb) {
+ obj->fault_cb(obj, da, errs, obj->fault_cb_priv);
+ /* No need to print error message as callback is called */
+ return IRQ_NONE;
+ }
+
iopgd = iopgd_offset(obj, da);
if (!iopgd_is_table(*iopgd)) {
@@ -917,6 +923,33 @@ void iommu_put(struct iommu *obj)
}
EXPORT_SYMBOL_GPL(iommu_put);
+int iommu_set_fault_callback(const char *name,
+ void (*fault_cb)(struct iommu *obj, u32 da,
+ u32 iommu_errs, void *priv),
+ void *fault_cb_priv)
+{
+ struct device *dev;
+ struct iommu *obj;
+
+ dev = driver_find_device(&omap_iommu_driver.driver, NULL, (void *)name,
+ device_match_by_alias);
+ if (!dev)
+ return -ENODEV;
+
+ obj = to_iommu(dev);
+ mutex_lock(&obj->iommu_lock);
+ if (obj->refcount != 0) {
+ mutex_unlock(&obj->iommu_lock);
+ return -EBUSY;
+ }
+ obj->fault_cb = fault_cb;
+ obj->fault_cb_priv = fault_cb_priv;
+ mutex_unlock(&obj->iommu_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_set_fault_callback);
+
/*
* OMAP Device MMU(IOMMU) detection
*/
--
1.7.2.3
^ permalink raw reply related
* [RFC PATCH 2/2] ARMv7: Invalidate the TLB before freeing page tables
From: Catalin Marinas @ 2011-02-15 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215121437.GG4152@n2100.arm.linux.org.uk>
On Tue, 2011-02-15 at 12:14 +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 15, 2011 at 11:32:42AM +0000, Russell King - ARM Linux wrote:
> > The point of TLB shootdown is that we unmap the entries from the page
> > tables, then issue the TLB flushes, and then free the pages and page
> > tables after that. All that Peter's patch tries to do is to get ARM to
> > use the generic stuff.
>
> As Peter's patch preserves the current behaviour, that's not sufficient.
> So, let's do this our own way and delay pages and page table frees on
> ARMv6 and v7. Untested.
ARMv7 should be enough, I'm not aware of any pre-v7 with this behaviour.
> Note that the generic code doesn't allow us to delay frees on UP as it
> assumes that if there's no TLB entry, the CPU won't speculatively
> prefetch. This seems to be where ARM differs from the rest of the
> planet. Please confirm that this is indeed the case.
The CPU can speculatively prefetch instructions and access data as long
as there is a valid mapping in the page tables. There is no need to have
a TLB entry for the speculative access, this can be created
speculatively from existing page table entries. That's not the issue
(ARM has been doing this for ages, probably other architectures too).
With newer cores, apart from the TLB (which stores a virtual to physical
translation), the CPU is allowed to cache entries in the higher page
table levels. This is important especially for LPAE where the 1st level
covers 1GB and can be easily cached to avoid 3 levels of page table walk
(or 2 levels for the classic page tables).
So even when we clear a page table entry in RAM (pmd_clear), the
processor still has it in its page table cache (pretty much part of the
TLB, different from the D-cache) and that's why we need the TLB
invalidation before freeing the lower page table.
>
> diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
> index f41a6f5..1ca3e16 100644
> --- a/arch/arm/include/asm/tlb.h
> +++ b/arch/arm/include/asm/tlb.h
> @@ -30,6 +30,16 @@
> #include <asm/pgalloc.h>
>
> /*
> + * As v6 and v7 speculatively prefetch, which can drag new entries into the
> + * TLB, we need to delay freeing pages and page tables.
> + */
> +#if defined(CONFIG_CPU_32v6) || defined(CONFIG_CPU_32v7)
> +#define tlb_fast_mode(tlb) 0
> +#else
> +#define tlb_fast_mode(tlb) 1
> +#endif
We could make this v7 only. If you want it to be more dynamic, we can
check the MMFR0[3:0] bits (Cortex-A15 sets them to 4). But
architecturally we should assume that intermediate page table levels may
be cached.
> -#define tlb_remove_page(tlb,page) free_page_and_swap_cache(page)
> -#define pte_free_tlb(tlb, ptep, addr) pte_free((tlb)->mm, ptep)
> +#define pte_free_tlb(tlb, ptep, addr) __pte_free_tlb(tlb, ptep, addr)
> #define pmd_free_tlb(tlb, pmdp, addr) pmd_free((tlb)->mm, pmdp)
With LPAE, we'll need a __pmd_free_tlb() but I can add this as part of
my patches.
Apart from the need for ARMv6, the patch looks fine (I'll give it a try
as well).
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Russell King - ARM Linux @ 2011-02-15 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin++DGAGT9-nahy1Qm7ASbGm=JjNuPZWZ6XUbcX@mail.gmail.com>
On Tue, Feb 15, 2011 at 04:36:26PM +0200, David Cohen wrote:
> But pr_cont() would be wrong in case of DEBUG isn't set, isn't it?
Yes. One other solution you could do is:
char buf[80], *p = buf;
buf[0] = '\0';
for (i = 0; i < ARRAY_SIZE(err_msg); i++)
if (stat & (1 << i))
p += scnprintf(p, sizeof(buf) - (p - buf),
" %s", err_msg[i]);
dev_dbg(obj->dev, "%s: da:%08x%s\n", __func__, da, buf);
which means that you're then printing the entire string in one go -
and there's no chance for another message to come in the middle of it.
Note that I've placed the ' ' at the beginning of the format string so
that we don't end up with useless trailing space in messages. Minor
point but it's easy to do here.
^ permalink raw reply
* [PATCH v2 1/1] OMAP: IOMMU: add support to callback during fault handling
From: Hiroshi DOYU @ 2011-02-15 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297780591-15613-2-git-send-email-dacohen@gmail.com>
Hi David,
Sorry for a bit late reply....
From: David Cohen <dacohen@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 <dacohen@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 int refcount;
> struct mutex iommu_lock; /* global for this whole object */
> @@ -48,6 +49,7 @@ struct iommu {
> struct mutex mmap_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);
^ permalink raw reply
* [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: David Cohen @ 2011-02-15 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215144457.GD11199@n2100.arm.linux.org.uk>
On Tue, Feb 15, 2011 at 4:44 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 15, 2011 at 04:36:26PM +0200, David Cohen wrote:
>> But pr_cont() would be wrong in case of DEBUG isn't set, isn't it?
>
> Yes. ?One other solution you could do is:
>
> ? ? ? ?char buf[80], *p = buf;
>
> ? ? ? ?buf[0] = '\0';
> ? ? ? ?for (i = 0; i < ARRAY_SIZE(err_msg); i++)
> ? ? ? ? ? ? ? ?if (stat & (1 << i))
> ? ? ? ? ? ? ? ? ? ? ? ?p += scnprintf(p, sizeof(buf) - (p - buf),
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?" %s", err_msg[i]);
>
> ? ? ? ?dev_dbg(obj->dev, "%s: da:%08x%s\n", __func__, da, buf);
>
> which means that you're then printing the entire string in one go -
> and there's no chance for another message to come in the middle of it.
>
> Note that I've placed the ' ' at the beginning of the format string so
> that we don't end up with useless trailing space in messages. ?Minor
> point but it's easy to do here.
That could be my choice.
I'm not planing to resend this patch, but how good/bad it sounds to
you to have dev_dbg_cont() for such situation?
Br,
David
^ permalink raw reply
* [PATCH v2 1/1] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen @ 2011-02-15 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215.164822.811675675026794737.Hiroshi.DOYU@nokia.com>
On Tue, Feb 15, 2011 at 4:48 PM, Hiroshi DOYU <Hiroshi.DOYU@nokia.com> wrote:
> Hi David,
Hi Hiroshi,
>
> Sorry for a bit late reply....
You're just in time. :)
>
> From: David Cohen <dacohen@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 <dacohen@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 int ? ?refcount;
>> ? ? ? struct mutex ? ?iommu_lock; ? ? /* global for this whole object */
>> @@ -48,6 +49,7 @@ struct iommu {
>> ? ? ? struct mutex ? ? ? ? ? ?mmap_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.
In this case, it seems we can re-use it.
>
> ? 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.
I agree. We need to add 'void *isr_priv' to iommu struct and the
function to register isr.
I'll send a v3 soon.
Regards,
David
>
>> ? ? ? int (*isr)(struct iommu *obj);
>> + ? ? void (*fault_cb)(struct iommu *obj, u32 da, u32 iommu_errs, void *priv);
>
^ permalink raw reply
* [RFC] ARM: dma-mapping: outer cache is invalidated twice
From: Per Forlin @ 2011-02-15 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215141253.GJ4152@n2100.arm.linux.org.uk>
On 15 February 2011 15:12, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 15, 2011 at 02:54:21PM +0100, Per Forlin wrote:
>> I don't fully understand this yet. I think you are right but I need a
>> little help to get there myself.
>> I agree, the cache (L1 and L2) must be invalidated after the DMA has completed.
>> Before starting the DMA the write buffers must be drained (cache_sync).
>>
>> Why invalidate the cache before starting the DMA?
>
> Think about what happens if you have dirty cache lines in the DMA region.
> These can be evicted when other cache lines are loaded, which will result
> in them overwriting contents of memory. ?If the DMA device has already
> written to that memory, the result is data corruption.
>
> So, the invalidate prior to DMA is to get rid of any dirty cache lines
> which could be written back to memory.
>
True. In my case write back is disable but read back is enable, that's
why I didn't consider it.
Do you think it is feasible to let dma-mapping detect the cache
configurations in runtime in order to prevent "unnecessary" cache
operations? I can see some FIXME comments in the code which indicates
you may have plans to change it.
I can try to think of a proposal if you agree.
Thanks again,
/Per
^ permalink raw reply
* [PATCH] ARM: PXA: Make PXA27x/PXA3xx overlay actually work
From: Eric Miao @ 2011-02-15 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102151551.20080.anarsoul@gmail.com>
On Tue, Feb 15, 2011 at 9:51 PM, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> On Tuesday 15 February 2011 15:36:07 you wrote:
>
>> Then maybe in this way? (I'd rather keep this bit in overlay specific
>> code, and make it valid not only to pxa27x)
>>
>> @@ -925,6 +925,8 @@ static int __devinit pxafb_overlay_init(struct
>> pxafb_info *fbi)
>>
>> ? ? ? ? /* place overlay(s) on top of base */
>> ? ? ? ? fbi->lccr0 |= LCCR0_OUC;
>> + ? ? ? lcd_writel(fbi, LCCR0, fbi->lccr0 & ~LCCR0_ENB);
>> +
>> ? ? ? ? pr_info("PXA Overlay driver loaded successfully!\n");
>> ? ? ? ? return 0;
>
> I tried it, it doesn't work that way (I got garbage on screen). Maybe it's not
> right time to modify LCCR0 reg?
>
I guess that's because OUC bit needs to be set when the panel is
not enabled. But re-enabling here is a bit hackish as well.
I don't mind move the code a bit, but can we separate this change
into another patch from the rest?
Thanks
- eric
^ permalink raw reply
* [PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: Jarkko Nikula @ 2011-02-15 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297756738-2696-1-git-send-email-shweta.gulati@ti.com>
On Tue, 15 Feb 2011 13:28:58 +0530
Shweta Gulati <shweta.gulati@ti.com> wrote:
> This patch is based on LO PM Branch and Smartreflex has been
> tested on OMAP3430 SDP, OMAP3630 SDP and boot tested on
> OMAP2430 SDP.
>
I saw this was working on N900 (kind of special instrumentation
setup) after enabling /sys/kernel/debug/voltage/[vdd_core |
vdd_mpu]/smartreflex/autocomp. Few comments below.
> @@ -269,6 +276,18 @@ int __init omap3_twl_init(void)
> omap3_core_volt_info.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
> }
...
> + if (!twl_sr_enable_autoinit)
> + omap3_twl_set_sr_bit(true);
...
> +int __init omap3_twl_set_sr_bit(bool enable)
> +{
> + u8 temp;
> + int ret;
> + if (twl_sr_enable_autoinit)
> + pr_warning("%s: unexpected multiple calls\n", __func__);
> +
> + ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &temp,
> + TWL4030_DCDC_GLOBAL_CFG);
> + if (ret)
> + goto err;
> +
> + if (enable)
> + temp |= SMARTREFLEX_ENABLE;
> + else
> + temp &= ~SMARTREFLEX_ENABLE;
> +
> + ret = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
> + TWL4030_DCDC_GLOBAL_CFG);
Would it make more sense to set only the flag here and do the register
writes when omap3_twl_init is executing? Then it's not so strict when
the board code calls this function.
> + if (!ret) {
> + twl_sr_enable_autoinit = true;
> + return 0;
Should this be twl_sr_enable_autoinit = enable (if going to do
register write here)?
--
Jarkko
^ permalink raw reply
* [PATCH] ARM: PXA: Make PXA27x/PXA3xx overlay actually work
From: Vasily Khoruzhick @ 2011-02-15 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimapyDg0G0k2GfTdQ6RcUs9oUxXmHGMWoDhaZED@mail.gmail.com>
On Tuesday 15 February 2011 17:12:10 Eric Miao wrote:
> On Tue, Feb 15, 2011 at 9:51 PM, Vasily Khoruzhick <anarsoul@gmail.com>
wrote:
> > On Tuesday 15 February 2011 15:36:07 you wrote:
> >> Then maybe in this way? (I'd rather keep this bit in overlay specific
> >> code, and make it valid not only to pxa27x)
> >>
> >> @@ -925,6 +925,8 @@ static int __devinit pxafb_overlay_init(struct
> >> pxafb_info *fbi)
> >>
> >> /* place overlay(s) on top of base */
> >> fbi->lccr0 |= LCCR0_OUC;
> >> + lcd_writel(fbi, LCCR0, fbi->lccr0 & ~LCCR0_ENB);
> >> +
> >> pr_info("PXA Overlay driver loaded successfully!\n");
> >> return 0;
> >
> > I tried it, it doesn't work that way (I got garbage on screen). Maybe
> > it's not right time to modify LCCR0 reg?
>
> I guess that's because OUC bit needs to be set when the panel is
> not enabled. But re-enabling here is a bit hackish as well.
>
> I don't mind move the code a bit, but can we separate this change
> into another patch from the rest?
Ok, will send patches tonight
> Thanks
> - eric
^ permalink raw reply
* [PATCH v4 16/19] ARM: LPAE: Use generic dma_addr_t type definition
From: Catalin Marinas @ 2011-02-15 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215142730.GM4152@n2100.arm.linux.org.uk>
On Tue, 2011-02-15 at 14:27 +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 14, 2011 at 01:01:30PM +0000, Catalin Marinas wrote:
> > Maybe we could make the dma_addr_t size configurable (and disabled by
> > default) since I expect there'll be platforms capable of >32-bit DMA.
>
> It would be far better to fix the dma_addr_t abuses.
That's not a simple task, I have no idea how many drivers get used on
ARM systems. We can defer this until people start using Cortex-A15 in
real hardware and only fix the drivers they need.
BTW, can sparse help here (I haven't used it much)?
--
Catalin
^ permalink raw reply
* [PATCH v4 15/19] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses
From: Will Deacon @ 2011-02-15 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215142339.GL4152@n2100.arm.linux.org.uk>
Hi Russell,
On Tue, 2011-02-15 at 14:23 +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 15, 2011 at 01:37:07PM +0000, Will Deacon wrote:
> > I should've spotted this either way. I've superseded the old patch with
> > 6674/1.
>
> One additional thing that I think has been lost. I said in the original
> reply to Catalin:
> | asm/memory.h will conflict non-trivially with p2v patch set, but I think
> | we can merge the changes to everything but __virt_to_phys/__phys_to_virt.
>
> So 6670/1 which I'm intending to apply to the p2v branch can't be merged
> as-is. The ideal solution would be a version of 6670/1 to apply on top
> of the existing p2v branch.
>
The conflict with the p2v branch is fairly hefty, but something like
this should do (if you're happy I'll submit it to replace 6670/1):
Note that because the v2p macros only work for lowmem, I've not bothered
to add casts for the __v2p macros (rather, I've just changed the types
of the static inline functions). This simplifies the code and means we
can stay clear of the runtime fixup stuff.
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 015fd5e..791cb3e 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -15,6 +15,7 @@
#include <linux/compiler.h>
#include <linux/const.h>
+#include <linux/types.h>
#include <mach/memory.h>
#include <asm/sizes.h>
@@ -135,8 +136,8 @@
/*
* Convert a physical address to a Page Frame Number and back
*/
-#define __phys_to_pfn(paddr) ((paddr) >> PAGE_SHIFT)
-#define __pfn_to_phys(pfn) ((pfn) << PAGE_SHIFT)
+#define __phys_to_pfn(paddr) ((unsigned long)((paddr) >> PAGE_SHIFT))
+#define __pfn_to_phys(pfn) ((phys_addr_t)(pfn) << PAGE_SHIFT)
/*
* Convert a page to/from a physical address
@@ -234,12 +235,12 @@ static inline unsigned long __phys_to_virt(unsigned long x)
* translation for translating DMA addresses. Use the driver
* DMA support - see dma-mapping.h.
*/
-static inline unsigned long virt_to_phys(void *x)
+static inline phys_addr_t virt_to_phys(void *x)
{
return __virt_to_phys((unsigned long)(x));
}
-static inline void *phys_to_virt(unsigned long x)
+static inline void *phys_to_virt(phys_addr_t x)
{
return (void *)(__phys_to_virt((unsigned long)(x)));
}
Cheers,
Will
^ permalink raw reply related
* [PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: Jarkko Nikula @ 2011-02-15 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215171652.601c9c68.jhnikula@gmail.com>
On Tue, 15 Feb 2011 17:16:52 +0200
Jarkko Nikula <jhnikula@gmail.com> wrote:
> Would it make more sense to set only the flag here and do the register
> writes when omap3_twl_init is executing? Then it's not so strict when
> the board code calls this function.
>
Probably discussed earlier but would it make more sense to have flag in
struct twl4030_platform_data and to do registers writes in twl-core?
Looks suspicious to have i2c_writes under arch/arm/.
--
Jarkko
^ permalink raw reply
* [PATCH v2] ARM: S5PV210: Add GONI board setup for CIF camera support
From: Sylwester Nawrocki @ 2011-02-15 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00a801cbccfa$df478e10$9dd6aa30$%kim@samsung.com>
Hi Kukjin,
On 02/15/2011 11:26 AM, Kukjin Kim wrote:
> Sylwester Nawrocki wrote:
>>
...
>
> As a note, I received request about common phy control from Marek. So I will
> re-think with your mipi phy patches, then let you know about that soon.
>
OK, thanks. It looks like treating PHYs as clocks would cause least trouble.
Some of PHYs are really not much different than clocks, they generate a carrier
of some frequency, like for example HDMI PHY. Some even have their own divider.
We thought about creating an API for PHYs, similar to clock API. There is
quite many PHYs in S5P SoCs - SATA, USB, MIPI, HDMI devices have them.
Such a PHY API would be mostly doubling the clock API functionality though.
We also cannot easily create common helpers in plat-s5p for mipi because
of the different headers issue.
So we have 3 options if it comes to mipi:
1. create helper functions in relevant mach-s5p* directories
2. register special clocks with own enable/disable functions
3. create separate API to manage all PHY's in the SoC series
MIPI PHY issue is a blocking point for a mipi-csi driver inclusion.
It has been ready for quite some time yet and I would appreciate
if we could take time to finally work out compromise.
Regards,
--
Sylwester Nawrocki
Samsung Poland R&D Center
^ permalink raw reply
* [PATCHv2] omap2/3: dmtimer: Enable autoidle
From: Santosh Shilimkar @ 2011-02-15 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297787428-5717-1-git-send-email-tero.kristo@nokia.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Tero Kristo
> Sent: Tuesday, February 15, 2011 10:00 PM
> To: linux-omap at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: [PATCHv2] omap2/3: dmtimer: Enable autoidle
>
> This saves some power. OMAP4 version should check for GPT module ID,
> as
> autoidle is only supported on a subset of these.
>
> Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
> ---
> arch/arm/plat-omap/dmtimer.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-
> omap/dmtimer.c
> index 1d706cf..ee9f6eb 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -342,6 +342,10 @@ static void omap_dm_timer_reset(struct
> omap_dm_timer *timer)
> l |= 0x02 << 3; /* Set to smart-idle mode */
> l |= 0x2 << 8; /* Set clock activity to perserve f-clock on
> idle */
>
> + /* Enable autoidle on OMAP2 / OMAP3 */
> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + l |= 0x1 << 0;
> +
We should get rid of this CPU checks. How about adding a flag
and populating it on init for the architectures it supports.
> /*
> * Enable wake-up on OMAP2 CPUs.
> */
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Clean up set_pxa_fb_info
From: Eric Miao @ 2011-02-15 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=VL8NT=ieuFRZNuU=H5Oyq5ARvB6Cd-_kuufPn@mail.gmail.com>
>>> -void set_pxa_fb_info(struct pxafb_mach_info *hard_pxa_fb_info);
>>> -void set_pxa_fb_parent(struct device *parent_dev);
>>> +void pxa_set_fb_info(struct pxafb_mach_info *hard_pxa_fb_info);
I think your original intention is:
+void pxa_set_fb_info(struct device *, struct pxafb_mach_info *);
I've amend the changes.
>>> ?unsigned long pxafb_get_hsync_time(struct device *dev);
>>>
>>> ?extern int pxafb_smart_queue(struct fb_info *info, uint16_t *cmds, int);
>>> diff --git a/arch/arm/mach-pxa/littleton.c b/arch/arm/mach-pxa/littleton.c
>>> index ccb7bfa..4b2c45f 100644
>>> --- a/arch/arm/mach-pxa/littleton.c
>>> +++ b/arch/arm/mach-pxa/littleton.c
>>> @@ -185,7 +185,7 @@ static struct pxafb_mach_info littleton_lcd_info = {
>>>
>>> ?static void littleton_init_lcd(void)
>>> ?{
>>> - ? ? set_pxa_fb_info(&littleton_lcd_info);
>>> + ? ? pxa_set_fb_info(NULL, &littleton_lcd_info);
>>> ?}
>>> ?#else
>>> ?static inline void littleton_init_lcd(void) {};
>>> diff --git a/arch/arm/mach-pxa/lpd270.c b/arch/arm/mach-pxa/lpd270.c
>>> index c9a3e77..8aebc58 100644
>>> --- a/arch/arm/mach-pxa/lpd270.c
>>> +++ b/arch/arm/mach-pxa/lpd270.c
>>> @@ -480,7 +480,7 @@ static void __init lpd270_init(void)
>>> ? ? ? pxa_set_ac97_info(NULL);
>>>
>>> ? ? ? if (lpd270_lcd_to_use != NULL)
>>> - ? ? ? ? ? ? set_pxa_fb_info(lpd270_lcd_to_use);
>>> + ? ? ? ? ? ? pxa_set_fb_info(NULL, lpd270_lcd_to_use);
>>>
>>> ? ? ? pxa_set_ohci_info(&lpd270_ohci_platform_data);
>>> ?}
>>> diff --git a/arch/arm/mach-pxa/lubbock.c b/arch/arm/mach-pxa/lubbock.c
>>> index dca20de..12a2a56 100644
>>> --- a/arch/arm/mach-pxa/lubbock.c
>>> +++ b/arch/arm/mach-pxa/lubbock.c
>>> @@ -521,7 +521,7 @@ static void __init lubbock_init(void)
>>>
>>> ? ? ? clk_add_alias("SA1111_CLK", NULL, "GPIO11_CLK", NULL);
>>> ? ? ? pxa_set_udc_info(&udc_info);
>>> - ? ? set_pxa_fb_info(&sharp_lm8v31);
>>> + ? ? pxa_set_fb_info(NULL, &sharp_lm8v31);
>>> ? ? ? pxa_set_mci_info(&lubbock_mci_platform_data);
>>> ? ? ? pxa_set_ficp_info(&lubbock_ficp_platform_data);
>>> ? ? ? pxa_set_ac97_info(NULL);
>>> diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
>>> index 41198f0..ad70264 100644
>>> --- a/arch/arm/mach-pxa/magician.c
>>> +++ b/arch/arm/mach-pxa/magician.c
>>> @@ -757,7 +757,7 @@ static void __init magician_init(void)
>>> ? ? ? ? ? ? ? gpio_direction_output(GPIO104_MAGICIAN_LCD_POWER_1, 0);
>>> ? ? ? ? ? ? ? gpio_direction_output(GPIO105_MAGICIAN_LCD_POWER_2, 0);
>>> ? ? ? ? ? ? ? gpio_direction_output(GPIO106_MAGICIAN_LCD_POWER_3, 0);
>>> - ? ? ? ? ? ? set_pxa_fb_info(lcd_select ? &samsung_info : &toppoly_info);
>>> + ? ? ? ? ? ? pxa_set_fb_info(NULL, lcd_select ? &samsung_info : &toppoly_info);
>>> ? ? ? } else
>>> ? ? ? ? ? ? ? pr_err("LCD detection: CPLD mapping failed\n");
>>> ?}
>>> diff --git a/arch/arm/mach-pxa/mainstone.c b/arch/arm/mach-pxa/mainstone.c
>>> index d4b6f23..a58f522 100644
>>> --- a/arch/arm/mach-pxa/mainstone.c
>>> +++ b/arch/arm/mach-pxa/mainstone.c
>>> @@ -592,7 +592,7 @@ static void __init mainstone_init(void)
>>> ? ? ? else
>>> ? ? ? ? ? ? ? mainstone_pxafb_info.modes = &toshiba_ltm035a776c_mode;
>>>
>>> - ? ? set_pxa_fb_info(&mainstone_pxafb_info);
>>> + ? ? pxa_set_fb_info(NULL, &mainstone_pxafb_info);
>>> ? ? ? mainstone_backlight_register();
>>>
>>> ? ? ? pxa_set_mci_info(&mainstone_mci_platform_data);
>>> diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
>>> index faafea3..18e05b1 100644
>>> --- a/arch/arm/mach-pxa/mioa701.c
>>> +++ b/arch/arm/mach-pxa/mioa701.c
>>> @@ -795,7 +795,7 @@ static void __init mioa701_machine_init(void)
>>> ? ? ? pxa_set_stuart_info(NULL);
>>> ? ? ? mio_gpio_request(ARRAY_AND_SIZE(global_gpios));
>>> ? ? ? bootstrap_init();
>>> - ? ? set_pxa_fb_info(&mioa701_pxafb_info);
>>> + ? ? pxa_set_fb_info(NULL, &mioa701_pxafb_info);
>>> ? ? ? pxa_set_mci_info(&mioa701_mci_info);
>>> ? ? ? pxa_set_keypad_info(&mioa701_keypad_info);
>>> ? ? ? pxa_set_udc_info(&mioa701_udc_info);
>>> diff --git a/arch/arm/mach-pxa/palm27x.c b/arch/arm/mach-pxa/palm27x.c
>>> index 405b92a..4f26d78 100644
>>> --- a/arch/arm/mach-pxa/palm27x.c
>>> +++ b/arch/arm/mach-pxa/palm27x.c
>>> @@ -159,7 +159,7 @@ void __init palm27x_lcd_init(int power, struct pxafb_mode_info *mode)
>>> ? ? ? ? ? ? ? palm27x_lcd_screen.pxafb_lcd_power = palm27x_lcd_ctl;
>>> ? ? ? }
>>>
>>> - ? ? set_pxa_fb_info(&palm27x_lcd_screen);
>>> + ? ? pxa_set_fb_info(NULL, &palm27x_lcd_screen);
>>> ?}
>>> ?#endif
>>>
>>> diff --git a/arch/arm/mach-pxa/palmtc.c b/arch/arm/mach-pxa/palmtc.c
>>> index a09a237..fb06bd0 100644
>>> --- a/arch/arm/mach-pxa/palmtc.c
>>> +++ b/arch/arm/mach-pxa/palmtc.c
>>> @@ -507,7 +507,7 @@ static struct pxafb_mach_info palmtc_lcd_screen = {
>>>
>>> ?static void __init palmtc_lcd_init(void)
>>> ?{
>>> - ? ? set_pxa_fb_info(&palmtc_lcd_screen);
>>> + ? ? pxa_set_fb_info(NULL, &palmtc_lcd_screen);
>>> ?}
>>> ?#else
>>> ?static inline void palmtc_lcd_init(void) {}
>>> diff --git a/arch/arm/mach-pxa/palmte2.c b/arch/arm/mach-pxa/palmte2.c
>>> index 3f25014..7fdf099 100644
>>> --- a/arch/arm/mach-pxa/palmte2.c
>>> +++ b/arch/arm/mach-pxa/palmte2.c
>>> @@ -363,7 +363,7 @@ static void __init palmte2_init(void)
>>> ? ? ? pxa_set_btuart_info(NULL);
>>> ? ? ? pxa_set_stuart_info(NULL);
>>>
>>> - ? ? set_pxa_fb_info(&palmte2_lcd_screen);
>>> + ? ? pxa_set_fb_info(NULL, &palmte2_lcd_screen);
>>> ? ? ? pxa_set_mci_info(&palmte2_mci_platform_data);
>>> ? ? ? palmte2_udc_init();
>>> ? ? ? pxa_set_ac97_info(&palmte2_ac97_pdata);
>>> diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c b/arch/arm/mach-pxa/pcm990-baseboard.c
>>> index 90820fa..c1a6448 100644
>>> --- a/arch/arm/mach-pxa/pcm990-baseboard.c
>>> +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
>>> @@ -515,7 +515,7 @@ void __init pcm990_baseboard_init(void)
>>> ? ? ? pcm990_init_irq();
>>>
>>> ?#ifndef CONFIG_PCM990_DISPLAY_NONE
>>> - ? ? set_pxa_fb_info(&pcm990_fbinfo);
>>> + ? ? pxa_set_fb_info(NULL, &pcm990_fbinfo);
>>> ?#endif
>>> ? ? ? platform_device_register(&pcm990_backlight_device);
>>>
>>> diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c
>>> index 4f0ff1a..be68ec5 100644
>>> --- a/arch/arm/mach-pxa/poodle.c
>>> +++ b/arch/arm/mach-pxa/poodle.c
>>> @@ -445,8 +445,7 @@ static void __init poodle_init(void)
>>> ? ? ? if (ret)
>>> ? ? ? ? ? ? ? pr_warning("poodle: Unable to register LoCoMo device\n");
>>>
>>> - ? ? set_pxa_fb_parent(&poodle_locomo_device.dev);
>>> - ? ? set_pxa_fb_info(&poodle_fb_info);
>>> + ? ? pxa_set_fb_info(&poodle_locomo_device.dev, &poodle_fb_info);
>>> ? ? ? pxa_set_udc_info(&udc_info);
>>> ? ? ? pxa_set_mci_info(&poodle_mci_platform_data);
>>> ? ? ? pxa_set_ficp_info(&poodle_ficp_platform_data);
>>> diff --git a/arch/arm/mach-pxa/raumfeld.c b/arch/arm/mach-pxa/raumfeld.c
>>> index 8361151..d9a5791 100644
>>> --- a/arch/arm/mach-pxa/raumfeld.c
>>> +++ b/arch/arm/mach-pxa/raumfeld.c
>>> @@ -597,7 +597,7 @@ static void __init raumfeld_lcd_init(void)
>>> ?{
>>> ? ? ? int ret;
>>>
>>> - ? ? set_pxa_fb_info(&raumfeld_sharp_lcd_info);
>>> + ? ? pxa_set_fb_info(NULL, &raumfeld_sharp_lcd_info);
>>>
>>> ? ? ? /* Earlier devices had the backlight regulator controlled
>>> ? ? ? ?* via PWM, later versions use another controller for that */
>>> diff --git a/arch/arm/mach-pxa/saar.c b/arch/arm/mach-pxa/saar.c
>>> index c1ca8cb..dd0118f 100644
>>> --- a/arch/arm/mach-pxa/saar.c
>>> +++ b/arch/arm/mach-pxa/saar.c
>>> @@ -473,7 +473,7 @@ static struct pxafb_mach_info saar_lcd_info = {
>>>
>>> ?static void __init saar_init_lcd(void)
>>> ?{
>>> - ? ? set_pxa_fb_info(&saar_lcd_info);
>>> + ? ? pxa_set_fb_info(NULL, &saar_lcd_info);
>>> ?}
>>> ?#else
>>> ?static inline void saar_init_lcd(void) {}
>>> diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
>>> index b49a2c2..e646b6d 100644
>>> --- a/arch/arm/mach-pxa/spitz.c
>>> +++ b/arch/arm/mach-pxa/spitz.c
>>> @@ -725,7 +725,7 @@ static struct pxafb_mach_info spitz_pxafb_info = {
>>>
>>> ?static void __init spitz_lcd_init(void)
>>> ?{
>>> - ? ? set_pxa_fb_info(&spitz_pxafb_info);
>>> + ? ? pxa_set_fb_info(NULL, &spitz_pxafb_info);
>>> ?}
>>> ?#else
>>> ?static inline void spitz_lcd_init(void) {}
>>> diff --git a/arch/arm/mach-pxa/tavorevb.c b/arch/arm/mach-pxa/tavorevb.c
>>> index 9cecf83..53d4a47 100644
>>> --- a/arch/arm/mach-pxa/tavorevb.c
>>> +++ b/arch/arm/mach-pxa/tavorevb.c
>>> @@ -466,7 +466,7 @@ static void __init tavorevb_init_lcd(void)
>>> ?{
>>> ? ? ? platform_device_register(&tavorevb_backlight_devices[0]);
>>> ? ? ? platform_device_register(&tavorevb_backlight_devices[1]);
>>> - ? ? set_pxa_fb_info(&tavorevb_lcd_info);
>>> + ? ? pxa_set_fb_info(NULL, &tavorevb_lcd_info);
>>> ?}
>>> ?#else
>>> ?static inline void tavorevb_init_lcd(void) {}
>>> diff --git a/arch/arm/mach-pxa/trizeps4.c b/arch/arm/mach-pxa/trizeps4.c
>>> index 423261d..fa510fd 100644
>>> --- a/arch/arm/mach-pxa/trizeps4.c
>>> +++ b/arch/arm/mach-pxa/trizeps4.c
>>> @@ -516,9 +516,9 @@ static void __init trizeps4_init(void)
>>> ? ? ? pxa_set_stuart_info(NULL);
>>>
>>> ? ? ? if (0) ?/* dont know how to determine LCD */
>>> - ? ? ? ? ? ? set_pxa_fb_info(&sharp_lcd);
>>> + ? ? ? ? ? ? pxa_set_fb_info(NULL, &sharp_lcd);
>>> ? ? ? else
>>> - ? ? ? ? ? ? set_pxa_fb_info(&toshiba_lcd);
>>> + ? ? ? ? ? ? pxa_set_fb_info(NULL, &toshiba_lcd);
>>>
>>> ? ? ? pxa_set_mci_info(&trizeps4_mci_platform_data);
>>> ?#ifndef STATUS_LEDS_ON_STUART_PINS
>>> diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
>>> index 49eeeab..53b2495 100644
>>> --- a/arch/arm/mach-pxa/viper.c
>>> +++ b/arch/arm/mach-pxa/viper.c
>>> @@ -932,7 +932,7 @@ static void __init viper_init(void)
>>> ? ? ? /* Wake-up serial console */
>>> ? ? ? viper_init_serial_gpio();
>>>
>>> - ? ? set_pxa_fb_info(&fb_info);
>>> + ? ? pxa_set_fb_info(NULL, &fb_info);
>>>
>>> ? ? ? /* v1 hardware cannot use the datacs line */
>>> ? ? ? version = viper_hw_version();
>>> diff --git a/arch/arm/mach-pxa/vpac270.c b/arch/arm/mach-pxa/vpac270.c
>>> index b9b5797..a46f8d1 100644
>>> --- a/arch/arm/mach-pxa/vpac270.c
>>> +++ b/arch/arm/mach-pxa/vpac270.c
>>> @@ -573,7 +573,7 @@ static void __init vpac270_lcd_init(void)
>>> ? ? ? }
>>>
>>> ? ? ? vpac270_lcd_screen.pxafb_lcd_power = vpac270_lcd_power;
>>> - ? ? set_pxa_fb_info(&vpac270_lcd_screen);
>>> + ? ? pxa_set_fb_info(NULL, &vpac270_lcd_screen);
>>> ? ? ? return;
>>>
>>> ?err2:
>>> diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
>>> index a323e07..084c724 100644
>>> --- a/arch/arm/mach-pxa/z2.c
>>> +++ b/arch/arm/mach-pxa/z2.c
>>> @@ -272,7 +272,7 @@ static struct pxafb_mach_info z2_lcd_screen = {
>>>
>>> ?static void __init z2_lcd_init(void)
>>> ?{
>>> - ? ? set_pxa_fb_info(&z2_lcd_screen);
>>> + ? ? pxa_set_fb_info(NULL, &z2_lcd_screen);
>>> ?}
>>> ?#else
>>> ?static inline void z2_lcd_init(void) {}
>>> diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
>>> index f4b053b..3db0ba4 100644
>>> --- a/arch/arm/mach-pxa/zeus.c
>>> +++ b/arch/arm/mach-pxa/zeus.c
>>> @@ -847,7 +847,7 @@ static void __init zeus_init(void)
>>> ? ? ? if (zeus_setup_fb_gpios())
>>> ? ? ? ? ? ? ? pr_err("Failed to setup fb gpios\n");
>>> ? ? ? else
>>> - ? ? ? ? ? ? set_pxa_fb_info(&zeus_fb_info);
>>> + ? ? ? ? ? ? pxa_set_fb_info(NULL, &zeus_fb_info);
>>>
>>> ? ? ? pxa_set_mci_info(&zeus_mci_platform_data);
>>> ? ? ? pxa_set_udc_info(&zeus_udc_info);
>>> diff --git a/arch/arm/mach-pxa/zylonite.c b/arch/arm/mach-pxa/zylonite.c
>>> index a4c784a..5821185 100644
>>> --- a/arch/arm/mach-pxa/zylonite.c
>>> +++ b/arch/arm/mach-pxa/zylonite.c
>>> @@ -208,7 +208,7 @@ static void __init zylonite_init_lcd(void)
>>> ? ? ? platform_device_register(&zylonite_backlight_device);
>>>
>>> ? ? ? if (lcd_id & 0x20) {
>>> - ? ? ? ? ? ? set_pxa_fb_info(&zylonite_sharp_lcd_info);
>>> + ? ? ? ? ? ? pxa_set_fb_info(NULL, &zylonite_sharp_lcd_info);
>>> ? ? ? ? ? ? ? return;
>>> ? ? ? }
>>>
>>> @@ -220,7 +220,7 @@ static void __init zylonite_init_lcd(void)
>>> ? ? ? else
>>> ? ? ? ? ? ? ? zylonite_toshiba_lcd_info.modes = &toshiba_ltm04c380k_mode;
>>>
>>> - ? ? set_pxa_fb_info(&zylonite_toshiba_lcd_info);
>>> + ? ? pxa_set_fb_info(NULL, &zylonite_toshiba_lcd_info);
>>> ?}
>>> ?#else
>>> ?static inline void zylonite_init_lcd(void) {}
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
^ permalink raw reply
* [RFC] ARM: dma-mapping: outer cache is invalidated twice
From: Russell King - ARM Linux @ 2011-02-15 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinpcYoHKKDhqy9mKpqOEGtMpNc1BSukNWH-GVBX@mail.gmail.com>
On Tue, Feb 15, 2011 at 04:11:09PM +0100, Per Forlin wrote:
> True. In my case write back is disable but read back is enable, that's
> why I didn't consider it.
What do you mean "write back is disable" ? You can only prevent
writebacks by using a write-through cache.
Any writeback cache, whether in read-allocate or read-write-allocate
mode will have writebacks.
> Do you think it is feasible to let dma-mapping detect the cache
> configurations in runtime in order to prevent "unnecessary" cache
> operations?
Let's first straighten out your cache understanding above, because I
don't think you understand properly yet.
^ permalink raw reply
* [PATCH v4 15/19] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses
From: Russell King - ARM Linux @ 2011-02-15 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297783609.23889.6.camel@e102144-lin.cambridge.arm.com>
On Tue, Feb 15, 2011 at 03:26:49PM +0000, Will Deacon wrote:
> The conflict with the p2v branch is fairly hefty, but something like
> this should do (if you're happy I'll submit it to replace 6670/1):
I was thinking that was the case - which is why I wanted this split up
so this can be tackled separately.
> Note that because the v2p macros only work for lowmem, I've not bothered
> to add casts for the __v2p macros (rather, I've just changed the types
> of the static inline functions). This simplifies the code and means we
> can stay clear of the runtime fixup stuff.
This patch looks good enough, thanks.
^ permalink raw reply
* [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Russell King - ARM Linux @ 2011-02-15 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin=4z0o6=J9f-1mszvGrpaRMgCMk=Ckh5+9j6EQ@mail.gmail.com>
On Tue, Feb 15, 2011 at 04:50:29PM +0200, David Cohen wrote:
> That could be my choice.
> I'm not planing to resend this patch, but how good/bad it sounds to
> you to have dev_dbg_cont() for such situation?
That doesn't help when the message gets corrupted by another thread,
so I'd much prefer the "format line then print" approach rather than
the blah_CONT stuff.
^ permalink raw reply
* [PATCH 1/3] IPUv3: Add i.MX53 IPU support
From: Fabio Estevam @ 2011-02-15 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297760175-19211-1-git-send-email-jason.chen@freescale.com>
Hi Jason,
On Tue, Feb 15, 2011 at 6:56 AM, <jason.chen@freescale.com> wrote:
> From: Jason Chen <b02280@freescale.com>
>
> Signed-off-by: Jason Chen <b02280@freescale.com>
> ---
> ?arch/arm/mach-mx5/board-mx51_babbage.c ? ? ? ? ?| ? ?2 +-
> ?arch/arm/mach-mx5/devices-imx51.h ? ? ? ? ? ? ? | ? ?3 -
> ?arch/arm/plat-mxc/devices/platform-imx_ipuv3.c ?| ? 97 +++++++++++++++++++++--
> ?arch/arm/plat-mxc/include/mach/devices-common.h | ? ?4 +-
> ?arch/arm/plat-mxc/include/mach/ipu-v3.h ? ? ? ? | ? ?1 +
> ?drivers/mfd/Kconfig ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?6 +-
> ?drivers/mfd/imx-ipu-v3/ipu-common.c ? ? ? ? ? ? | ? 66 +++------------
> ?drivers/mfd/imx-ipu-v3/ipu-prv.h ? ? ? ? ? ? ? ?| ? 32 ++++----
> ?8 files changed, 126 insertions(+), 85 deletions(-)
Which git tree did you use for these patches?
I can not see a git tree that contains both the MX51 IPU and MX53LOCO
board support.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
From: Kevin Hilman @ 2011-02-15 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinz1055v7x0y2W_AYkbj+9h7z_cGtF4xn4=pkQ7@mail.gmail.com>
Dave Martin <dave.martin@linaro.org> writes:
> On Mon, Feb 14, 2011 at 11:15 PM, Kevin Hilman <khilman@ti.com> wrote:
>> Hi Dave,
>>
>> Dave Martin <dave.martin@linaro.org> writes:
>>
>>> On Mon, Feb 14, 2011 at 10:00:23AM -0500, Nicolas Pitre wrote:
>>>> On Mon, 14 Feb 2011, Dave Martin wrote:
>>>>
>>>> > @@ -289,8 +297,20 @@ clean_l2:
>>>> > ? ? * ?- should be faster and will change with kernel
>>>> > ? ? * ?- 'might' have to copy address, load and jump to it
>>>> > ? ? */
>>>> > +#ifdef CONFIG_THUMB2_KERNEL
>>>> > + ?/* kernel is non-interworking : must do this from Thumb */
>>>> > + ?adr ? ? r1, . + 1
>>>> > + ?bx ? ? ?r1
>>>> > + ?.thumb
>>>> > +#endif
>>>> > ? ?ldr ? ? r1, kernel_flush
>>>>
>>>> Didn't you mean this instead:
>>>>
>>>> ? ? ?/* kernel is non-interworking : must do this from Thumb */
>>>> ? ? ?adr ? ? r1, 1f + 1
>>>> ? ? ?bx ? ? ?r1
>>>> ? ? ?.thumb
>>>> 1: ? ldr ? ? r1, kernel_flush
>>>> ? ? ?...
>>>
>>> Note that this is intended as an experimental hack, not a real patch
>>> (apologies if I didn't make that clear...)
>>>
>>> Well, actually I meant "add r1, pc, #1" ... which means I was too
>>> busy trying to be clever... oops!
>>>
>>> That is of course exactly equivalent to your code...
>>>
>>>>
>>>> ?
>>>>
>>>> > ? ?blx ? ? r1
>>>> > +#ifdef CONFIG_THUMB2_KERNEL
>>>> > + ?.align
>>>> > + ?bx ? ? ?pc
>>>> > + ?nop
>>>> > + ?.arm
>>>>
>>>> Also here, the .align has the potential to introduce a zero halfword in
>>>> the instruction stream before the bx. ?What about:
>>>>
>>>> ? ? ?adr ? ? r3, 1f
>>>> ? ? ?bx ? ? ?r3
>>>> ? ? ?.align
>>>> ? ? ?.arm
>>>> 1: ? ...
>>>
>>> .align inserts a 16-bit nop when misaligned in Thumb in a text section,
>>> and a word-aligned bx pc is a specific architecturally allowed way
>>> to do an inline switch to ARM. ?The linker uses this trick for PLT
>>> veneers etc.
>>>
>>> A nicer fix for doing this sort of call from low-level code which
>>> might be ARM is to convert arch/arm/mm/*-v7.S to use "bx lr" to return.
>>>
>>> Generally, we can do this for all arches >= v5, without any
>>> incompatibility. ?However, since the need for it will be rare and it
>>> will generate patch noise for not much real benefit,
>>> I haven't proposed this.
>>>
>>> Updated patch below.
>>
>> I tested the updated patch on top of your "dirty" branch I tested with
>> last week, and now see off-mode working just fine.
>
> Thanks for testing-- that's great news.
>
> I will have a think about whether the patch can be tidied up to revert
> most of the code back to Thumb, though that isn't essential. If I've
> understood what's going on correctly, I think only the restore entry
> points, SMC call sites and the entry to omap3_sram_configure_core_dpll
> could need to be ARM; the rest shouldn't really make any difference...
Yes, that sounds right.
Kevin
^ permalink raw reply
* [PATCHv2] omap2/3: dmtimer: Enable autoidle
From: Kevin Hilman @ 2011-02-15 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6038d98e9a2eb2129200f5e08560cf7e@mail.gmail.com>
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>> -----Original Message-----
>> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
>> owner at vger.kernel.org] On Behalf Of Tero Kristo
>> Sent: Tuesday, February 15, 2011 10:00 PM
>> To: linux-omap at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Subject: [PATCHv2] omap2/3: dmtimer: Enable autoidle
>>
>> This saves some power. OMAP4 version should check for GPT module ID,
>> as
>> autoidle is only supported on a subset of these.
>>
>> Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
>> ---
>> arch/arm/plat-omap/dmtimer.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-
>> omap/dmtimer.c
>> index 1d706cf..ee9f6eb 100644
>> --- a/arch/arm/plat-omap/dmtimer.c
>> +++ b/arch/arm/plat-omap/dmtimer.c
>> @@ -342,6 +342,10 @@ static void omap_dm_timer_reset(struct
>> omap_dm_timer *timer)
>> l |= 0x02 << 3; /* Set to smart-idle mode */
>> l |= 0x2 << 8; /* Set clock activity to perserve f-clock on
>> idle */
>>
>> + /* Enable autoidle on OMAP2 / OMAP3 */
>> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
>> + l |= 0x1 << 0;
>> +
> We should get rid of this CPU checks. How about adding a flag
> and populating it on init for the architectures it supports.
>
Instead, this should be implemented on top of Tarun's hwmod conversion
which knows that different timers have different capabilities (e.g. 1ms)
and autoidle can be set based on capabilities.
Kevin
^ permalink raw reply
* [PATCH] ARM: pxa: support 806MHz operating points for PXA31x processors A2 stepping
From: Axel Lin @ 2011-02-15 16:20 UTC (permalink / raw)
To: linux-arm-kernel
PXA3xx Specification Update document states that the 806MHz
operating points were added for PXA31x processors A2 stepping.
This patch adds 806MHz operating points support for PXA31x A2 stepping.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
I cannot find any details for PXA31x stepping B1 and B2,
thus I made this patch for PXA31x stepping A2 only.
Axel
arch/arm/mach-pxa/cpufreq-pxa3xx.c | 23 +++++++++++++++++++----
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-pxa/cpufreq-pxa3xx.c b/arch/arm/mach-pxa/cpufreq-pxa3xx.c
index 88fbec0..f4f0c2e 100644
--- a/arch/arm/mach-pxa/cpufreq-pxa3xx.c
+++ b/arch/arm/mach-pxa/cpufreq-pxa3xx.c
@@ -210,15 +210,30 @@ static int pxa3xx_cpufreq_init(struct cpufreq_policy *policy)
/* set default policy and cpuinfo */
policy->cpuinfo.min_freq = 104000;
- policy->cpuinfo.max_freq = (cpu_is_pxa320()) ? 806000 : 624000;
+
+ if (cpu_is_pxa300())
+ policy->cpuinfo.max_freq = 624000;
+ else if (cpu_is_pxa310())
+ policy->cpuinfo.max_freq = ((read_cpuid_id() & 0xf) == 0x2) ?
+ 806000 : 624000;
+ else if (cpu_is_pxa320())
+ policy->cpuinfo.max_freq = 806000;
+
policy->cpuinfo.transition_latency = 1000; /* FIXME: 1 ms, assumed */
policy->max = pxa3xx_get_clk_frequency_khz(0);
policy->cur = policy->min = policy->max;
- if (cpu_is_pxa300() || cpu_is_pxa310())
+ if (cpu_is_pxa300())
ret = setup_freqs_table(policy, ARRAY_AND_SIZE(pxa300_freqs));
-
- if (cpu_is_pxa320())
+ else if (cpu_is_pxa310())
+ /* PXA310 A2 STEPPING supports 806Mhz operating points */
+ if ((read_cpuid_id() & 0xf) == 0x2)
+ ret = setup_freqs_table(policy,
+ ARRAY_AND_SIZE(pxa320_freqs));
+ else
+ ret = setup_freqs_table(policy,
+ ARRAY_AND_SIZE(pxa300_freqs));
+ else if (cpu_is_pxa320())
ret = setup_freqs_table(policy, ARRAY_AND_SIZE(pxa320_freqs));
if (ret) {
--
1.7.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox