* [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
* [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: Hiroshi.DOYU; +Cc: tony, linux-omap, 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
* [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 0/1] OMAP: IOMMU fault callback support
From: David Cohen @ 2011-02-15 14:36 UTC (permalink / raw)
To: Hiroshi.DOYU; +Cc: tony, linux-omap, 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 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
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: David Cohen @ 2011-02-15 14:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: tony, linux-omap, Hiroshi.DOYU, linux-arm-kernel, Sergei Shtylyov
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
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] Add Write Request operation in gatttool
From: Bruna Moreira @ 2011-02-15 14:36 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bruna Moreira
Add option and callbacks for Write Request operation in gatttool.
---
attrib/gatttool.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 60 insertions(+), 1 deletions(-)
diff --git a/attrib/gatttool.c b/attrib/gatttool.c
index 8e8ed8e..b9f0087 100644
--- a/attrib/gatttool.c
+++ b/attrib/gatttool.c
@@ -63,6 +63,7 @@ static gboolean opt_listen = FALSE;
static gboolean opt_char_desc = FALSE;
static gboolean opt_le = FALSE;
static gboolean opt_char_write = FALSE;
+static gboolean opt_char_write_req = FALSE;
static GMainLoop *event_loop;
static gboolean got_error = FALSE;
@@ -436,6 +437,59 @@ error:
return FALSE;
}
+static void char_write_req_cb(guint8 status, const guint8 *pdu, guint16 plen,
+ gpointer user_data)
+{
+ if (status != 0) {
+ g_printerr("Characteristic Write Request failed: "
+ "%s\n", att_ecode2str(status));
+ goto done;
+ }
+
+ if (!dec_write_resp(pdu, plen)) {
+ g_printerr("Protocol error\n");
+ goto done;
+ }
+
+ g_print("Characteristic value was written sucessfully\n");
+
+done:
+ if (opt_listen == FALSE)
+ g_main_loop_quit(event_loop);
+}
+
+static gboolean characteristics_write_req(gpointer user_data)
+{
+ GAttrib *attrib = user_data;
+ uint8_t *value;
+ size_t len;
+
+ if (opt_handle <= 0) {
+ g_printerr("A valid handle is required\n");
+ goto error;
+ }
+
+ if (opt_value == NULL || opt_value[0] == '\0') {
+ g_printerr("A value is required\n");
+ goto error;
+ }
+
+ len = attr_data_from_string(opt_value, &value);
+ if (len == 0) {
+ g_printerr("Invalid value\n");
+ goto error;
+ }
+
+ gatt_write_char(attrib, opt_handle, value, len, char_write_req_cb,
+ NULL);
+
+ return FALSE;
+
+error:
+ g_main_loop_quit(event_loop);
+ return FALSE;
+}
+
static void char_desc_cb(guint8 status, const guint8 *pdu, guint16 plen,
gpointer user_data)
{
@@ -530,7 +584,10 @@ static GOptionEntry gatt_options[] = {
{ "char-read", 0, 0, G_OPTION_ARG_NONE, &opt_char_read,
"Characteristics Value/Descriptor Read", NULL },
{ "char-write", 0, 0, G_OPTION_ARG_NONE, &opt_char_write,
- "Characteristics Value Write", NULL },
+ "Characteristics Value Write Without Response (Write Command)",
+ NULL },
+ { "char-write-req", 0, 0, G_OPTION_ARG_NONE, &opt_char_write_req,
+ "Characteristics Value Write (Write Request)", NULL },
{ "char-desc", 0, 0, G_OPTION_ARG_NONE, &opt_char_desc,
"Characteristics Descriptor Discovery", NULL },
{ "listen", 0, 0, G_OPTION_ARG_NONE, &opt_listen,
@@ -602,6 +659,8 @@ int main(int argc, char *argv[])
callback = characteristics_read;
else if (opt_char_write)
callback = characteristics_write;
+ else if (opt_char_write_req)
+ callback = characteristics_write_req;
else if (opt_char_desc)
callback = characteristics_desc;
else {
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 5/6 v4] cfq-iosched: CFQ group hierarchical scheduling and use_hierarchy interface
From: Vivek Goyal @ 2011-02-15 14:27 UTC (permalink / raw)
To: Gui Jianfeng; +Cc: Jens Axboe, Shaohua Li, lkml, Chad Talbott, Divyesh Shah
In-Reply-To: <4D59E728.3030209@cn.fujitsu.com>
On Tue, Feb 15, 2011 at 10:38:32AM +0800, Gui Jianfeng wrote:
> Vivek Goyal wrote:
> > On Sat, Feb 12, 2011 at 10:21:47AM +0800, Gui Jianfeng wrote:
> > [..]
> >>>> +static struct cfq_group *
> >>>> +cfq_find_alloc_cfqg(struct cfq_data *cfqd, struct cgroup *cgroup, int create)
> >>>> +{
> >>>> + struct blkio_cgroup *blkcg = cgroup_to_blkio_cgroup(cgroup);
> >>>> + struct cfq_group *cfqg = NULL;
> >>>> + void *key = cfqd;
> >>>> + struct backing_dev_info *bdi = &cfqd->queue->backing_dev_info;
> >>>> + unsigned int major, minor;
> >>>> +
> >>>> + cfqg = cfqg_of_blkg(blkiocg_lookup_group(blkcg, key));
> >>>> + if (cfqg && !cfqg->blkg.dev && bdi->dev && dev_name(bdi->dev)) {
> >>>> + sscanf(dev_name(bdi->dev), "%u:%u", &major, &minor);
> >>>> + cfqg->blkg.dev = MKDEV(major, minor);
> >>>> + goto done;
> >>>> + }
> >>> Should we make this updation of this info hierarhical?
> >> IMHO, it's fine to defer the updation when we really get the cfqg.
> >
> > But if cfqg is alrady present, we will never hit the allocation path
> > again. So if somebody creates 2-3 level deep hierarchy and does IO
> > only in the children cgroup, parent cgroups will potentially not get
> > device info updated hence no visible stats?
>
> Ahh, I see your concern. But do we really need to show the stats even if
> a cgroup doesn't issue any IO on a given device?
I am assuming that once use_hierarchy=1, you are aggregating the stats
in parent cgroups? So if a child services 5 IOs, these are accounted
to parent group also when user_hier=1?
What happens in case of memoy cgroup controller?
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH 0/6 v4] cfq-iosched: Introduce CFQ group hierarchical scheduling and "use_hierarchy" interface
From: Vivek Goyal @ 2011-02-15 14:29 UTC (permalink / raw)
To: Gui Jianfeng; +Cc: Chad Talbott, Jens Axboe, Shaohua Li, lkml, Divyesh Shah
In-Reply-To: <4D59EF6C.2090303@cn.fujitsu.com>
On Tue, Feb 15, 2011 at 11:13:48AM +0800, Gui Jianfeng wrote:
> Vivek Goyal wrote:
> > On Sat, Feb 12, 2011 at 02:08:54PM +0800, Gui Jianfeng wrote:
> >> Vivek Goyal wrote:
> >>> On Thu, Feb 10, 2011 at 03:45:45PM +0800, Gui Jianfeng wrote:
> >>>> Hi
> >>>>
> >>>> Previously, I posted a patchset to add support of CFQ group hierarchical scheduling
> >>>> in the way that it puts all CFQ queues in a hidden group and schedules with other
> >>>> CFQ group under their parent. The patchset is available here,
> >>>> http://lkml.org/lkml/2010/8/30/30
> >>>>
> >>>> Vivek think this approach isn't so instinct that we should treat CFQ queues
> >>>> and groups at the same level. Here is the new approach for hierarchical
> >>>> scheduling based on Vivek's suggestion. The most big change of CFQ is that
> >>>> it gets rid of cfq_slice_offset logic, and makes use of vdisktime for CFQ
> >>>> queue scheduling just like CFQ group does. But I still give cfqq some jump
> >>>> in vdisktime based on ioprio, thanks for Vivek to point out this. Now CFQ
> >>>> queue and CFQ group use the same scheduling algorithm.
> >>>>
> >>>> "use_hierarchy" interface is now added to switch between hierarchical mode
> >>>> and flat mode. It works as memcg.
> >>>>
> >>>> --
> >>>> V3 -> V4 Changes:
> >>>> - Take io class into account when calculating the boost value.
> >>>> - Refine the vtime boosting logic as Vivek's Suggestion.
> >>> Hi Gui,
> >>>
> >>> What testing did you do to make sure that this vtime boosting logic is working
> >>> and is good replacement for slice_offset() logic for cfqq?
> >>>
> >>> Secondly, did you get a chance to look at chad's patch of keeping track
> >>> of previous assigned vdisktime and keeping track of genrations. I think
> >>> his patch is going to coflict with yours, so one of you will have to
> >>> make adjustments. I think both the boost logic and keeping track of generation
> >>> logic can be combined.
> >> Hi Vivek,
> >>
> >> For the time being, boosting logic only works for cfq queue, and keepinging track of
> >> generation works for cfq group.
> >> I think when we introduce boosting logic for cfq group, we can combine these two logic
> >> together.
> >
> > Ok, I am assuming that now you are introducing another patch in the series
> > to get boosting logic working for groups also.
> >
> > Also, it might be easier to test it with group_idle=0, as right now groups
> > don't preempt each other.
>
> Vivek,
>
> If you don't object, I'd like to introduce this in a seperate patch when this series
> gets merged. For I don't want to add more complexity for this seires. ;)
> I'll post v5.
Ok, that's fine. We can implement boosting logic for groups later.
I think Chad's patch of remembering generation should help in getting service
differentiation even with idiling disabled.
Thanks
Vivek
^ permalink raw reply
* [PATCH] HID: add IRTOUCH infrared USB to hid_have_special_driver
From: Benjamin Tissoires @ 2011-02-15 14:33 UTC (permalink / raw)
To: Dmitry Torokhov, Henrik Rydberg, Benjamin Tissoires, Jiri Kosina,
Stephane Chatty, linux-input, linux-kernel
Without this patch, the device is handled by hidinput and does
not have the right behavior.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
---
Hi guys,
In the previous patch including the support to IRTOUCH devices, I forgot to add it to hid_have_special_driver. Sorry.
Cheers,
Benjamin
drivers/hid/hid-core.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index d678cf3..a5f6439 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1345,6 +1345,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE_2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HANVON, USB_DEVICE_ID_HANVON_MULTITOUCH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IRTOUCHSYSTEMS, USB_DEVICE_ID_IRTOUCH_INFRARED_USB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LABTEC, USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD) },
--
1.7.4
^ permalink raw reply related
* [PATCH] HID: add IRTOUCH infrared USB to hid_have_special_driver
From: Benjamin Tissoires @ 2011-02-15 14:33 UTC (permalink / raw)
To: Dmitry Torokhov, Henrik Rydberg, Benjamin Tissoires, Jiri Kosina,
Stephane Chatty <ch>
Without this patch, the device is handled by hidinput and does
not have the right behavior.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
---
Hi guys,
In the previous patch including the support to IRTOUCH devices, I forgot to add it to hid_have_special_driver. Sorry.
Cheers,
Benjamin
drivers/hid/hid-core.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index d678cf3..a5f6439 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1345,6 +1345,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE_2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HANVON, USB_DEVICE_ID_HANVON_MULTITOUCH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_IRTOUCHSYSTEMS, USB_DEVICE_ID_IRTOUCH_INFRARED_USB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LABTEC, USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD) },
--
1.7.4
^ permalink raw reply related
* [Qemu-devel] Re: qemu compiling error on ppc64: kvm.c:81: error: ‘struct kvm_sregs’ has no member named ‘pvr’
From: Alexander Graf @ 2011-02-15 14:33 UTC (permalink / raw)
To: Dushyant Bansal
Cc: qemu-devel@nongnu.org List, <kvm-ppc@vger.kernel.org>,
Avi Kivity
In-Reply-To: <4D5A8BDB.1000206@cse.iitd.ac.in>
On 15.02.2011, at 15:21, Dushyant Bansal wrote:
>
>>>> Hrm. This means that your kernel headers in /usr/include/linux are too old. Can you try and find out which kernel version they are from please
>>>>
>>>>
>>> Yes, kernel headers version is 2.6.32. For the time being, I copied some of the header files from kvm/arch/powerpc/include/asm/ to kernel headers and qemu build was successful.
>>> Thanks a lot.
>>>
>> Awesome! I'm eager to hear how well it works for you :)
>
> I collected some performance stats using kvm_stat. To get more information about exit counts of individual instructions, I configured CFLAGS_emulate.o with DDEBUG flag.
> Now, I can see output of "pr_debug("Emulating opcode %d / %d\n", get_op(inst), get_xop(inst));" instruction in kernel logs.
> I have two queries:
>
> 1. The count of "Emulating opcode...." statement in /var/log/kern.log (3 million) is coming out to be much less than emulated_inst_exits (22 million) using kvm_stat.
The kernel log ring buffer is probably faster filled than read :).
> 2. How to configure makefiles to get output of printk statements inside kvm/arch/powerpc/kvm/trace.h
Better don't make them printks - just use the tracing framework. I'd write up a small howto here myself, but I'm pretty much on the jump to my plane for vacation. Avi, could you please guide him a bit on how to get data out of tracepoints?
> Also, every time I start kvm, I get this error "KVM: Couldn't find level irq capability. Expect the VM to stall at times". After some time, the VM just hangs. I traced this output to qemu/target-ppc/kvm.c Is there any way to avoid it.
This means exactly what it means. There are two possible causes:
1) Your kernel is too old and doesn't support the capability
2) Qemu was compiled with kernel headers that don't know the capability yet
If it's 2, just copy some of the kvm*.h files from your kernel source over to /usr/include/linux or /usr/include/asm-powerpc and fix them up to compile (remove __user).
Alex
^ permalink raw reply
* Re: qemu compiling error on ppc64: kvm.c:
From: Dushyant Bansal @ 2011-02-15 14:33 UTC (permalink / raw)
To: Alexander Graf; +Cc: qemu-devel@nongnu.org, kvm-ppc@vger.kernel.org
In-Reply-To: <7703D057-F12D-4B95-9AEE-190C4EB2A3CE@suse.de>
>>> Hrm. This means that your kernel headers in /usr/include/linux are too old. Can you try and find out which kernel version they are from please
>>>
>>>
>> Yes, kernel headers version is 2.6.32. For the time being, I copied some of the header files from kvm/arch/powerpc/include/asm/ to kernel headers and qemu build was successful.
>> Thanks a lot.
>>
> Awesome! I'm eager to hear how well it works for you :)
I collected some performance stats using kvm_stat. To get more
information about exit counts of individual instructions, I configured
CFLAGS_emulate.o with DDEBUG flag.
Now, I can see output of "pr_debug("Emulating opcode %d / %d\n",
get_op(inst), get_xop(inst));" instruction in kernel logs.
I have two queries:
1. The count of "Emulating opcode...." statement in /var/log/kern.log (3
million) is coming out to be much less than emulated_inst_exits (22
million) using kvm_stat.
2. How to configure makefiles to get output of printk statements inside
kvm/arch/powerpc/kvm/trace.h
Also, every time I start kvm, I get this error "KVM: Couldn't find level
irq capability. Expect the VM to stall at times". After some time, the
VM just hangs. I traced this output to qemu/target-ppc/kvm.c Is there
any way to avoid it.
Thanks,
Dushyant
^ permalink raw reply
* Re: qemu compiling error on ppc64: kvm.c:
From: Alexander Graf @ 2011-02-15 14:33 UTC (permalink / raw)
To: Dushyant Bansal
Cc: qemu-devel@nongnu.org List, <kvm-ppc@vger.kernel.org>,
Avi Kivity
In-Reply-To: <4D5A8BDB.1000206@cse.iitd.ac.in>
On 15.02.2011, at 15:21, Dushyant Bansal wrote:
>
>>>> Hrm. This means that your kernel headers in /usr/include/linux are too old. Can you try and find out which kernel version they are from please
>>>>
>>>>
>>> Yes, kernel headers version is 2.6.32. For the time being, I copied some of the header files from kvm/arch/powerpc/include/asm/ to kernel headers and qemu build was successful.
>>> Thanks a lot.
>>>
>> Awesome! I'm eager to hear how well it works for you :)
>
> I collected some performance stats using kvm_stat. To get more information about exit counts of individual instructions, I configured CFLAGS_emulate.o with DDEBUG flag.
> Now, I can see output of "pr_debug("Emulating opcode %d / %d\n", get_op(inst), get_xop(inst));" instruction in kernel logs.
> I have two queries:
>
> 1. The count of "Emulating opcode...." statement in /var/log/kern.log (3 million) is coming out to be much less than emulated_inst_exits (22 million) using kvm_stat.
The kernel log ring buffer is probably faster filled than read :).
> 2. How to configure makefiles to get output of printk statements inside kvm/arch/powerpc/kvm/trace.h
Better don't make them printks - just use the tracing framework. I'd write up a small howto here myself, but I'm pretty much on the jump to my plane for vacation. Avi, could you please guide him a bit on how to get data out of tracepoints?
> Also, every time I start kvm, I get this error "KVM: Couldn't find level irq capability. Expect the VM to stall at times". After some time, the VM just hangs. I traced this output to qemu/target-ppc/kvm.c Is there any way to avoid it.
This means exactly what it means. There are two possible causes:
1) Your kernel is too old and doesn't support the capability
2) Qemu was compiled with kernel headers that don't know the capability yet
If it's 2, just copy some of the kvm*.h files from your kernel source over to /usr/include/linux or /usr/include/asm-powerpc and fix them up to compile (remove __user).
Alex
^ permalink raw reply
* Re: [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 14:23 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel, linux-kernel
In-Reply-To: <1297777027.1293.2.camel@e102144-lin.cambridge.arm.com>
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.
Thanks.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 1/3] target-arm: Setup smpboot code in all setups
From: Adam Lackorzynski @ 2011-02-15 14:30 UTC (permalink / raw)
To: Peter Maydell; +Cc: qemu-devel
In-Reply-To: <AANLkTin0Bk5G7vDEMn25wDNrve8b-TMc1CxiXopU6LFF@mail.gmail.com>
On Tue Feb 15, 2011 at 13:37:44 +0000, Peter Maydell wrote:
> On 15 February 2011 13:12, Adam Lackorzynski <adam@os.inf.tu-dresden.de> wrote:
> >
> > On Tue Feb 15, 2011 at 13:01:08 +0000, Peter Maydell wrote:
> >> On 15 February 2011 10:48, Adam Lackorzynski <adam@os.inf.tu-dresden.de> wrote:
> >> > Make smpboot available not only for Linux but for all setups.
> >>
> >> I'm not convinced about this. I think if you're providing a raw
> >> image for an SMP system (rather than a Linux kernel) then it's
> >> your job to provide an image which handles the bootup of the
> >> secondary CPUs, the same way it would be if you were providing
> >> a ROM image for real hardware.
> >
> > Ok, this is one possibility. Another one would be something like this:
>
> > @@ -112,7 +112,11 @@ static void secondary_cpu_reset(void *opaque)
> > /* Set entry point for secondary CPUs. This assumes we're using
> > the init code from arm_boot.c. Real hardware resets all CPUs
> > the same. */
> > - env->regs[15] = SMP_BOOT_ADDR;
> > + if (realview_binfo.is_linux) {
> > + env->regs[15] = SMP_BOOT_ADDR;
> > + } else {
> > + env->regs[15] = realview_binfo.entry;
> > + }
> > }
>
> Moving in the right direction, but it would be cleaner if the secondary
> CPU reset was handled inside arm_boot.c, I think (there is a TODO
> in that file to that effect). Then we could get rid of the cpu reset
> hook from realview.c.
Like the following?
Subject: [PATCH] target-arm: Integrate secondary CPU reset in arm_boot
Integrate secondary CPU reset into arm_boot, removing it from realview.c.
On non-Linux systems secondary CPUs start with the same entry as the boot
CPU.
Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de>
---
hw/arm_boot.c | 23 +++++++++++++++--------
hw/realview.c | 14 --------------
2 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index 620550b..41e99d1 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -175,7 +175,7 @@ static void set_kernel_args_old(struct arm_boot_info *info,
}
}
-static void main_cpu_reset(void *opaque)
+static void do_cpu_reset(void *opaque)
{
CPUState *env = opaque;
struct arm_boot_info *info = env->boot_info;
@@ -187,16 +187,20 @@ static void main_cpu_reset(void *opaque)
env->regs[15] = info->entry & 0xfffffffe;
env->thumb = info->entry & 1;
} else {
- env->regs[15] = info->loader_start;
- if (old_param) {
- set_kernel_args_old(info, info->initrd_size,
+ if (env == first_cpu) {
+ env->regs[15] = info->loader_start;
+ if (old_param) {
+ set_kernel_args_old(info, info->initrd_size,
+ info->loader_start);
+ } else {
+ set_kernel_args(info, info->initrd_size,
info->loader_start);
+ }
} else {
- set_kernel_args(info, info->initrd_size, info->loader_start);
+ env->regs[15] = info->smp_loader_start;
}
}
}
- /* TODO: Reset secondary CPUs. */
}
void arm_load_kernel(CPUState *env, struct arm_boot_info *info)
@@ -217,7 +221,6 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info)
if (info->nb_cpus == 0)
info->nb_cpus = 1;
- env->boot_info = info;
#ifdef TARGET_WORDS_BIGENDIAN
big_endian = 1;
@@ -279,5 +282,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info)
info->initrd_size = initrd_size;
}
info->is_linux = is_linux;
- qemu_register_reset(main_cpu_reset, env);
+
+ for (; env; env = env->next_cpu) {
+ env->boot_info = info;
+ qemu_register_reset(do_cpu_reset, env);
+ }
}
diff --git a/hw/realview.c b/hw/realview.c
index 6eb6c6a..fae444a 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -104,17 +104,6 @@ static struct arm_boot_info realview_binfo = {
.smp_loader_start = SMP_BOOT_ADDR,
};
-static void secondary_cpu_reset(void *opaque)
-{
- CPUState *env = opaque;
-
- cpu_reset(env);
- /* Set entry point for secondary CPUs. This assumes we're using
- the init code from arm_boot.c. Real hardware resets all CPUs
- the same. */
- env->regs[15] = SMP_BOOT_ADDR;
-}
-
/* The following two lists must be consistent. */
enum realview_board_type {
BOARD_EB,
@@ -176,9 +165,6 @@ static void realview_init(ram_addr_t ram_size,
}
irqp = arm_pic_init_cpu(env);
cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ];
- if (n > 0) {
- qemu_register_reset(secondary_cpu_reset, env);
- }
}
if (arm_feature(env, ARM_FEATURE_V7)) {
if (is_mpcore) {
--
1.7.2.3
Adam
--
Adam adam@os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
^ permalink raw reply related
* Re: [LTP] [PATCH] unshare01.c: TEST_RETURN is used wrong
From: Garrett Cooper @ 2011-02-15 14:30 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: ltp-list
In-Reply-To: <20110215132603.GA3092@localhost>
On Tue, Feb 15, 2011 at 5:26 AM, Serge E. Hallyn
<serge.hallyn@canonical.com> wrote:
> Quoting Peng Haitao (penght@cn.fujitsu.com):
>> Hi Garrett,
>>
>> Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
>> ---
>> testcases/kernel/syscalls/unshare/unshare01.c | 6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/testcases/kernel/syscalls/unshare/unshare01.c b/testcases/kernel/syscalls/unshare/unshare01.c
>> index e19d73d..9ae5e8f 100644
>> --- a/testcases/kernel/syscalls/unshare/unshare01.c
>> +++ b/testcases/kernel/syscalls/unshare/unshare01.c
>> @@ -206,7 +206,7 @@ int main(int ac, char **av) {
>> }
>>
>> pid1 = fork();
>> - if (TEST_RETURN == -1) {
>> + if (pid1 == -1) {
>
> Looking at the rest of that file, isn't the right fix to
> wrap 'pid1 = fork();' in a TEST() macro?
Hi Serge!
I would agree with you, but in my firm opinion this testcase
abuses TEST_ERRNO, etc way too much for no good reason.
I just didn't remember to follow through finishing off this file
for some odd reason.
Thanks,
-Garrett
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply
* Re: [PATCH 3/6 v4] cfq-iosched: Introduce vdisktime and io weight for CFQ queue
From: Vivek Goyal @ 2011-02-15 14:24 UTC (permalink / raw)
To: Gui Jianfeng; +Cc: Jens Axboe, Shaohua Li, lkml, Chad Talbott, Divyesh Shah
In-Reply-To: <4D59DCB6.1020900@cn.fujitsu.com>
On Tue, Feb 15, 2011 at 09:53:58AM +0800, Gui Jianfeng wrote:
> Vivek Goyal wrote:
> > On Sat, Feb 12, 2011 at 09:20:58AM +0800, Gui Jianfeng wrote:
> >> Vivek Goyal wrote:
> >>> On Thu, Feb 10, 2011 at 03:47:16PM +0800, Gui Jianfeng wrote:
> >>>> Introduce vdisktime and io weight for CFQ queue scheduling. Currently, io priority
> >>>> maps to a range [100,1000]. It also gets rid of cfq_slice_offset() logic and makes
> >>>> use the same scheduling algorithm as CFQ group does. This helps for CFQ queue and
> >>>> group scheduling on the same service tree.
> >>>>
> >>>> Signed-off-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
> >>>> ---
> >>>> block/cfq-iosched.c | 219 +++++++++++++++++++++++++++++++++++++++------------
> >>>> 1 files changed, 167 insertions(+), 52 deletions(-)
> >>>>
> >>>> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> >>>> index f3a126e..41cef2e 100644
> >>>> --- a/block/cfq-iosched.c
> >>>> +++ b/block/cfq-iosched.c
> >>>> @@ -39,6 +39,13 @@ static const int cfq_hist_divisor = 4;
> >>>> */
> >>>> #define CFQ_IDLE_DELAY (HZ / 5)
> >>>>
> >>>> +/*
> >>>> + * The base boosting value.
> >>>> + */
> >>>> +#define CFQ_BOOST_SYNC_BASE (HZ / 10)
> >>>> +#define CFQ_BOOST_ASYNC_BASE (HZ / 25)
> >>>> +
> >>> These are same as cfq_slice_sync and cfq_slice_async. Looking at
> >>> boost logic, this is equivalent of starting a new queue/group as
> >>> if it is being requeued after conuming a full slice. So may be we can divide
> >>> it by some const number say 4 or something like that. This is a minor
> >>> point though as this algorimthm will kind of evolve and we will learn
> >>> what works best.
> >>>
> >>> Secondly, I think you wanted to SYNC vs ASYNC logic seem to be reversed.
> >>> We would like to give ASYNC queues higher boost (Put these farther in
> >>> tree) and lesser boost to SYNC queues. Looks like above constants will
> >>> do the reverse?
> >> Hi Vivek,
> >>
> >> Currently, SYNC and ASYNC queues are in different service tree, they don't
> >> impact each other. Here, I Really want use this logic.
> >
> > Ok, SYNC and ASYNC are on separate service tree so their vtime are not
> > comparable (as of today, down the line one might want to look at those for
> > better workload selection logic).
> >
> > Anyway, because two are on seprate tree so why should we have separate
> > boosting constants for them? How does it help?
>
> Here if we are using CFQ_BOOST_SYNC_BASE for both, I think it might boost
> too much for an ASYNC cfqe as compare to others on the same service tree(async).
> So I make charging and boosting follow the same base.
Ok, that makes sense. So as suggested in other mails, lets use a even
smaller base so that freshly backlogged queues get smaller vdisktimes
as compared to existing queues which are using disks for longer time.
Thanks
Vivek
^ permalink raw reply
* [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Jarkko Nikula @ 2011-02-15 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim3+PFgJUU_-YqOt1M5NkSyHo6wUwF_XwC9MWSP@mail.gmail.com>
On Tue, 15 Feb 2011 16:08:32 +0200
David Cohen <dacohen@gmail.com> wrote:
> > So it's sure that a developer won't need these error dumps when
> > receiving an error report? I.e. IOMMU upper level errors give enough
> > information to start doing own debugging?
>
> Yes, developers do need this information.
> But it's a bit useless tell only we've got an iommu fault, due to many
> places might be causing it. My purpose is to let the debug
> responsibility to IOMMU users. They have access to the iovmm layer as
> well and can provide a much more useful information.
> e.g. OMAP3 ISP has many submodules using IOMMU. With a fault callback,
> it can dump all the iovm areas and the faulty 'da' too. It might
> indicate which submodule was responsible for the issue.
>
> Of course we can just let this debug messages the way they are and
> print this redundant information. But IMO it's not necessary.
>
Sounds fair enough and if I understood correctly this is not something
what end user will hit but more like another developer. In that case
the debug messages are the right thing.
--
Jarkko
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Jarkko Nikula @ 2011-02-15 14:30 UTC (permalink / raw)
To: David Cohen
Cc: tony, linux-omap, Hiroshi.DOYU, linux-arm-kernel, Sergei Shtylyov
In-Reply-To: <AANLkTim3+PFgJUU_-YqOt1M5NkSyHo6wUwF_XwC9MWSP@mail.gmail.com>
On Tue, 15 Feb 2011 16:08:32 +0200
David Cohen <dacohen@gmail.com> wrote:
> > So it's sure that a developer won't need these error dumps when
> > receiving an error report? I.e. IOMMU upper level errors give enough
> > information to start doing own debugging?
>
> Yes, developers do need this information.
> But it's a bit useless tell only we've got an iommu fault, due to many
> places might be causing it. My purpose is to let the debug
> responsibility to IOMMU users. They have access to the iovmm layer as
> well and can provide a much more useful information.
> e.g. OMAP3 ISP has many submodules using IOMMU. With a fault callback,
> it can dump all the iovm areas and the faulty 'da' too. It might
> indicate which submodule was responsible for the issue.
>
> Of course we can just let this debug messages the way they are and
> print this redundant information. But IMO it's not necessary.
>
Sounds fair enough and if I understood correctly this is not something
what end user will hit but more like another developer. In that case
the debug messages are the right thing.
--
Jarkko
^ permalink raw reply
* Re: [PATCH v4 16/19] ARM: LPAE: Use generic dma_addr_t type definition
From: Russell King - ARM Linux @ 2011-02-15 14:27 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-arm-kernel, linux-kernel, Will Deacon
In-Reply-To: <1297688490.31111.38.camel@e102109-lin.cambridge.arm.com>
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. I've already fixed
those in the pl08x driver:
struct lli {
dma_addr_t src;
dma_addr_t dst;
dma_addr_t next;
u32 cctl;
};
became:
struct pl08x_lli {
u32 src;
u32 dst;
u32 lli;
u32 cctl;
};
and similar needs to be done elsewhere in ARM specific drivers.
dma_addr_t has no business being in structures that describe data which
hardware accesses.
^ permalink raw reply
* Re: [LTP] [PATCH] unshare01.c: TEST_RETURN is used wrong
From: Garrett Cooper @ 2011-02-15 14:29 UTC (permalink / raw)
To: Peng Haitao; +Cc: ltp-list
In-Reply-To: <4D5A47E5.3060108@cn.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]
On Tue, Feb 15, 2011 at 1:31 AM, Peng Haitao <penght@cn.fujitsu.com> wrote:
> Hi Garrett,
>
> Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
> ---
> testcases/kernel/syscalls/unshare/unshare01.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/testcases/kernel/syscalls/unshare/unshare01.c b/testcases/kernel/syscalls/unshare/unshare01.c
> index e19d73d..9ae5e8f 100644
> --- a/testcases/kernel/syscalls/unshare/unshare01.c
> +++ b/testcases/kernel/syscalls/unshare/unshare01.c
> @@ -206,7 +206,7 @@ int main(int ac, char **av) {
> }
>
> pid1 = fork();
> - if (TEST_RETURN == -1) {
> + if (pid1 == -1) {
> tst_brkm(TFAIL|TERRNO, cleanup,
> "fork failed");
> } else if (pid1 == 0) {
> @@ -249,7 +249,7 @@ int main(int ac, char **av) {
> if (pid1 == -1) {
> tst_brkm(TFAIL|TERRNO, cleanup,
> "fork() failed.");
> - } else if (TEST_RETURN == 0) {
> + } else if (pid1 == 0) {
> TEST(unshare(CLONE_NEWNS));
> if (TEST_RETURN == 0) {
> printf("unshare call with CLONE_NEWNS "
> @@ -299,4 +299,4 @@ int main(void)
> tst_resm(TCONF, "unshare is undefined.");
> tst_exit();
> }
> -#endif
> \ No newline at end of file
> +#endif
How about this?
Thanks,
-Garrett
[-- Attachment #2: ltp-testcases-kernel-syscalls-unshare-fix.patch --]
[-- Type: text/x-patch, Size: 4700 bytes --]
diff --git a/testcases/kernel/syscalls/unshare/unshare01.c b/testcases/kernel/syscalls/unshare/unshare01.c
index e19d73d..a460248 100644
--- a/testcases/kernel/syscalls/unshare/unshare01.c
+++ b/testcases/kernel/syscalls/unshare/unshare01.c
@@ -109,14 +109,14 @@ int TST_TOTAL = 1; /* total number of tests in this file. */
/* Description: Performs all one time clean up for this test on successful */
/* completion, premature exit or failure. Closes all temporary */
/* files, removes all temporary directories exits the test with */
-/* appropriate TEST_RETURNurn code by calling tst_exit() function. */
+/* appropriate return code by calling tst_exit() function. */
/* */
/* Input: None. */
/* */
/* Output: None. */
/* */
-/* Return: On failure - Exits calling tst_exit(). Non '0' TEST_RETURNurn code. */
-/* On success - Exits calling tst_exit(). With '0' TEST_RETURNurn code. */
+/* Return: On failure - Exits calling tst_exit(). Non '0' return code. */
+/* On success - Exits calling tst_exit(). With '0' return code. */
/* */
/******************************************************************************/
extern void cleanup() {
@@ -140,7 +140,7 @@ extern void cleanup() {
/* Output: None. */
/* */
/* Return: On failure - Exits by calling cleanup(). */
-/* On success - TEST_RETURNurns 0. */
+/* On success - returns 0. */
/* */
/******************************************************************************/
void setup() {
@@ -154,7 +154,7 @@ int main(int ac, char **av) {
pid_t pid1;
int lc; /* loop counter */
int rval;
- char *msg; /* message TEST_RETURNurned from parse_opts */
+ char *msg; /* message returned from parse_opts */
/* parse standard options */
if ((msg = parse_opts(ac, av, NULL, NULL)) != NULL)
@@ -166,20 +166,20 @@ int main(int ac, char **av) {
Tst_count = 0;
for (testno = 0; testno < TST_TOTAL; ++testno) {
- TEST(pid1 = fork()); //call to fork()
- if (TEST_RETURN == -1) {
- tst_brkm(TFAIL|TTERRNO, cleanup, "fork failed");
- } else if (TEST_RETURN == 0) {
- TEST(unshare(CLONE_FILES));
- if (TEST_RETURN == 0) {
+ pid1 = fork(); //call to fork()
+ if (pid1 == -1) {
+ tst_brkm(TFAIL|TERRNO, cleanup, "fork failed");
+ } else if (pid1 == 0) {
+ switch (unshare(CLONE_FILES)) {
+ case 0:
printf("unshare with CLONE_FILES call "
"succeeded\n");
rval = 0;
- } else if (TEST_RETURN == -1) {
- if (TEST_ERRNO == ENOSYS) {
+ break;
+ case -1:
+ if (errno == ENOSYS)
rval = 1;
- } else {
- errno = TEST_ERRNO;
+ else {
perror("unshare failed");
rval = 2;
}
@@ -200,36 +200,34 @@ int main(int ac, char **av) {
default:
tst_brkm(TFAIL, cleanup,
"unshare failed");
- break;
}
}
}
pid1 = fork();
- if (TEST_RETURN == -1) {
+ if (pid1 == -1) {
tst_brkm(TFAIL|TERRNO, cleanup,
"fork failed");
} else if (pid1 == 0) {
- TEST(unshare(CLONE_FS));
- if (TEST_RETURN == 0) {
+ switch (unshare(CLONE_FS)) {
+ case 0:
printf("unshare with CLONE_FS call "
"succeeded\n");
rval = 0;
- } else if (TEST_RETURN == -1) {
- if (TEST_ERRNO == ENOSYS) {
+ break;
+ case -1:
+ if (errno == ENOSYS)
rval = 1;
- } else {
- errno = TEST_ERRNO;
+ else {
perror("unshare failed");
rval = 2;
}
}
exit(rval);
} else {
- if (wait(&rval) == -1) {
+ if (wait(&rval) == -1)
tst_brkm(TBROK|TERRNO, cleanup,
"wait failed");
- }
if (rval != 0 && WIFEXITED(rval)) {
switch (WEXITSTATUS(rval)) {
case 1:
@@ -249,17 +247,17 @@ int main(int ac, char **av) {
if (pid1 == -1) {
tst_brkm(TFAIL|TERRNO, cleanup,
"fork() failed.");
- } else if (TEST_RETURN == 0) {
- TEST(unshare(CLONE_NEWNS));
- if (TEST_RETURN == 0) {
+ } else if (pid1 == 0) {
+ switch (unshare(CLONE_NEWNS)) {
+ case 0:
printf("unshare call with CLONE_NEWNS "
"succeeded\n");
rval = 0;
- } else if (TEST_RETURN == -1) {
- if (TEST_ERRNO == ENOSYS) {
+ break;
+ case -1:
+ if (errno == ENOSYS)
rval = 1;
- } else {
- errno = TEST_ERRNO;
+ else {
perror("unshare failed");
rval = 2;
}
@@ -299,4 +297,4 @@ int main(void)
tst_resm(TCONF, "unshare is undefined.");
tst_exit();
}
-#endif
\ No newline at end of file
+#endif
[-- Attachment #3: Type: text/plain, Size: 387 bytes --]
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
[-- Attachment #4: Type: text/plain, Size: 155 bytes --]
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply related
* [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Russell King - ARM Linux @ 2011-02-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5A81D8.2080800@ru.mvista.com>
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.
>> }
>> - 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.
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Russell King - ARM Linux @ 2011-02-15 14:29 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: tony, David Cohen, linux-omap, Hiroshi.DOYU, linux-arm-kernel
In-Reply-To: <4D5A81D8.2080800@ru.mvista.com>
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.
>> }
>> - 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.
^ permalink raw reply
* [Bug 28902] activated KMS leads to complete freeze when viewing BIG images in Iceweasel
From: bugzilla-daemon @ 2011-02-15 14:29 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-28902-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=28902
--- Comment #4 from Julien Cristau <jcristau@debian.org> 2011-02-15 14:29:20 ---
> --- Comment #3 from spamfang1199@yahoo.de 2011-02-14 21:53:46 ---
> I will try as soon as a newer kernel will be available in Debians SID or
> Experimental tree.
>
2.6.37 has been in the experimental tree for over a month.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.