All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 00/36] Staging: cx25821: Clean up patch series
From: Leonid V. Fedorenchik @ 2011-10-24 14:46 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Greg KH, Namhyung Kim, Palash Bandyopadhyay, Joe Perches,
	Ilia Mirkin, Youquan Song, devel, linux-kernel
In-Reply-To: <4EA47CF8.2090504@redhat.com>

On Sun, 23 Oct 2011 22:45:44 +0200
Mauro Carvalho Chehab <mchehab@redhat.com> wrote:

> Em 23-10-2011 17:24, Leonid V. Fedorenchik escreveu:
> > 
> > Thank you. Should I send my future patches for this driver directly to you?
> 
> The better is if you could send them to linux-media@vger.kernel.org. Patchwork
> will catch them and put on my queue automatically.

OK, will do. :)

> 
> Thanks,
> Mauro

Leonid V. Fedorenchik

^ permalink raw reply
* [PATCH v5 0/7] arm: pmu: support pmu/perf on OMAP4
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
  To: linux, will.deacon, tony; +Cc: linux-arm-kernel, linux-omap, khilman, paul

Hi,

This patches support pmu irq routed from CTI, such as implemented
on OMAP4:

	- introduce some CTI helpers and registers' definition
	- introduce .enable_irq and .disable_irq into platform_data,
	so perf irq handler can handle irq correctly if it is routed
	from CTI on OMAP4
	- configure CTI on OMAP4 so that perf can work on OMAP4

The patches have been tested Ok on Pandaboard, and 'perf' does work
after applying them.

v5:
	- build pmu device from hwmod
	- support runtime pm

v4:
	- some minor fix(add __iomem, comments, checkpatch warning...)

v3:
	- fix typo of patch 2/3 title, pointed by Will
	- move cti addresses to plat/omap44xx.h, suggested by
	Santosh Shilimkar

v2:
	- move cti related code out of perf_event.c
	- introduce .enable_irq and .disable_irq into platform_data
	as suggested by Will.

v1:
	- rebase the patch set against 2.6.38-rc6-next-20110301, fix
	conflicts, which is pointed out by Will Deacon

 arch/arm/include/asm/cti.h                 |  179 ++++++++++++++++++++++++++++
 arch/arm/include/asm/pmu.h                 |   15 ++-
 arch/arm/kernel/perf_event.c               |   20 +++-
 arch/arm/kernel/pmu.c                      |   12 ++-
 arch/arm/mach-omap2/devices.c              |  126 +++++++++++++++++++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   26 ++++
 arch/arm/plat-omap/include/plat/omap44xx.h |    3 +
 7 files changed, 367 insertions(+), 14 deletions(-)

thanks,
--
Lei Ming


^ permalink raw reply
* Re: [PATCH 13/X] uprobes: introduce UTASK_SSTEP_TRAPPED logic
From: Oleg Nesterov @ 2011-10-24 14:41 UTC (permalink / raw)
  To: Ananth N Mavinakayanahalli
  Cc: Srikar Dronamraju, Peter Zijlstra, Ingo Molnar, Steven Rostedt,
	Linux-mm, Arnaldo Carvalho de Melo, Linus Torvalds,
	Jonathan Corbet, Masami Hiramatsu, Hugh Dickins,
	Christoph Hellwig, Thomas Gleixner, Andi Kleen, Andrew Morton,
	Jim Keniston, Roland McGrath, LKML
In-Reply-To: <20111022072030.GB24475@in.ibm.com>

On 10/22, Ananth N Mavinakayanahalli wrote:
>
> On Wed, Oct 19, 2011 at 11:53:44PM +0200, Oleg Nesterov wrote:
> > Finally, add UTASK_SSTEP_TRAPPED state/code to handle the case when
> > xol insn itself triggers the signal.
> >
> > In this case we should restart the original insn even if the task is
> > already SIGKILL'ed (say, the coredump should report the correct ip).
> > This is even more important if the task has a handler for SIGSEGV/etc,
> > The _same_ instruction should be repeated again after return from the
> > signal handler, and SSTEP can never finish in this case.
>
> Oleg,
>
> Not sure I understand this completely...

I hope you do not think I do ;)

> When you say 'correct ip' you mean the original vaddr where we now have
> a uprobe breakpoint and not the xol copy, right?

Yes,

> Coredump needs to report the correct ip, but should it also not report
> correctly the instruction that caused the signal? Ergo, shouldn't we
> put the original instruction back at the uprobed vaddr?

OK, now I see what you mean. I was confused by the "restore the original
instruction before _restart_" suggestion.

Agreed! it would be nice to "hide" these int3's if we dump the core, but
I think this is a bit off-topic. It makes sense to do this in any case,
even if the core-dumping was triggered by another thread/insn. It makes
sense to remove all int3's, not only at regs->ip location. But how can
we do this? This is nontrivial.

And. Even worse. Suppose that you do "gdb probed_application". Now you
see int3's in the disassemble output. What can we do?

I think we can do nothing, at least currently. This just reflects the
fact that uprobe connects to inode, not to process/mm/etc.

What do you think?

Oleg.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply
* [PATCH v5 7/7] arm: omap4: pmu: support runtime pm
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>

From: Ming Lei <ming.lei@canonical.com>

Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/devices.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index bc791e0..ab4de0d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/of.h>
+#include <linux/pm_runtime.h>
 
 #include <mach/hardware.h>
 #include <mach/irqs.h>
@@ -395,9 +396,11 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
 };
 
 static struct cti omap4_cti[2];
+static struct platform_device *pmu_dev;
 
 static void omap4_enable_cti(int irq)
 {
+	pm_runtime_get_sync(&pmu_dev->dev);
 	if (irq == OMAP44XX_IRQ_CTI0)
 		cti_enable(&omap4_cti[0]);
 	else if (irq == OMAP44XX_IRQ_CTI1)
@@ -410,6 +413,7 @@ static void omap4_disable_cti(int irq)
 		cti_disable(&omap4_cti[0]);
 	else if (irq == OMAP44XX_IRQ_CTI1)
 		cti_disable(&omap4_cti[1]);
+	pm_runtime_put(&pmu_dev->dev);
 }
 
 static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
@@ -497,8 +501,11 @@ static void __init omap_init_pmu(void)
 		if (!pd)
 			return;
 
-		omap_device_enable(&od->pdev);
+		pmu_dev= pd;
+		pm_runtime_enable(&pd->dev);
+		pm_runtime_get_sync(&pd->dev);
 		omap4_configure_pmu_irq();
+		pm_runtime_put(&pd->dev);
 		return;
 	} else {
 		return;
-- 
1.7.5.4

^ permalink raw reply related
* [PATCH v5 6/7] arm: omap4: support pmu
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>

From: Ming Lei <ming.lei@canonical.com>

This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.

The idea is from Woodruff Richard in the disscussion
about "Oprofile on Pandaboard / Omap4" on pandaboard at googlegroups.com.

Acked-by: Jean Pihet <j-pihet@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Woodruff Richard <r-woodruff2@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/devices.c              |   60 +++++++++++++++++++++++++++-
 arch/arm/plat-omap/include/plat/omap44xx.h |    3 +
 2 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 6e16274..bc791e0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -23,6 +23,7 @@
 #include <asm/mach-types.h>
 #include <asm/mach/map.h>
 #include <asm/pmu.h>
+#include <asm/cti.h>
 
 #include <plat/tc.h>
 #include <plat/board.h>
@@ -393,6 +394,57 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
 	},
 };
 
+static struct cti omap4_cti[2];
+
+static void omap4_enable_cti(int irq)
+{
+	if (irq == OMAP44XX_IRQ_CTI0)
+		cti_enable(&omap4_cti[0]);
+	else if (irq == OMAP44XX_IRQ_CTI1)
+		cti_enable(&omap4_cti[1]);
+}
+
+static void omap4_disable_cti(int irq)
+{
+	if (irq == OMAP44XX_IRQ_CTI0)
+		cti_disable(&omap4_cti[0]);
+	else if (irq == OMAP44XX_IRQ_CTI1)
+		cti_disable(&omap4_cti[1]);
+}
+
+static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
+{
+	if (irq == OMAP44XX_IRQ_CTI0)
+		cti_irq_ack(&omap4_cti[0]);
+	else if (irq == OMAP44XX_IRQ_CTI1)
+		cti_irq_ack(&omap4_cti[1]);
+
+	return handler(irq, dev);
+}
+
+static void __init omap4_configure_pmu_irq(void)
+{
+	void __iomem *base0;
+	void __iomem *base1;
+
+	base0 = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+	base1 = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
+	if (!base0 && !base1) {
+		pr_err("ioremap for OMAP4 CTI failed\n");
+		return;
+	}
+
+	/*configure CTI0 for pmu irq routing*/
+	cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
+	cti_unlock(&omap4_cti[0]);
+	cti_map_trigger(&omap4_cti[0], 1, 6, 2);
+
+	/*configure CTI1 for pmu irq routing*/
+	cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
+	cti_unlock(&omap4_cti[1]);
+	cti_map_trigger(&omap4_cti[1], 1, 6, 2);
+}
+
 static struct platform_device* __init omap4_init_pmu(void)
 {
 	int id = -1;
@@ -420,6 +472,10 @@ static struct platform_device* __init omap4_init_pmu(void)
 		return NULL;
 	}
 
+	omap4_pmu_data.handle_irq = omap4_pmu_handler;
+	omap4_pmu_data.enable_irq = omap4_enable_cti;
+	omap4_pmu_data.disable_irq = omap4_disable_cti;
+
 	pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
 				sizeof(omap4_pmu_data),
 				omap_pmu_latency,
@@ -440,7 +496,9 @@ static void __init omap_init_pmu(void)
 		pd = omap4_init_pmu();
 		if (!pd)
 			return;
-		omap_device_enable(pd);
+
+		omap_device_enable(&od->pdev);
+		omap4_configure_pmu_irq();
 		return;
 	} else {
 		return;
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h
index ea2b8a6..4637980 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -57,5 +57,8 @@
 #define OMAP44XX_HSUSB_OHCI_BASE	(L4_44XX_BASE + 0x64800)
 #define OMAP44XX_HSUSB_EHCI_BASE	(L4_44XX_BASE + 0x64C00)
 
+#define OMAP44XX_CTI0_BASE		0x54148000
+#define OMAP44XX_CTI1_BASE		0x54149000
+
 #endif /* __ASM_ARCH_OMAP44XX_H */
 
-- 
1.7.5.4

^ permalink raw reply related
* [PATCH v5 5/7] arm: omap4: create pmu device via hwmod
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>

From: Ming Lei <ming.lei@canonical.com>

The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:

        emu, l3_instr, l3_main_3

so build the arm-pmu device via the three hwmods.

Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/devices.c |   61 ++++++++++++++++++++++++++++++++++++++---
 1 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0f8e0eb..6e16274 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -384,14 +384,67 @@ static struct platform_device omap_pmu_device = {
 	.num_resources	= 1,
 };
 
-static void omap_init_pmu(void)
+static struct arm_pmu_platdata omap4_pmu_data;
+static struct omap_device_pm_latency omap_pmu_latency[] = {
+	[0] = {
+		.deactivate_func = omap_device_idle_hwmods,
+		.activate_func   = omap_device_enable_hwmods,
+		.flags		 = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+	},
+};
+
+static struct platform_device* __init omap4_init_pmu(void)
 {
-	if (cpu_is_omap24xx())
+	int id = -1;
+	const char *hw;
+	struct platform_device *pd;
+	struct omap_hwmod* oh[3];
+	char *dev_name = "arm-pmu";
+
+	hw = "l3_main_3";
+	oh[0] = omap_hwmod_lookup(hw);
+	if (!oh[0]) {
+		pr_err("Could not look up %s hwmod\n", hw);
+		return NULL;
+	}
+	hw = "l3_instr";
+	oh[1] = omap_hwmod_lookup(hw);
+	if (!oh[1]) {
+		pr_err("Could not look up %s hwmod\n", hw);
+		return NULL;
+	}
+	hw = "emu";
+	oh[2] = omap_hwmod_lookup(hw);
+	if (!oh[2]) {
+		pr_err("Could not look up %s hwmod\n", hw);
+		return NULL;
+	}
+
+	pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
+				sizeof(omap4_pmu_data),
+				omap_pmu_latency,
+				ARRAY_SIZE(omap_pmu_latency), 0);
+	WARN(IS_ERR(pd), "Can't build omap_device for %s.\n",
+				dev_name);
+	return pd;
+}
+static void __init omap_init_pmu(void)
+{
+	if (cpu_is_omap24xx()) {
 		omap_pmu_device.resource = &omap2_pmu_resource;
-	else if (cpu_is_omap34xx())
+	} else if (cpu_is_omap34xx()) {
 		omap_pmu_device.resource = &omap3_pmu_resource;
-	else
+	} else if (cpu_is_omap44xx()) {
+		struct platform_device *pd;
+
+		pd = omap4_init_pmu();
+		if (!pd)
+			return;
+		omap_device_enable(pd);
+		return;
+	} else {
 		return;
+	}
 
 	platform_device_register(&omap_pmu_device);
 }
-- 
1.7.5.4

^ permalink raw reply related
* [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>

From: Ming Lei <ming.lei@canonical.com>

So that access to cross trigger interface can be allowed, which
will be introduce in later patches.

Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 393afac..c7289a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5276,6 +5276,30 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
 	.slaves_cnt	= ARRAY_SIZE(omap44xx_wd_timer3_slaves),
 };
 
+static struct omap_hwmod_class omap44xx_emu_hwmod_class = {
+	.name	= "emu",
+};
+
+static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
+	{ .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
+	{ .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+/*emu hwmod*/
+static struct omap_hwmod omap44xx_emu_hwmod = {
+	.name		= "emu",
+	.class		= &omap44xx_emu_hwmod_class,
+	.clkdm_name	= "emu_sys_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.mpu_irqs	= omap44xx_emu_irqs,
+};
+
 static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 
 	/* dmm class */
@@ -5422,6 +5446,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 	&omap44xx_wd_timer2_hwmod,
 	&omap44xx_wd_timer3_hwmod,
 
+	/*emu class*/
+	&omap44xx_emu_hwmod,
 	NULL,
 };
 
-- 
1.7.5.4

^ permalink raw reply related
* [PATCH v5 3/7] arm: perf: support device with other non-irq resources
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>

From: Ming Lei <ming.lei@canonical.com>

omap4 may create device via hwmod, which can create resources
automatically, so may include some non-irq resources.

This patch supports device with other non-irq resources.

Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/kernel/perf_event.c |    5 +++--
 arch/arm/kernel/pmu.c        |   12 ++++++++++--
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index f367780..d91dba2 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -19,6 +19,7 @@
 #include <linux/platform_device.h>
 #include <linux/spinlock.h>
 #include <linux/uaccess.h>
+#include <linux/cpumask.h>
 
 #include <asm/cputype.h>
 #include <asm/irq.h>
@@ -414,7 +415,7 @@ armpmu_reserve_hardware(void)
 		return -ENODEV;
 	}
 
-	for (i = 0; i < pmu_device->num_resources; ++i) {
+	for (i = 0; i < nr_cpu_ids; ++i) {
 		irq = platform_get_irq(pmu_device, i);
 		if (irq < 0)
 			continue;
@@ -453,7 +454,7 @@ armpmu_release_hardware(void)
 	struct arm_pmu_platdata *plat =
 		dev_get_platdata(&pmu_device->dev);
 
-	for (i = pmu_device->num_resources - 1; i >= 0; --i) {
+	for (i = nr_cpu_ids - 1; i >= 0; --i) {
 		irq = platform_get_irq(pmu_device, i);
 		if (irq >= 0) {
 			if (plat && plat->disable_irq)
diff --git a/arch/arm/kernel/pmu.c b/arch/arm/kernel/pmu.c
index c53474f..0e9c908 100644
--- a/arch/arm/kernel/pmu.c
+++ b/arch/arm/kernel/pmu.c
@@ -19,6 +19,7 @@
 #include <linux/module.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/cpumask.h>
 
 #include <asm/pmu.h>
 
@@ -172,8 +173,15 @@ init_cpu_pmu(void)
 	if (irqs == 1 && !irq_can_set_affinity(platform_get_irq(pdev, 0)))
 		return 0;
 
-	for (i = 0; i < irqs; ++i) {
-		err = set_irq_affinity(platform_get_irq(pdev, i), i);
+	for (i = 0; i < nr_cpu_ids; ++i) {
+		int irq;
+
+		irq = platform_get_irq(pdev, i);
+
+		if (irq < 0)
+			continue;
+
+		err = set_irq_affinity(irq, i);
 		if (err)
 			break;
 	}
-- 
1.7.5.4

^ permalink raw reply related
* [PATCH v5 2/7] arm: pmu: allow platform specific irq enable/disable handling
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>

From: Ming Lei <ming.lei@canonical.com>

This patch introduces .enable_irq and .disable_irq into
struct arm_pmu_platdata, so platform specific irq enablement
can be handled after request_irq, and platform specific irq
disablement can be handled before free_irq.

This patch is for support of  pmu irq routed from CTI on omap4.

Acked-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/include/asm/pmu.h   |   15 ++++++++++++---
 arch/arm/kernel/perf_event.c |   15 ++++++++++++---
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index b7e82c4..3af5e39 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -22,13 +22,22 @@ enum arm_pmu_type {
 /*
  * struct arm_pmu_platdata - ARM PMU platform data
  *
- * @handle_irq: an optional handler which will be called from the interrupt and
- * passed the address of the low level handler, and can be used to implement
- * any platform specific handling before or after calling it.
+ * @handle_irq: an optional handler which will be called from the
+ *	interrupt and passed the address of the low level handler,
+ *	and can be used to implement any platform specific handling
+ *	before or after calling it.
+ * @enable_irq: an optional handler which will be called after
+ *	request_irq and be used to handle some platform specific
+ *	irq enablement
+ * @disable_irq: an optional handler which will be called before
+ *	free_irq and be used to handle some platform specific
+ *	irq disablement
  */
 struct arm_pmu_platdata {
 	irqreturn_t (*handle_irq)(int irq, void *dev,
 				  irq_handler_t pmu_handler);
+	void (*enable_irq)(int irq);
+	void (*disable_irq)(int irq);
 };
 
 #ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 53c9c26..f367780 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -426,14 +426,18 @@ armpmu_reserve_hardware(void)
 			pr_warning("unable to request IRQ%d for ARM perf "
 				"counters\n", irq);
 			break;
-		}
+		} else if (plat && plat->enable_irq)
+			plat->enable_irq(irq);
 	}
 
 	if (err) {
 		for (i = i - 1; i >= 0; --i) {
 			irq = platform_get_irq(pmu_device, i);
-			if (irq >= 0)
+			if (irq >= 0) {
+				if (plat && plat->disable_irq)
+					plat->disable_irq(irq);
 				free_irq(irq, NULL);
+			}
 		}
 		release_pmu(ARM_PMU_DEVICE_CPU);
 		pmu_device = NULL;
@@ -446,11 +450,16 @@ static void
 armpmu_release_hardware(void)
 {
 	int i, irq;
+	struct arm_pmu_platdata *plat =
+		dev_get_platdata(&pmu_device->dev);
 
 	for (i = pmu_device->num_resources - 1; i >= 0; --i) {
 		irq = platform_get_irq(pmu_device, i);
-		if (irq >= 0)
+		if (irq >= 0) {
+			if (plat && plat->disable_irq)
+				plat->disable_irq(irq);
 			free_irq(irq, NULL);
+		}
 	}
 	armpmu->stop();
 
-- 
1.7.5.4

^ permalink raw reply related
* [PATCH v5 1/7] arm: introduce cross trigger interface helpers
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>

From: Ming Lei <ming.lei@canonical.com>

OMAP4 uses cross trigger interface(CTI) to route
performance monitor irq to GIC, so introduce cti
helpers to make access for cti easily.

Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/include/asm/cti.h |  179 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 179 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/cti.h

diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
new file mode 100644
index 0000000..a0ada3e
--- /dev/null
+++ b/arch/arm/include/asm/cti.h
@@ -0,0 +1,179 @@
+#ifndef __ASMARM_CTI_H
+#define __ASMARM_CTI_H
+
+#include	<asm/io.h>
+
+/* The registers' definition is from section 3.2 of
+ * Embedded Cross Trigger Revision: r0p0
+ */
+#define		CTICONTROL		0x000
+#define		CTISTATUS		0x004
+#define		CTILOCK			0x008
+#define		CTIPROTECTION		0x00C
+#define		CTIINTACK		0x010
+#define		CTIAPPSET		0x014
+#define		CTIAPPCLEAR		0x018
+#define		CTIAPPPULSE		0x01c
+#define		CTIINEN			0x020
+#define		CTIOUTEN		0x0A0
+#define		CTITRIGINSTATUS		0x130
+#define		CTITRIGOUTSTATUS	0x134
+#define		CTICHINSTATUS		0x138
+#define		CTICHOUTSTATUS		0x13c
+#define		CTIPERIPHID0		0xFE0
+#define		CTIPERIPHID1		0xFE4
+#define		CTIPERIPHID2		0xFE8
+#define		CTIPERIPHID3		0xFEC
+#define		CTIPCELLID0		0xFF0
+#define		CTIPCELLID1		0xFF4
+#define		CTIPCELLID2		0xFF8
+#define		CTIPCELLID3		0xFFC
+
+/* The below are from section 3.6.4 of
+ * CoreSight v1.0 Architecture Specification
+ */
+#define		LOCKACCESS		0xFB0
+#define		LOCKSTATUS		0xFB4
+
+/* write this value to LOCKACCESS will unlock the module, and
+ * other value will lock the module
+ */
+#define		LOCKCODE		0xC5ACCE55
+
+/**
+ * struct cti - cross trigger interface struct
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out_for_irq: triger out number which will cause
+ *	the @irq happen
+ *
+ * cti struct used to operate cti registers.
+ */
+struct cti {
+	void __iomem *base;
+	int irq;
+	int trig_out_for_irq;
+};
+
+/**
+ * cti_init - initialize the cti instance
+ * @cti: cti instance
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out: triger out number which will cause
+ *	the @irq happen
+ *
+ * called by machine code to pass the board dependent
+ * @base, @irq and @trig_out to cti.
+ */
+static inline void cti_init(struct cti *cti,
+	void __iomem *base, int irq, int trig_out)
+{
+	cti->base = base;
+	cti->irq  = irq;
+	cti->trig_out_for_irq = trig_out;
+}
+
+/**
+ * cti_map_trigger - use the @chan to map @trig_in to @trig_out
+ * @cti: cti instance
+ * @trig_in: trigger in number
+ * @trig_out: trigger out number
+ * @channel: channel number
+ *
+ * This function maps one trigger in of @trig_in to one trigger
+ * out of @trig_out using the channel @chan.
+ */
+static inline void cti_map_trigger(struct cti *cti,
+	int trig_in, int trig_out, int chan)
+{
+	void __iomem *base = cti->base;
+	unsigned long val;
+
+	val = __raw_readl(base + CTIINEN + trig_in * 4);
+	val |= BIT(chan);
+	__raw_writel(val, base + CTIINEN + trig_in * 4);
+
+	val = __raw_readl(base + CTIOUTEN + trig_out * 4);
+	val |= BIT(chan);
+	__raw_writel(val, base + CTIOUTEN + trig_out * 4);
+}
+
+/**
+ * cti_enable - enable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_enable(struct cti *cti)
+{
+	__raw_writel(0x1, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_disable - disable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_disable(struct cti *cti)
+{
+	__raw_writel(0, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_irq_ack - clear the cti irq
+ * @cti: cti instance
+ *
+ * clear the cti irq
+ */
+static inline void cti_irq_ack(struct cti *cti)
+{
+	void __iomem *base = cti->base;
+	unsigned long val;
+
+	val = __raw_readl(base + CTIINTACK);
+	val |= BIT(cti->trig_out_for_irq);
+	__raw_writel(val, base + CTIINTACK);
+}
+
+/**
+ * cti_unlock - unlock cti module
+ * @cti: cti instance
+ *
+ * unlock the cti module, or else any writes to the cti
+ * module is not allowed.
+ */
+static inline void cti_unlock(struct cti *cti)
+{
+	void __iomem *base = cti->base;
+	unsigned long val;
+
+	val = __raw_readl(base + LOCKSTATUS);
+
+	if (val & 1) {
+		val = LOCKCODE;
+		__raw_writel(val, base + LOCKACCESS);
+	}
+}
+
+/**
+ * cti_lock - lock cti module
+ * @cti: cti instance
+ *
+ * lock the cti module, so any writes to the cti
+ * module will be not allowed.
+ */
+static inline void cti_lock(struct cti *cti)
+{
+	void __iomem *base = cti->base;
+	unsigned long val;
+
+	val = __raw_readl(base + LOCKSTATUS);
+
+	if (!(val & 1)) {
+		val = ~LOCKCODE;
+		__raw_writel(val, base + LOCKACCESS);
+	}
+}
+#endif
-- 
1.7.5.4

^ permalink raw reply related
* [PATCH v5 0/7] arm: pmu: support pmu/perf on OMAP4
From: ming.lei at canonical.com @ 2011-10-24 14:45 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

This patches support pmu irq routed from CTI, such as implemented
on OMAP4:

	- introduce some CTI helpers and registers' definition
	- introduce .enable_irq and .disable_irq into platform_data,
	so perf irq handler can handle irq correctly if it is routed
	from CTI on OMAP4
	- configure CTI on OMAP4 so that perf can work on OMAP4

The patches have been tested Ok on Pandaboard, and 'perf' does work
after applying them.

v5:
	- build pmu device from hwmod
	- support runtime pm

v4:
	- some minor fix(add __iomem, comments, checkpatch warning...)

v3:
	- fix typo of patch 2/3 title, pointed by Will
	- move cti addresses to plat/omap44xx.h, suggested by
	Santosh Shilimkar

v2:
	- move cti related code out of perf_event.c
	- introduce .enable_irq and .disable_irq into platform_data
	as suggested by Will.

v1:
	- rebase the patch set against 2.6.38-rc6-next-20110301, fix
	conflicts, which is pointed out by Will Deacon

 arch/arm/include/asm/cti.h                 |  179 ++++++++++++++++++++++++++++
 arch/arm/include/asm/pmu.h                 |   15 ++-
 arch/arm/kernel/perf_event.c               |   20 +++-
 arch/arm/kernel/pmu.c                      |   12 ++-
 arch/arm/mach-omap2/devices.c              |  126 +++++++++++++++++++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   26 ++++
 arch/arm/plat-omap/include/plat/omap44xx.h |    3 +
 7 files changed, 367 insertions(+), 14 deletions(-)

thanks,
--
Lei Ming

^ permalink raw reply
* Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
From: Bob Breuer @ 2011-10-24 14:45 UTC (permalink / raw)
  To: Kai Tietz
  Cc: xunxun, Richard Henderson, qemu-devel, Mark Cave-Ayland,
	gcc@gcc.gnu.org
In-Reply-To: <CAEwic4Zey2f6fzSOAiGtyxuBnN2zSPwQCcDdTDdL8-DOiqC2GQ@mail.gmail.com>

Kai Tietz wrote:
> Hi,
> 
> For trunk-version I have a tentative patch for this issue.  On 4.6.x
> and older branches this doesn't work, as here we can't differenciate
> that easy between ms- and sysv-abi.
> 
> But could somebody give this patch a try?
> 
> Regards,
> Kai
> 
> ChangeLog
> 
>         * config/i386/i386.c (ix86_frame_pointer_required): Enforce use of
>         frame-pointer for 32-bit ms-abi, if setjmp is used.
> 
> Index: i386.c
> ===================================================================
> --- i386.c      (revision 180099)
> +++ i386.c      (working copy)
> @@ -8391,6 +8391,10 @@
>    if (SUBTARGET_FRAME_POINTER_REQUIRED)
>      return true;
> 
> +  /* For older 32-bit runtimes setjmp requires valid frame-pointer.  */
> +  if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
> +    return true;
> +
>    /* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER
>       turns off the frame pointer by default.  Turn it back on now if
>       we've not got a leaf function.  */
> 

For a gcc 4.7 snapshot, this does fix the longjmp problem that I
encountered.  So aside from specifying -fno-omit-frame-pointer for
affected files, what can be done for 4.6?

Bob

^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Rob Herring @ 2011-10-24 14:44 UTC (permalink / raw)
  To: Nicolas Ferre
  Cc: grant.likely, linux-kernel, linux-arm-kernel, devicetree-discuss,
	plagnioj
In-Reply-To: <15ab652499e7f6f8a26724bfd90643a8f3f96ad9.1319464310.git.nicolas.ferre@atmel.com>

On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> The Evaluation Kit at91sam9m10g45ek includes it.
> This first basic support will be populated as drivers and boards will be
> converted to device tree.
> Contains serial, dma and interrupt controllers.
> 
> The generic board file still takes advantage of platform data for early serial
> init. As we need a storage media and the NAND flash driver is not converted to
> DT yet, we keep old initialization for it.
> 

This comment is out of date for serial.

> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> V3:
> - additional clock lookup for device tree handling
> - devices disabled in dtsi file so that only useful devices are
>   enabled in dts files
> 
> V2: foundation for AT91SAM generic support
> - device tree focused board file
> - inclusion of USART DT support
> - early USART and NAND still using platform data
> 

Reviewed-by: Rob Herring <rob.herring@calxeda.com>

Rob

^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Rob Herring @ 2011-10-24 14:44 UTC (permalink / raw)
  To: Nicolas Ferre
  Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <15ab652499e7f6f8a26724bfd90643a8f3f96ad9.1319464310.git.nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>

On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> The Evaluation Kit at91sam9m10g45ek includes it.
> This first basic support will be populated as drivers and boards will be
> converted to device tree.
> Contains serial, dma and interrupt controllers.
> 
> The generic board file still takes advantage of platform data for early serial
> init. As we need a storage media and the NAND flash driver is not converted to
> DT yet, we keep old initialization for it.
> 

This comment is out of date for serial.

> Signed-off-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> ---
> V3:
> - additional clock lookup for device tree handling
> - devices disabled in dtsi file so that only useful devices are
>   enabled in dts files
> 
> V2: foundation for AT91SAM generic support
> - device tree focused board file
> - inclusion of USART DT support
> - early USART and NAND still using platform data
> 

Reviewed-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>

Rob

^ permalink raw reply
* [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Rob Herring @ 2011-10-24 14:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <15ab652499e7f6f8a26724bfd90643a8f3f96ad9.1319464310.git.nicolas.ferre@atmel.com>

On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> The Evaluation Kit at91sam9m10g45ek includes it.
> This first basic support will be populated as drivers and boards will be
> converted to device tree.
> Contains serial, dma and interrupt controllers.
> 
> The generic board file still takes advantage of platform data for early serial
> init. As we need a storage media and the NAND flash driver is not converted to
> DT yet, we keep old initialization for it.
> 

This comment is out of date for serial.

> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> V3:
> - additional clock lookup for device tree handling
> - devices disabled in dtsi file so that only useful devices are
>   enabled in dts files
> 
> V2: foundation for AT91SAM generic support
> - device tree focused board file
> - inclusion of USART DT support
> - early USART and NAND still using platform data
> 

Reviewed-by: Rob Herring <rob.herring@calxeda.com>

Rob

^ permalink raw reply
* [PATCH 05/10] user namespace: clamp down users of cap_raised
From: Serge E. Hallyn @ 2011-10-24 14:43 UTC (permalink / raw)
  To: David Howells
  Cc: Andrew G. Morgan, linux-kernel, ebiederm, akpm, oleg, richard,
	mikevs, segoon, gregkh, eparis, Serge E. Hallyn
In-Reply-To: <14652.1319014868@redhat.com>

A few modules are using cap_raised(current_cap(), cap) to authorize
actions.  This means that tasks which are privileged in non-initial
user namespaces will be deemed privileged.  The privilege should only
be granted if the task is in the initial user namespace.

Switching the calls to capable() would change the behavior - it would
cause the LSM capable hooks to be called, and set PF_SUPERPRIV if
the capability was used.  So instead, put in an explicit check and
refuse privilege if the caller is not in init_user_ns.

Changelog:
Oct 23: Use a nice macro to make the code shorter and easier to read,
	per advice from Andrew Morgan and David Howells.

Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Andrew Morgan <morgan@kernel.org>
Cc: Vasiliy Kulikov <segoon@openwall.com>
Cc: David Howells <dhowells@redhat.com>
---
 drivers/block/drbd/drbd_nl.c           |    2 +-
 drivers/md/dm-log-userspace-transfer.c |    2 +-
 drivers/staging/pohmelfs/config.c      |    2 +-
 drivers/video/uvesafb.c                |    2 +-
 include/linux/cred.h                   |    2 ++
 5 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index 0feab26..f799b15 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -2297,7 +2297,7 @@ static void drbd_connector_callback(struct cn_msg *req, struct netlink_skb_parms
 		return;
 	}
 
-	if (!cap_raised(current_cap(), CAP_SYS_ADMIN)) {
+	if (!IN_ROOT_USER_NS() || !cap_raised(current_cap(), CAP_SYS_ADMIN)) {
 		retcode = ERR_PERM;
 		goto fail;
 	}
diff --git a/drivers/md/dm-log-userspace-transfer.c b/drivers/md/dm-log-userspace-transfer.c
index 1f23e04..126a79b 100644
--- a/drivers/md/dm-log-userspace-transfer.c
+++ b/drivers/md/dm-log-userspace-transfer.c
@@ -134,7 +134,7 @@ static void cn_ulog_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp)
 {
 	struct dm_ulog_request *tfr = (struct dm_ulog_request *)(msg + 1);
 
-	if (!cap_raised(current_cap(), CAP_SYS_ADMIN))
+	if (!IN_ROOT_USER_NS() || !cap_raised(current_cap(), CAP_SYS_ADMIN))
 		return;
 
 	spin_lock(&receiving_list_lock);
diff --git a/drivers/staging/pohmelfs/config.c b/drivers/staging/pohmelfs/config.c
index b6c42cb..327c047 100644
--- a/drivers/staging/pohmelfs/config.c
+++ b/drivers/staging/pohmelfs/config.c
@@ -525,7 +525,7 @@ static void pohmelfs_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *n
 {
 	int err;
 
-	if (!cap_raised(current_cap(), CAP_SYS_ADMIN))
+	if (!IN_ROOT_USER_NS() || !cap_raised(current_cap(), CAP_SYS_ADMIN))
 		return;
 
 	switch (msg->flags) {
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 7f8472c..94e0e9d 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -73,7 +73,7 @@ static void uvesafb_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *ns
 	struct uvesafb_task *utask;
 	struct uvesafb_ktask *task;
 
-	if (!cap_raised(current_cap(), CAP_SYS_ADMIN))
+	if (!IN_ROOT_USER_NS() || !cap_raised(current_cap(), CAP_SYS_ADMIN))
 		return;
 
 	if (msg->seq >= UVESAFB_TASKS_MAX)
diff --git a/include/linux/cred.h b/include/linux/cred.h
index 4030896..2f75da7 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -359,9 +359,11 @@ static inline void put_cred(const struct cred *_cred)
 
 #ifdef CONFIG_USER_NS
 #define current_user_ns() (current_cred_xxx(user_ns))
+#define IN_ROOT_USER_NS() (current_user_ns() == &init_user_ns)
 #else
 extern struct user_namespace init_user_ns;
 #define current_user_ns() (&init_user_ns)
+#define IN_ROOT_USER_NS() (1)
 #endif
 
 
-- 
1.7.5.4


^ permalink raw reply related
* Re: 3.0.4 kernel oops in i2c ?
From: Hermann Lauer @ 2011-10-24 14:43 UTC (permalink / raw)
  To: sparclinux
In-Reply-To: <20111014144345.GB5070@lemon.iwr.uni-heidelberg.de>

On Mon, Oct 24, 2011 at 03:26:56PM +0200, Josip Rodin wrote:
> On Fri, Oct 14, 2011 at 04:43:45PM +0200, Hermann Lauer wrote:
> > when starting 3.0.4 on a V880 a non fatal oops happens when loading
> > i2c stuff. Proably there is a problem with i2c on the machine,
> > as the rsc "env" cmd shows "E880_FSP: ERROR getting FP stats ---> 9"
> > errors. An old 2.6.26-2-sparc64-smp (Debian 2.6.26-26lenny2) kernel
> > produces no oops.
> 
> Can you try the stable Debian 2.6.32 kernel at least?
> 
> Anything that helps you reduce the amount of git bisect...

2.6.32-5-sparc64-smp (Debian 2.6.32-38) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Oct 3 09:43:44 UTC 2011

is starting fine without oops. Thanks for caring,

 Hermann

> 
> -- 
>      2. That which causes joy or happiness.
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: Hermann.Lauer@iwr.uni-heidelberg.de

^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:51 UTC (permalink / raw)
  To: Grant Likely
  Cc: Mark Brown, Rajendra Nayak, patches, tony, devicetree-discuss,
	linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024135950.GV8708@ponder.secretlab.ca>

On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> > > 
> > > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > > when calling regulator_register(regulator_desc, dev, ...) from
> > > > regulator driver, the regulator core will be able to find all nodes under
> > > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> > > 
> > > Please provide concrete examples of the bindings you're talking about,
> > > the really important thing here is how sane the bindings look and I've
> > > really got no idea what any of what you're talking about will look like
> > > or if they make sense.
> > > 
> > The only thing different from what I attached last time is the
> > compatible string added to 'regulators' node.
> > 
> >         ecspi@70010000 { /* ECSPI1 */
> >                 fsl,spi-num-chipselects = <2>;
> >                 cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> >                            <&gpio3 25 0>; /* GPIO4_25 */
> >                 status = "okay";
> > 
> >                 pmic: mc13892@0 {
> >                         #address-cells = <1>;
> >                         #size-cells = <0>;
> >                         compatible = "fsl,mc13892";
> >                         spi-max-frequency = <6000000>;
> >                         reg = <0>;
> >                         mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
> > 
> >                         regulators {
> >                         	compatible = "fsl,mc13892-regulator";
> > 
> >                                 sw1reg: mc13892_sw1 {
> >                                         regulator-min-uV = <600000>;
> >                                         regulator-max-uV = <1375000>;
> >                                         regulator-change-voltage;
> >                                         regulator-boot-on;
> >                                         regulator-always-on;
> >                                 };
> > 
> >                                 sw2reg: mc13892_sw2 {
> >                                         regulator-min-uV = <900000>;
> >                                         regulator-max-uV = <1850000>;
> >                                         regulator-change-voltage;
> >                                         regulator-boot-on;
> >                                         regulator-always-on;
> >                                 };
> > 
> >                                 ......
> >                         };
> > 
> >                         leds {
> >                                 ......
> >                         };
> > 
> >                         buttons {
> >                                 ......
> >                         };
> >                 };
> > 
> >                 flash: at45db321d@1 {
> >                         ......
> >                 };
> >         };
> > 
> > > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > > "fsl,mc13892-regulators").
> > > 
> > > It's not immediately obvious to me that having a binding for the
> > > regulators separately makes sense, it's not a usefully distinct device.
> > > 
> > Fair point.  Actually, I also hate to have the finding of node
> > 'regulators' plugged into regulator driver.  What about following
> > change to address Grant's concern on global device tree search?
> >  
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 8fe132d..29dcf90 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> >         BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> > 
> >         /* find device_node and attach it */
> > -       rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > +       rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > +                                                regulator_desc->name);
> 
> of_find_node_by_name() doesn't work that way.  The first argument is a
> starting point, but it doesn't restrict the search to children of a
> node.
> 
> for_each_child_of_node() is what you want to use when iterating over
> the children which unfortunately changes the structure of this
> function.
> 
The dev->parent->of_node is meant to point to node 'pmic: mc13892@0'.
And the intention here is not to iterate over the children, but to
start a search from a reasonable point rather than the top root node.

-- 
Regards,
Shawn


^ permalink raw reply
* Re: [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:42 UTC (permalink / raw)
  To: Grant Likely
  Cc: Rob Herring, devicetree-discuss, Jean-Christophe PLAGNIOL-VILLARD,
	linux-kernel, linux-arm-kernel
In-Reply-To: <20111024143451.GA8708@ponder.secretlab.ca>

On 10/24/2011 04:34 PM, Grant Likely :
> On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
>> On 10/07/2011 02:56 PM, Nicolas Ferre :
>>> On 10/05/2011 03:00 PM, Rob Herring :
>>>> Nicolas,
>>>>
>>>> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
>>>>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>>>>> The Evaluation Kit at91sam9m10g45ek includes it.
>>>>> This first basic support will be populated as drivers and boards will be
>>>>> converted to device tree.
>>>>> Contains serial, dma and interrupt controllers.
>>>>>
>>>>> The generic board file still takes advantage of platform data for early serial
>>>>> init. As we need a storage media and the NAND flash driver is not converted to
>>>>> DT yet, we keep old initialization for it.
>>>>>
>>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>
>> [..]
>>
>>>>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
>>>>> new file mode 100644
>>>>> index 0000000..7bcb9a9
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-at91/board-dt.c
>>>>> @@ -0,0 +1,122 @@
>>>>> +/*
>>>>> + *  Setup code for AT91SAM Evaluation Kits with Device Tree support
>>>>> + *
>>>>> + *  Covers: * AT91SAM9G45-EKES  board
>>>>> + *          * AT91SAM9M10-EKES  board
>>>>> + *          * AT91SAM9M10G45-EK board
>>>>> + *
>>>>> + *  Copyright (C) 2011 Atmel,
>>>>> + *                2011 Nicolas Ferre <nicolas.ferre@atmel.com>
>>>>> + *
>>>>> + * Licensed under GPLv2 or later.
>>>>> + */
>>>>> +
>>>>> +#include <linux/types.h>
>>>>> +#include <linux/init.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/irqdomain.h>
>>>>> +#include <linux/of_irq.h>
>>>>> +#include <linux/of_platform.h>
>>>>> +
>>>>> +#include <mach/hardware.h>
>>>>> +#include <mach/board.h>
>>>>> +#include <mach/gpio.h>
>>>>> +#include <mach/system_rev.h>
>>>>> +#include <mach/at91sam9_smc.h>
>>>>> +
>>>>> +#include <asm/setup.h>
>>>>> +#include <asm/irq.h>
>>>>> +#include <asm/mach/arch.h>
>>>>> +#include <asm/mach/map.h>
>>>>> +#include <asm/mach/irq.h>
>>>>> +
>>>>> +#include "sam9_smc.h"
>>>>> +#include "generic.h"
>>
>> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
>>
>> +/*
>> + * Lookup table for attaching a specific name and platform_data pointer to
>> + * devices as they get created by of_platform_populate(). Ideally this table
>> + * would not exist, but the current clock implementation depends on some devices
>> + * having a specific name.
>> + /
>> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
>> + / at91sam9260/ at91sam9g20 /
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
>> + / at91sam9g45*/
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
>> + { /* sentinel */ }
>> +};
>>
>> With a change here:
>>   of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
>>
>> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?
> 
> yes.

Grant,

It seems that Rob has had another idea. He advices me (on a Oct. 20th
email) that I should add some clock lookup entries.
That is what I did in a couple of patches that I have just sent some
minutes ago... I tend to like the clock lookup adding more as it prevent
the adding of big amount of code into the board-dt.c file.

What is the preferred option? Are you fine with patches that I have just
sent?

Thanks,

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply
* Re: [xen-unstable bisection] complete test-i386-i386-pair
From: Ian Jackson @ 2011-10-24 14:42 UTC (permalink / raw)
  To: xen-devel@lists.xensource.com, Keir (Xen.org), Stefano Stabellini
In-Reply-To: <E1RIL73-0004qU-9L@woking.xci-test.com>

xen.org writes ("[xen-unstable bisection] complete test-i386-i386-pair"):
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  1c8789852eaf
>   Bug not present: 8269826353d8
> 
> 
>   changeset:   23990:1c8789852eaf
>   user:        Jan Beulich <jbeulich@suse.com>
>   date:        Fri Oct 21 09:44:47 2011 +0200
>       
>       x86/hpet: allocate CPU masks dynamically
>       
>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>       Acked-by: Keir Fraser <keir@xen.org>

Looking at the log, it seems that both the source and destination host
for the migration test crashed.

http://www.chiark.greenend.org.uk/~xensrcts/logs/9471/test-i386-i386-pair/info.html

Oct 23 01:36:23.433334 (XEN) ----[ Xen-4.2-unstable  x86_32p  debug=y  Not tainted ]----
Oct 23 01:36:44.057278 (XEN) CPU:    0
Oct 23 01:36:44.057308 (XEN) EIP:    e008:[<ff146151>] __find_first_bit+0x1d/0x3c
Oct 23 01:36:44.069240 (XEN) EFLAGS: 00010246   CONTEXT: hypervisor
Oct 23 01:36:44.069273 (XEN) eax: 00000000   ebx: 00000000   ecx: 00000001   edx: 00000045
Oct 23 01:36:44.077245 (XEN) esi: ff2180e0   edi: 00000000   ebp: ff253e34   esp: ff253e2c
Oct 23 01:36:44.077282 (XEN) cr0: 8005003b   cr4: 000426f0   cr3: 00bdf220   cr2: 00000000
Oct 23 01:36:44.089247 (XEN) ds: e010   es: e010   fs: 00d8   gs: 0000   ss: e010   cs: e008
Oct 23 01:36:44.097240 (XEN) Xen stack trace from esp=ff253e2c:
Oct 23 01:36:44.097271 (XEN)    00000002 ffbe4080 ff253e94 ff17fccc 00000000 00000002 bbcbc1c2 00000045
Oct 23 01:36:44.109238 (XEN)    ff253fb0 ffbe4094 f3520d09 00000045 ff253ebc ff11649d ffbfdddc ff27f180
Oct 23 01:36:44.109278 (XEN)    00000000 00000000 00000000 00000000 00989680 ff27fa80 bbcbc1c2 00000000
Oct 23 01:36:44.117253 (XEN)    ff2180e0 ff290080 ff253eb4 ff17f3e5 ffbe4080 ff14539a ff29d000 ff253f58
Oct 23 01:36:44.129244 (XEN)    00000002 ff253ebc ff253ee4 ff1695e0 ff290080 ff290080 ff253ee4 ff14fff5
Oct 23 01:36:44.129284 (XEN)    ff290080 00000000 00000082 ff253ee4 00000000 ff2180e0 ff253f54 ff154841
Oct 23 01:36:44.137258 (XEN)    00000000 00000000 ff253f60 00000045 00000000 ffbdf000 0000001d ff27f020
Oct 23 01:36:44.149240 (XEN)    ffbdf0c8 ff27f100 f30ab8f7 ff290094 00000000 00000000 00000000 ffbd9a80
Oct 23 01:36:44.157243 (XEN)    ff27f100 ff264200 ffffffff ff253fb0 ff253f7c ff120011 00000000 ff253fb0
Oct 23 01:36:44.157281 (XEN)    0000e010 0000e010 00dac08b ff14cf86 ff253f60 ff253fb0 ff27f100 00000000
Oct 23 01:36:44.169273 (XEN)    ff253fb0 ffffffff ff253f8c ff27f080 00f00000 ff14915d 0000e008 00000246
Oct 23 01:36:44.177260 (XEN)    ff253fac ff14ab2c ff253fb8 ff253fa8 ff120083 deadbeef ff29d000 ffbdf000
Oct 23 01:36:44.177301 (XEN)    ff253e38 deadbeef deadbeef 00000000 00000000 c166d350 c1663f94 00000000
Oct 23 01:36:44.189249 (XEN)    00f90000 c10023a7 00000061 00000246 c1663f84 00000069 0000007b 0000007b
Oct 23 01:36:44.197254 (XEN)    000000d8 00000000 00000000 ff29d000 00000000
Oct 23 01:36:44.197285 (XEN) Xen call trace:
Oct 23 01:36:44.209234 (XEN)    [<ff146151>] __find_first_bit+0x1d/0x3c
Oct 23 01:36:44.209267 (XEN)    [<ff17fccc>] handle_hpet_broadcast+0x87/0x263
Oct 23 01:36:44.217247 (XEN)    [<ff17f3e5>] hpet_legacy_irq_tick+0x37/0x45
Oct 23 01:36:44.217281 (XEN)    [<ff1695e0>] timer_interrupt+0x23/0x194
Oct 23 01:36:44.217314 (XEN)    [<ff154841>] do_IRQ+0x4c8/0x573
Oct 23 01:36:44.229241 (XEN)    [<ff14cf86>] common_interrupt+0x56/0x60
Oct 23 01:36:44.229274 (XEN)    [<ff14915d>] default_idle+0x5f/0x64
Oct 23 01:36:44.237248 (XEN)    [<ff14ab2c>] idle_loop+0x41/0x51
Oct 23 01:36:44.237280 (XEN)    
Oct 23 01:36:44.237302 (XEN) Pagetable walk from 00000000:
Oct 23 01:36:44.237334 (XEN)  L3[0x000] = 0000000123a91001 0001bf95
Oct 23 01:36:44.249238 (XEN)  L2[0x000] = 0000000000000000 ffffffff 
Oct 23 01:36:44.249269 (XEN) 
Oct 23 01:36:44.249290 (XEN) ****************************************
Oct 23 01:36:44.257243 (XEN) Panic on CPU 0:
Oct 23 01:36:44.257269 (XEN) FATAL PAGE FAULT
Oct 23 01:36:44.257294 (XEN) [error_code=0000]
Oct 23 01:36:44.257325 (XEN) Faulting linear address: 00000000
Oct 23 01:36:44.269239 (XEN) ****************************************
Oct 23 01:36:44.269269 (XEN) 
Oct 23 01:36:44.269290 (XEN) Reboot in five seconds...

^ permalink raw reply
* Re: [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:42 UTC (permalink / raw)
  To: Grant Likely
  Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20111024143451.GA8708-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>

On 10/24/2011 04:34 PM, Grant Likely :
> On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
>> On 10/07/2011 02:56 PM, Nicolas Ferre :
>>> On 10/05/2011 03:00 PM, Rob Herring :
>>>> Nicolas,
>>>>
>>>> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
>>>>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>>>>> The Evaluation Kit at91sam9m10g45ek includes it.
>>>>> This first basic support will be populated as drivers and boards will be
>>>>> converted to device tree.
>>>>> Contains serial, dma and interrupt controllers.
>>>>>
>>>>> The generic board file still takes advantage of platform data for early serial
>>>>> init. As we need a storage media and the NAND flash driver is not converted to
>>>>> DT yet, we keep old initialization for it.
>>>>>
>>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>>
>> [..]
>>
>>>>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
>>>>> new file mode 100644
>>>>> index 0000000..7bcb9a9
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-at91/board-dt.c
>>>>> @@ -0,0 +1,122 @@
>>>>> +/*
>>>>> + *  Setup code for AT91SAM Evaluation Kits with Device Tree support
>>>>> + *
>>>>> + *  Covers: * AT91SAM9G45-EKES  board
>>>>> + *          * AT91SAM9M10-EKES  board
>>>>> + *          * AT91SAM9M10G45-EK board
>>>>> + *
>>>>> + *  Copyright (C) 2011 Atmel,
>>>>> + *                2011 Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>>>>> + *
>>>>> + * Licensed under GPLv2 or later.
>>>>> + */
>>>>> +
>>>>> +#include <linux/types.h>
>>>>> +#include <linux/init.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/irqdomain.h>
>>>>> +#include <linux/of_irq.h>
>>>>> +#include <linux/of_platform.h>
>>>>> +
>>>>> +#include <mach/hardware.h>
>>>>> +#include <mach/board.h>
>>>>> +#include <mach/gpio.h>
>>>>> +#include <mach/system_rev.h>
>>>>> +#include <mach/at91sam9_smc.h>
>>>>> +
>>>>> +#include <asm/setup.h>
>>>>> +#include <asm/irq.h>
>>>>> +#include <asm/mach/arch.h>
>>>>> +#include <asm/mach/map.h>
>>>>> +#include <asm/mach/irq.h>
>>>>> +
>>>>> +#include "sam9_smc.h"
>>>>> +#include "generic.h"
>>
>> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
>>
>> +/*
>> + * Lookup table for attaching a specific name and platform_data pointer to
>> + * devices as they get created by of_platform_populate(). Ideally this table
>> + * would not exist, but the current clock implementation depends on some devices
>> + * having a specific name.
>> + /
>> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
>> + / at91sam9260/ at91sam9g20 /
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
>> + / at91sam9g45*/
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
>> + { /* sentinel */ }
>> +};
>>
>> With a change here:
>>   of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
>>
>> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?
> 
> yes.

Grant,

It seems that Rob has had another idea. He advices me (on a Oct. 20th
email) that I should add some clock lookup entries.
That is what I did in a couple of patches that I have just sent some
minutes ago... I tend to like the clock lookup adding more as it prevent
the adding of big amount of code into the board-dt.c file.

What is the preferred option? Are you fine with patches that I have just
sent?

Thanks,

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply
* [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20111024143451.GA8708@ponder.secretlab.ca>

On 10/24/2011 04:34 PM, Grant Likely :
> On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
>> On 10/07/2011 02:56 PM, Nicolas Ferre :
>>> On 10/05/2011 03:00 PM, Rob Herring :
>>>> Nicolas,
>>>>
>>>> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
>>>>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>>>>> The Evaluation Kit at91sam9m10g45ek includes it.
>>>>> This first basic support will be populated as drivers and boards will be
>>>>> converted to device tree.
>>>>> Contains serial, dma and interrupt controllers.
>>>>>
>>>>> The generic board file still takes advantage of platform data for early serial
>>>>> init. As we need a storage media and the NAND flash driver is not converted to
>>>>> DT yet, we keep old initialization for it.
>>>>>
>>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>
>> [..]
>>
>>>>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
>>>>> new file mode 100644
>>>>> index 0000000..7bcb9a9
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-at91/board-dt.c
>>>>> @@ -0,0 +1,122 @@
>>>>> +/*
>>>>> + *  Setup code for AT91SAM Evaluation Kits with Device Tree support
>>>>> + *
>>>>> + *  Covers: * AT91SAM9G45-EKES  board
>>>>> + *          * AT91SAM9M10-EKES  board
>>>>> + *          * AT91SAM9M10G45-EK board
>>>>> + *
>>>>> + *  Copyright (C) 2011 Atmel,
>>>>> + *                2011 Nicolas Ferre <nicolas.ferre@atmel.com>
>>>>> + *
>>>>> + * Licensed under GPLv2 or later.
>>>>> + */
>>>>> +
>>>>> +#include <linux/types.h>
>>>>> +#include <linux/init.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/irqdomain.h>
>>>>> +#include <linux/of_irq.h>
>>>>> +#include <linux/of_platform.h>
>>>>> +
>>>>> +#include <mach/hardware.h>
>>>>> +#include <mach/board.h>
>>>>> +#include <mach/gpio.h>
>>>>> +#include <mach/system_rev.h>
>>>>> +#include <mach/at91sam9_smc.h>
>>>>> +
>>>>> +#include <asm/setup.h>
>>>>> +#include <asm/irq.h>
>>>>> +#include <asm/mach/arch.h>
>>>>> +#include <asm/mach/map.h>
>>>>> +#include <asm/mach/irq.h>
>>>>> +
>>>>> +#include "sam9_smc.h"
>>>>> +#include "generic.h"
>>
>> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
>>
>> +/*
>> + * Lookup table for attaching a specific name and platform_data pointer to
>> + * devices as they get created by of_platform_populate(). Ideally this table
>> + * would not exist, but the current clock implementation depends on some devices
>> + * having a specific name.
>> + /
>> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
>> + / at91sam9260/ at91sam9g20 /
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
>> + / at91sam9g45*/
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
>> + { /* sentinel */ }
>> +};
>>
>> With a change here:
>>   of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
>>
>> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?
> 
> yes.

Grant,

It seems that Rob has had another idea. He advices me (on a Oct. 20th
email) that I should add some clock lookup entries.
That is what I did in a couple of patches that I have just sent some
minutes ago... I tend to like the clock lookup adding more as it prevent
the adding of big amount of code into the board-dt.c file.

What is the preferred option? Are you fine with patches that I have just
sent?

Thanks,

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply
* Re: fedora 16,64bit,8192drive
From: Larry Finger @ 2011-10-24 14:42 UTC (permalink / raw)
  To: 韩刚; +Cc: wireless
In-Reply-To: <CAC8FjyFZVrZRqyO3eYANH6yaaRgopd==mqHvF6hDiO2ABOA-9Q@mail.gmail.com>

On 10/24/2011 09:33 AM, 韩刚 wrote:
> Dear Larry Finger !
> Thank you for your reply!
> You can sen that,I downloaded the sources ,it's 
> 92ce_se_de_linux_mac80211_0004.0816.2011.tar.gz , extract the tar ,and used the 
> terminal,cd it,made,it error,the information what gave you in the last email.
> which step had error,as you knew that I had installed the 
> kernel,kernel-devel,kernel-headers,and so on.
> How to fix it,from the information which I gave you last mail,it's the format of 
> variable,I tried to fix it,failed.
> So,where are you means the diver or firmware ,or the compat-wireless package?
> I just first use the 64bit's linux,problems are too many to usual to use it!

The driver from the Realtek web site is not different from the one in the
kernel. If you are having problems with it, then you need to document them. In
addition, do not drop any of the Cc's. I only do private debugging when I have a
contract.

Larry



^ permalink raw reply
* Re: [Intel-gfx] [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there
From: Eugeni Dodonov @ 2011-10-24 14:40 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Michael Buesch, dri-devel
In-Reply-To: <20111020143339.59270702@endymion.delvare>


[-- Attachment #1.1: Type: text/plain, Size: 4071 bytes --]

On Thu, Oct 20, 2011 at 10:33, Jean Delvare <khali@linux-fr.org> wrote:

> Just to clarify: by "connectivity is setup", do you mean code in the
> driver setting the GPIO pin direction etc., or a display being
> connected to the graphics card?
>
> I admit I am a little surprised. I2C buses should have their lines up
> by default, thanks to pull-up resistors, and masters and slaves should
> merely drive the lines low as needed. The absence of slaves should have
> no impact on the line behavior. If the Intel graphics chips (or the
> driver) rely on the display to hold the lines high, I'd say this is a
> seriously broken design.
>
> As a side note, I thought that HDMI had the capability of presence
> detection, so there may be a better way to know if a display is
> connected or not, and this information could used to dynamically
> instantiate and delete the I2C buses? That way we could skip probing
> for EDID when there is no chance of success.
>

Yes, I think so too.

I admit I haven't got to the root of the problem here. My test was really
simple, borrowed from the test_bus() at i2c-algo-bit.c - without HDMI cable
plugged in, I was getting the "SDA stuck high" messages; with the cable
plugged in, I wasn't getting any of those.

But in any case, I haven't investigated it deeper in the hardware direction
after figuring out that drm_get_edid would retry its attempts for retreiving
the edid for 15 times, getting the -ENXIO error for all of them.


> Well, you could always do manual line testing of the I2C bus _before_
> calling drm_do_probe_ddc_edid()? And skip the call if the test fails
> (i.e. the bus isn't ready for use.) As said before, I am willing to
> export bit_test if it helps any. I've attached a patch doing exactly
> this. Let me know if you want me to commit it.
>

Yes, surely, I can do this. I did a similar test in the i915-specific patch,
checking if we can talk to i2c adapter pior to call drm_do_probe_ddc_edid,
but I thought that perhaps it would be easier for all the cards relying on
drm_get_edid to have a faster return path in case of problems.

I am fine with any solution, if this problem is happening to appear on i915
cards only, we could do this in our driver. It is that 15 attempts looks a
bit overkill.


> Your proposed patch is better than I first thought. I had forgotten
> that i2c-algo-bit tries up to 3 times to get a first ack from a slave.
> So if i2c_transfer returns -ENXIO, this means that i2c-algo-bit has
> already attempted 3 times to contact the slave, with no reply, so
> there's probably no point going on. A communication problem with a
> present slave would have returned a different error code.
>
> Without your patch, a missing slave would cause 3 * 5 = 15 retries,
> which is definitely too much.
>
> That being said, even then the whole probe sequence shouldn't exceed
> 10 ms, which I wouldn't expect a user to notice. The user-reported 4
> second delay when running xrandr can't be caused by this. 4 seconds for
> 15 attempts is 250 ms per attempt, this looks like a timeout due to
> non-functional bus, not a nack. Not that 250 ms is 1 jiffy for HZ=250,
> which I guess was what the reporting user was running. So even with
> your patch, there's still 750 ms to wait, I don't think this is
> acceptable. You really have to fix that I2C bus or skip probing it.
>

Yep, true. I've followed the easiest route so far - find out where the
initial problem happens, and attempt at solving it. This change in
drm_get_edid solves the delay at its origin, but we certainly could have
additional delays propagated somewhere else. I couldn't reproduce the
original reporter's huge delay, so I looked at what was within my reach.

In any case - looking at a faster way to leave the drm_do_probe_ddc_edid,
while also allowing a way for having a more detailed probing - would it be
an acceptable solution to add a:

MODULE_PARM(skip_unresponsive_edid, "Ignore outputs which do not provide
edid on first attempt");

and update the patch to use this option?

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>

[-- Attachment #1.2: Type: text/html, Size: 4966 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: Grant Likely, Rajendra Nayak, patches, tony, devicetree-discuss,
	linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024134930.GD26033@opensource.wolfsonmicro.com>

On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> 
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> >         BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> > 
> >         /* find device_node and attach it */
> > -       rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > +       rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > +                                                regulator_desc->name);
> > 
> 
> Is that going to do the right thing if you've got a MFD which does
> register each regulator as a separate device?

Based on my understanding, 1:1 is just a special case of N:1.  I
failed to see any problem having it work with registering each
regulator as a separate device.

> Might be best to just
> search within dev and get drivers to pass the "real" device in when
> registering the regulator rather than the virtual device.
> 
It should also work, but it will also change the API slightly for
non-dt users.  I'm not sure it's something we want.

-- 
Regards,
Shawn


^ permalink raw reply
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.