Re: [PATCH] atomic: add *_dec_not_zero
* 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. > arch/x86/include/asm/atomic.h |1 + > arch/x86/include/asm/atomic64_64.h |1 + Acked-by: Ingo Molnar Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] atomic: add *_dec_not_zero
> 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. Isn't there a place where a default definition of this can be defined? Instead of adding it separately to every architecture. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
On Wednesday 04 May 2011 10:05:53 David Laight 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. > > Isn't there a place where a default definition of this can be > defined? Instead of adding it separately to every architecture. Not that I would know about such a place - and all other atomic* macro definitions also suggest that there is no such place. Kind regards, Sven signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
On Wed, May 4, 2011 at 04:05, David Laight 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. > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
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 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
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 > Signed-off-by: Sven Eckelmann > [...] > arch/tile/include/asm/atomic.h |9 + > arch/tile/include/asm/atomic_32.h |1 + Acked-by: Chris Metcalf -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
On Tue, May 3, 2011 at 23: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.
> arch/m68k/include/asm/atomic.h | 1 +
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/qoriq: Add default mode for P1020RDB USB
Add P1020 USB controller default value for "dr_mode" property
Signed-off-by: Ramneek Mehresh
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fsl/usb: Unused endpoint failure for USB gadget
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
Signed-off-by: Ramneek Mehresh
---
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
* Jiang Bo
@@ -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 = (0x001F & 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpc8610_hpcd: Do not use "/" in interrupt names
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
---
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 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
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-de...@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 This goes for parisc as well. Acked-by: James Bottomley James ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/6] General device tree irq domain infrastructure
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 tra
Re: [PATCH] atomic: add *_dec_not_zero
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 > Signed-off-by: Sven Eckelmann Acked-by: David Howells [MN10300 and FRV] ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/6] powerpc: make irq_{alloc, free}_virt private and remove count argument
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/6] dt: generalize irq_of_create_mapping()
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
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 Cheers, Will ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] atomic: add *_dec_not_zero
On Tue, May 3, 2011 at 5:30 PM, Sven Eckelmann wrote: > diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.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) > } > > #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0) > +#define atomic_dec_not_zero(v) atomic_add_unless((v), -1, 0) > > /** > * 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) > } > > #define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0) > +#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0) > > #define atomic_add_negative(a, v) (atomic_add_return((a), (v)) < 0) > #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/local.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) > c != (u); \ > }) > #define local_inc_not_zero(l) local_add_unless((l), 1, 0) > +#define local_dec_not_zero(l) local_add_unless((l), -1, 0) > > #define local_add_negative(a, l) (local_add_return((a), (l)) < 0) > Acked-by: Matt Turner [alpha] ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC][PATCH] powerpc: respect how command line nr_cpus is set
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
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: ensure dtl buffers do not cross 4k boundary
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
Cc: Paul Mackerras
Cc: Anton Blanchard
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
[PATCH 3/3] [repost] powerpc/eeh: Display eeh error location for bus and device
From: Richard A Lary
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
---
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/6] General device tree irq domain infrastructure
> 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 -
Re: [PATCH 4/6] dt: generalize irq_of_create_mapping()
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/6] powerpc: make irq_{alloc, free}_virt private and remove count argument
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] powerpc: respect how command line nr_cpus is set
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
> ---
> 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);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc tree related)
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 Rothwells...@canb.auug.org.au
From: Stephen Rothwell
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
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
