* [PATCH] mmc: mmc_spi: Fix return value evaluation of irq_of_parse_and_map()
From: Roland Stigge @ 2013-01-30 17:05 UTC (permalink / raw)
To: linux-arm-kernel
When irq_of_parse_and_map() returns an error, it does as zero. But in
mmc_spi_get_pdata(), the error return case is compared against NO_IRQ. This
might work where NO_IRQ is zero (defaults to zero when undefined, as on MIPS)
but not where NO_IRQ is sth. different, e.g. on ARM, where it is -1.
This patch changes to comparison with 0 which is the error return value of
irq_of_parse_and_map().
Tested on ARM that mmc_spi is working now.
Signed-off-by: Roland Stigge <stigge@antcom.de>
diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index 1534b58..d720b5e 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -146,7 +146,7 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct spi_device *spi)
oms->pdata.get_ro = of_mmc_spi_get_ro;
oms->detect_irq = irq_of_parse_and_map(np, 0);
- if (oms->detect_irq != NO_IRQ) {
+ if (oms->detect_irq != 0) {
oms->pdata.init = of_mmc_spi_init;
oms->pdata.exit = of_mmc_spi_exit;
} else {
^ permalink raw reply related
* [PATCH 1/1] pinctrl: nomadik: Rename Device Tree compatible string
From: Lee Jones @ 2013-01-30 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51094E50.4000302@wwwdotorg.org>
The preference is to use '-' instead of '_' in compatible strings.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 2 +-
arch/arm/mach-ux500/cpu-db8500.c | 2 +-
drivers/pinctrl/pinctrl-nomadik.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 3381ba6..b6256f3 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -171,7 +171,7 @@
};
pinctrl {
- compatible = "stericsson,nmk_pinctrl";
+ compatible = "stericsson,nmk-pinctrl";
prcm = <&prcmu>;
};
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 5b286e0..b80ad96 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -285,7 +285,7 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("st,nomadik-i2c", 0x80110000, "nmk-i2c.3", NULL),
OF_DEV_AUXDATA("st,nomadik-i2c", 0x8012a000, "nmk-i2c.4", NULL),
/* Requires device name bindings. */
- OF_DEV_AUXDATA("stericsson,nmk_pinctrl", U8500_PRCMU_BASE,
+ OF_DEV_AUXDATA("stericsson,nmk-pinctrl", U8500_PRCMU_BASE,
"pinctrl-db8500", NULL),
/* Requires clock name and DMA bindings. */
OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80123000,
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index 4954302..2081931 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -1847,7 +1847,7 @@ static struct pinctrl_desc nmk_pinctrl_desc = {
static const struct of_device_id nmk_pinctrl_match[] = {
{
- .compatible = "stericsson,nmk_pinctrl",
+ .compatible = "stericsson,nmk-pinctrl",
.data = (void *)PINCTRL_NMK_DB8500,
},
{},
--
1.7.9.5
^ permalink raw reply related
* OMAP4 PM bootloader dependency problems
From: Paul Walmsley @ 2013-01-30 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301220229140.25789@utopia.booyaka.com>
Hi Tero et al.,
On Tue, 22 Jan 2013, Paul Walmsley wrote:
> As we've discussed, there are known bootloader dependencies with the OMAP4
> PM retention idle code, introduced in v3.8. Boards booted with u-boot
> versions even as recent as 2011 won't enter retention idle correctly; for
> example:
>
> http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt
...
> Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds
> a warning, printed to the kernel console, during boot. The warning should
> state that the OMAP4 PM code only works with certain bootloaders, and
> should identify the minimum u-boot release needed for OMAP4 full-chip
> retention idle to work.
Any progress on this one? Time is getting very short to get this into
v3.8-rc fixes, and it's important to get this into v3.8 so we don't
have users expecting chip power management to work correctly with most
u-boot versions that are out in the field.
All we should need for v3.8-rc are a few pr_warn()s that execute during
OMAP4 PM init, noting that the OMAP4 chip power management doesn't work
correctly with many bootloaders, due to missing code in the kernel to
properly reset and initialize some devices, and noting the first u-boot
version that is known to work correctly.
Otherwise there's a very real risk that folks out there will waste lots of
time trying to figure out why power management doesn't work as they
expect. To respect our users, we shouldn't put them in that situation.
- Paul
^ permalink raw reply
* Commit 384a290283fde63ba8dc671fca5420111cdac19a seems to break 11MPCore boot
From: Russell King - ARM Linux @ 2013-01-30 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130164535.GN23505@n2100.arm.linux.org.uk>
On Wed, Jan 30, 2013 at 04:45:35PM +0000, Russell King - ARM Linux wrote:
> What we could do is scan interrupts 0-31 for a non-zero value. If they're
> all zero, we should complain. Otherwise, we use the first non-zero value
> we find and validate it for a single bit set.
And here's a patch to do this - I've not run this but it's just built
successfully here. Anyone want to give it a go?
I've decided that if we do hit the mask==0 case, we should just wail
loudly - panic'ing will bring the kernel to a halt right there and then,
which may be before any console drivers have been initialized (and the
kernel message buffer is no longer easy to read). Moreover, panic()ing,
along with the possibility of rebooting won't really fix this kind of
error - it's rather fatal as far as that goes. So, I think just wailing
at CRIT level is fine for this condition that should not occur.
arch/arm/common/gic.c | 23 +++++++++++++++++++++--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 36ae03a..3bcef49 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -351,6 +351,23 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
irq_set_chained_handler(irq, gic_handle_cascade_irq);
}
+static u8 gic_get_cpumask(struct gic_chip_data *gic)
+{
+ void __iomem *base = gic_data_dist_base(gic);
+ u8 mask, i;
+
+ for (i = mask = 0; i < 32; i++) {
+ mask = readl_relaxed(base + GIC_DIST_TARGET + i);
+ if (mask)
+ break;
+ }
+
+ if (!mask)
+ pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
+
+ return mask;
+}
+
static void __init gic_dist_init(struct gic_chip_data *gic)
{
unsigned int i;
@@ -369,7 +386,9 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
/*
* Set all global interrupts to this CPU only.
*/
- cpumask = readl_relaxed(base + GIC_DIST_TARGET + 0);
+ cpumask = gic_get_cpumask(gic);
+ cpumask |= cpumask << 8;
+ cpumask |= cpumask << 16;
for (i = 32; i < gic_irqs; i += 4)
writel_relaxed(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
@@ -400,7 +419,7 @@ static void __cpuinit gic_cpu_init(struct gic_chip_data *gic)
* Get what the GIC says our CPU mask is.
*/
BUG_ON(cpu >= NR_GIC_CPU_IF);
- cpu_mask = readl_relaxed(dist_base + GIC_DIST_TARGET + 0);
+ cpu_mask = gic_get_cpumask(gic);
gic_cpu_map[cpu] = cpu_mask;
/*
^ permalink raw reply related
* [PATCH] ARM: architected timers: allow dt based discovery using clocksource_of_init
From: Mark Rutland @ 2013-01-30 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122110456.GC18876@e106331-lin.cambridge.arm.com>
Thomas,
On Tue, Jan 22, 2013 at 11:04:56AM +0000, Mark Rutland wrote:
> On Mon, Jan 21, 2013 at 06:30:47PM +0000, Thomas Abraham wrote:
> > Hi Stephen,
> >
> > On 21 January 2013 09:21, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > > On 01/20/2013 06:22 PM, Thomas Abraham wrote:
> > >> Add an entry in __clksrc_of_table so that ARMv7 architected timer is
> > >> discoverable using call to clocksource_of_init.
> > >
> > >> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
> > >
> > >> +#ifdef CONFIG_CLKSRC_OF
> > >> +CLOCKSOURCE_OF_DECLARE(armv7_timer, "arm,armv7-timer", arch_timer_of_register)
> > >> +#endif
> > >
> > > I wonder if we shouldn't enhance include/linux/clocksource.h to define
> > > CLOCKSOURCE_OF_DECLARE even when !CONFIG_CLKSRC_OF; that way, drivers
> > > wouldn't need that ifdef.
> >
> > Yes, it will be helpful to have a !CONFIG_CLKSRC_OF version of
> > CLOCKSOURCE_OF_DECLARE. And can CONFIG_CLKSRC_OF be enabled by default
> > for all ARM platforms?
> >
> > Thanks,
> > Thomas.
>
> Thomas,
>
> Once the above is worked out, could you send me the updated patch with a
> pointer to whichever {branch,patch}(es) I need for CLKSRC_OF?
Is there any news on this? I'd like to be able to push out a branch ready for
merging soon.
I've also realised that platforms using of_clocksource_init won't get the
architected timer registered as a sched_clock, which would seem like a loss.
I'm not sure what the relative requirements are for sched_clock and
clocksource, so there may be some platforms that want it and some that don't.
I see for exynos5440 the architected timer is regsitered as a
clock{source,_event_device}, but not as a sched_clock, and omap5 is similar,
but may register dmtimer_read_sched_clock first.
We can probably leave it out for now, but it's something we'll need to consider
in future.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] Adding support for the new Armada XP evaluation board from Marvell
From: Gregory CLEMENT @ 2013-01-30 17:26 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This single patch add the dts support for new Armada XP evaluation
board from Marvell called DB-MV784MP-GP. I am a little annoyed because
on my board the Ethernet don't work under Linux (it works with
U-Boot). However Florian Fainelli had more chance with the same board
and managed to have a fully working Ethernet for the 4 ports. I would
not miss the 3.9 kernel just because of a hardware problem on my side.
As Simon Guinot have also the same board and is interested by running
a mainline Linux kernel on it, I hope he will be able to test it,
soon. If I get the tested-by from Florian and Simon, we can consider
that the support is OK, and it is my board which have a hardware
problem.
Thanks,
Gregory CLEMENT (1):
arm: mvebu: support for the new Armada XP evaluation
board(DB-MV784MP-GP)
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-xp-gp.dts | 94 ++++++++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
--
1.7.9.5
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Gregory CLEMENT @ 2013-01-30 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359566774-27669-1-git-send-email-gregory.clement@free-electrons.com>
This is the new Armada XP evaluation board from Marvell. It comes with
a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
Gigabit links.
Support for USB (Host and device), SDIO, PCIe will be added as drivers
when they become available for Armada XP in mainline.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-xp-gp.dts | 94 ++++++++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5ebb44f..51aab4b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-370-mirabox.dtb \
armada-xp-db.dtb \
+ armada-xp-gp.dtb \
armada-xp-openblocks-ax3-4.dtb
dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
new file mode 100644
index 0000000..85ba642
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -0,0 +1,94 @@
+/*
+ * Device Tree file for Marvell Armada XP evaluation board
+ * (RD-MV784MP-GP)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-xp-mv78460.dtsi"
+
+/ {
+ model = "Marvell Armada XP Evaluation Board: RD-MV784MP-GP";
+ compatible = "marvell,axp-db", "marvell,armadaxp-mv78460", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0xC0000000>; /* 3 GB */
+ };
+
+ soc {
+ serial at d0012000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012100 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012200 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012300 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+
+ sata at d00a0000 {
+ nr-ports = <2>;
+ status = "okay";
+ };
+
+ mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <16>;
+ };
+
+ phy1: ethernet-phy at 1 {
+ reg = <17>;
+ };
+
+ phy2: ethernet-phy at 2 {
+ reg = <18>;
+ };
+
+ phy3: ethernet-phy at 3 {
+ reg = <19>;
+ };
+ };
+
+ ethernet at d0070000 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0074000 {
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0030000 {
+ status = "okay";
+ phy = <&phy2>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0034000 {
+ status = "okay";
+ phy = <&phy3>;
+ phy-mode = "rgmii-id";
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 14/15] ARM: vexpress/dcscb: handle platform coherency exit/setup and CCI
From: Lorenzo Pieralisi @ 2013-01-30 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301291327340.6300@xanadu.home>
On Tue, Jan 29, 2013 at 06:42:33PM +0000, Nicolas Pitre wrote:
> On Tue, 29 Jan 2013, Lorenzo Pieralisi wrote:
>
> > On Tue, Jan 29, 2013 at 07:51:09AM +0000, Nicolas Pitre wrote:
> >
> > [...]
> >
> > > + /*
> > > + * Flush the local CPU cache.
> > > + *
> > > + * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
> > > + * a preliminary flush here for those CPUs. At least, that's
> > > + * the theory -- without the extra flush, Linux explodes on
> > > + * RTSM (maybe not needed anymore, to be investigated).
> > > + */
> > > + flush_cache_louis();
> >
> > This is not needed. If it is, that is a model bug and should be flagged
> > up as such.
>
> Could someone at ARM do that?
I will do that.
>
> I just confirmed that this is still the case by commenting out the
> preliminary flush calls and hot-plugging CPUs out and back. Result is a
> non-sensical kernel oops which has the looks of serious memory
> corruption. This is with RTSM version 7.1.42.
>
> > > + cpu_proc_fin(); /* disable allocation into internal caches*/
> >
> > This code disables the I-cache causing following instruction fetches from
> > DRAM; that is extremely slow and should be avoided, there is no point in
> > disabling the I-cache here, that is not required.
> > On fast-models that's a non-issue, but I really want to prevent copy'n'paste
> > of this sequence as it stands.
>
> Agreed, I'll change that. The (not included in this series) TC2 backend
> does leave the I-cache active already.
Great, thanks !!
Lorenzo
^ permalink raw reply
* [PATCH 1/1] pinctrl: nomadik: Rename Device Tree compatible string
From: Stephen Warren @ 2013-01-30 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130170750.GA5217@gmail.com>
On 01/30/2013 10:07 AM, Lee Jones wrote:
> The preference is to use '-' instead of '_' in compatible strings.
OK, this version seems complete. One issue here is that older device
trees now won't work with newer kernels since the driver's support of
the original compatible value is removed. DT is supposed to be backwards
compatible, but perhaps at this earlyish stage you don't care about this
on your platform yet?
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Florian Fainelli @ 2013-01-30 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359566774-27669-2-git-send-email-gregory.clement@free-electrons.com>
Hello Gregory,
On 01/30/2013 06:26 PM, Gregory CLEMENT wrote:
> This is the new Armada XP evaluation board from Marvell. It comes with
> a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
> Gigabit links.
>
> Support for USB (Host and device), SDIO, PCIe will be added as drivers
> when they become available for Armada XP in mainline.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/armada-xp-gp.dts | 94 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 95 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5ebb44f..51aab4b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> armada-370-mirabox.dtb \
> armada-xp-db.dtb \
> + armada-xp-gp.dtb \
> armada-xp-openblocks-ax3-4.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
> imx53-ard.dtb \
> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
> new file mode 100644
> index 0000000..85ba642
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
> @@ -0,0 +1,94 @@
> +/*
> + * Device Tree file for Marvell Armada XP evaluation board
> + * (RD-MV784MP-GP)
Marvell refers to this as a Reference Design (which it is because it is
boxed).
> + *
> + * Copyright (C) 2013 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +/include/ "armada-xp-mv78460.dtsi"
> +
> +/ {
> + model = "Marvell Armada XP Evaluation Board: RD-MV784MP-GP";
Ditto, should be "Marvell Armada XP Reference Design Board".
> + compatible = "marvell,axp-db", "marvell,armadaxp-mv78460", "marvell,armadaxp", "marvell,armada-370-xp";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200 earlyprintk";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0xC0000000>; /* 3 GB */
> + };
> +
> + soc {
> + serial at d0012000 {
> + clock-frequency = <250000000>;
> + status = "okay";
> + };
> + serial at d0012100 {
> + clock-frequency = <250000000>;
> + status = "okay";
> + };
> + serial at d0012200 {
> + clock-frequency = <250000000>;
> + status = "okay";
> + };
> + serial at d0012300 {
> + clock-frequency = <250000000>;
> + status = "okay";
> + };
> +
> + sata at d00a0000 {
> + nr-ports = <2>;
> + status = "okay";
> + };
> +
> + mdio {
> + phy0: ethernet-phy at 0 {
> + reg = <16>;
> + };
> +
> + phy1: ethernet-phy at 1 {
> + reg = <17>;
> + };
> +
> + phy2: ethernet-phy at 2 {
> + reg = <18>;
> + };
> +
> + phy3: ethernet-phy at 3 {
> + reg = <19>;
> + };
> + };
It seemed to me like the PHY addresses were 0 to 3, but I will test that
within the next few minutes.
--
Florian
^ permalink raw reply
* Commit 384a290283fde63ba8dc671fca5420111cdac19a seems to break 11MPCore boot
From: Nicolas Pitre @ 2013-01-30 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130171918.GO23505@n2100.arm.linux.org.uk>
On Wed, 30 Jan 2013, Russell King - ARM Linux wrote:
> On Wed, Jan 30, 2013 at 04:45:35PM +0000, Russell King - ARM Linux wrote:
> > What we could do is scan interrupts 0-31 for a non-zero value. If they're
> > all zero, we should complain. Otherwise, we use the first non-zero value
> > we find and validate it for a single bit set.
>
> And here's a patch to do this - I've not run this but it's just built
> successfully here. Anyone want to give it a go?
>
> I've decided that if we do hit the mask==0 case, we should just wail
> loudly - panic'ing will bring the kernel to a halt right there and then,
> which may be before any console drivers have been initialized (and the
> kernel message buffer is no longer easy to read). Moreover, panic()ing,
> along with the possibility of rebooting won't really fix this kind of
> error - it's rather fatal as far as that goes. So, I think just wailing
> at CRIT level is fine for this condition that should not occur.
>
> arch/arm/common/gic.c | 23 +++++++++++++++++++++--
> 1 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index 36ae03a..3bcef49 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -351,6 +351,23 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
> irq_set_chained_handler(irq, gic_handle_cascade_irq);
> }
>
> +static u8 gic_get_cpumask(struct gic_chip_data *gic)
> +{
> + void __iomem *base = gic_data_dist_base(gic);
> + u8 mask, i;
> +
> + for (i = mask = 0; i < 32; i++) {
> + mask = readl_relaxed(base + GIC_DIST_TARGET + i);
> + if (mask)
> + break;
> + }
That should probably be:
u32 mask;
for (i = 0; i < 32; i += 4) {
mask = readl_relaxed(base + GIC_DIST_TARGET + i);
mask |= (mask >> 16);
mask |= (mask >> 8);
if (mask)
return mask;
}
I know that the spec says that the GIC should accept byte sized
accesses, but that too is known not to work on all implementations.
Nicolas
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Jason Cooper @ 2013-01-30 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359566774-27669-2-git-send-email-gregory.clement@free-electrons.com>
On Wed, Jan 30, 2013 at 06:26:14PM +0100, Gregory CLEMENT wrote:
> This is the new Armada XP evaluation board from Marvell. It comes with
> a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
> Gigabit links.
>
> Support for USB (Host and device), SDIO, PCIe will be added as drivers
> when they become available for Armada XP in mainline.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/armada-xp-gp.dts | 94 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 95 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5ebb44f..51aab4b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> armada-370-mirabox.dtb \
> armada-xp-db.dtb \
> + armada-xp-gp.dtb \
> armada-xp-openblocks-ax3-4.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
> imx53-ard.dtb \
> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
> new file mode 100644
> index 0000000..85ba642
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
> @@ -0,0 +1,94 @@
> +/*
> + * Device Tree file for Marvell Armada XP evaluation board
> + * (RD-MV784MP-GP)
> + *
> + * Copyright (C) 2013 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +/include/ "armada-xp-mv78460.dtsi"
> +
> +/ {
> + model = "Marvell Armada XP Evaluation Board: RD-MV784MP-GP";
> + compatible = "marvell,axp-db", "marvell,armadaxp-mv78460", "marvell,armadaxp", "marvell,armada-370-xp";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200 earlyprintk";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0xC0000000>; /* 3 GB */
Is this the soldered on the board amount, or the amount with an
expandable slot filled?
thx,
Jason.
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Gregory CLEMENT @ 2013-01-30 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51095843.30107@openwrt.org>
On 01/30/2013 06:28 PM, Florian Fainelli wrote:
> Hello Gregory,
Hi Floran,
thanks for your quick feedback
>
> On 01/30/2013 06:26 PM, Gregory CLEMENT wrote:
>> This is the new Armada XP evaluation board from Marvell. It comes with
>> a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
>> Gigabit links.
>>
>> Support for USB (Host and device), SDIO, PCIe will be added as drivers
>> when they become available for Armada XP in mainline.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/armada-xp-gp.dts | 94 ++++++++++++++++++++++++++++++++++++
>> 2 files changed, 95 insertions(+)
>> create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 5ebb44f..51aab4b 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>> armada-370-mirabox.dtb \
>> armada-xp-db.dtb \
>> + armada-xp-gp.dtb \
>> armada-xp-openblocks-ax3-4.dtb
>> dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
>> imx53-ard.dtb \
>> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
>> new file mode 100644
>> index 0000000..85ba642
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Device Tree file for Marvell Armada XP evaluation board
>> + * (RD-MV784MP-GP)
>
> Marvell refers to this as a Reference Design (which it is because it is
> boxed).
OK I will change this
>
>> + *
>> + * Copyright (C) 2013 Marvell
>> + *
>> + * Lior Amsalem <alior@marvell.com>
>> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +/dts-v1/;
>> +/include/ "armada-xp-mv78460.dtsi"
>> +
>> +/ {
>> + model = "Marvell Armada XP Evaluation Board: RD-MV784MP-GP";
>
> Ditto, should be "Marvell Armada XP Reference Design Board".
I will change this too
>> + compatible = "marvell,axp-db", "marvell,armadaxp-mv78460", "marvell,armadaxp", "marvell,armada-370-xp";
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200 earlyprintk";
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0xC0000000>; /* 3 GB */
>> + };
>> +
>> + soc {
>> + serial at d0012000 {
>> + clock-frequency = <250000000>;
>> + status = "okay";
>> + };
>> + serial at d0012100 {
>> + clock-frequency = <250000000>;
>> + status = "okay";
>> + };
>> + serial at d0012200 {
>> + clock-frequency = <250000000>;
>> + status = "okay";
>> + };
>> + serial at d0012300 {
>> + clock-frequency = <250000000>;
>> + status = "okay";
>> + };
>> +
>> + sata at d00a0000 {
>> + nr-ports = <2>;
>> + status = "okay";
>> + };
>> +
>> + mdio {
>> + phy0: ethernet-phy at 0 {
>> + reg = <16>;
>> + };
>> +
>> + phy1: ethernet-phy at 1 {
>> + reg = <17>;
>> + };
>> +
>> + phy2: ethernet-phy at 2 {
>> + reg = <18>;
>> + };
>> +
>> + phy3: ethernet-phy at 3 {
>> + reg = <19>;
>> + };
>> + };
>
> It seemed to me like the PHY addresses were 0 to 3, but I will test that
> within the next few minutes.
I wait for your results
> --
> Florian
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Gregory CLEMENT @ 2013-01-30 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130173306.GO7717@titan.lakedaemon.net>
On 01/30/2013 06:33 PM, Jason Cooper wrote:
> On Wed, Jan 30, 2013 at 06:26:14PM +0100, Gregory CLEMENT wrote:
>> This is the new Armada XP evaluation board from Marvell. It comes with
>> a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
>> Gigabit links.
>>
>> Support for USB (Host and device), SDIO, PCIe will be added as drivers
>> when they become available for Armada XP in mainline.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/armada-xp-gp.dts | 94 ++++++++++++++++++++++++++++++++++++
>> 2 files changed, 95 insertions(+)
>> create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 5ebb44f..51aab4b 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>> armada-370-mirabox.dtb \
>> armada-xp-db.dtb \
>> + armada-xp-gp.dtb \
>> armada-xp-openblocks-ax3-4.dtb
>> dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
>> imx53-ard.dtb \
>> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
>> new file mode 100644
>> index 0000000..85ba642
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Device Tree file for Marvell Armada XP evaluation board
>> + * (RD-MV784MP-GP)
>> + *
>> + * Copyright (C) 2013 Marvell
>> + *
>> + * Lior Amsalem <alior@marvell.com>
>> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +/dts-v1/;
>> +/include/ "armada-xp-mv78460.dtsi"
>> +
>> +/ {
>> + model = "Marvell Armada XP Evaluation Board: RD-MV784MP-GP";
>> + compatible = "marvell,axp-db", "marvell,armadaxp-mv78460", "marvell,armadaxp", "marvell,armada-370-xp";
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200 earlyprintk";
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0xC0000000>; /* 3 GB */
>
> Is this the soldered on the board amount, or the amount with an
> expandable slot filled?
It is not soldered, so you can change the amount of memory
>
> thx,
>
> Jason.
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] at91: fixes for 3.8-rc6
From: Olof Johansson @ 2013-01-30 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108EA04.80002@atmel.com>
On Wed, Jan 30, 2013 at 1:38 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> git://github.com/at91linux/linux-at91.git tags/at91-fixes
Pulled, thanks.
-Olof
^ permalink raw reply
* [PATCH 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers
From: Jon Hunter @ 2013-01-30 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358522856-12180-8-git-send-email-santosh.shilimkar@ti.com>
On 01/18/2013 09:27 AM, Santosh Shilimkar wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> Add the clock tree related data for OMAP54xx platforms.
[snip]
> + CLK("omap_timer.1", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.2", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.3", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.4", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.5", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.6", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.7", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.8", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.9", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.10", "32k_ck", &sys_32k_ck, CK_54XX),
> + CLK("omap_timer.11", "32k_ck", &sys_32k_ck, CK_54XX),
I have been trying to get away from having so many aliases for the same
clock for timers. Here we should replace all of the above and just have ...
+ CLK(NULL, "timer_32k_ck", &sys_32k_ck, CK_54XX),
For more details see [1].
> + CLK("omap_timer.1", "sys_ck", &sys_clkin, CK_54XX),
> + CLK("omap_timer.2", "sys_ck", &sys_clkin, CK_54XX),
> + CLK("omap_timer.3", "sys_ck", &sys_clkin, CK_54XX),
> + CLK("omap_timer.4", "sys_ck", &sys_clkin, CK_54XX),
> + CLK("omap_timer.9", "sys_ck", &sys_clkin, CK_54XX),
> + CLK("omap_timer.10", "sys_ck", &sys_clkin, CK_54XX),
> + CLK("omap_timer.11", "sys_ck", &sys_clkin, CK_54XX),
> + CLK("omap_timer.5", "sys_ck", &dss_syc_gfclk_div, CK_54XX),
> + CLK("omap_timer.6", "sys_ck", &dss_syc_gfclk_div, CK_54XX),
> + CLK("omap_timer.7", "sys_ck", &dss_syc_gfclk_div, CK_54XX),
> + CLK("omap_timer.8", "sys_ck", &dss_syc_gfclk_div, CK_54XX),
> +};
These aliases will not work with device-tree because the device-name is
formatted <addr>.<device>. Hence, when configuring a the timer parent
clock via the dmtimer driver it will fail. So it should be more like ...
+ CLK("4ae18000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("48032000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("48034000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("48036000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("40138000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("4013a000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("4013c000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("4013e000.timer", "timer_sys_ck", &dss_syc_gfclk_div,
CK_54XX),
+ CLK("4803e000.timer", "timer_sys_ck", &dss_syc_gfclk_div, CK_54XX),
+ CLK("48086000.timer", "timer_sys_ck", &dss_syc_gfclk_div, CK_54XX),
+ CLK("48088000.timer", "timer_sys_ck", &dss_syc_gfclk_div, CK_54XX),
For more details see [2].
If you would like to test the dmtimer driver on omap5, then you can grab
my omap-test module [3], build it (see README), load it and then ...
# echo 1 > /sys/kernel/debug/omap-test/timer/all
This will perform some basic tests on all the dmtimers. I would do it
myself, but there appears to be several issues getting this to boot on
an ES1.0 (which is probably expected).
Cheers
Jon
[1] http://www.spinics.net/lists/linux-omap/msg71272.html
[2] https://patchwork.kernel.org/patch/1204351/
[3] https://github.com/jonhunter/omap-test
^ permalink raw reply
* [PATCH 2/5] ARM: OMAP2+: timer: Update the OMAP5 clocksource name as per clock data
From: Jon Hunter @ 2013-01-30 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358523141-12295-3-git-send-email-santosh.shilimkar@ti.com>
On 01/18/2013 09:32 AM, Santosh Shilimkar wrote:
> OMAP5 clockdata has different sys clock clock node name. Fix the timer code
> to take care of it.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/timer.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 691aa67..a0a1b14 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -62,6 +62,7 @@
> #define OMAP2_MPU_SOURCE "sys_ck"
> #define OMAP3_MPU_SOURCE OMAP2_MPU_SOURCE
> #define OMAP4_MPU_SOURCE "sys_clkin_ck"
> +#define OMAP5_MPU_SOURCE "sys_clkin"
I would like to remove this definitions and in fact posted a patch today
to do that [1] ;-)
> #define OMAP2_32K_SOURCE "func_32k_ck"
> #define OMAP3_32K_SOURCE "omap_32k_fck"
> #define OMAP4_32K_SOURCE "sys_32k_ck"
> @@ -498,7 +499,7 @@ static void __init realtime_counter_init(void)
> pr_err("%s: ioremap failed\n", __func__);
> return;
> }
> - sys_clk = clk_get(NULL, "sys_clkin_ck");
> + sys_clk = clk_get(NULL, OMAP5_MPU_SOURCE);
> if (IS_ERR(sys_clk)) {
> pr_err("%s: failed to get system clock handle\n", __func__);
> iounmap(base);
> @@ -638,7 +639,7 @@ OMAP_SYS_TIMER(4, local);
>
> #ifdef CONFIG_SOC_OMAP5
> OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
> - 2, OMAP4_MPU_SOURCE);
> + 2, OMAP5_MPU_SOURCE);
I am hoping we can remove this completely for omap5 and use the same
function defined for omap2 [2].
Care to try your series on top of mine [3] on omap5?
Cheers
Jon
[1] http://www.spinics.net/lists/arm-kernel/msg221263.html
[2] http://www.spinics.net/lists/arm-kernel/msg221264.html
[3] http://www.spinics.net/lists/arm-kernel/msg221260.html
^ permalink raw reply
* [PATCH v3 15/15] ARM: vexpress/dcscb: probe via device tree
From: Nicolas Pitre @ 2013-01-30 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpgmWA0CCSRYxSvA1rNDYLo_RD-UavmX7coBXVpC+HEwQaBFg@mail.gmail.com>
On Wed, 30 Jan 2013, Achin Gupta wrote:
> On Tue, Jan 29, 2013 at 9:41 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Tue, 29 Jan 2013, Rob Herring wrote:
> >
> >> On 01/29/2013 01:51 AM, Nicolas Pitre wrote:
> >> > + node = of_find_compatible_node(NULL, NULL, "arm,dcscb");
> >>
> >> This needs binding documentation and should be a more specific name. Not
> >> knowing what dcscb is, I don't have a suggestion.
> >
> > Yes, I mentioned in the cover page that DT bindings are not yet
> > documented.
> >
> > DCSCB stands for "Dual Cluster System Control Block". This is in fact a
> > set of miscellaneous registers, mainly for reset control of individual
> > CPUs and clusters.
> >
> >> Perhaps should include vexpress or specific core tile name it is part
> >> of.
> >
> > /me hopes for some ARM dude more acquainted with their nomenclature to
> > chime in with suggestions.
> >
>
> As nico said, the DCSCB is just a reset controller thats a part of the
> FastModels implementation. The implementation should be referred to as
> VE bL RTSM. The official name goes by:
>
> RTSM_VE_Cortex-A15x4-A7x4
> RTSM_VE_Cortex-A15x1-A7x1
>
> The file should be renamed as bL_rtsm.c or something similar.
I don't think the file name is a problem. Actually, going with
bL_rtsm.c is rather too generic for what itcovers.
It's the actual device tree binding name that I'd need suggestions for.
Nicolas
^ permalink raw reply
* [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
From: Jon Hunter @ 2013-01-30 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433ECF0B60@DBDE01.ent.ti.com>
On 01/21/2013 01:22 AM, Bedia, Vaibhav wrote:
> On Fri, Jan 18, 2013 at 10:55:43, Shilimkar, Santosh wrote:
>> On Friday 18 January 2013 12:15 AM, Jon Hunter wrote:
>>>
>>> On 01/10/2013 10:37 PM, Bedia, Vaibhav wrote:
>>>> On Tue, Jan 08, 2013 at 20:45:10, Shilimkar, Santosh wrote:
>>>>> On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
>>>>>> The current OMAP timer code registers two timers -
>>>>>> one as clocksource and one as clockevent.
>>>>>> AM33XX has only one usable timer in the WKUP domain
>>>>>> so one of the timers needs suspend-resume support
>>>>>> to restore the configuration to pre-suspend state.
>>>>>>
>>>>>> commit adc78e6 (timekeeping: Add suspend and resume
>>>>>> of clock event devices) introduced .suspend and .resume
>>>>>> callbacks for clock event devices. Leverages these
>>>>>> callbacks to have AM33XX clockevent timer which is
>>>>>> in not in WKUP domain to behave properly across system
>>>>>> suspend.
>>>>>>
>>>>>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
>>>>>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>>>> Cc: Benoit Cousson <b-cousson@ti.com>
>>>>>> Cc: Paul Walmsley <paul@pwsan.com>
>>>>>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>>>>>> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
>>>>>> Cc: Jon Hunter <jon-hunter@ti.com>
>>>>>> ---
>>>>>> v1->v2:
>>>>>> Get rid of harcoded timer id.
>>>>>> Note: since a platform device is not created for these timer
>>>>>> instances and because there's very minimal change needed for
>>>>>> restarting the timer a full blown context save and restore
>>>>>> has been skipped.
>>>>>>
>>>>>> arch/arm/mach-omap2/timer.c | 33 +++++++++++++++++++++++++++++++++
>>>>>> 1 files changed, 33 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>>>>> index 691aa67..38f9cbc 100644
>>>>>> --- a/arch/arm/mach-omap2/timer.c
>>>>>> +++ b/arch/arm/mach-omap2/timer.c
>>>>>> @@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> +static void omap_clkevt_suspend(struct clock_event_device *unused)
>>>>>> +{
>>>>>> + char name[10];
>>>>>> + struct omap_hwmod *oh;
>>>>>> +
>>>>>> + sprintf(name, "timer%d", clkev.id);
>>>>>> + oh = omap_hwmod_lookup(name);
>>>>>> + if (!oh)
>>>>>> + return;
>>>>>> +
>>>>>> + __omap_dm_timer_stop(&clkev, 1, clkev.rate);
>>>>>> + omap_hwmod_idle(oh);
>>>>>> +}
>>>>>> +
>>>>>> +static void omap_clkevt_resume(struct clock_event_device *unused)
>>>>>> +{
>>>>>> + char name[10];
>>>>>> + struct omap_hwmod *oh;
>>>>>> +
>>>>>> + sprintf(name, "timer%d", clkev.id);
>>>>>> + oh = omap_hwmod_lookup(name);
>>>>>> + if (!oh)
>>>>>> + return;
>>>>>> +
>>>>>> + omap_hwmod_enable(oh);
>>>>>> + __omap_dm_timer_load_start(&clkev,
>>>>>> + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
>>>>>> + __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
>>>>>> +}
>>>>>> +
>>>>> Am still bit uncomfortable with direct hwmod usage in the suspend/resmue
>>>>> hooks.
>>>>>
>>>>> Jon, Any alternatives you can think of ?
>>>>>
>>>>
>>>> Jon,
>>>>
>>>> Any suggestions here?
>>>
>>> Sorry completed this missed this!
>>>
>>> Unfortunately, I don't have any good suggestions here. However, I am
>>> wondering if the suspend/resume handlers can just be calls to
>>> omap_hwmod_idle/enable and we can remove these __omap_dm_timer_xxxx
>>> calls (I don't think they are needed). Furthermore, my understanding is
>>> this is only needed for AM335x (per the changelog), and so we should not
>>> add suspend/resume handlers for all OMAP2+ based devices.
>>>
>> I agree with the direction.
>>
>
> I need to retain the call to enable the interrupt but the others can be dropped.
> Will take care of this and the comment on invoking the suspend/resume handlers
> only for AM335x in the next version.
Ok fair enough. By the way, I posted a patch today [1] that will use the
hwmod name as the clockevent timer name. Care to try on top of that
patch and then we can eliminate the sprintf.
Cheers
Jon
[1] http://www.spinics.net/lists/arm-kernel/msg221262.html
^ permalink raw reply
* [RFC v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
From: Jon Hunter @ 2013-01-30 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5101B622.7050901@ti.com>
On 01/24/2013 04:30 PM, Jon Hunter wrote:
> Hi Vaibhav,
>
> On 12/31/2012 07:07 AM, Vaibhav Bedia wrote:
>> AM33XX has two timers (DTIMER0/1) in the WKUP domain.
>> On GP devices the source of DMTIMER0 is fixed to an
>> inaccurate internal 32k RC oscillator and this makes
>> the DMTIMER0 practically either as a clocksource or
>> as clockevent.
>>
>> Currently the timer instance in WKUP domain is used
>> as the clockevent and the timer in non-WKUP domain
>> as the clocksource. DMTIMER1 in WKUP domain can keep
>> running in suspend from a 32K clock fed from external
>> OSC and can serve as the persistent clock for the kernel.
>> To enable this, interchange the timers used as clocksource
>> and clockevent for AM33XX.
>
> I have been thinking about this some more. In the case where we are
> using gptimers for both clock-events and clock-source (on both AM33xx
> and OMAP) and I am wondering if it makes sense to switch the timers so
> that we use the always-on timer for clock-source and a different one
> from clock-events.
>
> For OMAP, if we are not using the 32k-sync for clock-source, then we are
> never going to achieve low power states during idle as we will always
> have one gptimer running. And in this case, to your point below, it
> would be better to use the always-on for clock-source so that in suspend
> we can at least hit low power states and maintain time.
I have posted a patch today [1] that I hope will address this issue for
you. Can you give that a try?
Cheers
Jon
[1] http://www.spinics.net/lists/arm-kernel/msg221265.html
^ permalink raw reply
* [PATCH] clocksource: always define CLOCKSOURCE_OF_DECLARE
From: Stephen Warren @ 2013-01-30 17:49 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
This allows clocksource drivers that support both DT and non-DT to
always invoke macro CLOCKSOURCE_OF_DECLARE(), rather than wrapping
it in a #ifdef CONFIG_CLKSRC_OF, which simplifies their code.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
Olof, Arnd, this is based on arm-soc's timer/cleanup branch, which is
probably the best place for this patch.
include/linux/clocksource.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 7944f14..27cfda4 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -339,6 +339,8 @@ extern void clocksource_of_init(void);
static const struct of_device_id __clksrc_of_table_##name \
__used __section(__clksrc_of_table) \
= { .compatible = compat, .data = fn };
+#else
+#define CLOCKSOURCE_OF_DECLARE(name, compat, fn)
#endif
#endif /* _LINUX_CLOCKSOURCE_H */
--
1.7.10.4
^ permalink raw reply related
* [RFC v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
From: Jon Hunter @ 2013-01-30 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51095CDA.9090701@ti.com>
On 01/30/2013 11:48 AM, Jon Hunter wrote:
>
> On 01/24/2013 04:30 PM, Jon Hunter wrote:
>> Hi Vaibhav,
>>
>> On 12/31/2012 07:07 AM, Vaibhav Bedia wrote:
>>> AM33XX has two timers (DTIMER0/1) in the WKUP domain.
>>> On GP devices the source of DMTIMER0 is fixed to an
>>> inaccurate internal 32k RC oscillator and this makes
>>> the DMTIMER0 practically either as a clocksource or
>>> as clockevent.
>>>
>>> Currently the timer instance in WKUP domain is used
>>> as the clockevent and the timer in non-WKUP domain
>>> as the clocksource. DMTIMER1 in WKUP domain can keep
>>> running in suspend from a 32K clock fed from external
>>> OSC and can serve as the persistent clock for the kernel.
>>> To enable this, interchange the timers used as clocksource
>>> and clockevent for AM33XX.
>>
>> I have been thinking about this some more. In the case where we are
>> using gptimers for both clock-events and clock-source (on both AM33xx
>> and OMAP) and I am wondering if it makes sense to switch the timers so
>> that we use the always-on timer for clock-source and a different one
>> from clock-events.
>>
>> For OMAP, if we are not using the 32k-sync for clock-source, then we are
>> never going to achieve low power states during idle as we will always
>> have one gptimer running. And in this case, to your point below, it
>> would be better to use the always-on for clock-source so that in suspend
>> we can at least hit low power states and maintain time.
>
> I have posted a patch today [1] that I hope will address this issue for
> you. Can you give that a try?
By the way, this need to be applied on top of the fix I sent yesterday
to pass the property.
Cheers
Jon
^ permalink raw reply
* [PATCH] ARM: architected timers: allow dt based discovery using clocksource_of_init
From: Stephen Warren @ 2013-01-30 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130171930.GA23801@e106331-lin.cambridge.arm.com>
On 01/30/2013 10:19 AM, Mark Rutland wrote:
> Thomas,
>
> On Tue, Jan 22, 2013 at 11:04:56AM +0000, Mark Rutland wrote:
>> On Mon, Jan 21, 2013 at 06:30:47PM +0000, Thomas Abraham wrote:
>>> Hi Stephen,
>>>
>>> On 21 January 2013 09:21, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 01/20/2013 06:22 PM, Thomas Abraham wrote:
>>>>> Add an entry in __clksrc_of_table so that ARMv7 architected timer is
>>>>> discoverable using call to clocksource_of_init.
>>>>
>>>>> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
>>>>
>>>>> +#ifdef CONFIG_CLKSRC_OF
>>>>> +CLOCKSOURCE_OF_DECLARE(armv7_timer, "arm,armv7-timer", arch_timer_of_register)
>>>>> +#endif
>>>>
>>>> I wonder if we shouldn't enhance include/linux/clocksource.h to define
>>>> CLOCKSOURCE_OF_DECLARE even when !CONFIG_CLKSRC_OF; that way, drivers
>>>> wouldn't need that ifdef.
>>>
>>> Yes, it will be helpful to have a !CONFIG_CLKSRC_OF version of
>>> CLOCKSOURCE_OF_DECLARE. And can CONFIG_CLKSRC_OF be enabled by default
>>> for all ARM platforms?
>>>
>>> Thanks,
>>> Thomas.
>>
>> Thomas,
>>
>> Once the above is worked out, could you send me the updated patch with a
>> pointer to whichever {branch,patch}(es) I need for CLKSRC_OF?
>
> Is there any news on this? I'd like to be able to push out a branch ready for
> merging soon.
I just sent a patch for this.
^ permalink raw reply
* [PATCH v4 4/7] ARM: Exynos: allow dt based discovery of mct controller using clocksource_of_init
From: Stephen Warren @ 2013-01-30 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106E645.70807@wwwdotorg.org>
On 01/28/2013 01:57 PM, Stephen Warren wrote:
> On 01/21/2013 03:02 AM, Thomas Abraham wrote:
>> Add entries to __clksrc_of_table so that Exynos MCT controller is discoverable
>> using call to clocksource_of_init. With this change, it would be appropriate to
>> rename the function 'exynos4_timer_init' as 'mct_init' since it aptly describes
>> this function. Additionally, the 'init_time' callback of all machine descriptors
>> for exynos platforms that were previously set to 'exynos4_timer_init' are now
>> set to either 'mct_init' or 'clocksource_of_init'.
>
>> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
>
>> +#ifdef CONFIG_CLKSRC_OF
>> +CLOCKSOURCE_OF_DECLARE(exynos4210, "samsung,exynos4210-mct", mct_init)
>> +CLOCKSOURCE_OF_DECLARE(exynos4412, "samsung,exynos4412-mct", mct_init)
>> +#endif
>
> I suggested in another review (IIRC for a different SoC) that
> CLOCKSOURCE_OF_DECLARE() should always be declared so you don't need
> that ifdef. Would you care to send a patch to add to arm-soc's
> timer/cleanup branch to do that? If not, let me know and I can.
I just sent a patch for this.
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Fix selection of clockevent timer when using device-tree
From: Jon Hunter @ 2013-01-30 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433ED03931@DBDE01.ent.ti.com>
On 01/30/2013 01:18 AM, Bedia, Vaibhav wrote:
> On Wed, Jan 30, 2013 at 01:53:11, Hunter, Jon wrote:
>> Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added
>> device-tree support for selecting a clockevent timer by property.
>> However, the code is currently ignoring the property passed and
>> selecting the first available timer found. Hence, for the OMAP3 beagle
>> board timer-12 is not being selected as expected. Fix this problem
>> by ensuring the timer property is passed to omap_get_timer_dt().
>
> I thought that was intentional ;) and had this change in the clkevt-clksrc
> interchange patch for AM33xx.
No definitely was not. Thanks, I had missed that detail in the patch you
sent!
> Anyways, this change works for me so...
>
> Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Thanks!
Jon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox