* [PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263
From: Arnd Bergmann @ 2013-01-25 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125154219.GM7360@game.jcrosoft.org>
On Friday 25 January 2013 16:42:19 Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:14 Fri 25 Jan , Arnd Bergmann wrote:
> > For the past three years, we have had a #warning in
> > mach-at91 about the sdram_selfrefresh_enable or
> > at91sam9_standby functions possibly not working on
> > at91sam9263. In the meantime a function was added
> > to do the right thing on at91sam9g45, which looks like
> > it should also work on '9263.
> >
> > This patch blindly removes the warning and changes the
> > at91sam9263 to use the same code at at91sam9g45, which
> > may or may not be the right solution. If it is not,
> > maybe someone could provide a better fix.
> it's not
>
> the 9g45 use DDR Controler where the 9263 use a SDRAM controler
>
Ah, right. What about this one then?
Arnd
8<-----
Subject: [PATCH] ARM: at91: suspend both memory controllers on at91sam9263
For the past three years, we have had a #warning in
mach-at91 about the sdram_selfrefresh_enable or
at91sam9_standby functions possibly not working on
at91sam9263. In the meantime a function was added
to do the right thing on at91sam9g45, which looks like
it should also work on '9263.
This patch blindly removes the warning and changes the
at91sam9263 to use the same code at at91sam9g45, which
may or may not be the right solution. If it is not,
maybe someone could provide a better fix.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..4c67946 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -38,6 +38,8 @@ static int at91_enter_idle(struct cpuidle_device *dev,
at91rm9200_standby();
else if (cpu_is_at91sam9g45())
at91sam9g45_standby();
+ else if (cpu_is_at91sam9263())
+ at91sam9263_standby();
else
at91sam9_standby();
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index adb6db8..b8017c1 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -267,6 +267,8 @@ static int at91_pm_enter(suspend_state_t state)
at91rm9200_standby();
else if (cpu_is_at91sam9g45())
at91sam9g45_standby();
+ else if (cpu_is_at91sam9263())
+ at91sam9263_standby();
else
at91sam9_standby();
break;
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 38f467c..2f5908f 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -70,13 +70,31 @@ static inline void at91sam9g45_standby(void)
at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
}
-#ifdef CONFIG_SOC_AT91SAM9263
-/*
- * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
- * handle those cases both here and in the Suspend-To-RAM support.
+/* We manage both DDRAM/SDRAM controllers, we need more than one value to
+ * remember.
*/
-#warning Assuming EB1 SDRAM controller is *NOT* used
-#endif
+static inline void at91sam9263_standby(void)
+{
+ u32 lpr0, lpr1;
+ u32 saved_lpr0, saved_lpr1;
+
+ saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
+ lpr1 = saved_lpr1 & ~AT91_SDRAMC_LPCB;
+ lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+ saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
+ lpr0 = saved_lpr0 & ~AT91_SDRAMC_LPCB;
+ lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+ /* self-refresh mode now */
+ at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
+ at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
+
+ cpu_do_idle();
+
+ at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
+ at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
+}
static inline void at91sam9_standby(void)
{
^ permalink raw reply related
* [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
From: Mark Rutland @ 2013-01-25 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125145928.GC28379@arwen.pp.htv.fi>
On Fri, Jan 25, 2013 at 02:59:28PM +0000, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 25, 2013 at 12:29:43PM +0000, Mark Rutland wrote:
> > > > > + depending upon omap4 or omap5.
> > > > > + - reg-names: The names of the register addresses corresponding to the registers
> > > > > + filled in "reg".
> > > > > + - ti,type: This is used to differentiate whether the control module has
> > > > > + usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
> > > > > + notify events to the musb core and omap5 has usb3 phy power register to
> > > > > + power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
> > > > > + phy power.
> > > >
> > > > Why not make this a string property, perhaps values "mailbox" or "register"?
> > >
> > > NAK.
> >
> > Can I ask what your objection to using a string property is?
> >
> > As far as I can see, "ti,type" is only used by this driver, so there's no
> > common convention to stick to. Using a string makes the binding easier for
> > humans to read, and thus harder to mess up in a dts, and it decouples the
> > binding from kernel-side constants.
>
> IIRC there is some work going on to add #define-like support for DT,
> which would allow us to match against integers while still having
> meaningful symbolic representations.
I was under the impression that the motivation for using the preprocessor on
the DT was to allow symbolic names for device/soc-specific values like
addresses, rather than what amounts to ABI values for the binding.
I don't see the point in building a binding that depends on future
functionality to be legible, especially as we can make it more readable,
robust, and just as extensible today, with a simple change to the proposed
binding.
Even ignoring the above, the driver isn't doing appropriate sanity checking.
If you use a string property, this sanity check is implicit in the parsing --
you've either matched a value you can handle or you haven't.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Dinh Nguyen @ 2013-01-25 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358963974-5496-5-git-send-email-catalin.marinas@arm.com>
Hi Catalin,
On Wed, 2013-01-23 at 17:59 +0000, Catalin Marinas wrote:
> All the calls to gic_secondary_init() pass 0 as the first argument.
> Since this function is called on each CPU when starting, it can be done
> in a platform-independent way via a CPU notifier registered by the GIC
> code.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: David Brown <davidb@codeaurora.org>
> Cc: Daniel Walker <dwalker@fifo99.com>
> Cc: Bryan Huntsman <bryanh@codeaurora.org>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Dinh Nguyen <dinguyen@altera.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: Shiraz Hashim <shiraz.hashim@st.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> ---
>
> Randomly chosen CPU notifier priority. I can add a definition somewhere
> though they don't seem to be used much and cause conflicts.
>
> arch/arm/mach-exynos/platsmp.c | 8 --------
> arch/arm/mach-highbank/platsmp.c | 7 -------
> arch/arm/mach-imx/platsmp.c | 12 ------------
> arch/arm/mach-msm/platsmp.c | 8 --------
> arch/arm/mach-omap2/omap-smp.c | 7 -------
> arch/arm/mach-shmobile/smp-emev2.c | 7 -------
> arch/arm/mach-shmobile/smp-r8a7779.c | 7 -------
> arch/arm/mach-shmobile/smp-sh73a0.c | 7 -------
> arch/arm/mach-socfpga/platsmp.c | 12 ------------
For socfpga, I get this error when I build for sofpga_defconfig:
drivers/gpio/gpio-pl061.c: In function ?pl061_irq_handler?:
drivers/gpio/gpio-pl061.c:183:2: error: implicit declaration of function
?chained_irq_enter? [-Werror=implicit-function-declaration]
drivers/gpio/gpio-pl061.c:192:2: error: implicit declaration of function
?chained_irq_exit? [-Werror=implicit-function-declaration]
Dinh
^ permalink raw reply
* [PATCHv1 for soc 1/5] arm: socfpga: Add new device tree source for actual socfpga HW
From: Dinh Nguyen @ 2013-01-25 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125142240.GB10055@amd.pavel.ucw.cz>
Hi Pavel,
On Fri, 2013-01-25 at 15:22 +0100, Pavel Machek wrote:
> Hi!
>
> > From: Dinh Nguyen <dinguyen@altera.com>
> >
> > Up to this point, support for socfpga has only been on a virtual
> > platform. Now that actual hardware is available, we add the appropriate
> > device tree source files.
>
> Wow, actual hardware :-). Can I get one?
Ramping up production now...
>
> > Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Olof Johansson <olof@lixom.net>
> > Cc: Pavel Machek <pavel@denx.de>
>
> I tested it on 3.7-rc2-based tree, as it is newest I have around. It
> seems to work ok. [Do you have newer git tree somewhere?]
>
> Tested-by: Pavel Machek <pavel@denx.de>
> Reviewed-by: Pavel Machek <pavel@denx.de>
Thanks,
Dinh
>
> Pavel
>
^ permalink raw reply
* [PATCHv1 for soc 4/5] arm: Add v7_invalidate_l1 to cache-v7.S
From: Dinh Nguyen @ 2013-01-25 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125043538.GC8930@verge.net.au>
Hi Simon,
On Fri, 2013-01-25 at 13:35 +0900, Simon Horman wrote:
> On Fri, Jan 25, 2013 at 01:15:03PM +0900, Simon Horman wrote:
> > On Thu, Jan 24, 2013 at 07:00:32PM -0600, dinguyen at altera.com wrote:
> > > From: Dinh Nguyen <dinguyen@altera.com>
> > >
> > > mach-socfpga is another platform that needs to use
> > > v7_invalidate_l1 to bringup additional cores. There was a comment that
> > > the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
> > >
> > > Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Cc: Olof Johansson <olof@lixom.net>
> > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: Rob Herring <rob.herring@calxeda.com>
> > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > Cc: Simon Horman <horms@verge.net.au>
> > > Cc: Magnus Damm <magnus.damm@gmail.com>
> > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > Cc: Pavel Machek <pavel@denx.de>
> >
> > mach-shmobile portion:
> >
> > Acked-by: Simon Horman <horms+renesas@verge.net.au>
>
> For the record, I tested this on the kzm9g, kzm9d and marzen boards.
Thanks,
Dinh
>
^ permalink raw reply
* [PATCHv1 for soc 4/5] arm: Add v7_invalidate_l1 to cache-v7.S
From: Dinh Nguyen @ 2013-01-25 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51023E99.7040802@ti.com>
Hi Santosh,
On Fri, 2013-01-25 at 13:43 +0530, Santosh Shilimkar wrote:
> On Friday 25 January 2013 06:30 AM, dinguyen at altera.com wrote:
> > From: Dinh Nguyen <dinguyen@altera.com>
> >
> > mach-socfpga is another platform that needs to use
> > v7_invalidate_l1 to bringup additional cores. There was a comment that
> > the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
> >
> > Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Olof Johansson <olof@lixom.net>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Rob Herring <rob.herring@calxeda.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Simon Horman <horms@verge.net.au>
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > Cc: Pavel Machek <pavel@denx.de>
> > ---
> > arch/arm/mach-imx/headsmp.S | 47 -------------------------------------
> > arch/arm/mach-shmobile/headsmp.S | 48 --------------------------------------
> > arch/arm/mach-tegra/headsmp.S | 43 ----------------------------------
> > arch/arm/mm/cache-v7.S | 47 +++++++++++++++++++++++++++++++++++++
> > 4 files changed, 47 insertions(+), 138 deletions(-)
> >
> Does yor kernel skips the decompresser. Am just curious about
> what you describe above since you should see the issue already
> at decompresser. Your boot loader is expected to clean and
> invalidating the caches before jumping into the kernel.
This is for bringing up the 2nd core after the main CPU is already
alive. Indeed, I did see this issue when the main CPU was coming up and
have changed the bootloader to clean and invalidate the caches.
Dinh
>
> Regards,
> Santosh
>
>
^ permalink raw reply
* [PATCHv1 for soc 3/5] arm: socfpga: Add entries to enable make dtbs socfpga
From: Dinh Nguyen @ 2013-01-25 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125151357.GC10055@amd.pavel.ucw.cz>
Hi Pavel,
On Fri, 2013-01-25 at 16:13 +0100, Pavel Machek wrote:
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -124,6 +124,8 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
> > r8a7740-armadillo800eva.dtb \
> > sh73a0-kzm9g.dtb \
> > sh7372-mackerel.dtb
> > +dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
> > + socfpga_vt.dtb
> > dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
> > spear1340-evb.dtb
> > dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
>
> This allows me to remove manual dtb invocation from the build
> scripts. Good.
>
> For 2,3/5:
>
> Tested-by: Pavel Machek <pavel@denx.de>
> Reviewed-by: Pavel Machek <pavel@denx.de>
Thanks,
Dinh
>
> Pavel
^ permalink raw reply
* [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
From: Felipe Balbi @ 2013-01-25 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125161401.GD16795@e106331-lin.cambridge.arm.com>
Hi,
On Fri, Jan 25, 2013 at 04:14:02PM +0000, Mark Rutland wrote:
> On Fri, Jan 25, 2013 at 02:59:28PM +0000, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Jan 25, 2013 at 12:29:43PM +0000, Mark Rutland wrote:
> > > > > > + depending upon omap4 or omap5.
> > > > > > + - reg-names: The names of the register addresses corresponding to the registers
> > > > > > + filled in "reg".
> > > > > > + - ti,type: This is used to differentiate whether the control module has
> > > > > > + usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
> > > > > > + notify events to the musb core and omap5 has usb3 phy power register to
> > > > > > + power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
> > > > > > + phy power.
> > > > >
> > > > > Why not make this a string property, perhaps values "mailbox" or "register"?
> > > >
> > > > NAK.
> > >
> > > Can I ask what your objection to using a string property is?
> > >
> > > As far as I can see, "ti,type" is only used by this driver, so there's no
> > > common convention to stick to. Using a string makes the binding easier for
> > > humans to read, and thus harder to mess up in a dts, and it decouples the
> > > binding from kernel-side constants.
> >
> > IIRC there is some work going on to add #define-like support for DT,
> > which would allow us to match against integers while still having
> > meaningful symbolic representations.
>
> I was under the impression that the motivation for using the preprocessor on
> the DT was to allow symbolic names for device/soc-specific values like
> addresses, rather than what amounts to ABI values for the binding.
>
> I don't see the point in building a binding that depends on future
> functionality to be legible, especially as we can make it more readable,
> robust, and just as extensible today, with a simple change to the proposed
> binding.
>
> Even ignoring the above, the driver isn't doing appropriate sanity checking.
> If you use a string property, this sanity check is implicit in the parsing --
> you've either matched a value you can handle or you haven't.
Even IRQs use numbers (not talking about the IRQ number, but the IRQ
flags), why would we depend on string comparisson ? It doesn't make
sense.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130125/1d9f17bb/attachment-0001.sig>
^ permalink raw reply
* [PATCHv1 for soc 4/5] arm: Add v7_invalidate_l1 to cache-v7.S
From: Dinh Nguyen @ 2013-01-25 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125154955.GD10055@amd.pavel.ucw.cz>
Hi Pavel,
On Fri, 2013-01-25 at 16:49 +0100, Pavel Machek wrote:
> Hi!
>
> > mach-socfpga is another platform that needs to use
> > v7_invalidate_l1 to bringup additional cores. There was a comment that
> > the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
>
> If there are three copies of code, with fourth one needed for next
> platform, moving it into common code makes sense.
>
> But... The code was not identical before the merge. Are you sure that
> the differences do not hurt? At the very least, it should be mentioned
> in the changelog.
Indeed, the addition of
mcr p15, 0, r0, c7, c5, 0 @ invalidate I cache
was done by commit # 5b2acf384c8a8707d32a98106192ee7187e4446d
This adds invalidate I-Cache as well as D-Cache, which I think should be
ok for most platforms.
Hopefully, Stephen can test and verify.
Dinh
>
> Thanks,
> Pavel
>
> > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> > index 7e49deb..921fc15 100644
> > --- a/arch/arm/mach-imx/headsmp.S
> > +++ b/arch/arm/mach-imx/headsmp.S
> > @@ -17,53 +17,6 @@
> > -ENTRY(v7_invalidate_l1)
> > - mov r0, #0
> > - mcr p15, 0, r0, c7, c5, 0 @ invalidate I cache
> > - mcr p15, 2, r0, c0, c0, 0
> > - mrc p15, 1, r0, c0, c0, 0
> ...
> > diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S
> > index 4a317fa..fb082c4 100644
> > --- a/arch/arm/mach-tegra/headsmp.S
> > +++ b/arch/arm/mach-tegra/headsmp.S
> > @@ -18,49 +18,6 @@
> > -ENTRY(v7_invalidate_l1)
> > - mov r0, #0
> > - mcr p15, 2, r0, c0, c0, 0
> > - mrc p15, 1, r0, c0, c0, 0
>
> [Note missing mcr p15, 0, .. line.]
>
>
^ permalink raw reply
* [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
From: Tony Lindgren @ 2013-01-25 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510103F9.4080601@ti.com>
* Rajendra Nayak <rnayak@ti.com> [130124 01:54]:
> On Wednesday 23 January 2013 12:09 AM, Tony Lindgren wrote:
> >It seems that we should have the iospace available in the driver
> >at that point. And it should be also available to the runtime PM
> >code in hwmod in the device somewhere?
>
> I couldn't find anything as part of the device. Definitely not the
> ioremaped address. There's a device_private->driver_data which the
> drivers can use to populate the ioremaped address but I am sure thats
> not whats its meant for.
I guess we could have runtime PM init function to pass the driver
region to the low level bus code if needed. Anybody got better ideas?
Regards,
Tony
^ permalink raw reply
* [PATCH 0/2] Improvement for pca953x drivers
From: Gregory CLEMENT @ 2013-01-25 16:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
those two patches are the begining of the improvement work we have
spoken about earlier. I started with the two patches you sent.
I've just made a small fix to make it build on the 2nd patch so I keep
your autorship and signed-off.
For the second one, it didn't build too, but I made a more substantial
change on it by moving the setting of the irq to the map function. So
for this one, I took the authorship and remove your signed-off to not
make you responsible of my possible bug! :)
I've compiled and run it, but as I don't have support for the pca905
interrupt on my board, I can't say it didn't break anything. Maybe
this time again Maxime will be willing to test it.
For the remaining improvement related to the PWA and MMP #ifdef, I
hope to be able to work on it this week-end.
Regards
Gregory CLEMENT (1):
gpio: pca953x: use simple irqdomain
Linus Walleij (1):
gpio: pca953x: use managed resources
drivers/gpio/gpio-pca953x.c | 97 ++++++++++++++++---------------------------
1 file changed, 36 insertions(+), 61 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/2] gpio: pca953x: use simple irqdomain
From: Gregory CLEMENT @ 2013-01-25 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359133168-14879-1-git-send-email-gregory.clement@free-electrons.com>
This switches the legacy irqdomain to the simple one, which will
auto-allocate descriptors, and also make sure that we use
irq_create_mapping() in the to_irq function. Also use the map function
of irq_domain_ops to setup the irq configuration on demand and no more
statically during the initialization of the driver.
Based on a initial patch from Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-pca953x.c | 65 +++++++++++++++++++------------------------
1 file changed, 28 insertions(+), 37 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 3a68aed..1dc9906 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -89,7 +89,6 @@ struct pca953x_chip {
u8 irq_stat[MAX_BANK];
u8 irq_trig_raise[MAX_BANK];
u8 irq_trig_fall[MAX_BANK];
- int irq_base;
struct irq_domain *domain;
#endif
@@ -372,7 +371,7 @@ static int pca953x_gpio_to_irq(struct gpio_chip *gc, unsigned off)
struct pca953x_chip *chip;
chip = container_of(gc, struct pca953x_chip, gpio_chip);
- return chip->irq_base + off;
+ return irq_create_mapping(chip->domain, off);
}
static void pca953x_irq_mask(struct irq_data *d)
@@ -520,6 +519,27 @@ static irqreturn_t pca953x_irq_handler(int irq, void *devid)
return IRQ_HANDLED;
}
+static int pca953x_gpio_irq_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ irq_clear_status_flags(irq, IRQ_NOREQUEST);
+ irq_set_chip_data(irq, d->host_data);
+ irq_set_chip(irq, &pca953x_irq_chip);
+ irq_set_nested_thread(irq, true);
+#ifdef CONFIG_ARM
+ set_irq_flags(irq, IRQF_VALID);
+#else
+ irq_set_noprobe(irq);
+#endif
+
+ return 0;
+}
+
+static const struct irq_domain_ops pca953x_irq_simple_ops = {
+ .map = pca953x_gpio_irq_map,
+ .xlate = irq_domain_xlate_twocell,
+};
+
static int pca953x_irq_setup(struct pca953x_chip *chip,
const struct i2c_device_id *id,
int irq_base)
@@ -529,7 +549,6 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
if (irq_base != -1
&& (id->driver_data & PCA_INT)) {
- int lvl;
switch (chip->chip_type) {
case PCA953X_TYPE:
@@ -552,34 +571,13 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
chip->irq_stat[i] &= chip->reg_direction[i];
mutex_init(&chip->irq_lock);
- chip->irq_base = irq_alloc_descs(-1, irq_base, chip->gpio_chip.ngpio, -1);
- if (chip->irq_base < 0)
- goto out_failed;
-
- chip->domain = irq_domain_add_legacy(client->dev.of_node,
+ chip->domain = irq_domain_add_simple(client->dev.of_node,
chip->gpio_chip.ngpio,
- chip->irq_base,
- 0,
- &irq_domain_simple_ops,
+ irq_base,
+ &pca953x_irq_simple_ops,
NULL);
- if (!chip->domain) {
- ret = -ENODEV;
- goto out_irqdesc_free;
- }
-
- for (lvl = 0; lvl < chip->gpio_chip.ngpio; lvl++) {
- int irq = lvl + chip->irq_base;
-
- irq_clear_status_flags(irq, IRQ_NOREQUEST);
- irq_set_chip_data(irq, chip);
- irq_set_chip(irq, &pca953x_irq_chip);
- irq_set_nested_thread(irq, true);
-#ifdef CONFIG_ARM
- set_irq_flags(irq, IRQF_VALID);
-#else
- irq_set_noprobe(irq);
-#endif
- }
+ if (!chip->domain)
+ return -ENODEV;
ret = request_threaded_irq(client->irq,
NULL,
@@ -589,25 +587,18 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
if (ret) {
dev_err(&client->dev, "failed to request irq %d\n",
client->irq);
- goto out_irqdesc_free;
+ return ret;
}
chip->gpio_chip.to_irq = pca953x_gpio_to_irq;
}
return 0;
-
-out_irqdesc_free:
- irq_free_descs(chip->irq_base, chip->gpio_chip.ngpio);
-out_failed:
- chip->irq_base = -1;
- return ret;
}
static void pca953x_irq_teardown(struct pca953x_chip *chip)
{
if (chip->irq_base != -1) {
- irq_free_descs(chip->irq_base, chip->gpio_chip.ngpio);
free_irq(chip->client->irq, chip);
}
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] gpio: pca953x: use managed resources
From: Gregory CLEMENT @ 2013-01-25 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359133168-14879-1-git-send-email-gregory.clement@free-electrons.com>
From: Linus Walleij <linus.walleij@linaro.org>
Using the devm_* managed resources the pca driver can be simplified
and cut down on boilerplate code.
[gcl: fixed a inccorect reference to a removed label, "goto fail_out"
became "return ret"]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-pca953x.c | 32 ++++++++------------------------
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 1dc9906..2405946 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -560,7 +560,7 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
}
ret = pca953x_read_regs(chip, offset, chip->irq_stat);
if (ret)
- goto out_failed;
+ return ret;
/*
* There is no way to know which GPIO line generated the
@@ -579,7 +579,8 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
if (!chip->domain)
return -ENODEV;
- ret = request_threaded_irq(client->irq,
+ ret = devm_request_threaded_irq(&client->dev,
+ client->irq,
NULL,
pca953x_irq_handler,
IRQF_TRIGGER_LOW | IRQF_ONESHOT,
@@ -596,12 +597,6 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
return 0;
}
-static void pca953x_irq_teardown(struct pca953x_chip *chip)
-{
- if (chip->irq_base != -1) {
- free_irq(chip->client->irq, chip);
- }
-}
#else /* CONFIG_GPIO_PCA953X_IRQ */
static int pca953x_irq_setup(struct pca953x_chip *chip,
const struct i2c_device_id *id,
@@ -614,10 +609,6 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
return 0;
}
-
-static void pca953x_irq_teardown(struct pca953x_chip *chip)
-{
-}
#endif
/*
@@ -736,7 +727,8 @@ static int pca953x_probe(struct i2c_client *client,
int ret;
u32 invert = 0;
- chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
+ chip = devm_kzalloc(&client->dev,
+ sizeof(struct pca953x_chip), GFP_KERNEL);
if (chip == NULL)
return -ENOMEM;
@@ -771,15 +763,15 @@ static int pca953x_probe(struct i2c_client *client,
else
ret = device_pca957x_init(chip, invert);
if (ret)
- goto out_failed;
+ return ret;
ret = pca953x_irq_setup(chip, id, irq_base);
if (ret)
- goto out_failed;
+ return ret;
ret = gpiochip_add(&chip->gpio_chip);
if (ret)
- goto out_failed_irq;
+ return ret;
if (pdata && pdata->setup) {
ret = pdata->setup(client, chip->gpio_chip.base,
@@ -790,12 +782,6 @@ static int pca953x_probe(struct i2c_client *client,
i2c_set_clientdata(client, chip);
return 0;
-
-out_failed_irq:
- pca953x_irq_teardown(chip);
-out_failed:
- kfree(chip);
- return ret;
}
static int pca953x_remove(struct i2c_client *client)
@@ -821,8 +807,6 @@ static int pca953x_remove(struct i2c_client *client)
return ret;
}
- pca953x_irq_teardown(chip);
- kfree(chip);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND
From: Dave Martin @ 2013-01-25 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359132254.21576.230.camel@gandalf.local.home>
On Fri, Jan 25, 2013 at 11:44:14AM -0500, Steven Rostedt wrote:
> [ I got an error with linux-arm-kernel at list.infradead.org and had to
> remove from CC ]
Blame Arnd :)
>
> On Fri, 2013-01-25 at 16:26 +0000, Dave Martin wrote:
>
> > However, if the purpose if making return_address() notrace is just to
> > prevent infinite recursion, where finite recursion is safe, then it
> > feels fixable as described above.
> >
> > Steven, do you know whether such an approach might be safe?
> >
>
> I rewrote the function trace recursion code (see linux-next). The
> function tracer wont recurse on itself. If the return_address() is only
> used by callbacks and not directly by the mcount(ftrace_caller), then
> after the first trace, ftrace wont let recursion of the callback. IOW,
> callbacks of ftrace don't need to worry about re-entrancy at the same
> context level (but do for different contexts, ie. normal, irq, softirq
> and NMI).
>
> (commit edc15cafcbfa3d73f819cae99885a2e35e4cbce5 in linux-next and
> friends)
Cool. Are you aware of return_address being used elsewhere? Currently
I'm not aware of anything else which uses it, and grep is not finding
any calls outside ftrace.h that I can see.
Cheers
---Dave
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Tony Lindgren @ 2013-01-25 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433ECF6261@DBDE01.ent.ti.com>
* Bedia, Vaibhav <vaibhav.bedia@ti.com> [130123 06:35]:
> Hi Tony,
>
> On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote:
> [...]
> > >
> > > But I should get *something* from the kernel before it starts trying to access the rootfs ?
> >
> > Here's something Kevin fixed but did not send it out before going to
> > a vacation. Can you give it a try with earlyprintk enabled?
> >
> > Note that this does not help with no output early on, that sounds
> > like a bug configuring the DEBUG_LL port somewhere.
> >
>
> I think earlyprintk on AM335x has not been functional for a while [1].
> Will the latest patches from you to enable multiplatform debug-ll be sufficient
> to test this out? I am trying to track down the boot issues reported and just
> want to be sure of the dependencies.
Yes you should check with current linux next and select the DEBUG_LL
port manually.
> [1] http://marc.info/?l=linux-omap&m=134642491119235&w=2
This one should no longer be needed as we now use the machine_id
for board-generic.c for DT boot.
> [2] https://patchwork.kernel.org/patch/1896851/
This alone won't work without multiplatform support. At least modifying
the Kconfig to use the new settings for OMAP2PLUS is needed.
Probably easiest to make sure it works in linux next first.
Regards,
Tony
^ permalink raw reply
* [PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND
From: Steven Rostedt @ 2013-01-25 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125165934.GE2069@linaro.org>
On Fri, 2013-01-25 at 16:59 +0000, Dave Martin wrote:
> Cool. Are you aware of return_address being used elsewhere? Currently
> I'm not aware of anything else which uses it, and grep is not finding
> any calls outside ftrace.h that I can see.
softirq.c has a trace_preempt_off() use of CALLER_ADDR1.
kernel/sched/core.c has CALLER_ADDR1, 2 an 3.
-- Steve
^ permalink raw reply
* [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
From: Mark Rutland @ 2013-01-25 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125162346.GM28379@arwen.pp.htv.fi>
On Fri, Jan 25, 2013 at 04:23:46PM +0000, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 25, 2013 at 04:14:02PM +0000, Mark Rutland wrote:
> > On Fri, Jan 25, 2013 at 02:59:28PM +0000, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Fri, Jan 25, 2013 at 12:29:43PM +0000, Mark Rutland wrote:
> > > > > > > + depending upon omap4 or omap5.
> > > > > > > + - reg-names: The names of the register addresses corresponding to the registers
> > > > > > > + filled in "reg".
> > > > > > > + - ti,type: This is used to differentiate whether the control module has
> > > > > > > + usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
> > > > > > > + notify events to the musb core and omap5 has usb3 phy power register to
> > > > > > > + power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
> > > > > > > + phy power.
> > > > > >
> > > > > > Why not make this a string property, perhaps values "mailbox" or "register"?
> > > > >
> > > > > NAK.
> > > >
> > > > Can I ask what your objection to using a string property is?
> > > >
> > > > As far as I can see, "ti,type" is only used by this driver, so there's no
> > > > common convention to stick to. Using a string makes the binding easier for
> > > > humans to read, and thus harder to mess up in a dts, and it decouples the
> > > > binding from kernel-side constants.
> > >
> > > IIRC there is some work going on to add #define-like support for DT,
> > > which would allow us to match against integers while still having
> > > meaningful symbolic representations.
> >
> > I was under the impression that the motivation for using the preprocessor on
> > the DT was to allow symbolic names for device/soc-specific values like
> > addresses, rather than what amounts to ABI values for the binding.
> >
> > I don't see the point in building a binding that depends on future
> > functionality to be legible, especially as we can make it more readable,
> > robust, and just as extensible today, with a simple change to the proposed
> > binding.
> >
> > Even ignoring the above, the driver isn't doing appropriate sanity checking.
> > If you use a string property, this sanity check is implicit in the parsing --
> > you've either matched a value you can handle or you haven't.
>
> Even IRQs use numbers (not talking about the IRQ number, but the IRQ
> flags), why would we depend on string comparisson ? It doesn't make
> sense.
When describing interrupts, the flags are associated with the interrupt number,
and don't really make sense on their own. devicetree does not allow you to mix
strings and integers in a value, so you'd never be able to encode irq flags
with strings without completely breaking away from the way ePAPR describes how
to encode interrupts.
By using a string property, the binding is self-describing and easy for humans
to read and verify. It doesn't add a large overhead to either the driver or the
dts, and is no worse (possibly better) for future extension of bindings to
support new device variants while retaining backwards compatibility.
See the standard "status" property, which is string encoded. This would still
work were it an integer-encoded enumeration. Having it as a string makes the
meaning clear to a reader of the dts, and it's trivial for code to deal with.
I don't understand why you think encoding a more legible value in the dt does
not make sense.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 5/5] wlcore: move wl12xx_platform_data up and make it truly optional
From: Tony Lindgren @ 2013-01-25 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359108334-18459-1-git-send-email-coelho@ti.com>
* Luciano Coelho <coelho@ti.com> [130125 02:09]:
> The platform data is used not only by wlcore-based drivers, but also
> by wl1251. Move it up in the directory hierarchy to reflect this.
>
> Additionally, make it truly optional. At the moment, disabling
> platform data while wl1251_sdio or wlcore_sdio are enabled doesn't
> work, but it will be necessary when device tree support is
> implemented.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> Reviewed-by: Felipe Balbi <balbi@ti.com>
> ---
>
> In v2:
> * Fix ti/Makefile
> * Modify board_omap3evm.c which was still using the old Kconfig define
>
> Tony, is it okay if I add this change in the omap3evm board in this
> patch and queue it via wireless so that the whole thing is in sync?
OK, this should not cause additional merge conflicts:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND
From: Dave Martin @ 2013-01-25 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359133703.21576.233.camel@gandalf.local.home>
On Fri, Jan 25, 2013 at 12:08:23PM -0500, Steven Rostedt wrote:
> On Fri, 2013-01-25 at 16:59 +0000, Dave Martin wrote:
>
> > Cool. Are you aware of return_address being used elsewhere? Currently
> > I'm not aware of anything else which uses it, and grep is not finding
> > any calls outside ftrace.h that I can see.
>
> softirq.c has a trace_preempt_off() use of CALLER_ADDR1.
>
> kernel/sched/core.c has CALLER_ADDR1, 2 an 3.
These cases look safe to me ... sched/core.c:get_parent_ip() looks like
it uses notrace purely to avoid the spurious extra frame which it would
otherwise insert, and the code in softirq.c doesn't appear to be in a
notrace context.
Am I being too optimistic, or does that match your understanding?
Cheers
---Dave
^ permalink raw reply
* [PATCH v2 0/5] arm: mvebu: add support for local timer for Armada 370/XP
From: Gregory CLEMENT @ 2013-01-25 17:32 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
The Armada XP SoCs comes with private timers. This allows us to use
local timers through CONFIG_LOCAL_TIMERS and as stated in the kconfig
help, it prevents a "thundering herd" at every timer tick.
Armada 370 also have these private timers, and even if it comes only
with a single CPU, the feature is also enabled for this SoC to keep
the code generic.
In order to be able to use the local timer, I also had to add the
support for the per-CPU interrupts.
There are not many changes since the first version (see the changelog
below), I hope it means that everybody is happy with this patch
set. If it is, so please could you give your acked-by. I especially
expect the acked-by from John Stultz then I will feel more comfortable
to ask Jason to pull it.
This patch set is based on 3.8-rc4 and is obviously 3.9 material. The
git branch called local_timer is available at:
https://github.com/MISL-EBU-System-SW/mainline-public.git.
Thanks,
Changelog:
V1->V2:
- Fixed unneeded empty line and wrong indentation.
- Made percpu_armada_370_xp_evt a static variable
- Removed the patch "arm: kconfig: don't select TWD with local timer
for Armada 370/XP" from the series. There is still some improvement
possible in this area, but this patch set not depends on it.
Gregory CLEMENT (5):
arm: mvebu: Add support for local interrupt
clocksource: time-armada-370-xp: add local timer support
arm: mvebu: update defconfig with local timer support
arm: mvebu: update DT to support local timers
clocksource: update and move armada-370-xp-timer documentation to
timer directory
.../bindings/arm/armada-370-xp-timer.txt | 12 --
.../bindings/timer/marvell,armada-370-xp-timer.txt | 15 ++
arch/arm/boot/dts/armada-370-xp.dtsi | 5 +-
arch/arm/configs/mvebu_defconfig | 1 -
arch/arm/mach-mvebu/irq-armada-370-xp.c | 15 +-
drivers/clocksource/time-armada-370-xp.c | 150 +++++++++++++++-----
6 files changed, 141 insertions(+), 57 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/5] arm: mvebu: Add support for local interrupt
From: Gregory CLEMENT @ 2013-01-25 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359135165-32108-1-git-send-email-gregory.clement@free-electrons.com>
MPIC allows the use of private interrupt for each CPUs. The 28th first
interrupts are per-cpu. This patch adds support to use them.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/irq-armada-370-xp.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/arch/arm/mach-mvebu/irq-armada-370-xp.c
index f99a4a2..274ff58 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -145,10 +145,17 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
{
armada_370_xp_irq_mask(irq_get_irq_data(virq));
writel(hw, main_int_base + ARMADA_370_XP_INT_SET_ENABLE_OFFS);
-
- irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
- handle_level_irq);
irq_set_status_flags(virq, IRQ_LEVEL);
+
+ if (hw < ARMADA_370_XP_MAX_PER_CPU_IRQS) {
+ irq_set_percpu_devid(virq);
+ irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
+ handle_percpu_devid_irq);
+
+ } else {
+ irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
+ handle_level_irq);
+ }
set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
return 0;
@@ -245,7 +252,7 @@ asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
if (irqnr > 1022)
break;
- if (irqnr >= 8) {
+ if (irqnr > 0) {
irqnr = irq_find_mapping(armada_370_xp_mpic_domain,
irqnr);
handle_IRQ(irqnr, regs);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/5] clocksource: time-armada-370-xp: add local timer support
From: Gregory CLEMENT @ 2013-01-25 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359135165-32108-1-git-send-email-gregory.clement@free-electrons.com>
On the SOCs Armada 370 and Armada XP, each CPU comes with two private
timers. This patch use the timer 0 of each CPU as local timer for the
clockevent if CONFIG_LOCAL_TIMER is selected. In the other case, use
only the private Timer 0 of CPU 0.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/clocksource/time-armada-370-xp.c | 150 ++++++++++++++++++++++--------
1 file changed, 112 insertions(+), 38 deletions(-)
diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index a4605fd..47a6730 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -27,8 +27,10 @@
#include <linux/of_address.h>
#include <linux/irq.h>
#include <linux/module.h>
-#include <asm/sched_clock.h>
+#include <asm/sched_clock.h>
+#include <asm/localtimer.h>
+#include <linux/percpu.h>
/*
* Timer block registers.
*/
@@ -49,6 +51,7 @@
#define TIMER1_RELOAD_OFF 0x0018
#define TIMER1_VAL_OFF 0x001c
+#define LCL_TIMER_EVENTS_STATUS 0x0028
/* Global timers are connected to the coherency fabric clock, and the
below divider reduces their incrementing frequency. */
#define TIMER_DIVIDER_SHIFT 5
@@ -57,14 +60,17 @@
/*
* SoC-specific data.
*/
-static void __iomem *timer_base;
-static int timer_irq;
+static void __iomem *timer_base, *local_base;
+static unsigned int timer_clk;
+static bool timer25Mhz = true;
/*
* Number of timer ticks per jiffy.
*/
static u32 ticks_per_jiffy;
+static struct clock_event_device __percpu **percpu_armada_370_xp_evt;
+
static u32 notrace armada_370_xp_read_sched_clock(void)
{
return ~readl(timer_base + TIMER0_VAL_OFF);
@@ -78,24 +84,23 @@ armada_370_xp_clkevt_next_event(unsigned long delta,
struct clock_event_device *dev)
{
u32 u;
-
/*
* Clear clockevent timer interrupt.
*/
- writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
+ writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
/*
* Setup new clockevent timer value.
*/
- writel(delta, timer_base + TIMER1_VAL_OFF);
+ writel(delta, local_base + TIMER0_VAL_OFF);
/*
* Enable the timer.
*/
- u = readl(timer_base + TIMER_CTRL_OFF);
- u = ((u & ~TIMER1_RELOAD_EN) | TIMER1_EN |
- TIMER1_DIV(TIMER_DIVIDER_SHIFT));
- writel(u, timer_base + TIMER_CTRL_OFF);
+ u = readl(local_base + TIMER_CTRL_OFF);
+ u = ((u & ~TIMER0_RELOAD_EN) | TIMER0_EN |
+ TIMER0_DIV(TIMER_DIVIDER_SHIFT));
+ writel(u, local_base + TIMER_CTRL_OFF);
return 0;
}
@@ -107,37 +112,38 @@ armada_370_xp_clkevt_mode(enum clock_event_mode mode,
u32 u;
if (mode == CLOCK_EVT_MODE_PERIODIC) {
+
/*
* Setup timer to fire at 1/HZ intervals.
*/
- writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD_OFF);
- writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL_OFF);
+ writel(ticks_per_jiffy - 1, local_base + TIMER0_RELOAD_OFF);
+ writel(ticks_per_jiffy - 1, local_base + TIMER0_VAL_OFF);
/*
* Enable timer.
*/
- u = readl(timer_base + TIMER_CTRL_OFF);
- writel((u | TIMER1_EN | TIMER1_RELOAD_EN |
- TIMER1_DIV(TIMER_DIVIDER_SHIFT)),
- timer_base + TIMER_CTRL_OFF);
+ u = readl(local_base + TIMER_CTRL_OFF);
+
+ writel((u | TIMER0_EN | TIMER0_RELOAD_EN |
+ TIMER0_DIV(TIMER_DIVIDER_SHIFT)),
+ local_base + TIMER_CTRL_OFF);
} else {
/*
* Disable timer.
*/
- u = readl(timer_base + TIMER_CTRL_OFF);
- writel(u & ~TIMER1_EN, timer_base + TIMER_CTRL_OFF);
+ u = readl(local_base + TIMER_CTRL_OFF);
+ writel(u & ~TIMER0_EN, local_base + TIMER_CTRL_OFF);
/*
* ACK pending timer interrupt.
*/
- writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
-
+ writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
}
}
static struct clock_event_device armada_370_xp_clkevt = {
- .name = "armada_370_xp_tick",
+ .name = "armada_370_xp_per_cpu_tick",
.features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
.shift = 32,
.rating = 300,
@@ -150,32 +156,78 @@ static irqreturn_t armada_370_xp_timer_interrupt(int irq, void *dev_id)
/*
* ACK timer interrupt and call event handler.
*/
+ struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
- writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
- armada_370_xp_clkevt.event_handler(&armada_370_xp_clkevt);
+ writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
+ evt->event_handler(evt);
return IRQ_HANDLED;
}
-static struct irqaction armada_370_xp_timer_irq = {
- .name = "armada_370_xp_tick",
- .flags = IRQF_DISABLED | IRQF_TIMER,
- .handler = armada_370_xp_timer_interrupt
+/*
+ * Setup the local clock events for a CPU.
+ */
+static int __cpuinit armada_370_xp_timer_setup(struct clock_event_device *evt)
+{
+ u32 u;
+ int cpu = smp_processor_id();
+
+ /* Use existing clock_event for cpu 0 */
+ if (!smp_processor_id())
+ return 0;
+
+ u = readl(local_base + TIMER_CTRL_OFF);
+ if (timer25Mhz)
+ writel(u | TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
+ else
+ writel(u & ~TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
+
+ evt->name = armada_370_xp_clkevt.name;
+ evt->irq = armada_370_xp_clkevt.irq;
+ evt->features = armada_370_xp_clkevt.features;
+ evt->shift = armada_370_xp_clkevt.shift;
+ evt->rating = armada_370_xp_clkevt.rating,
+ evt->set_next_event = armada_370_xp_clkevt_next_event,
+ evt->set_mode = armada_370_xp_clkevt_mode,
+ evt->cpumask = cpumask_of(cpu);
+
+ *__this_cpu_ptr(percpu_armada_370_xp_evt) = evt;
+
+ clockevents_config_and_register(evt, timer_clk, 1, 0xfffffffe);
+ enable_percpu_irq(evt->irq, 0);
+
+ return 0;
+}
+
+static void armada_370_xp_timer_stop(struct clock_event_device *evt)
+{
+ evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
+ disable_percpu_irq(evt->irq);
+}
+
+static struct local_timer_ops armada_370_xp_local_timer_ops __cpuinitdata = {
+ .setup = armada_370_xp_timer_setup,
+ .stop = armada_370_xp_timer_stop,
};
void __init armada_370_xp_timer_init(void)
{
u32 u;
struct device_node *np;
- unsigned int timer_clk;
+ int res;
+
np = of_find_compatible_node(NULL, NULL, "marvell,armada-370-xp-timer");
timer_base = of_iomap(np, 0);
WARN_ON(!timer_base);
+ local_base = of_iomap(np, 1);
if (of_find_property(np, "marvell,timer-25Mhz", NULL)) {
/* The fixed 25MHz timer is available so let's use it */
+ u = readl(local_base + TIMER_CTRL_OFF);
+ writel(u | TIMER0_25MHZ,
+ local_base + TIMER_CTRL_OFF);
u = readl(timer_base + TIMER_CTRL_OFF);
- writel(u | TIMER0_25MHZ | TIMER1_25MHZ,
+ writel(u | TIMER0_25MHZ,
timer_base + TIMER_CTRL_OFF);
timer_clk = 25000000;
} else {
@@ -183,15 +235,23 @@ void __init armada_370_xp_timer_init(void)
struct clk *clk = of_clk_get(np, 0);
WARN_ON(IS_ERR(clk));
rate = clk_get_rate(clk);
+ u = readl(local_base + TIMER_CTRL_OFF);
+ writel(u & ~(TIMER0_25MHZ),
+ local_base + TIMER_CTRL_OFF);
+
u = readl(timer_base + TIMER_CTRL_OFF);
- writel(u & ~(TIMER0_25MHZ | TIMER1_25MHZ),
+ writel(u & ~(TIMER0_25MHZ),
timer_base + TIMER_CTRL_OFF);
+
timer_clk = rate / TIMER_DIVIDER;
+ timer25Mhz = false;
}
- /* We use timer 0 as clocksource, and timer 1 for
- clockevents */
- timer_irq = irq_of_parse_and_map(np, 1);
+ /*
+ * We use timer 0 as clocksource, and private(local) timer 0
+ * for clockevents
+ */
+ armada_370_xp_clkevt.irq = irq_of_parse_and_map(np, 4);
ticks_per_jiffy = (timer_clk + HZ / 2) / HZ;
@@ -216,12 +276,26 @@ void __init armada_370_xp_timer_init(void)
"armada_370_xp_clocksource",
timer_clk, 300, 32, clocksource_mmio_readl_down);
- /*
- * Setup clockevent timer (interrupt-driven).
- */
- setup_irq(timer_irq, &armada_370_xp_timer_irq);
+ /* Register the clockevent on the private timer of CPU 0 */
armada_370_xp_clkevt.cpumask = cpumask_of(0);
clockevents_config_and_register(&armada_370_xp_clkevt,
timer_clk, 1, 0xfffffffe);
-}
+ percpu_armada_370_xp_evt = alloc_percpu(struct clock_event_device *);
+
+
+ /*
+ * Setup clockevent timer (interrupt-driven).
+ */
+ *__this_cpu_ptr(percpu_armada_370_xp_evt) = &armada_370_xp_clkevt;
+ res = request_percpu_irq(armada_370_xp_clkevt.irq,
+ armada_370_xp_timer_interrupt,
+ armada_370_xp_clkevt.name,
+ percpu_armada_370_xp_evt);
+ if (!res) {
+ enable_percpu_irq(armada_370_xp_clkevt.irq, 0);
+#ifdef CONFIG_LOCAL_TIMERS
+ local_timer_register(&armada_370_xp_local_timer_ops);
+#endif
+ }
+}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/5] arm: mvebu: update defconfig with local timer support
From: Gregory CLEMENT @ 2013-01-25 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359135165-32108-1-git-send-email-gregory.clement@free-electrons.com>
Now that we have support for local timers, enable it by default
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/configs/mvebu_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index b5bc96c..28c1e38 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -14,7 +14,6 @@ CONFIG_MACH_ARMADA_XP=y
# CONFIG_CACHE_L2X0 is not set
# CONFIG_SWP_EMULATE is not set
CONFIG_SMP=y
-# CONFIG_LOCAL_TIMERS is not set
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
# CONFIG_COMPACTION is not set
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/5] arm: mvebu: update DT to support local timers
From: Gregory CLEMENT @ 2013-01-25 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359135165-32108-1-git-send-email-gregory.clement@free-electrons.com>
Now that the time-armada-370-xp support local timers, updated the
device tree to take it into account.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 4c0abe8..aa6a187 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -68,8 +68,9 @@
timer at d0020300 {
compatible = "marvell,armada-370-xp-timer";
- reg = <0xd0020300 0x30>;
- interrupts = <37>, <38>, <39>, <40>;
+ reg = <0xd0020300 0x30>,
+ <0xd0021040 0x30>;
+ interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
clocks = <&coreclk 2>;
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 5/5] clocksource: update and move armada-370-xp-timer documentation to timer directory
From: Gregory CLEMENT @ 2013-01-25 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359135165-32108-1-git-send-email-gregory.clement@free-electrons.com>
Timer driver for Armada 370 and Armada XP have gained local timers
support. So it needs new resources information regarding the IRQs
and the registers.
Also move the documentation in the new and more accurate directory
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../bindings/arm/armada-370-xp-timer.txt | 12 ------------
.../bindings/timer/marvell,armada-370-xp-timer.txt | 15 +++++++++++++++
2 files changed, 15 insertions(+), 12 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
deleted file mode 100644
index 6483011..0000000
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Marvell Armada 370 and Armada XP Global Timers
-----------------------------------------------
-
-Required properties:
-- compatible: Should be "marvell,armada-370-xp-timer"
-- interrupts: Should contain the list of Global Timer interrupts
-- reg: Should contain the base address of the Global Timer registers
-- clocks: clock driving the timer hardware
-
-Optional properties:
-- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
- Mhz fixed mode (available on Armada XP and not on Armada 370)
diff --git a/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
new file mode 100644
index 0000000..3638112
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
@@ -0,0 +1,15 @@
+Marvell Armada 370 and Armada XP Timers
+---------------------------------------
+
+Required properties:
+- compatible: Should be "marvell,armada-370-xp-timer"
+- interrupts: Should contain the list of Global Timer interrupts and
+ then local timer interrupts
+- reg: Should contain location and length for timers register. First
+ pair for the Global Timer registers, second pair for the
+ local/private timers.
+- clocks: clock driving the timer hardware
+
+Optional properties:
+- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
+ Mhz fixed mode (available on Armada XP and not on Armada 370)
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox