* [PATCH 1/2] ARM: CLKDEV: Add Common Macro for clk_lookup
From: H Hartley Sweeten @ 2011-09-30 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317381097-2691-2-git-send-email-padma.v@samsung.com>
On Friday, September 30, 2011 4:12 AM, Padmavathi Venna wrote:
>
> Added a standardized macro CLKDEV_INIT which can used across all
> the platforms to support clkdev
>
> Suggested by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
> ---
> include/linux/clkdev.h | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
> index 457bcb0..f2db158 100644
> --- a/include/linux/clkdev.h
> +++ b/include/linux/clkdev.h
> @@ -14,6 +14,13 @@
>
> #include <asm/clkdev.h>
>
> +#define CLKDEV_INIT(d, n, c) \
> + { \
> + .dev_id = d, \
> + .con_id = n, \
> + .clk = &c, \
> + },
Padmavathi,
I just noticed you have the ending ',' in the macro. This makes the
clk_lookup tables look a bit strange and hides what each entry in the
table is.
static struct clk_lookup foo_clks[] = {
CLKDEV("bar1_dev", "bar1_con", bar1_clk)
CLKDEV("bar2_dev", "bar2_con", bar2_clk)
...
};
I think this is a bit clearer:
static struct clk_lookup foo_clks[] = {
CLKDEV("bar1_dev", "bar1_con", bar1_clk),
CLKDEV("bar2_dev", "bar2_con", bar2_clk),
...
};
Also, having the macro automatically add the '&' to the clk parameter
hides the fact that it's a pointer. If you remove it CLKDEV(NULL, NULL, NULL)
would then work for the sentinel entry's in mach0-davinci.
Care to remove that comma, and possibly the '&', and redo the patch set?
Regards,
Hartley
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Linus Walleij @ 2011-09-30 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6v19pZ0i-+ksYZbG2ZvGT30UkXEHTzpZMBTB4RNUV5bnA@mail.gmail.com>
On Fri, Sep 30, 2011 at 7:07 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> [Me]
>> That is not the reason it's there actually, what we have
>> discussed on the mailing list is getting sysfs entries for the same
>> reason gpiolib registers a class: handle pin control from userspace,
>>(...)
>
> Sure, but you don't need the bus yet. ?It can be added when it is
> actually needed. ?I'm not convinced that the sysfs approach is
> actually the right interface here (I'm certainly not a fan of the gpio
> sysfs i/f), and I'd rather not be putting in unneeded stuff until the
> userspace i/f is hammered out.
OK I buy that, I will post a v9 without bus...
Thanks!
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF
From: Tony Lindgren @ 2011-09-30 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANrkHUaJr3L+y33j=za-j6Kcsv1dy-rt0URc_9GgzpfOjqPTZA@mail.gmail.com>
* T Krishnamoorthy, Balaji <balajitk@ti.com> [110930 07:43]:
> On Thu, Sep 29, 2011 at 9:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Balaji T K <balajitk@ti.com> [110929 07:11]:
> >> MMC1 data line IO's are powered down in before set regulator function.
> >> IO's should not be powered ON when regulator is OFF.
> >> Keep the IO's in power pown mode after regulator OFF.
> >> Delete incorrect comments which are not applicable for OMAP4.
> >
> > Care to check how this is different from what I added into fixes
> > branch as commit 3fe8df93b0992199e3a0026fc51e90b705f94e40?
> >
> > Is this a separate issue?
>
> Yes.
> commit 3fe8df93b fixes USBC1 configuration.
> USBC1 IO was configured unnecessarily for MMC IO.
>
> This patch keeps the MMC IO's in power down after regulator OFF
> otherwise it generates VMODE_ERROR due to mismatch in input (regulator)
> voltage and MMC IO drive voltage.
OK, can you please refresh it against the current fixes branch?
Thanks,
Tony
^ permalink raw reply
* [PATCH] usb: musb: OMAP4430: Remove a redundant omap4430_phy_init call in usb_musb_init
From: Tony Lindgren @ 2011-09-30 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929070849.GA27987@legolas.emea.dhcp.ti.com>
* Felipe Balbi <balbi@ti.com> [110928 23:35]:
> On Tue, Sep 20, 2011 at 04:50:29PM +0800, Axel Lin wrote:
> > Current code calls omap4430_phy_init() twice in usb_musb_init().
> > Calling omap4430_phy_init() once is enough.
> > This patch removes the first omap4430_phy_init() call, which using an
> > uninitialized pointer as parameter.
> >
> > This patch elimates below build warning:
> > arch/arm/mach-omap2/usb-musb.c: In function 'usb_musb_init':
> > arch/arm/mach-omap2/usb-musb.c:141: warning: 'dev' may be used uninitialized in this function
> >
> > Signed-off-by: Axel Lin <axel.lin@gmail.com>
>
> Acked-by: Felipe Balbi <balbi@ti.com>
Thanks, applying into fixes.
Tony
>
> > ---
> > arch/arm/mach-omap2/usb-musb.c | 3 ---
> > 1 files changed, 0 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> > index a65145b..19e4dac 100644
> > --- a/arch/arm/mach-omap2/usb-musb.c
> > +++ b/arch/arm/mach-omap2/usb-musb.c
> > @@ -137,9 +137,6 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
> > musb_plat.mode = board_data->mode;
> > musb_plat.extvbus = board_data->extvbus;
> >
> > - if (cpu_is_omap44xx())
> > - omap4430_phy_init(dev);
> > -
> > if (cpu_is_omap3517() || cpu_is_omap3505()) {
> > oh_name = "am35x_otg_hs";
> > name = "musb-am35x";
> > --
> > 1.7.4.1
> >
> >
> >
>
> --
> balbi
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Stephen Warren @ 2011-09-30 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317211419-18472-1-git-send-email-linus.walleij@stericsson.com>
Linus Walleij wrote at Wednesday, September 28, 2011 6:04 AM:
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
I still haven't had a chance to look through the .c files, just the docs
and headers, but they look good to me now, so:
Acked-by: Stephen Warren <swarren@nvidia.com>
--
nvpublic
^ permalink raw reply
* [PATCH] ARM: OMAP2+: PM: only register TWL with voltage layer when device is present
From: Kevin Hilman @ 2011-09-30 18:24 UTC (permalink / raw)
To: linux-arm-kernel
Current code registers voltage layer details for TWL PMIC even when a TWL
has not been registered. Fix this to only register the TWL with voltage
layer when the TWL PMIC is initialized by board-level code.
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/pm.c | 6 ++----
arch/arm/mach-omap2/twl-common.c | 11 +++++++++++
arch/arm/mach-omap2/twl-common.h | 3 +++
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d34fc52..602fc66 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -23,6 +23,7 @@
#include "powerdomain.h"
#include "clockdomain.h"
#include "pm.h"
+#include "twl-common.h"
static struct omap_device_pm_latency *pm_lats;
@@ -251,11 +252,8 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
- /* Init the OMAP TWL parameters */
- omap3_twl_init();
- omap4_twl_init();
-
/* Init the voltage layer */
+ omap_pmic_late_init();
omap_voltage_late_init();
/* Initialize the voltages */
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index daa056e..47133fa 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -30,6 +30,7 @@
#include <plat/usb.h>
#include "twl-common.h"
+#include "pm.h"
static struct i2c_board_info __initdata pmic_i2c_board_info = {
.addr = 0x48,
@@ -48,6 +49,16 @@ void __init omap_pmic_init(int bus, u32 clkrate,
omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
}
+void __init omap_pmic_late_init(void)
+{
+ /* Init the OMAP TWL parameters (if PMIC has been registerd) */
+ if (!pmic_i2c_board_info.irq)
+ return;
+
+ omap3_twl_init();
+ omap4_twl_init();
+}
+
#if defined(CONFIG_ARCH_OMAP3)
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 5e83a5b..275dde8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -1,6 +1,8 @@
#ifndef __OMAP_PMIC_COMMON__
#define __OMAP_PMIC_COMMON__
+#include <plat/irqs.h>
+
#define TWL_COMMON_PDATA_USB (1 << 0)
#define TWL_COMMON_PDATA_BCI (1 << 1)
#define TWL_COMMON_PDATA_MADC (1 << 2)
@@ -30,6 +32,7 @@ struct twl4030_platform_data;
void omap_pmic_init(int bus, u32 clkrate, const char *pmic_type, int pmic_irq,
struct twl4030_platform_data *pmic_data);
+void omap_pmic_late_init(void);
static inline void omap2_pmic_init(const char *pmic_type,
struct twl4030_platform_data *pmic_data)
--
1.7.6
^ permalink raw reply related
* [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
From: Paul Walmsley @ 2011-09-30 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317363153-10259-4-git-send-email-abhilash.kv@ti.com>
Hi
On Fri, 30 Sep 2011, Abhilash K V wrote:
> From: Abhilash K V <abhilash.kv@ti.com>
>
> If PMIC info is not available in omap_vp_init(), abort.
>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
> ---
> arch/arm/mach-omap2/vp.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> index 66bd700..0ed3d13 100644
> --- a/arch/arm/mach-omap2/vp.c
> +++ b/arch/arm/mach-omap2/vp.c
> @@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
> u32 val, sys_clk_rate, timeout, waittime;
> u32 vddmin, vddmax, vstepmin, vstepmax;
>
> + if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
> + pr_err("%s: PMIC info requried to configure VP for "
> + "vdd_%s not populated.Hence cannot initialize VP\n",
> + __func__, voltdm->name);
> + return;
> + }
> +
Just wondering about the intent of this patch. Is the goal here to not
call omap_vp_init() for chips that don't have a VP IP block? If so, then
implementing code that does that directly seems like a better approach
than using the PMIC data? Because it seems likely that even SoCs without
VP IP blocks will have PMICs on the board, right?
- Paul
^ permalink raw reply
* [PATCH v2] ARM: OMAP2+: clock: cleanup CPUfreq leftovers
From: Paul Walmsley @ 2011-09-30 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316793611-9949-1-git-send-email-khilman@ti.com>
On Fri, 23 Sep 2011, Kevin Hilman wrote:
> Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
> longer need/use the clock framework code for filling up CPUfreq
> tables. Remove it.
>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
Queued for 3.3 cleanups (to avoid potential dependency issues with which
of our branches is merged first) - thanks Kevin.
- Paul
^ permalink raw reply
* [RFC] Need help deciphering reboot modes!
From: Russell King - ARM Linux @ 2011-09-30 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930125725.GG3895@e102144-lin.cambridge.arm.com>
On Fri, Sep 30, 2011 at 01:57:25PM +0100, Will Deacon wrote:
> As part of my kexec work, I've been looking at the machine_restart path
> on ARM and, more specifically, the use of the reboot_mode character that
> gets passed around and ultimately ignored.
It gets ignored because platform maintainers are a lazy bunch of people
and don't want to write any more code than they absolutely have to.
Overall, it is meant as a hint to the platform code about what reboot
method to use.
> It seems that the following mode characters are used:
>
> 0 -> Currently used by kexec as a dummy argument given that it is
> ignored anyway.
No idea what that means, afaik it's never been used.
> 'h' -> The default assignment to reboot_mode and that used by
> machine_restart. For some reason, reboot_mode can also be
> overridden on the command line. I would guess that this means
> "hard".
It does mean 'hard' and it tells platforms which have the option (the
early ones do!) to use some hardware method to provoke the machine into
rebooting.
> 's' -> A supported option by mioa701 (mach-pxa) and mach-s3c24xx. I
> would guess that this means "soft".
This means to reboot by vectoring through the reset vector - so it is
'soft'.
> 'g' -> A supported option by spitz and tosa (both mach-pxa). I can't
> begin to imagine what it might stand for.
'gpio', using a gpio signal to cause the reboot rather than setting up
a watchdog or something to cause it.
Note that as I say above, it is only a hint - if you pass 's' for soft,
a platform can still elect to do a hard reboot if it knows that soft
reboots just don't work on the platform.
^ permalink raw reply
* [PATCH 0/3] GIC OF bindings
From: Rob Herring @ 2011-09-30 19:27 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
Another round of GIC devicetree support.
This moves the tracking of the starting hwirq number into the irq domain
code. Doing this makes hwirq == GIC interrupt ID and simplifies the GIC
code removing irq_offset.
The full series is available here. This includes Russell's devel-stable and
for-next branches and Nico's vmalloc branch:
git://git.jdl.com/software/linux-3.0.git gic-v2
Tested on highbank and Realview 11MPCore qemu (2 GICs).
Rob
Rob Herring (3):
irq: support domains with non-zero hwirq base
ARM: gic: add irq_domain support
ARM: gic: add OF based initialization
Documentation/devicetree/bindings/arm/gic.txt | 55 ++++++++++
arch/arm/common/Kconfig | 1 +
arch/arm/common/gic.c | 142 +++++++++++++++++++------
arch/arm/include/asm/hardware/gic.h | 5 +-
include/linux/irqdomain.h | 16 +++-
kernel/irq/irqdomain.c | 12 +-
6 files changed, 189 insertions(+), 42 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
--
1.7.5.4
^ permalink raw reply
* [PATCH 1/3] irq: support domains with non-zero hwirq base
From: Rob Herring @ 2011-09-30 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317410880-24828-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Interrupt controllers can have non-zero starting value for h/w irq numbers.
Adding support in irq_domain allows the domain hwirq numbering to match
the interrupt controllers' numbering.
As this makes looping over irqs for a domain more complicated, add loop
iterators to iterate over all hwirqs and irqs for a domain.
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
include/linux/irqdomain.h | 16 +++++++++++++++-
kernel/irq/irqdomain.c | 12 ++++++------
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 3ad553e..c0026b6 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -47,6 +47,7 @@ struct irq_domain_ops {
* of the irq_domain is responsible for allocating the array of
* irq_desc structures.
* @nr_irq: Number of irqs managed by the irq domain
+ * @hwirq_base: Starting number for hwirqs managed by the irq domain
* @ops: pointer to irq_domain methods
* @priv: private data pointer for use by owner. Not touched by irq_domain
* core code.
@@ -57,6 +58,7 @@ struct irq_domain {
struct list_head list;
unsigned int irq_base;
unsigned int nr_irq;
+ unsigned int hwirq_base;
const struct irq_domain_ops *ops;
void *priv;
struct device_node *of_node;
@@ -72,9 +74,21 @@ struct irq_domain {
static inline unsigned int irq_domain_to_irq(struct irq_domain *d,
unsigned long hwirq)
{
- return d->ops->to_irq ? d->ops->to_irq(d, hwirq) : d->irq_base + hwirq;
+ if (d->ops->to_irq)
+ return d->ops->to_irq(d, hwirq);
+ if (hwirq < d->hwirq_base)
+ return NO_IRQ;
+ return d->irq_base + hwirq - d->hwirq_base;
}
+#define irq_domain_for_each_hwirq(d, hw) \
+ for (hw = d->hwirq_base; hw < d->hwirq_base + d->nr_irq; hw++)
+
+#define irq_domain_for_each_irq(d, hw, irq) \
+ for (hw = d->hwirq_base, irq = irq_domain_to_irq(d, hw); \
+ hw < d->hwirq_base + d->nr_irq; \
+ hw++, irq = irq_domain_to_irq(d, hw))
+
extern void irq_domain_add(struct irq_domain *domain);
extern void irq_domain_del(struct irq_domain *domain);
#endif /* CONFIG_IRQ_DOMAIN */
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 84f4110..6b67057 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -20,15 +20,15 @@ static DEFINE_MUTEX(irq_domain_mutex);
void irq_domain_add(struct irq_domain *domain)
{
struct irq_data *d;
- int hwirq;
+ int hwirq, irq;
/*
* This assumes that the irq_domain owner has already allocated
* the irq_descs. This block will be removed when support for dynamic
* allocation of irq_descs is added to irq_domain.
*/
- for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
- d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
+ irq_domain_for_each_irq(domain, hwirq, irq) {
+ d = irq_get_irq_data(irq);
if (d && d->domain) {
/* things are broken; just report, don't clean up */
WARN(1, "error: irq_desc already assigned to a domain");
@@ -50,15 +50,15 @@ void irq_domain_add(struct irq_domain *domain)
void irq_domain_del(struct irq_domain *domain)
{
struct irq_data *d;
- int hwirq;
+ int hwirq, irq;
mutex_lock(&irq_domain_mutex);
list_del(&domain->list);
mutex_unlock(&irq_domain_mutex);
/* Clear the irq_domain assignments */
- for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
- d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
+ irq_domain_for_each_irq(domain, hwirq, irq) {
+ d = irq_get_irq_data(irq);
d->domain = NULL;
}
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/3] ARM: gic: add irq_domain support
From: Rob Herring @ 2011-09-30 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317410880-24828-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Convert the gic interrupt controller to use irq domains in preparation
for device-tree binding and MULTI_IRQ. This allows for translation between
GIC interrupt IDs and Linux irq numbers.
The meaning of irq_offset has changed. It now is just the number of skipped
GIC interrupt IDs for the controller. It will be 16 for primary GIC and 32
for secondary GICs.
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/common/Kconfig | 1 +
arch/arm/common/gic.c | 81 ++++++++++++++++++++---------------
arch/arm/include/asm/hardware/gic.h | 4 +-
3 files changed, 51 insertions(+), 35 deletions(-)
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 4b71766..74df9ca 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -1,4 +1,5 @@
config ARM_GIC
+ select IRQ_DOMAIN
bool
config ARM_VIC
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 8b5be72..6fbe1db 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -29,6 +29,7 @@
#include <linux/cpu_pm.h>
#include <linux/cpumask.h>
#include <linux/io.h>
+#include <linux/irqdomain.h>
#include <asm/irq.h>
#include <asm/mach/irq.h>
@@ -72,8 +73,7 @@ static inline void __iomem *gic_cpu_base(struct irq_data *d)
static inline unsigned int gic_irq(struct irq_data *d)
{
- struct gic_chip_data *gic_data = irq_data_get_irq_chip_data(d);
- return d->irq - gic_data->irq_offset;
+ return d->hwirq;
}
/*
@@ -81,7 +81,7 @@ static inline unsigned int gic_irq(struct irq_data *d)
*/
static void gic_mask_irq(struct irq_data *d)
{
- u32 mask = 1 << (d->irq % 32);
+ u32 mask = 1 << (gic_irq(d) % 32);
spin_lock(&irq_controller_lock);
writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4);
@@ -92,7 +92,7 @@ static void gic_mask_irq(struct irq_data *d)
static void gic_unmask_irq(struct irq_data *d)
{
- u32 mask = 1 << (d->irq % 32);
+ u32 mask = 1 << (gic_irq(d) % 32);
spin_lock(&irq_controller_lock);
if (gic_arch_extn.irq_unmask)
@@ -173,7 +173,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
bool force)
{
void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3);
- unsigned int shift = (d->irq % 4) * 8;
+ unsigned int shift = (gic_irq(d) % 4) * 8;
unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
u32 val, mask, bit;
@@ -224,7 +224,7 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
if (gic_irq == 1023)
goto out;
- cascade_irq = gic_irq + chip_data->irq_offset;
+ cascade_irq = irq_domain_to_irq(&chip_data->domain, gic_irq);
if (unlikely(gic_irq < 32 || gic_irq > 1020 || cascade_irq >= NR_IRQS))
do_bad_IRQ(cascade_irq, desc);
else
@@ -256,10 +256,11 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
irq_set_chained_handler(irq, gic_handle_cascade_irq);
}
-static void __init gic_dist_init(struct gic_chip_data *gic,
- unsigned int irq_start)
+static void __init gic_dist_init(struct gic_chip_data *gic)
{
- unsigned int gic_irqs, irq_limit, i;
+ unsigned int gic_irqs = gic->gic_irqs;
+ struct irq_domain *domain = &gic->domain;
+ unsigned int i, irq;
u32 cpumask;
void __iomem *base = gic->dist_base;
u32 cpu = 0;
@@ -275,17 +276,6 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
writel_relaxed(0, base + GIC_DIST_CTRL);
/*
- * Find out how many interrupts are supported.
- * The GIC only supports up to 1020 interrupt sources.
- */
- gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
- gic_irqs = (gic_irqs + 1) * 32;
- if (gic_irqs > 1020)
- gic_irqs = 1020;
-
- gic->gic_irqs = gic_irqs;
-
- /*
* Set all global interrupts to be level triggered, active low.
*/
for (i = 32; i < gic_irqs; i += 16)
@@ -311,19 +301,12 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
writel_relaxed(0xffffffff, base + GIC_DIST_ENABLE_CLEAR + i * 4 / 32);
/*
- * Limit number of interrupts registered to the platform maximum
- */
- irq_limit = gic->irq_offset + gic_irqs;
- if (WARN_ON(irq_limit > NR_IRQS))
- irq_limit = NR_IRQS;
-
- /*
* Setup the Linux IRQ subsystem.
*/
- for (i = irq_start; i < irq_limit; i++) {
- irq_set_chip_and_handler(i, &gic_chip, handle_fasteoi_irq);
- irq_set_chip_data(i, gic);
- set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
+ irq_domain_for_each_irq(domain, i, irq) {
+ irq_set_chip_and_handler(irq, &gic_chip, handle_fasteoi_irq);
+ irq_set_chip_data(irq, gic);
+ set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
}
writel_relaxed(1, base + GIC_DIST_CTRL);
@@ -535,23 +518,53 @@ static void __init gic_pm_init(struct gic_chip_data *gic)
}
#endif
+const struct irq_domain_ops gic_irq_domain_ops = {
+};
+
void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
void __iomem *dist_base, void __iomem *cpu_base)
{
struct gic_chip_data *gic;
+ struct irq_domain *domain;
+ int gic_irqs;
BUG_ON(gic_nr >= MAX_GIC_NR);
gic = &gic_data[gic_nr];
+ domain = &gic->domain;
gic->dist_base = dist_base;
gic->cpu_base = cpu_base;
- gic->irq_offset = (irq_start - 1) & ~31;
- if (gic_nr == 0)
+ /*
+ * For primary GICs, skip over SGIs.
+ * For secondary GICs, skip over PPIs, too.
+ */
+ if (gic_nr == 0) {
gic_cpu_base_addr = cpu_base;
+ domain->hwirq_base = 16;
+ irq_start = (irq_start & ~31) + 16;
+ } else
+ domain->hwirq_base = 32;
+
+ /*
+ * Find out how many interrupts are supported.
+ * The GIC only supports up to 1020 interrupt sources.
+ */
+ gic_irqs = readl_relaxed(dist_base + GIC_DIST_CTR) & 0x1f;
+ gic_irqs = (gic_irqs + 1) * 32;
+ if (gic_irqs > 1020)
+ gic_irqs = 1020;
+ gic->gic_irqs = gic_irqs;
+
+ domain->nr_irq = gic_irqs - domain->hwirq_base;
+ domain->irq_base = irq_alloc_descs(-1, irq_start, domain->nr_irq,
+ numa_node_id());
+ domain->priv = gic;
+ domain->ops = &gic_irq_domain_ops;
+ irq_domain_add(domain);
gic_chip.flags |= gic_arch_extn.flags;
- gic_dist_init(gic, irq_start);
+ gic_dist_init(gic);
gic_cpu_init(gic);
gic_pm_init(gic);
}
diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index c562705..ade84a4 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -33,6 +33,8 @@
#define GIC_DIST_SOFTINT 0xf00
#ifndef __ASSEMBLY__
+#include <linux/irqdomain.h>
+
extern void __iomem *gic_cpu_base_addr;
extern struct irq_chip gic_arch_extn;
@@ -43,7 +45,6 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
void gic_enable_ppi(unsigned int);
struct gic_chip_data {
- unsigned int irq_offset;
void __iomem *dist_base;
void __iomem *cpu_base;
#ifdef CONFIG_CPU_PM
@@ -53,6 +54,7 @@ struct gic_chip_data {
u32 __percpu *saved_ppi_enable;
u32 __percpu *saved_ppi_conf;
#endif
+ struct irq_domain domain;
unsigned int gic_irqs;
};
#endif
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/3] ARM: gic: add OF based initialization
From: Rob Herring @ 2011-09-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317410880-24828-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
This adds ARM gic interrupt controller initialization using device tree
data.
The initialization function is intended to be called by of_irq_init
function like this:
const static struct of_device_id irq_match[] = {
{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
{}
};
static void __init init_irqs(void)
{
of_irq_init(irq_match);
}
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
Documentation/devicetree/bindings/arm/gic.txt | 55 ++++++++++++++++++++++
arch/arm/common/gic.c | 61 +++++++++++++++++++++++++
arch/arm/include/asm/hardware/gic.h | 1 +
3 files changed, 117 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
new file mode 100644
index 0000000..52916b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -0,0 +1,55 @@
+* ARM Generic Interrupt Controller
+
+ARM SMP cores are often associated with a GIC, providing per processor
+interrupts (PPI), shared processor interrupts (SPI) and software
+generated interrupts (SGI).
+
+Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
+Secondary GICs are cascaded into the upward interrupt controller and do not
+have PPIs or SGIs.
+
+Main node required properties:
+
+- compatible : should be one of:
+ "arm,cortex-a9-gic"
+ "arm,arm11mp-gic"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a <u32> and the value shall be 3.
+
+ The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
+ interrupts.
+
+ The 2nd cell contains the interrupt number for the interrupt type.
+ SPI interrupts are in the range [0-987]. PPI interrupts are in the
+ range [0-15].
+
+ The 3rd cell is the flags, encoded as follows:
+ bits[3:0] trigger type and level flags.
+ 1 = low-to-high edge triggered
+ 2 = high-to-low edge triggered
+ 4 = active high level-sensitive
+ 8 = active low level-sensitive
+ bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
+ the 8 possible cpus attached to the GIC. A bit set to '1' indicated
+ the interrupt is wired to that CPU. Only valid for PPI interrupts.
+
+- reg : Specifies base physical address(s) and size of the GIC registers. The
+ first region is the GIC distributor register base and size. The 2nd region is
+ the GIC cpu interface register base and size.
+
+Optional
+- interrupts : Interrupt source of the parent interrupt controller. Only
+ present on secondary GICs.
+
+Example:
+
+ intc: interrupt-controller at fff11000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0xfff11000 0x1000>,
+ <0xfff10100 0x100>;
+ };
+
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 6fbe1db..3e67970 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -29,6 +29,9 @@
#include <linux/cpu_pm.h>
#include <linux/cpumask.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <linux/irqdomain.h>
#include <asm/irq.h>
@@ -518,7 +521,33 @@ static void __init gic_pm_init(struct gic_chip_data *gic)
}
#endif
+#ifdef CONFIG_OF
+static int gic_irq_domain_dt_translate(struct irq_domain *d,
+ struct device_node *controller,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq, unsigned int *out_type)
+{
+ if (d->of_node != controller)
+ return -EINVAL;
+ if (intsize < 3)
+ return -EINVAL;
+
+ /* Get the interrupt number and add 16 to skip over SGIs */
+ *out_hwirq = intspec[1] + 16;
+
+ /* For SPIs, we need to add 16 more to get the GIC irq ID number */
+ if (!intspec[0])
+ *out_hwirq += 16;
+
+ *out_type = intspec[2] & IRQ_TYPE_SENSE_MASK;
+ return 0;
+}
+#endif
+
const struct irq_domain_ops gic_irq_domain_ops = {
+#ifdef CONFIG_OF
+ .dt_translate = gic_irq_domain_dt_translate,
+#endif
};
void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
@@ -606,3 +635,35 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
writel_relaxed(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT);
}
#endif
+
+#ifdef CONFIG_OF
+static int gic_cnt __initdata = 0;
+
+int __init gic_of_init(struct device_node *node, struct device_node *parent)
+{
+ void __iomem *cpu_base;
+ void __iomem *dist_base;
+ int irq;
+ struct irq_domain *domain = &gic_data[gic_cnt].domain;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ dist_base = of_iomap(node, 0);
+ WARN(!dist_base, "unable to map gic dist registers\n");
+
+ cpu_base = of_iomap(node, 1);
+ WARN(!cpu_base, "unable to map gic cpu registers\n");
+
+ domain->of_node = of_node_get(node);
+
+ gic_init(gic_cnt, 16, dist_base, cpu_base);
+
+ if (parent) {
+ irq = irq_of_parse_and_map(node, 0);
+ gic_cascade_irq(gic_cnt, irq);
+ }
+ gic_cnt++;
+ return 0;
+}
+#endif
diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index ade84a4..1a776a1 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -39,6 +39,7 @@ extern void __iomem *gic_cpu_base_addr;
extern struct irq_chip gic_arch_extn;
void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
+int gic_of_init(struct device_node *node, struct device_node *parent);
void gic_secondary_init(unsigned int);
void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/4] ARM: CSR: cleanup some minor coding-style issues
From: Arnd Bergmann @ 2011-09-30 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316757091-14916-1-git-send-email-Baohua.Song@csr.com>
On Friday 23 September 2011, Barry Song wrote:
> Barry Song (4):
> ARM: CSR: timer: do not initialise statics to 0 or NULL
> ARM: CSR: timer: space required before the open parenthesis '('
> ARM: CSR: prima2: fix trailing whitespace
> ARM: CSR: clock: Fix indentation
>
> arch/arm/mach-prima2/clock.c | 4 ++--
> arch/arm/mach-prima2/prima2.c | 2 +-
> arch/arm/mach-prima2/timer.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
Hi Barry,
Sorry for the late reply. This series and the one before all look good
to me, but I fear I'm losing track of the patches.
Can you send me pull requests for each set (fixes, cleanups, other
changes) so I can be sure I get everything? If you have trouble
with git.kernel.org still being down, I can apply the patches
manually and let you double-check them, but that would be more
work for both of us I think.
Arnd
^ permalink raw reply
* [GIT PULL] omap cleanup part3 for v3.2 merge window
From: Tony Lindgren @ 2011-09-30 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110923213735.GZ2937@atomide.com>
Hi Arnd,
Please pull omap cleanup part3 into cleanup from:
git://github.com/tmlind/linux.git cleanup-part3
If you did not already pull the earlier updated
cleanup, pulling this is enough and will bring that
in too.
Regards,
Tony
The following changes since commit 48b48fc996ad98bc7b7cf133882e08cd2331ae11:
Tony Lindgren (1):
Merge branch 'for_3.2/pm-cleanup' of git://gitorious.org/khilman/linux-omap-pm into cleanup
are available in the git repository at:
git://github.com/tmlind/linux.git cleanup-part3
Benoit Cousson (1):
ARM: OMAP2+: Add SoC specific map_io functions
Jarkko Nikula (13):
ARM: OMAP: mcbsp: Remove unused variables from platform data
ARM: OMAP: mcbsp: Move out omap_mcbsp_register_board_cfg from plat-omap/devices.c
ARM: OMAP: mcbsp: Implement generic register access
ARM: OMAP: mcbsp: Make wakeup control generic
ARM: OMAP: mcbsp: Make tranceiver configuration control register access generic
ARM: OMAP: mcbsp: Make threshold based transfer code generic
ARM: OMAP: mcbsp: Use per instance register cache size
ARM: OMAP: mcbsp: Move sidetone clock management to mach-omap2/mcbsp.c
ARM: OMAP: mcbsp: Cleanup sidetone control initialization and make it generic
ARM: OMAP: mcbsp: Update mcbsp.h include dependencies
ARM: OMAP: mcbsp: Move address definitions to arch/arm/mach-omap1/mcbsp.c
ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src
ARM: OMAP: mcbsp: Start generalize signal muxing functions
Tony Lindgren (2):
ARM: OMAP2+: Use SoC specifc map_io
ARM: OMAP2+: Remove custom init_irq for remaining boards
arch/arm/mach-omap1/mcbsp.c | 45 ++++
arch/arm/mach-omap2/board-2430sdp.c | 8 +-
arch/arm/mach-omap2/board-4430sdp.c | 8 +-
arch/arm/mach-omap2/board-apollon.c | 8 +-
arch/arm/mach-omap2/board-devkit8000.c | 7 +-
arch/arm/mach-omap2/board-h4.c | 15 +-
arch/arm/mach-omap2/board-n8x0.c | 12 +-
arch/arm/mach-omap2/board-omap3beagle.c | 7 +-
arch/arm/mach-omap2/board-omap3stalker.c | 7 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 7 +-
arch/arm/mach-omap2/board-omap4panda.c | 8 +-
arch/arm/mach-omap2/board-rm680.c | 8 +-
arch/arm/mach-omap2/board-rx51.c | 8 +-
arch/arm/mach-omap2/common.c | 18 ++
arch/arm/mach-omap2/mcbsp.c | 103 ++++++---
arch/arm/plat-omap/devices.c | 46 ----
arch/arm/plat-omap/include/plat/common.h | 4 +
arch/arm/plat-omap/include/plat/mcbsp.h | 208 +++++-----------
arch/arm/plat-omap/mcbsp.c | 358 +++++++++++++---------------
19 files changed, 379 insertions(+), 506 deletions(-)
^ permalink raw reply
* [GIT PULL] omap cleanup part2 for v3.2 merge window
From: Arnd Bergmann @ 2011-09-30 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110923213735.GZ2937@atomide.com>
On Friday 23 September 2011, Tony Lindgren wrote:
> Please pull omap cleanup branch again from:
>
> git://github.com/tmlind/linux.git cleanup
>
> This contains a fix for earlier cleanup patches and has omap_device
> cleanup and PM cleanup merged in.
>
> As some of the later cleanup was based on a -rc6 while the
> earlier branch was based on -rc4, the git request pull
> against the earlier cleanup produces noise.
>
> So instead, below is a diff to the previous pull request
> against -rc7 that show the incremental changes.
Pulled, thanks.
Sorry for the delay.
Arnd
^ permalink raw reply
* [GIT PULL] omap cleanup part1 for v3.2 merge window
From: Arnd Bergmann @ 2011-09-30 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110923225309.GA6324@atomide.com>
On Saturday 24 September 2011, Tony Lindgren wrote:
> >
> > If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which
> > is already pulled into arm-soc/next/voltage) so just re-pulling will
> > pick up the fix.
>
> Arnd, care to pull this in directly from Kevin into voltage branch?
> It's available at:
>
> git://gitorious.org/khilman/linux-omap-pm for_3.2/voltage-cleanup
Applied, thanks for taking care of this!
Arnd
^ permalink raw reply
* [GIT PULL] dmtimer changes for v3.2 merge window
From: Arnd Bergmann @ 2011-09-30 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110928220237.GE6324@atomide.com>
On Thursday 29 September 2011, Tony Lindgren wrote:
> Please pull omap dmtimer changes from:
>
> git://github.com/tmlind/linux.git dmtimer
>
> This series completes the system timer separation from the
> driver like features. It also adds support for v2 ip that is
> available for some timers starting with omap4.
>
> After this series arch/arm/plat-omap/dmtimer.c could be
> moved to live under drivers somewhere, but there is still
> discussion going on which features should be supported in
> a generic way.
>
> This series depends on the cleanup you pulled earlier.
> As this series adds some new features like runtime PM suppport,
> I've kept it separate from cleanup.
Looks really nice. I've put it into another top-level branch
named next/dmtimer for now. I'm open for suggestions on whether
I should generally push branches like this separately Linuswards
or better aggregate multiple standalone features into a single
branch.
Arnd
^ permalink raw reply
* [GIT PULL] at91 fixes for 3.1
From: Arnd Bergmann @ 2011-09-30 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E838F77.2040705@atmel.com>
On Wednesday 28 September 2011, Nicolas FERRE wrote:
> Here is a couple of fixes that may be included in 3.1-final.
> The Kconfig modification will allow to select the PWM driver for SAM9G45
> SoC. This will also benefit to stable kernels.
> The new defconfig for SAM9G45 family will allow us to better monitor the
> health of this port through automatic compilation mechanism. I find it
> interesting to have it included the sooner.
>
> The pull is based on the following changes since commit
> a102a9ece5489e1718cd7543aa079082450ac3a2:
>
> Linux 3.1-rc8 (2011-09-27 15:48:34 -0700)
>
> are available in the git repository at:
> git://github.com/at91linux/linux-at91.git at91-fixes
Hi Nicolas,
I've pulled them into the fixes branch now. My feeling however is that
these by themselves are not reason enough to send a pull request to Linus,
so they will probably be the first thing I send in the 3.2 merge window,
unless some other important fixes appear.
Arnd
^ permalink raw reply
* [GIT PULL] ux500-timers
From: Arnd Bergmann @ 2011-09-30 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbCZwSdXzqvPCrGagaikc53xLyDTQaZMRtuyqo9vw=Yng@mail.gmail.com>
On Tuesday 27 September 2011, Linus Walleij wrote:
> could you please pull the ux500-timers branch into the arm-soc
> tree? These patches have circulated for a long time and my repost
> from last week has not generated any new comments.
>
> (On popular request I try to keep pull requests per-topic...)
Thanks, I really like it this way!
> The following changes since commit d93dc5c4478c1fd5de85a3e8aece9aad7bbae044:
>
> Linux 3.1-rc7 (2011-09-21 16:58:15 -0700)
>
> are available in the git repository at:
> git://git.linaro.org/people/triad/linux-stericsson.git ux500-nomadik-timers
pulled into a new top-level next/timer branch.
Arnd
^ permalink raw reply
* [PATCH v2 0/7] Initial Calxeda Highbank support
From: Arnd Bergmann @ 2011-09-30 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E80C6D1.1010601@gmail.com>
On Monday 26 September 2011, Rob Herring wrote:
> Any comments on v2?
>
> The GIC binding series seems to be firming up. As myself and several
> others are dependent on it, I was planning to send both through arm-soc
> tree as 2 pulls. I also have some dependencies on rmk's tree with l2x0
> DT support and mach header clean-ups.
Looks all good as far as I can tell. Please send the pull requests.
Arnd
^ permalink raw reply
* [GIT PATCH] OMAP: Add initial support for DT on OMAP3 & OMAP4
From: Cousson, Benoit @ 2011-09-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony,
Please pull the initial OMAP device tree support for v3.2.
Thanks,
Benoit
The following changes since commit 1c3543a34a8ce3e050d7706135bdffd5921c42f5:
Tony Lindgren (1):
Merge branch 'for_3.2/omap_device-2' of git://github.com/khilman/linux-omap-pm into dt
are available in the git repository at:
git://gitorious.org/omap-pm/linux.git for_3.2/3_omap_devicetree
Benoit Cousson (10):
arm/dts: Add initial device tree support for OMAP4 SoC
arm/dts: Add support for OMAP4 PandaBoard
arm/dts: Add support for OMAP4 SDP board
arm/dts: Add initial device tree support for OMAP3 SoC
arm/dts: Add support for OMAP3 Beagle board
OMAP2+: board-generic: Add DT support to generic board
OMAP2+: board-generic: Add i2c static init
OMAP2+: l3-noc: Add support for device-tree
arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver
arm/dts: OMAP3+: Add mpu, dsp and iva nodes
Documentation/devicetree/bindings/arm/omap/dsp.txt | 14 ++
Documentation/devicetree/bindings/arm/omap/iva.txt | 19 +++
.../devicetree/bindings/arm/omap/l3-noc.txt | 19 +++
Documentation/devicetree/bindings/arm/omap/mpu.txt | 27 ++++
arch/arm/boot/dts/omap3-beagle.dts | 29 ++++
arch/arm/boot/dts/omap3.dtsi | 63 ++++++++
arch/arm/boot/dts/omap4-panda.dts | 29 ++++
arch/arm/boot/dts/omap4-sdp.dts | 29 ++++
arch/arm/boot/dts/omap4.dtsi | 103 +++++++++++++
arch/arm/mach-omap2/Kconfig | 8 +-
arch/arm/mach-omap2/board-generic.c | 156 +++++++++++++++-----
arch/arm/mach-omap2/devices.c | 5 +
arch/arm/mach-omap2/omap_l3_noc.c | 23 +++-
arch/arm/mach-omap2/pm.c | 3 +-
14 files changed, 480 insertions(+), 47 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/dsp.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/iva.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/l3-noc.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/mpu.txt
create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
create mode 100644 arch/arm/boot/dts/omap3.dtsi
create mode 100644 arch/arm/boot/dts/omap4-panda.dts
create mode 100644 arch/arm/boot/dts/omap4-sdp.dts
create mode 100644 arch/arm/boot/dts/omap4.dtsi
^ permalink raw reply
* [GIT PULL] dmtimer changes for v3.2 merge window
From: Tony Lindgren @ 2011-09-30 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109302213.42435.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [110930 12:40]:
> On Thursday 29 September 2011, Tony Lindgren wrote:
> > Please pull omap dmtimer changes from:
> >
> > git://github.com/tmlind/linux.git dmtimer
> >
> > This series completes the system timer separation from the
> > driver like features. It also adds support for v2 ip that is
> > available for some timers starting with omap4.
> >
> > After this series arch/arm/plat-omap/dmtimer.c could be
> > moved to live under drivers somewhere, but there is still
> > discussion going on which features should be supported in
> > a generic way.
> >
> > This series depends on the cleanup you pulled earlier.
> > As this series adds some new features like runtime PM suppport,
> > I've kept it separate from cleanup.
>
> Looks really nice. I've put it into another top-level branch
> named next/dmtimer for now. I'm open for suggestions on whether
> I should generally push branches like this separately Linuswards
> or better aggregate multiple standalone features into a single
> branch.
How about a branch called driver?
There are still lots of pieces of code under arch/arm that should
be eventually moved to live under drivers. For example the mux
code and most of PM code can eventually be under drivers.
But before that can be done some preparation is often needed,
the actual move to live under drivers should be handled then
by the driver and subsystem maintainers.
Regards,
Tony
^ permalink raw reply
* [PATCHv3 0/4] Initial support for Picochip picoXcell
From: Arnd Bergmann @ 2011-09-30 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317050689-16417-1-git-send-email-jamie@jamieiles.com>
Hi Jamie,
On Monday 26 September 2011, Jamie Iles wrote:
> This is largely a repost of v2, but with a couple of minor changes:
> - Removed bootargs from board dts files
> - Fix up the VIC binding documentation
>
> I've also added a 4th patch which removes the picoxcell specific ioremap
> functionality. This could either be applied/folded into the first patch
> if Nicolas' vmalloc cleanups go in.
>
> These patches can also be found in a git tree at:
>
> git://github.com/jamieiles/linux-2.6-ji.git for-next
I've pulled it into the next/soc branch now, and I'll also pul
Rob's highbank patches in there.
Sorry for taking so long.
There might be a few things that break when this is merged with the
cross-platform changes, so I'm planning right now to submit these
rather late in the merge window to allow fixing any mismerges
before it gets upstream.
Arnd
^ permalink raw reply
* [GIT PULL] dmtimer changes for v3.2 merge window
From: Arnd Bergmann @ 2011-09-30 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930204319.GM6324@atomide.com>
On Friday 30 September 2011, Tony Lindgren wrote:
> How about a branch called driver?
>
> There are still lots of pieces of code under arch/arm that should
> be eventually moved to live under drivers. For example the mux
> code and most of PM code can eventually be under drivers.
Yes, good idea! For the omap/voltage series, I currently plan to
group that with pm changes for that I got for the other socs
this time, but if there was less of it, that could also be drivers.
> But before that can be done some preparation is often needed,
> the actual move to live under drivers should be handled then
> by the driver and subsystem maintainers.
I think in some cases we first need to nominate a subsystem
maintainer who can take the drivers, but that's a different
issue.
Arnd
^ 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