* Re: [PATCH] atomic: add *_dec_not_zero
From: Mike Frysinger @ 2011-05-04 8:33 UTC (permalink / raw)
To: David Laight
Cc: linux-arch, linux-mips, linux-m32r, linux-ia64, linux-cris-kernel,
linux-parisc, linux-s390, linux-sh, linux-kernel, Chris Metcalf,
David Howells, linux-m68k, linux-am33-list, linux-arm-kernel,
linux-alpha, sparclinux, uclinux-dist-devel, x86, linuxppc-dev,
Sven Eckelmann
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AD0D@saturn3.aculab.com>
On Wed, May 4, 2011 at 04:05, David Laight wrote:
>> Introduce an *_dec_not_zero operation. =C2=A0Make this a special case of
>> *_add_unless because batman-adv uses atomic_dec_not_zero in different
>> places like re-broadcast queue or aggregation queue management. There
>> are other non-final patches which may also want to use this macro.
>
> Isn't there a place where a default definition of this can be
> defined? Instead of adding it separately to every architecture.
that's what asm-generic is for. if the arch isnt using it, it's
either because the arch needs to convert to it, or they're using SMP
and asm-generic doesnt yet support that for atomic.h.
for example, the Blackfin port only needed updating for the SMP case.
in the non-SMP case, we're getting the def from asm-generic/atomic.h.
-mike
^ permalink raw reply
* Re: [PATCH] atomic: add *_dec_not_zero
From: Jesper Nilsson @ 2011-05-04 10:48 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-arch@vger.kernel.org, linux-mips@linux-mips.org,
linux-m68k@lists.linux-m68k.org, linux-m32r@ml.linux-m32r.org,
linux-ia64@vger.kernel.org, linux-cris-kernel,
linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
Chris Metcalf, David Howells, linux-am33-list@redhat.com,
linux-alpha@vger.kernel.org, sparclinux@vger.kernel.org,
uclinux-dist-devel@blackfin.uclinux.org, x86@kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1304458235-28473-1-git-send-email-sven@narfation.org>
On Tue, May 03, 2011 at 11:30:35PM +0200, Sven Eckelmann wrote:
> Introduce an *_dec_not_zero operation. Make this a special case of
> *_add_unless because batman-adv uses atomic_dec_not_zero in different
> places like re-broadcast queue or aggregation queue management. There
> are other non-final patches which may also want to use this macro.
For the CRIS-part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH] atomic: add *_dec_not_zero
From: Ralf Baechle @ 2011-05-04 11:02 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-arch, linux-mips, linux-m68k, linux-m32r, linux-ia64,
linux-parisc, linux-cris-kernel, linux-s390, linux-sh, x86,
linux-kernel, Chris Metcalf, David Howells, linux-am33-list,
linux-alpha, sparclinux, uclinux-dist-devel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1304458235-28473-1-git-send-email-sven@narfation.org>
On Tue, May 03, 2011 at 11:30:35PM +0200, Sven Eckelmann wrote:
> arch/mips/include/asm/atomic.h | 2 ++
> arch/mips/include/asm/local.h | 1 +
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply
* Re: [PATCH] atomic: add *_dec_not_zero
From: David Howells @ 2011-05-04 11:53 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-arch, linux-mips, linux-m68k, linux-m32r, linux-ia64,
linux-parisc, linux-cris-kernel, linux-s390, linux-sh, x86,
linux-kernel, Chris Metcalf, dhowells, linux-am33-list,
linux-alpha, sparclinux, uclinux-dist-devel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1304458235-28473-1-git-send-email-sven@narfation.org>
Sven Eckelmann <sven@narfation.org> wrote:
> Introduce an *_dec_not_zero operation. Make this a special case of
> *_add_unless because batman-adv uses atomic_dec_not_zero in different
> places like re-broadcast queue or aggregation queue management. There
> are other non-final patches which may also want to use this macro.
>
> Reported-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
Acked-by: David Howells <dhowells@redhat.com> [MN10300 and FRV]
^ permalink raw reply
* Re: [PATCH] atomic: add *_dec_not_zero
From: Chris Metcalf @ 2011-05-04 12:09 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-arch, linux-mips, linux-m32r, linux-ia64, linux-parisc,
linux-cris-kernel, linux-s390, linux-sh, x86, linux-kernel,
David Howells, linux-m68k, linux-am33-list, linux-alpha,
sparclinux, uclinux-dist-devel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1304458235-28473-1-git-send-email-sven@narfation.org>
On 5/3/2011 5:30 PM, Sven Eckelmann wrote:
> Introduce an *_dec_not_zero operation. Make this a special case of
> *_add_unless because batman-adv uses atomic_dec_not_zero in different
> places like re-broadcast queue or aggregation queue management. There
> are other non-final patches which may also want to use this macro.
>
> Reported-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
> [...]
> arch/tile/include/asm/atomic.h | 9 +++++++++
> arch/tile/include/asm/atomic_32.h | 1 +
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH] atomic: add *_dec_not_zero
From: Geert Uytterhoeven @ 2011-05-04 12:17 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-arch, linux-mips, linux-m32r, linux-ia64, linux-parisc,
linux-cris-kernel, linux-s390, linux-sh, x86, linux-kernel,
Chris Metcalf, David Howells, linux-m68k, linux-am33-list,
linux-alpha, sparclinux, uclinux-dist-devel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1304458235-28473-1-git-send-email-sven@narfation.org>
On Tue, May 3, 2011 at 23:30, Sven Eckelmann <sven@narfation.org> wrote:
> Introduce an *_dec_not_zero operation. =C2=A0Make this a special case of
> *_add_unless because batman-adv uses atomic_dec_not_zero in different
> places like re-broadcast queue or aggregation queue management. There
> are other non-final patches which may also want to use this macro.
> =C2=A0arch/m68k/include/asm/atomic.h =C2=A0 =C2=A0 | =C2=A0 =C2=A01 +
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* [PATCH] powerpc/qoriq: Add default mode for P1020RDB USB
From: Ramneek Mehresh @ 2011-05-04 13:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, Ramneek Mehresh
Add P1020 USB controller default value for "dr_mode" property
Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
---
Applies on git://git.am.freescale.net/mirrors/linux-2.6.git
(branch master)
arch/powerpc/boot/dts/p1020rdb.dts | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020rdb.dts b/arch/powerpc/boot/dts/p1020rdb.dts
index e0668f8..c630b51 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -473,13 +473,11 @@
interrupt-parent = <&mpic>;
interrupts = <28 0x2>;
phy_type = "ulpi";
+ dr_mode = "host";
};
- /* USB2 is shared with localbus, so it must be disabled
- by default. We can't put 'status = "disabled";' here
- since U-Boot doesn't clear the status property when
- it enables USB2. OTOH, U-Boot does create a new node
- when there isn't any. So, just comment it out.
+ /* USB2 is shared with localbus. It is used
+ only in case of SPI and SD boot*/
usb@23000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -488,8 +486,8 @@
interrupt-parent = <&mpic>;
interrupts = <46 0x2>;
phy_type = "ulpi";
+ dr_mode = "host";
};
- */
sdhci@2e000 {
compatible = "fsl,p1020-esdhc", "fsl,esdhc";
--
1.6.1
^ permalink raw reply related
* [PATCH] fsl/usb: Unused endpoint failure for USB gadget
From: Ramneek Mehresh @ 2011-05-04 14:11 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-release
Cc: Suchit Lepcha, dbrownell, gregkh, Ramneek Mehresh
Though USB controller works without this most of the time, an issue was faced
where USB was configured as printer device and it was dropping first
packet(64 bytes) in full speed mode due to DATA PID mismatch.
The problem gets resolved once unused endpoints are configured as bulk.
As per P1020 RM (Table17-31, bits 19-18, bits 3-2) "When only one endpoint
(RX or TX, but not both) of an endpoint pair is used, the unused endpoint
should be configured as a bulk type endpoint." So according to the RM,
this patch is initializing TX and RX endpoints as bulk type
Signed-off-by: Suchit Lepcha <Suchit.Lepcha@freescale.com>
Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
---
Applies on git://git.am.freescale.net/mirrors/linux-2.6.git
(branch master)
drivers/usb/gadget/fsl_udc_core.c | 27 +++++++++++++++++++++------
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index 07499c1..bac8ca9 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2004-2007 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2004-2007,2011 Freescale Semiconductor, Inc.
+ * All rights reserved.
*
* Author: Li Yang <leoli@freescale.com>
* Jiang Bo <tanya.jiang@freescale.com>
@@ -177,7 +178,8 @@ static void nuke(struct fsl_ep *ep, int status)
static int dr_controller_setup(struct fsl_udc *udc)
{
- unsigned int tmp, portctrl;
+ unsigned int tmp, portctrl, ep_num;
+ unsigned int max_no_of_ep;
#ifndef CONFIG_ARCH_MXC
unsigned int ctrl;
#endif
@@ -242,6 +244,14 @@ static int dr_controller_setup(struct fsl_udc *udc)
udc->ep_qh, (int)tmp,
fsl_readl(&dr_regs->endpointlistaddr));
+ max_no_of_ep = (0x0000001F & fsl_readl(&dr_regs->dccparams));
+ for (ep_num = 1; ep_num < max_no_of_ep; ep_num++) {
+ tmp = fsl_readl(&dr_regs->endptctrl[ep_num]);
+ tmp &= ~(EPCTRL_TX_TYPE | EPCTRL_RX_TYPE);
+ tmp |= (EPCTRL_EP_TYPE_BULK << EPCTRL_TX_EP_TYPE_SHIFT)
+ | (EPCTRL_EP_TYPE_BULK << EPCTRL_RX_EP_TYPE_SHIFT);
+ fsl_writel(tmp, &dr_regs->endptctrl[ep_num]);
+ }
/* Config control enable i/o output, cpu endian register */
#ifndef CONFIG_ARCH_MXC
ctrl = __raw_readl(&usb_sys_regs->control);
@@ -318,12 +328,14 @@ static void dr_ep_setup(unsigned char ep_num, unsigned char dir,
if (ep_num)
tmp_epctrl |= EPCTRL_TX_DATA_TOGGLE_RST;
tmp_epctrl |= EPCTRL_TX_ENABLE;
+ tmp_epctrl &= ~EPCTRL_TX_TYPE;
tmp_epctrl |= ((unsigned int)(ep_type)
<< EPCTRL_TX_EP_TYPE_SHIFT);
} else {
if (ep_num)
tmp_epctrl |= EPCTRL_RX_DATA_TOGGLE_RST;
tmp_epctrl |= EPCTRL_RX_ENABLE;
+ tmp_epctrl &= ~EPCTRL_RX_TYPE;
tmp_epctrl |= ((unsigned int)(ep_type)
<< EPCTRL_RX_EP_TYPE_SHIFT);
}
@@ -546,10 +558,13 @@ static int fsl_ep_disable(struct usb_ep *_ep)
/* disable ep on controller */
ep_num = ep_index(ep);
epctrl = fsl_readl(&dr_regs->endptctrl[ep_num]);
- if (ep_is_in(ep))
- epctrl &= ~EPCTRL_TX_ENABLE;
- else
- epctrl &= ~EPCTRL_RX_ENABLE;
+ if (ep_is_in(ep)) {
+ epctrl &= ~(EPCTRL_TX_ENABLE | EPCTRL_TX_TYPE);
+ epctrl |= EPCTRL_EP_TYPE_BULK << EPCTRL_TX_EP_TYPE_SHIFT;
+ } else {
+ epctrl &= ~(EPCTRL_RX_ENABLE | EPCTRL_TX_TYPE);
+ epctrl |= EPCTRL_EP_TYPE_BULK << EPCTRL_RX_EP_TYPE_SHIFT;
+ }
fsl_writel(epctrl, &dr_regs->endptctrl[ep_num]);
udc = (struct fsl_udc *)ep->udc;
--
1.6.1
^ permalink raw reply related
* [PATCH] powerpc/mpc8610_hpcd: Do not use "/" in interrupt names
From: Geert Uytterhoeven @ 2011-05-04 14:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Anton Vorontsov, Kumar Gala
Cc: Linux/PPC Development, Linux Kernel Development
It may trigger a warning in fs/proc/generic.c:__xlate_proc_name() when
trying to add an entry for the interrupt handler to sysfs.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 018cc67..efadd3b 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -66,7 +66,7 @@ static void __init mpc8610_suspend_init(void)
return;
}
- ret = request_irq(irq, mpc8610_sw9_irq, 0, "sw9/wakeup", NULL);
+ ret = request_irq(irq, mpc8610_sw9_irq, 0, "sw9:wakeup", NULL);
if (ret) {
pr_err("%s: can't request pixis event IRQ: %d\n",
__func__, ret);
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
* Re: [PATCH] atomic: add *_dec_not_zero
From: James Bottomley @ 2011-05-04 15:04 UTC (permalink / raw)
To: Mike Frysinger
Cc: linux-arch, linux-mips, linux-m32r, linux-ia64, linux-parisc,
linux-cris-kernel, linux-s390, linux-sh, x86, linux-kernel,
Chris Metcalf, David Howells, linux-m68k, linux-am33-list,
linux-arm-kernel, linux-alpha, sparclinux, uclinux-dist-devel,
linuxppc-dev, Sven Eckelmann
In-Reply-To: <BANLkTiminpyJ_opxhqG0E0gBOrF490b+tQ@mail.gmail.com>
On Wed, 2011-05-04 at 00:44 -0400, Mike Frysinger wrote:
> On Tue, May 3, 2011 at 17:30, Sven Eckelmann wrote:
> > Introduce an *_dec_not_zero operation. Make this a special case of
> > *_add_unless because batman-adv uses atomic_dec_not_zero in different
> > places like re-broadcast queue or aggregation queue management. There
> > are other non-final patches which may also want to use this macro.
> >
> > Cc: uclinux-dist-devel@blackfin.uclinux.org
> >
> > --- a/arch/blackfin/include/asm/atomic.h
> > +++ b/arch/blackfin/include/asm/atomic.h
> > @@ -103,6 +103,7 @@ static inline int atomic_test_mask(int mask, atomic_t *v)
> > c != (u); \
> > })
> > #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
> > +#define atomic_dec_not_zero(v) atomic_add_unless((v), -1, 0)
> >
> > /*
> > * atomic_inc_and_test - increment and test
>
> no opinion on the actual idea, but for the Blackfin pieces:
> Acked-by: Mike Frysinger <vapier@gentoo.org>
This goes for parisc as well.
Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com>
James
^ permalink raw reply
* Re: [PATCH 0/6] General device tree irq domain infrastructure
From: Grant Likely @ 2011-05-04 15:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michal Simek, Sebastian Andrzej Siewior, x86, linux-kernel,
Ralf Baechle, hpa, Dirk Brandewie, Thomas Gleixner, linuxppc-dev,
devicetree-discuss
In-Reply-To: <1304386999.2513.293.camel@pasglop>
On Tue, May 03, 2011 at 11:43:19AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2011-04-28 at 14:01 -0600, Grant Likely wrote:
> > A lot of this series ends up being fixups to powerpc code; but the 4th
> > patch is of importance to every architecture using CONFIG_OF (except
> > SPARC, which has its own solution).
> >
> > This series (finally!) factors out device tree irq domain decoding
> > from arch/powerpc and makes it generic for all architectures. The
> > infrastructure is quite simple. Any interrupt controller can embed
> > the of_irq_domain structure and register it with the core code. After
> > that, device nodes referencing interrupts on that device tree node
> > will trigger a call to the domain's map function.
>
> This leads to an immediate reaction from me : why "of_irq_domain" ?
>
> The concept of interrupt domains is completely orthogonal to "OF" and
> whether you use the device-tree or not.
>
> Having a remapping mechanism allowing to deal with multiple interrupt
> domains without playing stupid numbering tricks is generally useful for
> architectures, regardless of their adoption of the device-tree.
>
> The irq domain has one and -only one- op that is related to OF which
> allows to map a device node to a domain, but that's 'optional' and only
> use if you use the OF resolving process. The whole mechanism can be (and
> is under some circumstances on ppc) without a device-tree relationship.
>
> We instanciate IRQs within domains manually in some cases, either
> because we lack proper DT informations or bcs the IRQs come from the
> firmware or as "created" out of the blue (device-tree). A domain pointer
> (or NULL for the default domain) is all is needed.
>
> Thus I object to tying this infrastructure generically to "OF" even if
> it's just a mater of naming of the domain structure and location of the
> code in the kernel tree.
>
> It should basically all go into kernel/irq/domains.c or something like
> that.
I completely agree that irq domains are a generically useful feature
for architectures, and it should be made available. I also completely
agree that it is orthogonal to device tree translations, which in a
large part is why I've structured this series and the new code the
way I have.
In this series I'm specifically addressing device tree translation,
which is the one bit that is DT specific, and is important regardless
of the backend translation mechanism. In fact, the more I looked at
it, the more it seems that the DT api really is orthogonal to the
backend irq mapping and I don't think that the way irq_host ties them
together is necessarily the best way to do it. Many of the interrupt
controllers which need to gain dt irq parsing have already been
converted to using the irq_alloc_desc*() apis and have all the mapping
mechanism they need, but lack a method of exposing it for DT
translation.
As for the mapping, I agree that the functionality is generally
useful, I'm just not fond of the current implementation. I think it
is more complex than it needs to be and I'm not excited about bring it
over to the other architectures as-is.
For the majority of fixed hw interrupt controllers it is overkill.
There is no need for a map table when all the irq descs (<=32 of them)
get allocated when the irq controller is instantiated and the mapping
consists of 'virq = hw_irq + virq_base'. For instance, with the arm
irq controllers, it's be more than sufficient to use irq_alloc_descs
to obtain a range of irq numbers and then a simple of_irq_domain
registration to handle the parsing.
For the cases where an interrupt controller isn't able to alloc all
the irq descs at once, like for MSI, then yes the LINEAR and RADIX
mappings are important. What bothers me though is the way irq_host
needs to use unions and the ->revmap_type value to implement multiple
behaviours into a single type. That's the sort of thing that can be
broken out into a library and instantiated only by the interrupt
controllers that actually need it. Similarly, it bothers me that that
radix mapping makes up a significant portion of the code, yet it has
only one user. I'd be happier if each kind of mapping had its own
structure that embedded a generic irq_host/irq_domain with mapping
specific ops populated to manipulate it.
Regardless, the immediate priority is to implement a mapper that will
work for all architectures (or at least everything but powerpc and
sparc). x86 has already implemented a skeleton irq_domain because
there wasn't any common code for it to use. ARM also needs the
functionality immediately, and I don't want to see yet another
arch-specific implementation. I'd like to get the framework in place
now, and grafting in mapping features as follow on patches. That way
the new DT users aren't blocked while waiting for us to hammer down
the features that the other architectures don't need yet.
What I /could/ have done I suppose was called it 'struct irq_domain'
as you suggest, and allowed each translation mechanism to define its
own match/map pair of routines, with device tree being the only one
actually implemented at this point. Yes, I understand that the
core code treats the controller pointer as an anonymous cookie, but
the api is still very device tree centric, and I'm not convinced that
the assumption that all firmware irq representations will be an array
of u32 values is going to hold up. I'd rather state upfront that the
device tree translation really is device tree and let translations for
other representation have the option of defining their own API.
However, that is not a strong objection, and if Thomas agrees with you
then I'm okay with renaming of_irq_domain to irq_domain and moving it
to kernel/irq/irqdomain.c. The mapping functionality I think should
stay out for now until we come to agreement on how it should look, and
I'll fix up any users if the API needs to change at a later date.
g.
>
> > PowerPC and x86 have been converted to use of_irq_domain. MIPS and
> > Microblaze have it enabled, but nothing actually registers domains
> > yet, so a workaround is in place to preserve the current behaviour
> > until it is fixed.
> >
> > I'd really like to get patches 1-4 merged into 2.6.40. Please test.
> > I'm also running through build testing here, and when it's complete
> > I'll push it out to a 'devicetree/irq-domain' branch on
> > git://git.secretlab.ca/git/linux-2.6
> >
> > It needs testing. I've booted it on a powerpc board here without any
> > apparent regressions, but that isn't a very big sample. I've also
> > build tested on everything I think is affected.
> >
> > I'd also like to get it into linux-next. Ben, if things checkout okay
> > over the next few days, would you be okay with me adding it to
> > linux-next, say around Wednesday next week? As for merging, I think
> > this should probably go via your powerpc tree since the that's where
> > the bulk of the changes are, but I'm open to other suggestions).
> >
> > Patches 5 & 6 are follow-on cleanup work to powerpc, but patch 6 is
> > RFC only since there is a locking problem that I haven't fixed yet.
> >
> > Cheers,
> > g.
> >
> > ---
> >
> > Grant Likely (6):
> > powerpc: stop exporting irq_map
> > powerpc: make irq_{alloc,free}_virt private and remove count argument
> > powerpc: Make struct irq_host semi-private by moving into irqhost.h
> > dt: generalize of_irq_parse_and_map()
> > powerpc: move irq_alloc_descs_at() call into irq_alloc_virt()
> > powerpc: use irq_alloc_desc() to manage irq allocations
> >
> >
> > arch/microblaze/kernel/irq.c | 7 -
> > arch/microblaze/kernel/setup.c | 2
> > arch/mips/kernel/prom.c | 14 -
> > arch/powerpc/include/asm/irq.h | 88 +------
> > arch/powerpc/include/asm/irqhost.h | 27 ++
> > arch/powerpc/kernel/irq.c | 260 ++++++++++++----------
> > arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 5
> > arch/powerpc/platforms/52xx/media5200.c | 5
> > arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 1
> > arch/powerpc/platforms/52xx/mpc52xx_pic.c | 80 +------
> > arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 5
> > arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 26 +-
> > arch/powerpc/platforms/86xx/gef_pic.c | 10 -
> > arch/powerpc/platforms/8xx/m8xx_setup.c | 2
> > arch/powerpc/platforms/cell/axon_msi.c | 15 +
> > arch/powerpc/platforms/cell/spider-pic.c | 19 +-
> > arch/powerpc/platforms/embedded6xx/flipper-pic.c | 9 -
> > arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 9 -
> > arch/powerpc/platforms/embedded6xx/wii.c | 6 -
> > arch/powerpc/platforms/iseries/irq.c | 10 -
> > arch/powerpc/platforms/powermac/pic.c | 12 +
> > arch/powerpc/platforms/pseries/ras.c | 4
> > arch/powerpc/platforms/pseries/xics.c | 14 +
> > arch/powerpc/sysdev/cpm1.c | 8 -
> > arch/powerpc/sysdev/cpm2_pic.c | 10 -
> > arch/powerpc/sysdev/fsl_msi.c | 3
> > arch/powerpc/sysdev/i8259.c | 3
> > arch/powerpc/sysdev/ipic.c | 19 +-
> > arch/powerpc/sysdev/mpc8xx_pic.c | 10 -
> > arch/powerpc/sysdev/mpc8xxx_gpio.c | 13 +
> > arch/powerpc/sysdev/mpic.c | 33 +--
> > arch/powerpc/sysdev/mpic_msi.c | 3
> > arch/powerpc/sysdev/mpic_pasemi_msi.c | 5
> > arch/powerpc/sysdev/mv64x60_pic.c | 14 +
> > arch/powerpc/sysdev/qe_lib/qe_ic.c | 9 -
> > arch/powerpc/sysdev/uic.c | 13 +
> > arch/powerpc/sysdev/xilinx_intc.c | 9 -
> > arch/x86/include/asm/irq_controller.h | 12 -
> > arch/x86/include/asm/prom.h | 1
> > arch/x86/kernel/devicetree.c | 77 +------
> > drivers/of/irq.c | 118 ++++++++++
> > include/linux/of_irq.h | 31 +++
> > 42 files changed, 504 insertions(+), 517 deletions(-)
> > create mode 100644 arch/powerpc/include/asm/irqhost.h
> > delete mode 100644 arch/x86/include/asm/irq_controller.h
>
>
^ permalink raw reply
* Re: [PATCH 2/6] powerpc: make irq_{alloc, free}_virt private and remove count argument
From: Grant Likely @ 2011-05-04 15:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michal Simek, Sebastian Andrzej Siewior, x86, linux-kernel,
Ralf Baechle, hpa, Dirk Brandewie, Thomas Gleixner, linuxppc-dev,
devicetree-discuss
In-Reply-To: <1304387267.2513.298.camel@pasglop>
On Tue, May 03, 2011 at 11:47:47AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2011-04-28 at 14:01 -0600, Grant Likely wrote:
> > irq_alloc_virt() and irq_free_virt() aren't called anywhere but from
> > arch/powerpc/kernel/irq.c, and they are only ever called with count=1.
> > This patch removes the prototypes from the header file, removes the
> > count arguments, and cuts out the dead code.
> >
> > Also removes obsolete references to irq_early_init()
>
> Nack.
>
> The count was intended to be able to allocate blocks of interrupts. This
> was not used so far because we didn't support MSI blocks (for non-X
> MSIs) but that is coming, and unfortunately, the API that was designed
> for that is crap and requires contiguous IRQ numbers on the linux side
> as well as on the device side (well device side is a HW requirement but
> we could have been smarter on the Linux side).
>
> So the ability to allocate blocks will be needed. In fact it's not clear
> yet whether we'll also need them to be naturally aligned powers of two
> or not at this stage. It depends how the bloody API is going to be used
> by drivers.
Heh, I wondered about that, but there hasn't been any users for at
least 5 years (as evidenced by commit e12514650b, "Fix loop logic in
irq_alloc_virt()") so it was looking pretty dead, and it made the
patch to switch to using irq_alloc_desc*() quite a bit simpler if it
was removed. :-)
I'm not particularly attached to this patch, so I can drop it from the
series.
g.
^ permalink raw reply
* Re: [PATCH 4/6] dt: generalize irq_of_create_mapping()
From: Grant Likely @ 2011-05-04 16:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michal Simek, Sebastian Andrzej Siewior, x86, linux-kernel,
Ralf Baechle, hpa, Dirk Brandewie, Thomas Gleixner, linuxppc-dev,
devicetree-discuss
In-Reply-To: <1304387422.2513.301.camel@pasglop>
On Tue, May 03, 2011 at 11:50:22AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2011-04-28 at 14:02 -0600, Grant Likely wrote:
> > This patch creates a common implementation of irq_of_create_mapping()
> > and factors out the interrupt domain translation code from powerpc to
> > make it available for all architectures.
>
> I think you are going the wrong way around.
>
> First thing first, is to make the irq domain / mapping API generic
> without the OF bits.
>
> IE. move the IRQ domain generically, get rid of irq_map by putting the
> domain ptr & hw numbers in the irq desc/data etc...
>
> Then you can move over the OF specific bits which are optional and
> orthogonal to a large extent.
As discussed in my other reply, I disagree. There isn't an immediate
need for the mapping interface in common code. It would be useful,
sure, for some interrupt controllers, but for many of them
irq_alloc_descs() and an irq_base value is all the functionality that
is needed, and irq_host doesn't gain anything.
The OF translation on the other hand is needed immediately by several
architectures and are very much non-optional in that regard.
g.
^ permalink raw reply
* Re: [PATCH] atomic: add *_dec_not_zero
From: Will Deacon @ 2011-05-04 17:27 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-arch, linux-mips, linux-m68k, linux-m32r, linux-ia64,
linux-cris-kernel, linux-parisc, linux-s390, linux-sh,
linux-kernel, Chris Metcalf, David Howells, linux-am33-list,
linux-alpha, sparclinux, uclinux-dist-devel, x86, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1304458235-28473-1-git-send-email-sven@narfation.org>
On Tue, 2011-05-03 at 22:30 +0100, Sven Eckelmann wrote:
> Introduce an *_dec_not_zero operation. Make this a special case of
> *_add_unless because batman-adv uses atomic_dec_not_zero in different
> places like re-broadcast queue or aggregation queue management. There
> are other non-final patches which may also want to use this macro.
>
For the ARM changes:
Acked-by: Will Deacon <will.deacon@arm.com>
Cheers,
Will
^ permalink raw reply
* Re: [PATCH] atomic: add *_dec_not_zero
From: Matt Turner @ 2011-05-04 18:13 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-arch, linux-mips, linux-m32r, linux-ia64, linux-parisc,
linux-cris-kernel, linux-s390, linux-sh, x86, linux-kernel,
Chris Metcalf, David Howells, linux-m68k, linux-am33-list,
linux-alpha, sparclinux, uclinux-dist-devel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1304458235-28473-1-git-send-email-sven@narfation.org>
On Tue, May 3, 2011 at 5:30 PM, Sven Eckelmann <sven@narfation.org> wrote:
> diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/ato=
mic.h
> index e756d04..7e9434e 100644
> --- a/arch/alpha/include/asm/atomic.h
> +++ b/arch/alpha/include/asm/atomic.h
> @@ -200,6 +200,7 @@ static __inline__ int atomic_add_unless(atomic_t *v, =
int a, int u)
> =A0}
>
> =A0#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
> +#define atomic_dec_not_zero(v) atomic_add_unless((v), -1, 0)
>
> =A0/**
> =A0* atomic64_add_unless - add unless the number is a given value
> @@ -226,6 +227,7 @@ static __inline__ int atomic64_add_unless(atomic64_t =
*v, long a, long u)
> =A0}
>
> =A0#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
> +#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
>
> =A0#define atomic_add_negative(a, v) (atomic_add_return((a), (v)) < 0)
> =A0#define atomic64_add_negative(a, v) (atomic64_add_return((a), (v)) < 0=
)
> diff --git a/arch/alpha/include/asm/local.h b/arch/alpha/include/asm/loca=
l.h
> index b9e3e33..09fb327 100644
> --- a/arch/alpha/include/asm/local.h
> +++ b/arch/alpha/include/asm/local.h
> @@ -79,6 +79,7 @@ static __inline__ long local_sub_return(long i, local_t=
* l)
> =A0 =A0 =A0 =A0c !=3D (u); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0})
> =A0#define local_inc_not_zero(l) local_add_unless((l), 1, 0)
> +#define local_dec_not_zero(l) local_add_unless((l), -1, 0)
>
> =A0#define local_add_negative(a, l) (local_add_return((a), (l)) < 0)
>
Acked-by: Matt Turner <mattst88@gmail.com> [alpha]
^ permalink raw reply
* [RFC][PATCH] powerpc: respect how command line nr_cpus is set
From: Kumar Gala @ 2011-05-04 20:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
We should utilize nr_cpus as the max # of CPUs that we can have present
instead of NR_CPUS. This way we actually respect how nr_cpus is set on
the command line rather than ignoring it.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
I think this is what we should be doing, but would like someone else to take
a look.
- k
arch/powerpc/kernel/setup-common.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 21f30cb..fedf813 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -424,7 +424,7 @@ void __init smp_setup_cpu_maps(void)
DBG("smp_setup_cpu_maps()\n");
- while ((dn = of_find_node_by_type(dn, "cpu")) && cpu < NR_CPUS) {
+ while ((dn = of_find_node_by_type(dn, "cpu")) && cpu < nr_cpu_ids) {
const int *intserv;
int j, len;
@@ -443,7 +443,7 @@ void __init smp_setup_cpu_maps(void)
intserv = &cpu; /* assume logical == phys */
}
- for (j = 0; j < nthreads && cpu < NR_CPUS; j++) {
+ for (j = 0; j < nthreads && cpu < nr_cpu_ids; j++) {
DBG(" thread %d -> cpu %d (hard id %d)\n",
j, cpu, intserv[j]);
set_cpu_present(cpu, true);
@@ -483,12 +483,12 @@ void __init smp_setup_cpu_maps(void)
if (cpu_has_feature(CPU_FTR_SMT))
maxcpus *= nthreads;
- if (maxcpus > NR_CPUS) {
+ if (maxcpus > nr_cpu_ids) {
printk(KERN_WARNING
"Partition configured for %d cpus, "
"operating system maximum is %d.\n",
- maxcpus, NR_CPUS);
- maxcpus = NR_CPUS;
+ maxcpus, nr_cpu_ids);
+ maxcpus = nr_cpu_ids;
} else
printk(KERN_INFO "Partition configured for %d cpus.\n",
maxcpus);
--
1.7.3.4
^ permalink raw reply related
* [PATCH] powerpc: ensure dtl buffers do not cross 4k boundary
From: Nishanth Aravamudan @ 2011-05-04 22:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
Future releases of fimrware will enforce a requirement that DTL buffers
do not cross a 4k boundary. Commit
127493d5dc73589cbe00ea5ec8357cc2a4c0d82a satisfies this requirement for
CONFIG_VIRT_CPU_ACCOUNTING=y kernels, but if !CONFIG_VIRT_CPU_ACCOUNTING
&& CONFIG_DTL=y, the current code will fail at dtl registration time.
Fix this by making the kmem cache from
127493d5dc73589cbe00ea5ec8357cc2a4c0d82a visible outside of setup.c and
using the same cache in both dtl.c and setup.c. This requires a bit of
reorganization to ensure ordering of the kmem cache and buffer
allocations.
Note: Since firmware now limits the size of the buffer, I made
dtl_buf_entries read-only in debugfs.
Tested with upcoming firmware with the 4 combinations of
CONFIG_VIRT_CPU_ACCOUNTING and CONFIG_DTL.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
Paul, why should `cat /sys/kernel/debug/powerpc/dtl/cpu-0` return
EINVAL? I understand why it does from the code as the page size (4k or
64k) is not evenly divisble by 48 bytes, but is that EINVAL just to
avoid dealing with short reads?
arch/powerpc/include/asm/lppaca.h | 2 ++
arch/powerpc/platforms/pseries/dtl.c | 20 +++++++++++---------
arch/powerpc/platforms/pseries/setup.c | 31 ++++++++++++++++++++++---------
3 files changed, 35 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h b/arch/powerpc/include/asm/lppaca.h
index a077adc..e0298d2 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -210,6 +210,8 @@ struct dtl_entry {
#define DISPATCH_LOG_BYTES 4096 /* bytes per cpu */
#define N_DISPATCH_LOG (DISPATCH_LOG_BYTES / sizeof(struct dtl_entry))
+extern struct kmem_cache *dtl_cache;
+
/*
* When CONFIG_VIRT_CPU_ACCOUNTING = y, the cpu accounting code controls
* reading from the dispatch trace log. If other code wants to consume
diff --git a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/pseries/dtl.c
index c371bc0..e919007 100644
--- a/arch/powerpc/platforms/pseries/dtl.c
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -52,10 +52,10 @@ static u8 dtl_event_mask = 0x7;
/*
- * Size of per-cpu log buffers. Default is just under 16 pages worth.
+ * Size of per-cpu log buffers. Firmware requires that the buffer does
+ * not cross a 4k boundary.
*/
-static int dtl_buf_entries = (16 * 85);
-
+static int dtl_buf_entries = N_DISPATCH_LOG;
#ifdef CONFIG_VIRT_CPU_ACCOUNTING
struct dtl_ring {
@@ -151,7 +151,7 @@ static int dtl_start(struct dtl *dtl)
/* Register our dtl buffer with the hypervisor. The HV expects the
* buffer size to be passed in the second word of the buffer */
- ((u32 *)dtl->buf)[1] = dtl->buf_entries * sizeof(struct dtl_entry);
+ ((u32 *)dtl->buf)[1] = DISPATCH_LOG_BYTES;
hwcpu = get_hard_smp_processor_id(dtl->cpu);
addr = __pa(dtl->buf);
@@ -196,13 +196,15 @@ static int dtl_enable(struct dtl *dtl)
long int rc;
struct dtl_entry *buf = NULL;
+ if (!dtl_cache)
+ return -ENOMEM;
+
/* only allow one reader */
if (dtl->buf)
return -EBUSY;
n_entries = dtl_buf_entries;
- buf = kmalloc_node(n_entries * sizeof(struct dtl_entry),
- GFP_KERNEL, cpu_to_node(dtl->cpu));
+ buf = kmem_cache_alloc_node(dtl_cache, GFP_KERNEL, cpu_to_node(dtl->cpu));
if (!buf) {
printk(KERN_WARNING "%s: buffer alloc failed for cpu %d\n",
__func__, dtl->cpu);
@@ -223,7 +225,7 @@ static int dtl_enable(struct dtl *dtl)
spin_unlock(&dtl->lock);
if (rc)
- kfree(buf);
+ kmem_cache_free(dtl_cache, buf);
return rc;
}
@@ -231,7 +233,7 @@ static void dtl_disable(struct dtl *dtl)
{
spin_lock(&dtl->lock);
dtl_stop(dtl);
- kfree(dtl->buf);
+ kmem_cache_free(dtl_cache, dtl->buf);
dtl->buf = NULL;
dtl->buf_entries = 0;
spin_unlock(&dtl->lock);
@@ -365,7 +367,7 @@ static int dtl_init(void)
event_mask_file = debugfs_create_x8("dtl_event_mask", 0600,
dtl_dir, &dtl_event_mask);
- buf_entries_file = debugfs_create_u32("dtl_buf_entries", 0600,
+ buf_entries_file = debugfs_create_u32("dtl_buf_entries", 0400,
dtl_dir, &dtl_buf_entries);
if (!event_mask_file || !buf_entries_file) {
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 6c42cfd..b6ecd04 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -276,6 +276,8 @@ static struct notifier_block pci_dn_reconfig_nb = {
.notifier_call = pci_dn_reconfig_notifier,
};
+struct kmem_cache *dtl_cache;
+
#ifdef CONFIG_VIRT_CPU_ACCOUNTING
/*
* Allocate space for the dispatch trace log for all possible cpus
@@ -287,18 +289,12 @@ static int alloc_dispatch_logs(void)
int cpu, ret;
struct paca_struct *pp;
struct dtl_entry *dtl;
- struct kmem_cache *dtl_cache;
if (!firmware_has_feature(FW_FEATURE_SPLPAR))
return 0;
- dtl_cache = kmem_cache_create("dtl", DISPATCH_LOG_BYTES,
- DISPATCH_LOG_BYTES, 0, NULL);
- if (!dtl_cache) {
- pr_warn("Failed to create dispatch trace log buffer cache\n");
- pr_warn("Stolen time statistics will be unreliable\n");
+ if (!dtl_cache)
return 0;
- }
for_each_possible_cpu(cpu) {
pp = &paca[cpu];
@@ -332,10 +328,27 @@ static int alloc_dispatch_logs(void)
return 0;
}
-
-early_initcall(alloc_dispatch_logs);
+#else /* !CONFIG_VIRT_CPU_ACCOUNTING */
+static inline int alloc_dispatch_logs(void)
+{
+ return 0;
+}
#endif /* CONFIG_VIRT_CPU_ACCOUNTING */
+static int alloc_dispatch_log_kmem_cache(void)
+{
+ dtl_cache = kmem_cache_create("dtl", DISPATCH_LOG_BYTES,
+ DISPATCH_LOG_BYTES, 0, NULL);
+ if (!dtl_cache) {
+ pr_warn("Failed to create dispatch trace log buffer cache\n");
+ pr_warn("Stolen time statistics will be unreliable\n");
+ return 0;
+ }
+
+ return alloc_dispatch_logs();
+}
+early_initcall(alloc_dispatch_log_kmem_cache);
+
static void __init pSeries_setup_arch(void)
{
/* Discover PIC type and setup ppc_md accordingly */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/3] [repost] powerpc/eeh: Display eeh error location for bus and device
From: Richard A Lary @ 2011-05-04 22:57 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt, antonb
From: Richard A Lary <rlary@linux.vnet.ibm.com>
For adapters which have devices under a PCIe switch/bridge it is informative
to display information for both the PCIe switch/bridge and the device on
which the bus error was detected.
rebased to powerpc-next
Signed-off-by: Richard A Lary <rlary@linux.vnet.ibm.com>
---
---
arch/powerpc/platforms/pseries/eeh_driver.c | 22 13 + 9 - 0 !
1 file changed, 13 insertions(+), 9 deletions(-)
Index: b/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- a/arch/powerpc/platforms/pseries/eeh_driver.c
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c
@@ -328,7 +328,7 @@ struct pci_dn * handle_eeh_events (struc
struct pci_bus *frozen_bus;
int rc = 0;
enum pci_ers_result result = PCI_ERS_RESULT_NONE;
- const char *location, *pci_str, *drv_str;
+ const char *location, *pci_str, *drv_str, *bus_pci_str, *bus_drv_str;
frozen_dn = find_device_pe(event->dn);
if (!frozen_dn) {
@@ -364,13 +364,8 @@ struct pci_dn * handle_eeh_events (struc
frozen_pdn = PCI_DN(frozen_dn);
frozen_pdn->eeh_freeze_count++;
- if (frozen_pdn->pcidev) {
- pci_str = pci_name (frozen_pdn->pcidev);
- drv_str = pcid_name (frozen_pdn->pcidev);
- } else {
- pci_str = eeh_pci_name(event->dev);
- drv_str = pcid_name (event->dev);
- }
+ pci_str = eeh_pci_name(event->dev);
+ drv_str = pcid_name(event->dev);
if (frozen_pdn->eeh_freeze_count > EEH_MAX_ALLOWED_FREEZES)
goto excess_failures;
@@ -378,8 +373,17 @@ struct pci_dn * handle_eeh_events (struc
printk(KERN_WARNING
"EEH: This PCI device has failed %d times in the last hour:\n",
frozen_pdn->eeh_freeze_count);
+
+ if (frozen_pdn->pcidev) {
+ bus_pci_str = pci_name(frozen_pdn->pcidev);
+ bus_drv_str = pcid_name(frozen_pdn->pcidev);
+ printk(KERN_WARNING
+ "EEH: Bus location=%s driver=%s pci addr=%s\n",
+ location, bus_drv_str, bus_pci_str);
+ }
+
printk(KERN_WARNING
- "EEH: location=%s driver=%s pci addr=%s\n",
+ "EEH: Device location=%s driver=%s pci addr=%s\n",
location, drv_str, pci_str);
/* Walk the various device drivers attached to this slot through
^ permalink raw reply
* Re: [PATCH 0/6] General device tree irq domain infrastructure
From: Benjamin Herrenschmidt @ 2011-05-05 0:39 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, Sebastian Andrzej Siewior, x86, linux-kernel,
Ralf Baechle, hpa, Dirk Brandewie, Thomas Gleixner, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20110504155227.GA3317@ponder.secretlab.ca>
> I completely agree that irq domains are a generically useful feature
> for architectures, and it should be made available. I also completely
> agree that it is orthogonal to device tree translations, which in a
> large part is why I've structured this series and the new code the
> way I have.
>
> In this series I'm specifically addressing device tree translation,
> which is the one bit that is DT specific, and is important regardless
> of the backend translation mechanism. In fact, the more I looked at
> it, the more it seems that the DT api really is orthogonal to the
> backend irq mapping and I don't think that the way irq_host ties them
> together is necessarily the best way to do it. Many of the interrupt
> controllers which need to gain dt irq parsing have already been
> converted to using the irq_alloc_desc*() apis and have all the mapping
> mechanism they need, but lack a method of exposing it for DT
> translation.
But irq_alloc_desc() is purely about allocating the linux side irq
descriptors. Nothing to do with HW numbers here.
You still need a mapping mechanism, regardless of the device-tree, to
map those linux number to your HW numbers.
This is simple and eventually even 1:1 on things like x86, but the
minute you start having cascaded IRQ controllers, multiple IRQ domains,
and/or very large HW numbers that encode node IDs etc... this falls
appart.
And this is still completely orthogonal to the device-tree.
Mapping is the important functionality. Whatever the actual allocator is
is indeed irrelevant.
> As for the mapping, I agree that the functionality is generally
> useful, I'm just not fond of the current implementation. I think it
> is more complex than it needs to be and I'm not excited about bring it
> over to the other architectures as-is.
Nobody cares about the current implementation. What is important is
indeed the functionality. The basic thing I think everybody agrees is
that you need to extend the irq_desc (or data, whatever tglx prefers)
with two bits of information: Some identifier of the domain and some
identifier of the interrupt number within that domain.
In addition, PIC code will need a way to perform efficient reverse
mapping. You may decide that for simple IRQ controllers that handle a
small linear range of interrupts, it's kosher to simply reserve a linear
range of descriptors and use a simple offset, I'm find with that now
that we no longer live in a world constrained by NR_IRQ.
But the need for the radix tree remains for things that have massively
large potential HW numbers such as we have on powerpc.
> For the majority of fixed hw interrupt controllers it is overkill.
> There is no need for a map table when all the irq descs (<=32 of them)
> get allocated when the irq controller is instantiated and the mapping
> consists of 'virq = hw_irq + virq_base'. For instance, with the arm
> irq controllers, it's be more than sufficient to use irq_alloc_descs
> to obtain a range of irq numbers and then a simple of_irq_domain
> registration to handle the parsing.
That's true if and only if you make NR_IRQ a non issue and if you accept
the general wastage due to unused interrupts.
The main problem has always been that hard limit which made me chose a
more efficient mechanisms. Take a mac with 2 cascaded MPICs with 256
sources each which are mostly never used. I would need an NR_IRQs of 512
with your scheme (plus 16 because I do want to continue avoiding the
"ISA" numbers), which is a waste of space, even with SPARSE_IRQ.
Now I hope eventually NR_IRQ will go away and we'll have a more
efficient mechanism to allocate descriptors and so it will become less
of an issue.
> For the cases where an interrupt controller isn't able to alloc all
> the irq descs at once, like for MSI, then yes the LINEAR and RADIX
> mappings are important. What bothers me though is the way irq_host
> needs to use unions and the ->revmap_type value to implement multiple
> behaviours into a single type. That's the sort of thing that can be
> broken out into a library and instantiated only by the interrupt
> controllers that actually need it.
But that's what it is really. You'll notice that on the fast path the
interrupt controller code calls directly into the "right" type of revmap
routine. You may want to refactor things a bit if you want, but the
union served me well simply because I didnt have to bother doing lots of
different alloc_bootmem back then. Nowadays, kmalloc is available much
earlier so it might have become a non issue too.
> Similarly, it bothers me that that
> radix mapping makes up a significant portion of the code, yet it has
> only one user.
"significant" ? Seriously ? Like 3 function calls ? It's nothing. We use
an existing radix tree facility, and the amount of code in our irq.c is
actually very small.
Originally it was living in xics in fact, but I moved it out
specifically because I wanted a common interface to remapping, so for
example, I can expose the linux -> hw mapping in debugfs generically,
among others.
> I'd be happier if each kind of mapping had its own
> structure that embedded a generic irq_host/irq_domain with mapping
> specific ops populated to manipulate it.
Whatever, that's just plumbing, I don't care either way, that doesn't
change the fact that the concept of domain doesn't have much to do with
OF :-)
> Regardless, the immediate priority is to implement a mapper that will
> work for all architectures (or at least everything but powerpc and
> sparc).
I oppose the implementation of a new mapper that doesn't include
powerpc, that would be stupid. Either re-use ours or implement a new one
that encompass our needs. I can't talk for sparc but I wouldn't be
surprised if David thought about the same lines.
> x86 has already implemented a skeleton irq_domain because
> there wasn't any common code for it to use. ARM also needs the
> functionality immediately, and I don't want to see yet another
> arch-specific implementation. I'd like to get the framework in place
> now, and grafting in mapping features as follow on patches. That way
> the new DT users aren't blocked while waiting for us to hammer down
> the features that the other architectures don't need yet.
But the mapping code exist already. It returns a device-node as the
interrupt controller. What you then need is to establish the
relationship between that device-node and a domain in linux, and have
code to decode the content of the interrupts property.
So you need the concept of domain first, generic, and -then- you can
start adding a way to bind it to OF.
> What I /could/ have done I suppose was called it 'struct irq_domain'
> as you suggest, and allowed each translation mechanism to define its
> own match/map pair of routines, with device tree being the only one
> actually implemented at this point. Yes, I understand that the
> core code treats the controller pointer as an anonymous cookie, but
> the api is still very device tree centric, and I'm not convinced that
> the assumption that all firmware irq representations will be an array
> of u32 values is going to hold up.
How so ?
> I'd rather state upfront that the
> device tree translation really is device tree and let translations for
> other representation have the option of defining their own API.
>
> However, that is not a strong objection, and if Thomas agrees with you
> then I'm okay with renaming of_irq_domain to irq_domain and moving it
> to kernel/irq/irqdomain.c. The mapping functionality I think should
> stay out for now until we come to agreement on how it should look, and
> I'll fix up any users if the API needs to change at a later date.
But I think the mapping functionality is what needs to be sorted first.
Cheers
Ben.
> g.
>
>
>
> >
> > > PowerPC and x86 have been converted to use of_irq_domain. MIPS and
> > > Microblaze have it enabled, but nothing actually registers domains
> > > yet, so a workaround is in place to preserve the current behaviour
> > > until it is fixed.
> > >
> > > I'd really like to get patches 1-4 merged into 2.6.40. Please test.
> > > I'm also running through build testing here, and when it's complete
> > > I'll push it out to a 'devicetree/irq-domain' branch on
> > > git://git.secretlab.ca/git/linux-2.6
> > >
> > > It needs testing. I've booted it on a powerpc board here without any
> > > apparent regressions, but that isn't a very big sample. I've also
> > > build tested on everything I think is affected.
> > >
> > > I'd also like to get it into linux-next. Ben, if things checkout okay
> > > over the next few days, would you be okay with me adding it to
> > > linux-next, say around Wednesday next week? As for merging, I think
> > > this should probably go via your powerpc tree since the that's where
> > > the bulk of the changes are, but I'm open to other suggestions).
> > >
> > > Patches 5 & 6 are follow-on cleanup work to powerpc, but patch 6 is
> > > RFC only since there is a locking problem that I haven't fixed yet.
> > >
> > > Cheers,
> > > g.
> > >
> > > ---
> > >
> > > Grant Likely (6):
> > > powerpc: stop exporting irq_map
> > > powerpc: make irq_{alloc,free}_virt private and remove count argument
> > > powerpc: Make struct irq_host semi-private by moving into irqhost.h
> > > dt: generalize of_irq_parse_and_map()
> > > powerpc: move irq_alloc_descs_at() call into irq_alloc_virt()
> > > powerpc: use irq_alloc_desc() to manage irq allocations
> > >
> > >
> > > arch/microblaze/kernel/irq.c | 7 -
> > > arch/microblaze/kernel/setup.c | 2
> > > arch/mips/kernel/prom.c | 14 -
> > > arch/powerpc/include/asm/irq.h | 88 +------
> > > arch/powerpc/include/asm/irqhost.h | 27 ++
> > > arch/powerpc/kernel/irq.c | 260 ++++++++++++----------
> > > arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 5
> > > arch/powerpc/platforms/52xx/media5200.c | 5
> > > arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 1
> > > arch/powerpc/platforms/52xx/mpc52xx_pic.c | 80 +------
> > > arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 5
> > > arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 26 +-
> > > arch/powerpc/platforms/86xx/gef_pic.c | 10 -
> > > arch/powerpc/platforms/8xx/m8xx_setup.c | 2
> > > arch/powerpc/platforms/cell/axon_msi.c | 15 +
> > > arch/powerpc/platforms/cell/spider-pic.c | 19 +-
> > > arch/powerpc/platforms/embedded6xx/flipper-pic.c | 9 -
> > > arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 9 -
> > > arch/powerpc/platforms/embedded6xx/wii.c | 6 -
> > > arch/powerpc/platforms/iseries/irq.c | 10 -
> > > arch/powerpc/platforms/powermac/pic.c | 12 +
> > > arch/powerpc/platforms/pseries/ras.c | 4
> > > arch/powerpc/platforms/pseries/xics.c | 14 +
> > > arch/powerpc/sysdev/cpm1.c | 8 -
> > > arch/powerpc/sysdev/cpm2_pic.c | 10 -
> > > arch/powerpc/sysdev/fsl_msi.c | 3
> > > arch/powerpc/sysdev/i8259.c | 3
> > > arch/powerpc/sysdev/ipic.c | 19 +-
> > > arch/powerpc/sysdev/mpc8xx_pic.c | 10 -
> > > arch/powerpc/sysdev/mpc8xxx_gpio.c | 13 +
> > > arch/powerpc/sysdev/mpic.c | 33 +--
> > > arch/powerpc/sysdev/mpic_msi.c | 3
> > > arch/powerpc/sysdev/mpic_pasemi_msi.c | 5
> > > arch/powerpc/sysdev/mv64x60_pic.c | 14 +
> > > arch/powerpc/sysdev/qe_lib/qe_ic.c | 9 -
> > > arch/powerpc/sysdev/uic.c | 13 +
> > > arch/powerpc/sysdev/xilinx_intc.c | 9 -
> > > arch/x86/include/asm/irq_controller.h | 12 -
> > > arch/x86/include/asm/prom.h | 1
> > > arch/x86/kernel/devicetree.c | 77 +------
> > > drivers/of/irq.c | 118 ++++++++++
> > > include/linux/of_irq.h | 31 +++
> > > 42 files changed, 504 insertions(+), 517 deletions(-)
> > > create mode 100644 arch/powerpc/include/asm/irqhost.h
> > > delete mode 100644 arch/x86/include/asm/irq_controller.h
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 2/6] powerpc: make irq_{alloc, free}_virt private and remove count argument
From: Benjamin Herrenschmidt @ 2011-05-05 0:39 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, Sebastian Andrzej Siewior, x86, linux-kernel,
Ralf Baechle, hpa, Dirk Brandewie, Thomas Gleixner, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20110504155905.GB3317@ponder.secretlab.ca>
On Wed, 2011-05-04 at 09:59 -0600, Grant Likely wrote:
>
> Heh, I wondered about that, but there hasn't been any users for at
> least 5 years (as evidenced by commit e12514650b, "Fix loop logic in
> irq_alloc_virt()") so it was looking pretty dead, and it made the
> patch to switch to using irq_alloc_desc*() quite a bit simpler if it
> was removed. :-)
>
> I'm not particularly attached to this patch, so I can drop it from the
> series.
Well, Willy recently added support for the MSI block allocation so ...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 4/6] dt: generalize irq_of_create_mapping()
From: Benjamin Herrenschmidt @ 2011-05-05 0:43 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, Sebastian Andrzej Siewior, x86, linux-kernel,
Ralf Baechle, hpa, Dirk Brandewie, Thomas Gleixner, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20110504160502.GC3317@ponder.secretlab.ca>
On Wed, 2011-05-04 at 10:05 -0600, Grant Likely wrote:
> > I think you are going the wrong way around.
> >
> > First thing first, is to make the irq domain / mapping API generic
> > without the OF bits.
> >
> > IE. move the IRQ domain generically, get rid of irq_map by putting
> the
> > domain ptr & hw numbers in the irq desc/data etc...
> >
> > Then you can move over the OF specific bits which are optional and
> > orthogonal to a large extent.
>
> As discussed in my other reply, I disagree. There isn't an immediate
> need for the mapping interface in common code. It would be useful,
> sure, for some interrupt controllers, but for many of them
> irq_alloc_descs() and an irq_base value is all the functionality that
> is needed, and irq_host doesn't gain anything.
No but the concept of domain is a pre-requisite. Even if it's an opaque
data structure. And I don't want to have it be some "of" specific thing.
> The OF translation on the other hand is needed immediately by several
> architectures and are very much non-optional in that regard.
But it relies on having an underlying mapping. I don't see how you can
do one without the other, even if your mapping in effect is just an
offset.
And it is -not- related to OF.
Whether you obtain that your interrupt you are interested it is
interrupt 5 of your PIC "foo" via the device-tree or any other way (an
arch quirk for example), you need the mechanism to associate them
together, whether it's a simple offset as you propose (I'm ok with that
for simple things, I just didn't think it was the right approach for
powerpc but it's perfectly valid as an option generically) or a more
complex radix-tree style mapping.
Thus sort out the mapping interfaces first. _Then_ layout the
device-tree bits on top.
The basic parsing for the DT is already there. It will return a parent
node and a __be32* pointer.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC][PATCH] powerpc: respect how command line nr_cpus is set
From: Benjamin Herrenschmidt @ 2011-05-05 2:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1304540257-19831-1-git-send-email-galak@kernel.crashing.org>
On Wed, 2011-05-04 at 15:17 -0500, Kumar Gala wrote:
> We should utilize nr_cpus as the max # of CPUs that we can have present
> instead of NR_CPUS. This way we actually respect how nr_cpus is set on
> the command line rather than ignoring it.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> I think this is what we should be doing, but would like someone else to take
> a look.
The main question I have is should max_cpus absolutely limit the number
of possible CPUs or should it limit the number that get automatically
onlined at boot, potentially letting us bring the rest online later on ?
Cheers,
Ben.
> - k
>
> arch/powerpc/kernel/setup-common.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index 21f30cb..fedf813 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -424,7 +424,7 @@ void __init smp_setup_cpu_maps(void)
>
> DBG("smp_setup_cpu_maps()\n");
>
> - while ((dn = of_find_node_by_type(dn, "cpu")) && cpu < NR_CPUS) {
> + while ((dn = of_find_node_by_type(dn, "cpu")) && cpu < nr_cpu_ids) {
> const int *intserv;
> int j, len;
>
> @@ -443,7 +443,7 @@ void __init smp_setup_cpu_maps(void)
> intserv = &cpu; /* assume logical == phys */
> }
>
> - for (j = 0; j < nthreads && cpu < NR_CPUS; j++) {
> + for (j = 0; j < nthreads && cpu < nr_cpu_ids; j++) {
> DBG(" thread %d -> cpu %d (hard id %d)\n",
> j, cpu, intserv[j]);
> set_cpu_present(cpu, true);
> @@ -483,12 +483,12 @@ void __init smp_setup_cpu_maps(void)
> if (cpu_has_feature(CPU_FTR_SMT))
> maxcpus *= nthreads;
>
> - if (maxcpus > NR_CPUS) {
> + if (maxcpus > nr_cpu_ids) {
> printk(KERN_WARNING
> "Partition configured for %d cpus, "
> "operating system maximum is %d.\n",
> - maxcpus, NR_CPUS);
> - maxcpus = NR_CPUS;
> + maxcpus, nr_cpu_ids);
> + maxcpus = nr_cpu_ids;
> } else
> printk(KERN_INFO "Partition configured for %d cpus.\n",
> maxcpus);
^ permalink raw reply
* linux-next: build failure after merge of the final tree (powerpc tree related)
From: Stephen Rothwell @ 2011-05-05 3:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: Michael Ellerman, Tseng-Hui (Frank) Lin, Sonny Rao, linux-kernel,
linux-next, Anton Blanchard
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
arch/powerpc/mm/mmu_context_hash64.c: In function 'init_new_context':
arch/powerpc/mm/mmu_context_hash64.c:282: error: 'NO_CONTEXT' undeclared (first use in this function)
Presumably caused by commit 851d2e2fe8db ("powerpc: Add Initiate
Coprocessor Store Word (icswx) support") interacting with commit
5e8e7b404ac9 ("powerpc/mm: Standardise on MMU_NO_CONTEXT").
I added the below patch for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 5 May 2011 13:32:02 +1000
Subject: [PATCH] powerpc: fix up mismerge in mmu_context_hash64.c
NO_CONTEXT was changed to MMU_NO_CONTEXT.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/mm/mmu_context_hash64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_hash64.c b/arch/powerpc/mm/mmu_context_hash64.c
index c517815..3bafc3d 100644
--- a/arch/powerpc/mm/mmu_context_hash64.c
+++ b/arch/powerpc/mm/mmu_context_hash64.c
@@ -279,7 +279,7 @@ int init_new_context(struct task_struct *tsk, struct mm_struct *mm)
if (!mm->context.cop_lockp) {
__destroy_context(index);
subpage_prot_free(mm);
- mm->context.id = NO_CONTEXT;
+ mm->context.id = MMU_NO_CONTEXT;
return -ENOMEM;
}
spin_lock_init(mm->context.cop_lockp);
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 0/6] General device tree irq domain infrastructure
From: Thomas Gleixner @ 2011-05-05 8:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michal Simek, Sebastian Andrzej Siewior, x86, linux-kernel,
Ralf Baechle, hpa, Dirk Brandewie, linuxppc-dev,
devicetree-discuss
In-Reply-To: <1304555953.2513.390.camel@pasglop>
On Thu, 5 May 2011, Benjamin Herrenschmidt wrote:
> > As for the mapping, I agree that the functionality is generally
> > useful, I'm just not fond of the current implementation. I think it
> > is more complex than it needs to be and I'm not excited about bring it
> > over to the other architectures as-is.
>
> Nobody cares about the current implementation. What is important is
> indeed the functionality. The basic thing I think everybody agrees is
> that you need to extend the irq_desc (or data, whatever tglx prefers)
> with two bits of information: Some identifier of the domain and some
> identifier of the interrupt number within that domain.
irq_data because that's what is handed into the callbacks and you
probably want to have the HW number there.
> In addition, PIC code will need a way to perform efficient reverse
> mapping. You may decide that for simple IRQ controllers that handle a
> small linear range of interrupts, it's kosher to simply reserve a linear
> range of descriptors and use a simple offset, I'm find with that now
> that we no longer live in a world constrained by NR_IRQ.
>
> But the need for the radix tree remains for things that have massively
> large potential HW numbers such as we have on powerpc.
>
> > For the majority of fixed hw interrupt controllers it is overkill.
> > There is no need for a map table when all the irq descs (<=32 of them)
> > get allocated when the irq controller is instantiated and the mapping
> > consists of 'virq = hw_irq + virq_base'. For instance, with the arm
> > irq controllers, it's be more than sufficient to use irq_alloc_descs
> > to obtain a range of irq numbers and then a simple of_irq_domain
> > registration to handle the parsing.
>
> That's true if and only if you make NR_IRQ a non issue and if you accept
> the general wastage due to unused interrupts.
>
> The main problem has always been that hard limit which made me chose a
> more efficient mechanisms. Take a mac with 2 cascaded MPICs with 256
> sources each which are mostly never used. I would need an NR_IRQs of 512
> with your scheme (plus 16 because I do want to continue avoiding the
> "ISA" numbers), which is a waste of space, even with SPARSE_IRQ.
>
> Now I hope eventually NR_IRQ will go away and we'll have a more
> efficient mechanism to allocate descriptors and so it will become less
> of an issue.
Well, NR_IRQS in the sparse case is irrelevant already and I'm looking
into a way to remove the !SPARSE code completely.
One thing we can do to avoid allocating 512 irq descriptors for the
MAC case is to reserve the space and only allocate the descriptors you
really need to be operational.
> > For the cases where an interrupt controller isn't able to alloc all
> > the irq descs at once, like for MSI, then yes the LINEAR and RADIX
> > mappings are important. What bothers me though is the way irq_host
> > needs to use unions and the ->revmap_type value to implement multiple
> > behaviours into a single type. That's the sort of thing that can be
> > broken out into a library and instantiated only by the interrupt
> > controllers that actually need it.
>
> But that's what it is really. You'll notice that on the fast path the
> interrupt controller code calls directly into the "right" type of revmap
> routine. You may want to refactor things a bit if you want, but the
> union served me well simply because I didnt have to bother doing lots of
> different alloc_bootmem back then. Nowadays, kmalloc is available much
> earlier so it might have become a non issue too.
>
> > Similarly, it bothers me that that
> > radix mapping makes up a significant portion of the code, yet it has
> > only one user.
>
> "significant" ? Seriously ? Like 3 function calls ? It's nothing. We use
> an existing radix tree facility, and the amount of code in our irq.c is
> actually very small.
>
> Originally it was living in xics in fact, but I moved it out
> specifically because I wanted a common interface to remapping, so for
> example, I can expose the linux -> hw mapping in debugfs generically,
> among others.
And there is another reverse mapping implementation in the superH
code.
> > I'd be happier if each kind of mapping had its own
> > structure that embedded a generic irq_host/irq_domain with mapping
> > specific ops populated to manipulate it.
>
> Whatever, that's just plumbing, I don't care either way, that doesn't
> change the fact that the concept of domain doesn't have much to do with
> OF :-)
>
> > Regardless, the immediate priority is to implement a mapper that will
> > work for all architectures (or at least everything but powerpc and
> > sparc).
>
> I oppose the implementation of a new mapper that doesn't include
> powerpc, that would be stupid. Either re-use ours or implement a new one
> that encompass our needs. I can't talk for sparc but I wouldn't be
> surprised if David thought about the same lines.
>
> > x86 has already implemented a skeleton irq_domain because
> > there wasn't any common code for it to use. ARM also needs the
> > functionality immediately, and I don't want to see yet another
> > arch-specific implementation. I'd like to get the framework in place
> > now, and grafting in mapping features as follow on patches. That way
> > the new DT users aren't blocked while waiting for us to hammer down
> > the features that the other architectures don't need yet.
>
> But the mapping code exist already. It returns a device-node as the
> interrupt controller. What you then need is to establish the
> relationship between that device-node and a domain in linux, and have
> code to decode the content of the interrupts property.
>
> So you need the concept of domain first, generic, and -then- you can
> start adding a way to bind it to OF.
Ack.
Thanks,
tglx
^ permalink raw reply
* Re: [RFC][PATCH] powerpc: respect how command line nr_cpus is set
From: Kumar Gala @ 2011-05-05 11:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1304562302.2513.418.camel@pasglop>
On May 4, 2011, at 9:25 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2011-05-04 at 15:17 -0500, Kumar Gala wrote:
>> We should utilize nr_cpus as the max # of CPUs that we can have =
present
>> instead of NR_CPUS. This way we actually respect how nr_cpus is set =
on
>> the command line rather than ignoring it.
>>=20
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> I think this is what we should be doing, but would like someone else =
to take
>> a look.
>=20
> The main question I have is should max_cpus absolutely limit the =
number
> of possible CPUs or should it limit the number that get automatically
> onlined at boot, potentially letting us bring the rest online later on =
?
>=20
> Cheers,
> Ben.
=46rom Documentation/kernel-parameters.txt:
nr_cpus=3D [SMP] Maximum number of processors that an SMP =
kernel
could support. nr_cpus=3Dn : n >=3D 1 limits =
the kernel to
supporting 'n' processors. Later in runtime you =
can not
use hotplug cpu feature to put more cpu back to =
online.
just like you compile the kernel NR_CPUS=3Dn
Which makes me think we should have max_cpus be an absolute limit.
- k=
^ 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