* Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Mike Frysinger @ 2009-06-18 23:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <18995.20685.227683.561827@cargo.ozlabs.ibm.com>
On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
> +typedef struct {
> + =C2=A0 =C2=A0 =C2=A0 long long counter;
> +} atomic64_t;
lack of volatile seems odd compared to:
include/linux/types.h:
typedef struct {
volatile int counter;
} atomic_t;
-mike
^ permalink raw reply
* Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Benjamin Herrenschmidt @ 2009-06-19 0:46 UTC (permalink / raw)
To: Mike Frysinger; +Cc: torvalds, akpm, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <8bd0f97a0906181655jd68835fg10fe0783b6a6068d@mail.gmail.com>
On Thu, 2009-06-18 at 19:55 -0400, Mike Frysinger wrote:
> On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
> > +typedef struct {
> > + long long counter;
> > +} atomic64_t;
>
> lack of volatile seems odd compared to:
> include/linux/types.h:
> typedef struct {
> volatile int counter;
> } atomic_t;
Since the counter is only accessed within a spinlock, the volatile
wouldn't be very useful here.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Paul Mackerras @ 2009-06-19 0:47 UTC (permalink / raw)
To: Mike Frysinger; +Cc: akpm, torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <8bd0f97a0906181655jd68835fg10fe0783b6a6068d@mail.gmail.com>
Mike Frysinger writes:
> On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
> > +typedef struct {
> > + =A0 =A0 =A0 long long counter;
> > +} atomic64_t;
>=20
> lack of volatile seems odd compared to:
> include/linux/types.h:
> typedef struct {
> volatile int counter;
> } atomic_t;
> -mike
It's only accessed under a spinlock, so I don't think it needs to be
volatile. On UP it's accessed within local_irq_save/restore which
should also be compiler barriers and prevent memory access reordering,
so again volatile isn't needed.
Paul.
^ permalink raw reply
* Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Mike Frysinger @ 2009-06-19 0:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <19002.57382.880505.913539@cargo.ozlabs.ibm.com>
On Thu, Jun 18, 2009 at 20:47, Paul Mackerras wrote:
> Mike Frysinger writes:
>> On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
>> > +typedef struct {
>> > + =C2=A0 =C2=A0 =C2=A0 long long counter;
>> > +} atomic64_t;
>>
>> lack of volatile seems odd compared to:
>> include/linux/types.h:
>> typedef struct {
>> =C2=A0 =C2=A0 volatile int counter;
>> } atomic_t;
>
> It's only accessed under a spinlock, so I don't think it needs to be
> volatile. =C2=A0On UP it's accessed within local_irq_save/restore which
> should also be compiler barriers and prevent memory access reordering,
> so again volatile isn't needed.
i'm not suggesting it is needed, i'm saying it's a bit confusing. a
simple comment above the atomic64_t type with your simple explanation
here would go a long way.
-mike
^ permalink raw reply
* Re: [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel
From: Sonny Rao @ 2009-06-19 1:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, sonnyrao
In-Reply-To: <20081117072613.GO16240@us.ibm.com>
On Mon, Nov 17, 2008 at 01:26:13AM -0600, Sonny Rao wrote:
> On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote:
> > Sonny Rao writes:
> >
> > > Fix the BSR driver to allow small BSR devices, which are limited to a
> > > single 4k space, on a 64k page kernel. Previously the driver would
> > > reject the mmap since the size was smaller than PAGESIZE (or because
> > > the size was greater than the size of the device). Now, we check for
> > > this case use remap_4k_pfn(). Also, take out code to set vm_flags,
> > > as the remap_pfn functions will do this for us.
> >
> > Thanks.
> >
> > Do we know that the BSR size will always be 4k if it's not a multiple
> > of 64k? Is it possible that we could get 8k, 16k or 32k or BSRs?
> > If it is possible, what does the user need to be able to do? Do they
> > just want to map 4k, or might then want to map the whole thing?
>
>
> Hi Paul, I took a look at changing the driver to reject a request for
> mapping more than a single 4k page, however the only indication we get
> of the requested size in the mmap function is the vma size, and this
> is always one page at minimum. So, it's not possible to determine if
> the user wants one 4k page or more. As I noted in my first response,
> there is only one case where this is even possible and I don't think
> it is a significant concern.
>
> I did notice that I left out the check to see if the user is trying to
> map more than the device length, so I fixed that. Here's the revised
> patch.
Alright, I've reworked this now so that if we get one of these cases
where there's a bsr that's > 4k and < 64k on a 64k kernel we'll only
advertise that it is a 4k BSR to userspace. I think this is the best
solution since user programs are only supposed to look at sysfs to
determine how much can be mapped, and libbsr does this as well.
Please consider for 2.6.31 as a fix, thanks.
---
Fix the BSR driver to allow small BSR devices on a 64k page kernel.
Previously the driver would reject the mmap since the size was smaller
than PAGESIZE. This patch adds a check for this case and uses remap_4k_pfn().
There are also casees where we have a size that is greater than 4k but
smaller than 64k, and in that case we would only map the first 4k using
remap_4k_pfn, so we also change the length that we advertise in sysfs,
so the user knows they can only map 4k.
Also, take out code to set vm_flags, as the remap_pfn functions will
do this for us.
Signed-off-by: Sonny Rao <sonnyrao@us.ibm.com>
Index: linux-2.6.30/drivers/char/bsr.c
===================================================================
--- linux-2.6.30.orig/drivers/char/bsr.c 2009-06-18 13:02:16.000000000 -0500
+++ linux-2.6.30/drivers/char/bsr.c 2009-06-18 18:18:29.000000000 -0500
@@ -27,6 +27,7 @@
#include <linux/cdev.h>
#include <linux/list.h>
#include <linux/mm.h>
+#include <asm/pgtable.h>
#include <asm/io.h>
/*
@@ -117,15 +118,22 @@
{
unsigned long size = vma->vm_end - vma->vm_start;
struct bsr_dev *dev = filp->private_data;
+ int ret;
- if (size > dev->bsr_len || (size & (PAGE_SIZE-1)))
- return -EINVAL;
-
- vma->vm_flags |= (VM_IO | VM_DONTEXPAND);
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
- if (io_remap_pfn_range(vma, vma->vm_start, dev->bsr_addr >> PAGE_SHIFT,
- size, vma->vm_page_prot))
+ /* check for the case of a small BSR device and map one 4k page for it*/
+ if (dev->bsr_len < PAGE_SIZE && size == PAGE_SIZE)
+ ret = remap_4k_pfn(vma, vma->vm_start, dev->bsr_addr >> 12,
+ vma->vm_page_prot);
+ else if (size <= dev->bsr_len)
+ ret = io_remap_pfn_range(vma, vma->vm_start,
+ dev->bsr_addr >> PAGE_SHIFT,
+ size, vma->vm_page_prot);
+ else
+ return -EINVAL;
+
+ if (ret)
return -EAGAIN;
return 0;
@@ -205,6 +213,11 @@
cur->bsr_stride = bsr_stride[i];
cur->bsr_dev = MKDEV(bsr_major, i + total_bsr_devs);
+ /* if we have a bsr_len of > 4k and less then PAGE_SIZE (64k pages) */
+ /* we can only map 4k of it, so only advertise the 4k in sysfs */
+ if (cur->bsr_len > 4096 && cur->bsr_len < PAGE_SIZE)
+ cur->bsr_len = 4096;
+
switch(cur->bsr_bytes) {
case 8:
cur->bsr_type = BSR_8;
^ permalink raw reply
* [PATCH] BSR: add 4096 byte BSR size
From: Sonny Rao @ 2009-06-19 1:14 UTC (permalink / raw)
To: linuxppc-dev, benh; +Cc: sonnyrao, paulus
Add a 4096 byte BSR size which will be used on new machines. Also, remove
the warning when we run into an unknown size, as this can spam the kernel
log excessively.
Signed-off-by: Sonny Rao <sonnyrao@us.ibm.com>
Index: linux-2.6.27/drivers/char/bsr.c
===================================================================
--- linux-2.6.27.orig/drivers/char/bsr.c 2009-06-18 17:50:41.000000000 -0500
+++ linux-2.6.27/drivers/char/bsr.c 2009-06-18 17:50:58.000000000 -0500
@@ -76,12 +76,13 @@
static int bsr_major;
enum {
- BSR_8 = 0,
- BSR_16 = 1,
- BSR_64 = 2,
- BSR_128 = 3,
- BSR_UNKNOWN = 4,
- BSR_MAX = 5,
+ BSR_8 = 0,
+ BSR_16 = 1,
+ BSR_64 = 2,
+ BSR_128 = 3,
+ BSR_4096 = 4,
+ BSR_UNKNOWN = 5,
+ BSR_MAX = 6,
};
static unsigned bsr_types[BSR_MAX];
@@ -231,9 +232,11 @@
case 128:
cur->bsr_type = BSR_128;
break;
+ case 4096:
+ cur->bsr_type = BSR_4096;
+ break;
default:
cur->bsr_type = BSR_UNKNOWN;
- printk(KERN_INFO "unknown BSR size %d\n",cur->bsr_bytes);
}
cur->bsr_num = bsr_types[cur->bsr_type];
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS
From: Kumar Gala @ 2009-06-19 2:25 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090618233752.GA13279@oksana.dev.rtsoft.ru>
On Jun 18, 2009, at 6:37 PM, Anton Vorontsov wrote:
> For yet unknown reason 4-bit mode doesn't work on MPC8569E-MDS boards,
> so make 1-bit mode default. When we resolve the issue, u-boot will
> remove sdhci,1-bit-only property from the device tree, while SDHCI
> will still work with older u-boots.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8569mds.dts | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Did I miss the patch that adds this property defn. to our docs?
- k
^ permalink raw reply
* Re: [PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.
From: Geoff Thorpe @ 2009-06-19 3:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1245363751.8693.6.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2009-06-18 at 16:30 -0400, Geoff Thorpe wrote:
>> I've left the volatile qualifier in the generated API because I didn't
>> feel so comfortable changing APIs, but I also added the "memory" clobber
>> for all cases - whereas it seems the existing set_bits(), clear_bits(),
>> [...] functions didn't declare this... Do you see any issue with having
>> the 'volatile' in the prototype as well as the clobber in the asm?
>>
>> Actually, might as well just respond to the new patch instead... :-) Thx.
>
> I think the story with the memory clobber is that it depends whether
> we consider the functions as ordering accesses or not (ie, can
> potentially be used with lock/unlock semantics).
>
> The general rule is that those who don't return anything don't need
> to have those semantics, and thus could only be advertised as clobbering
> p[word] -but- there are issues there. For example, despite the
> (relatively new) official _lock/_unlock variants, there's still code
> that abuses constructs like test_and_set_bit/clear_bit as locks and in
> that case, clear bits needs a clobber.
>
> So I would say at this stage better safe than having to track down
> incredibly hard to find bugs, and let's make them all take that clobber.
Well I'm tempted agree because I'm abusing these constructs in exactly
the manner you describe. :-) However I didn't know that this was abuse
until you mentioned it. Some time ago I noticed that the bitops code was
very similar to spinlocks, and so I presumed that a bitops word could
act as its own spinlock (ie. rather than spinlocking access to a u32).
Now that I look at spinlocks again, I see the presence of those
CLEAR_IO_SYNC definitions in the function preambles - is that the
distinction I'm abusing? CLEAR_IO_SYNC appears to be undefined except on
64-bit, in which case it's "(get_paca()->io_sync = 0)".
W.r.t the _lock/_unlock variants on the bitops side, the "lock"
particulars appear to depend on LWSYNC_ON_SMP and ISYNC_ON_SMP, which
are "isync" and "lwsync" for all platforms IIUC. So it seems the locking
intentions here are different from that of spinlocks? Is there something
I can look at that describes what semantics these primitives (are
supposed to) guarantee? I may be assuming other things that I shouldn't
be ...
Cheers,
Geoff
^ permalink raw reply
* [PATCH] powerpc/85xx: Stop using ppc_md.init on socrates
From: Kumar Gala @ 2009-06-19 4:30 UTC (permalink / raw)
To: linuxppc-dev
Match what other 85xx platforms do for of_platform_bus_probe and use
machine_device_initcall. This is one small step in killing of
ppc_md.init.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/85xx/socrates.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/socrates.c b/arch/powerpc/platforms/85xx/socrates.c
index d0e8443..747d8fb 100644
--- a/arch/powerpc/platforms/85xx/socrates.c
+++ b/arch/powerpc/platforms/85xx/socrates.c
@@ -102,10 +102,11 @@ static struct of_device_id __initdata socrates_of_bus_ids[] = {
{},
};
-static void __init socrates_init(void)
+static int __init socrates_publish_devices(void)
{
- of_platform_bus_probe(NULL, socrates_of_bus_ids, NULL);
+ return of_platform_bus_probe(NULL, socrates_of_bus_ids, NULL);
}
+machine_device_initcall(socrates, socrates_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -124,7 +125,6 @@ define_machine(socrates) {
.name = "Socrates",
.probe = socrates_probe,
.setup_arch = socrates_setup_arch,
- .init = socrates_init,
.init_IRQ = socrates_pic_init,
.get_irq = mpic_get_irq,
.restart = fsl_rstcr_restart,
--
1.6.0.6
^ permalink raw reply related
* RE: Problem with memcpy on ppc8536
From: Liu Dave-R63238 @ 2009-06-19 4:42 UTC (permalink / raw)
To: Fahd Abidi, linuxppc-dev; +Cc: u-boot
In-Reply-To: <71DEA556544D7A4F9C6848402D8184340C4A13@usi01.ultsol.local>
I believe the question should be sent to u-boot@lists.denx.de,
not linuxppc-dev list.
What is the TLB settings for NAND FCM buffer? Pay attention
to set the TLB as cache inhibited and guarded attribute.
If not set the guarded bit, it is possible to cause the speculate
load from FCM buffer below the cmplwi and blt inst.
IIRC, the FCM buffer only has the 4KB. So if it has one speculated
Load above the 4KB, it will run into problem.
The 0x700 is not alignment exception, it is program exception.
If you can dump the exception error information from console
to us, maybe we can give better help.
Thanks, Dave
________________________________
From:
linuxppc-dev-bounces+daveliu=3Dfreescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+daveliu=3Dfreescale.com@lists.ozlabs.org] =
On
Behalf Of Fahd Abidi
Sent: Friday, June 19, 2009 4:34 AM
To: linuxppc-dev@ozlabs.org
Subject: Problem with memcpy on ppc8536
=09
=09
Hello,=20
=09
I am trying to debug a crash during memcpy while copying data
from the FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy
enough through my BDI3000 to see that the entire contents of the fcm
buffer I want moved are actually moved off to memory location I specify.
The crash comes after it memcpy finishes copying and performs the
instruction "2: cmplwi 0,r5,4":=20
=09
memcpy:=20
rlwinm. r7,r5,32-3,3,31 /* r0 =3D r5 >> 3 */=20
addi r6,r3,-4=20
addi r4,r4,-4=20
beq 2f /* if less than 8 bytes to do */=20
andi. r0,r6,3 /* get dest word aligned */=20
mtctr r7=20
bne 5f=20
1: lwz r7,4(r4)=20
lwzu r8,8(r4)=20
stw r7,4(r6)=20
stwu r8,8(r6)=20
bdnz 1b=20
andi. r5,r5,7=20
2: cmplwi 0,r5,4=20
=09
contents of r5 are 0x0 showing that the entire 0x1000 size
transfer I specified correctly finished. At this point I can check the
memory contents through my BDI and verify all the data is in the ddr as
I expect. Now the strange thing happens, if I execute the "cmplwi
0,r5,4" the program takes an exception and eventually gets struck at
exception vector 0x700 which I saw from start.S is an "Alignment"
exception. I am not sure what this exception means, can someone help me
understand what is happening?=20
=09
Does this exception somehow mean that memcpy did not move all
the data? Does memcpy expect contents of r5 to be 4 and not 0 when it
hits the cmplwi instruction?=20
=09
Fahd Abidi
Product Manager - Technical Tools and Development
Ultimate Solutions, Inc.
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Your Single Source for Professional Development Tools and
Embedded Solutions
Ph: 978-455-3383 x255
Fx: 978-926-3091
Email: fabidi@ultsol.com
Visit: http://www.ultsol.com <http://www.ultsol.com/> =20
^ permalink raw reply
* Re: [Patch 4/6] Modify process and processor handling code to recognise hardware debug registers
From: David Gibson @ 2009-06-19 4:57 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Alan Stern, Roland McGrath
In-Reply-To: <20090618175623.GB4590@in.ibm.com>
On Thu, Jun 18, 2009 at 11:26:23PM +0530, K.Prasad wrote:
> On Wed, Jun 17, 2009 at 02:14:20PM +1000, David Gibson wrote:
> > On Wed, Jun 10, 2009 at 02:38:18PM +0530, K.Prasad wrote:
[snip]
> > > @@ -254,8 +255,10 @@ void do_dabr(struct pt_regs *regs, unsig
> > > 11, SIGSEGV) == NOTIFY_STOP)
> > > return;
> > >
> > > +#ifndef CONFIG_PPC64
> > > if (debugger_dabr_match(regs))
> > > return;
> > > +#endif
> >
> > Won't this disable the check for breakpoints set by xmon - but I don't
> > see anything in this patch series to convert xmon to use the new
> > breakpoint interface instead.
>
> As noted by me here:
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/071832.html the
> Xmon integration is pending. When I tried to study and integrate Xmon, I
> found that the HW Breakpoint triggering was broken as of 2.6.29 kernel
> (tested on a Power5 box).
>
> This would mean that if Xmon's hardware breakpoint infrastructure is
> used in tandem with the given breakpoint interfaces, they would conflict
> with each other resulting in difficult-to-predict behaviour (the last to
> grab the register will use it).
>
> I think that tidying up do_dabr() is best done along with Xmon
> integration.
Hmm, ok.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
From: David Gibson @ 2009-06-19 5:04 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Alan Stern, Roland McGrath
In-Reply-To: <20090618182045.GC4590@in.ibm.com>
On Thu, Jun 18, 2009 at 11:50:45PM +0530, K.Prasad wrote:
> On Wed, Jun 17, 2009 at 02:32:24PM +1000, David Gibson wrote:
> > On Wed, Jun 10, 2009 at 02:38:06PM +0530, K.Prasad wrote:
[snip]
> > > +int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
> > > + struct task_struct *tsk)
> > > +{
> > > + int is_kernel, ret = -EINVAL;
> > > +
> > > + if (!bp)
> > > + return ret;
> > > +
> > > + switch (bp->info.type) {
> > > + case HW_BREAKPOINT_READ:
> > > + case HW_BREAKPOINT_WRITE:
> > > + case HW_BREAKPOINT_RW:
> > > + break;
> > > + default:
> > > + return ret;
> > > + }
> > > +
> > > + if (bp->triggered)
> > > + ret = arch_store_info(bp, tsk);
> >
> > Under what circumstances would triggered be NULL? It's not clear to
> > me that you wouldn't still need arch_store_info() in this case.
> >
>
> Simple, triggered would be NULL when a user fails to specify it!
> This function would return EINVAL if that's the case.
Ah, right, yes. This seems a really non obvious control flow for a
NULL triggered value to lead to EINVAL. I'd prefer:
if (!bp->triggered)
return -EINVAL
/* Then the kernel address test */
return arch_store_info(bp, tsk);
[snip]
> > > + /* Verify if dar lies within the address range occupied by the symbol
> > > + * being watched. Since we cannot get the symbol size for
> > > + * user-space requests we skip this check in that case
> > > + */
> > > + if ((hbp_kernel_pos == 0) &&
> > > + !((bp->info.address <= dar) &&
> > > + (dar <= (bp->info.address + bp->info.symbolsize))))
> > > + /*
> > > + * This exception is triggered not because of a memory access on
> > > + * the monitored variable but in the double-word address range
> > > + * in which it is contained. We will consume this exception,
> > > + * considering it as 'noise'.
> > > + */
> > > + goto out;
> > > +
> > > + (bp->triggered)(bp, regs);
> >
> > So this confuses me. You go to great efforts to step over the
> > instruction to generate a SIGTRAP after the instruction, for
> > consistency with x86. But that SIGTRAP is *never* used, since the
> > only way to set userspace breakpoints is through ptrace at the moment.
> > At the same time, the triggered function is called here before the
> > instruction is executed, so not consistent with x86 anyway.
> >
> > It just seems strange to me that sending a SIGTRAP is a special case
> > anyway. Why can't sending a SIGTRAP be just a particular triggered
> > function.
>
> The consistency in the interface across architectures that I referred to
> in my previous mail was w.r.t. continuous triggering of breakpoints and
> not to implement a trigger-before or trigger-after behaviour across
> architectures. In fact, this behaviour differs even on the same
> processor depending upon the breakpoint type (trigger-before for
> instructions and trigger-after for data in x86), and introducing
> uniformity might be a) at the cost of loss of some unique & innovative
> uses for each of them b) may not be always possible e.g. trigger-after
> to trigger-before.
Hrm. Well (a) is why I was suggesting an option to allow trigger
before on powerpc. Plus, I don't see why you think (a) is important
for the triggered function, but not for the timing of a SIGTRAP to
userspace.
As for (b), well there are already a bunch of things which can only be
done on certain archs/processors, so I don't see that's anything
really new.
How do you handle continuous breakpoints in the trigger-before case
(instruction breakpoints) on x86? Do you need to step over an
instruction is the same manner as you do for powerpc? In this case
where does x86 send the SIGTRAP?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] powerpc: Map more memory early on 601 processors
From: Benjamin Herrenschmidt @ 2009-06-19 5:17 UTC (permalink / raw)
To: linuxppc-dev
The 32-bit kernel relies on some memory being mapped covering
the kernel text,data and bss at least, early during boot before
the full MMU setup is done. On 32-bit "classic" processors, this
is done using BAT registers.
On 601, the size of BATs is limited to 8M and we use 2 of them
for that initial mapping. This can become quite tight when enabling
features like lockdep, so let's use a 3rd one to bump that mapping
from 16M to 24M. We keep the 4th BAT free as it can be useful for
debugging early boot code to map things like serial ports.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/head_32.S | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/head_32.S 2009-06-19 10:31:41.000000000 +1000
+++ linux-work/arch/powerpc/kernel/head_32.S 2009-06-19 10:32:13.000000000 +1000
@@ -1124,9 +1124,8 @@ mmu_off:
RFI
/*
- * Use the first pair of BAT registers to map the 1st 16MB
- * of RAM to PAGE_OFFSET. From this point on we can't safely
- * call OF any more.
+ * On 601, we use 3 BATs to map up to 24M of RAM at _PAGE_OFFSET
+ * (we keep one for debugging) and on others, we use one 256M BAT.
*/
initial_bats:
lis r11,PAGE_OFFSET@h
@@ -1136,12 +1135,16 @@ initial_bats:
bne 4f
ori r11,r11,4 /* set up BAT registers for 601 */
li r8,0x7f /* valid, block length = 8MB */
- oris r9,r11,0x800000@h /* set up BAT reg for 2nd 8M */
- oris r10,r8,0x800000@h /* set up BAT reg for 2nd 8M */
mtspr SPRN_IBAT0U,r11 /* N.B. 601 has valid bit in */
mtspr SPRN_IBAT0L,r8 /* lower BAT register */
- mtspr SPRN_IBAT1U,r9
- mtspr SPRN_IBAT1L,r10
+ addis r11,r11,0x800000@h
+ addis r8,r8,0x800000@h
+ mtspr SPRN_IBAT1U,r11
+ mtspr SPRN_IBAT1L,r8
+ addis r11,r11,0x800000@h
+ addis r8,r8,0x800000@h
+ mtspr SPRN_IBAT2U,r11
+ mtspr SPRN_IBAT2L,r8
isync
blr
^ permalink raw reply
* [PATCH] powerpc/pmac: Fix DMA ops for MacIO devices
From: Benjamin Herrenschmidt @ 2009-06-19 5:20 UTC (permalink / raw)
To: linuxppc-dev
The macio_dev's created to map devices inside the MacIO ASICs
don't have proper dma_ops. This causes crashes on some machines
since the SCSI code calls dma_map_* on our behalf using the
device we hang from.
This fixes it by copying the parent PCI device dma_ops into
the macio_dev when creating it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/macintosh/macio_asic.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- linux-work.orig/drivers/macintosh/macio_asic.c 2009-06-19 10:38:17.000000000 +1000
+++ linux-work/drivers/macintosh/macio_asic.c 2009-06-19 10:38:33.000000000 +1000
@@ -378,6 +378,17 @@ static struct macio_dev * macio_add_one_
dev->ofdev.dev.bus = &macio_bus_type;
dev->ofdev.dev.release = macio_release_dev;
+#ifdef CONFIG_PCI
+ /* Set the DMA ops to the ones from the PCI device, this could be
+ * fishy if we didn't know that on PowerMac it's always direct ops
+ * or iommu ops that will work fine
+ */
+ dev->ofdev.dev.archdata.dma_ops =
+ chip->lbus.pdev->dev.archdata.dma_ops;
+ dev->ofdev.dev.archdata.dma_data =
+ chip->lbus.pdev->dev.archdata.dma_data;
+#endif /* CONFIG_PCI */
+
#ifdef DEBUG
printk("preparing mdev @%p, ofdev @%p, dev @%p, kobj @%p\n",
dev, &dev->ofdev, &dev->ofdev.dev, &dev->ofdev.dev.kobj);
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Make k(un)map_atomic out of line
From: Benjamin Herrenschmidt @ 2009-06-19 5:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090618033952.B60D4DDDA2@ozlabs.org>
On Thu, 2009-06-18 at 13:39 +1000, Benjamin Herrenschmidt wrote:
> Those functions are way too big to be inline, besides, kmap_atomic()
> wants to call debug_kmap_atomic() which isn't exported for modules
> and causes module link failures.
Missing a quilt ref ... this one won't build.
Ben.
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> arch/powerpc/include/asm/highmem.h | 55 +--------------------------
> arch/powerpc/mm/Makefile | 1
> arch/powerpc/mm/highmem.c | 75 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 80 insertions(+), 51 deletions(-)
>
> --- linux-work.orig/arch/powerpc/include/asm/highmem.h 2009-06-18 11:34:42.000000000 +1000
> +++ linux-work/arch/powerpc/include/asm/highmem.h 2009-06-18 11:34:45.000000000 +1000
> @@ -62,6 +62,9 @@ extern pte_t *pkmap_page_table;
>
> extern void *kmap_high(struct page *page);
> extern void kunmap_high(struct page *page);
> +extern void *kmap_atomic_prot(struct page *page, enum km_type type,
> + pgprot_t prot);
> +extern void kunmap_atomic(void *kvaddr, enum km_type type);
>
> static inline void *kmap(struct page *page)
> {
> @@ -79,62 +82,11 @@ static inline void kunmap(struct page *p
> kunmap_high(page);
> }
>
> -/*
> - * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
> - * gives a more generic (and caching) interface. But kmap_atomic can
> - * be used in IRQ contexts, so in some (very limited) cases we need
> - * it.
> - */
> -static inline void *kmap_atomic_prot(struct page *page, enum km_type type, pgprot_t prot)
> -{
> - unsigned int idx;
> - unsigned long vaddr;
> -
> - /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
> - pagefault_disable();
> - if (!PageHighMem(page))
> - return page_address(page);
> -
> - debug_kmap_atomic(type);
> - idx = type + KM_TYPE_NR*smp_processor_id();
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> -#ifdef CONFIG_DEBUG_HIGHMEM
> - BUG_ON(!pte_none(*(kmap_pte-idx)));
> -#endif
> - __set_pte_at(&init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot), 1);
> - local_flush_tlb_page(NULL, vaddr);
> -
> - return (void*) vaddr;
> -}
> -
> static inline void *kmap_atomic(struct page *page, enum km_type type)
> {
> return kmap_atomic_prot(page, type, kmap_prot);
> }
>
> -static inline void kunmap_atomic(void *kvaddr, enum km_type type)
> -{
> -#ifdef CONFIG_DEBUG_HIGHMEM
> - unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
> - enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
> -
> - if (vaddr < __fix_to_virt(FIX_KMAP_END)) {
> - pagefault_enable();
> - return;
> - }
> -
> - BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
> -
> - /*
> - * force other mappings to Oops if they'll try to access
> - * this pte without first remap it
> - */
> - pte_clear(&init_mm, vaddr, kmap_pte-idx);
> - local_flush_tlb_page(NULL, vaddr);
> -#endif
> - pagefault_enable();
> -}
> -
> static inline struct page *kmap_atomic_to_page(void *ptr)
> {
> unsigned long idx, vaddr = (unsigned long) ptr;
> @@ -148,6 +100,7 @@ static inline struct page *kmap_atomic_t
> return pte_page(*pte);
> }
>
> +
> #define flush_cache_kmaps() flush_cache_all()
>
> #endif /* __KERNEL__ */
> Index: linux-work/arch/powerpc/mm/Makefile
> ===================================================================
> --- linux-work.orig/arch/powerpc/mm/Makefile 2009-06-18 11:34:42.000000000 +1000
> +++ linux-work/arch/powerpc/mm/Makefile 2009-06-18 11:34:45.000000000 +1000
> @@ -30,3 +30,4 @@ obj-$(CONFIG_PPC_MM_SLICES) += slice.o
> obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
> obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
> obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
> +obj-$(CONFIG_HIGHMEM) += highmem.o
> Index: linux-work/arch/powerpc/mm/highmem.c
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-work/arch/powerpc/mm/highmem.c 2009-06-18 11:35:51.000000000 +1000
> @@ -0,0 +1,75 @@
> +/*
> + * highmem.c: virtual kernel memory mappings for high memory
> + *
> + * PowerPC version, stolen from the i386 version.
> + *
> + * Used in CONFIG_HIGHMEM systems for memory pages which
> + * are not addressable by direct kernel virtual addresses.
> + *
> + * Copyright (C) 1999 Gerhard Wichert, Siemens AG
> + * Gerhard.Wichert@pdb.siemens.de
> + *
> + *
> + * Redesigned the x86 32-bit VM architecture to deal with
> + * up to 16 Terrabyte physical memory. With current x86 CPUs
> + * we now support up to 64 Gigabytes physical RAM.
> + *
> + * Copyright (C) 1999 Ingo Molnar <mingo@redhat.com>
> + *
> + * Reworked for PowerPC by various contributors. Moved from
> + * highmem.h by Benjamin Herrenschmidt (c) 2009 IBM Corp.
> + */
> +
> +
> +/*
> + * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
> + * gives a more generic (and caching) interface. But kmap_atomic can
> + * be used in IRQ contexts, so in some (very limited) cases we need
> + * it.
> + */
> +void *kmap_atomic_prot(struct page *page, enum km_type type, pgprot_t prot)
> +{
> + unsigned int idx;
> + unsigned long vaddr;
> +
> + /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
> + pagefault_disable();
> + if (!PageHighMem(page))
> + return page_address(page);
> +
> + debug_kmap_atomic(type);
> + idx = type + KM_TYPE_NR*smp_processor_id();
> + vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> +#ifdef CONFIG_DEBUG_HIGHMEM
> + BUG_ON(!pte_none(*(kmap_pte-idx)));
> +#endif
> + __set_pte_at(&init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot), 1);
> + local_flush_tlb_page(NULL, vaddr);
> +
> + return (void*) vaddr;
> +}
> +EXPORT_SYMBOL(kmap_atomic_prot);
> +
> +void kunmap_atomic(void *kvaddr, enum km_type type)
> +{
> +#ifdef CONFIG_DEBUG_HIGHMEM
> + unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
> + enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
> +
> + if (vaddr < __fix_to_virt(FIX_KMAP_END)) {
> + pagefault_enable();
> + return;
> + }
> +
> + BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
> +
> + /*
> + * force other mappings to Oops if they'll try to access
> + * this pte without first remap it
> + */
> + pte_clear(&init_mm, vaddr, kmap_pte-idx);
> + local_flush_tlb_page(NULL, vaddr);
> +#endif
> + pagefault_enable();
> +}
> +EXPORT_SYMBOL(kunmap_atomic);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc/mm: Make k(un)map_atomic out of line
From: Benjamin Herrenschmidt @ 2009-06-19 5:25 UTC (permalink / raw)
To: linuxppc-dev
Those functions are way too big to be inline, besides, kmap_atomic()
wants to call debug_kmap_atomic() which isn't exported for modules
and causes module link failures.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/highmem.h | 57 +--------------------------
arch/powerpc/mm/Makefile | 1
arch/powerpc/mm/highmem.c | 77 +++++++++++++++++++++++++++++++++++++
3 files changed, 82 insertions(+), 53 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/highmem.h 2009-06-18 11:34:42.000000000 +1000
+++ linux-work/arch/powerpc/include/asm/highmem.h 2009-06-18 11:38:06.000000000 +1000
@@ -22,9 +22,7 @@
#ifdef __KERNEL__
-#include <linux/init.h>
#include <linux/interrupt.h>
-#include <linux/highmem.h>
#include <asm/kmap_types.h>
#include <asm/tlbflush.h>
#include <asm/page.h>
@@ -62,6 +60,9 @@ extern pte_t *pkmap_page_table;
extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
+extern void *kmap_atomic_prot(struct page *page, enum km_type type,
+ pgprot_t prot);
+extern void kunmap_atomic(void *kvaddr, enum km_type type);
static inline void *kmap(struct page *page)
{
@@ -79,62 +80,11 @@ static inline void kunmap(struct page *p
kunmap_high(page);
}
-/*
- * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
- * gives a more generic (and caching) interface. But kmap_atomic can
- * be used in IRQ contexts, so in some (very limited) cases we need
- * it.
- */
-static inline void *kmap_atomic_prot(struct page *page, enum km_type type, pgprot_t prot)
-{
- unsigned int idx;
- unsigned long vaddr;
-
- /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
- pagefault_disable();
- if (!PageHighMem(page))
- return page_address(page);
-
- debug_kmap_atomic(type);
- idx = type + KM_TYPE_NR*smp_processor_id();
- vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
-#ifdef CONFIG_DEBUG_HIGHMEM
- BUG_ON(!pte_none(*(kmap_pte-idx)));
-#endif
- __set_pte_at(&init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot), 1);
- local_flush_tlb_page(NULL, vaddr);
-
- return (void*) vaddr;
-}
-
static inline void *kmap_atomic(struct page *page, enum km_type type)
{
return kmap_atomic_prot(page, type, kmap_prot);
}
-static inline void kunmap_atomic(void *kvaddr, enum km_type type)
-{
-#ifdef CONFIG_DEBUG_HIGHMEM
- unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
- enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
-
- if (vaddr < __fix_to_virt(FIX_KMAP_END)) {
- pagefault_enable();
- return;
- }
-
- BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
-
- /*
- * force other mappings to Oops if they'll try to access
- * this pte without first remap it
- */
- pte_clear(&init_mm, vaddr, kmap_pte-idx);
- local_flush_tlb_page(NULL, vaddr);
-#endif
- pagefault_enable();
-}
-
static inline struct page *kmap_atomic_to_page(void *ptr)
{
unsigned long idx, vaddr = (unsigned long) ptr;
@@ -148,6 +98,7 @@ static inline struct page *kmap_atomic_t
return pte_page(*pte);
}
+
#define flush_cache_kmaps() flush_cache_all()
#endif /* __KERNEL__ */
Index: linux-work/arch/powerpc/mm/Makefile
===================================================================
--- linux-work.orig/arch/powerpc/mm/Makefile 2009-06-18 11:34:42.000000000 +1000
+++ linux-work/arch/powerpc/mm/Makefile 2009-06-18 11:34:45.000000000 +1000
@@ -30,3 +30,4 @@ obj-$(CONFIG_PPC_MM_SLICES) += slice.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
+obj-$(CONFIG_HIGHMEM) += highmem.o
Index: linux-work/arch/powerpc/mm/highmem.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/mm/highmem.c 2009-06-18 11:38:33.000000000 +1000
@@ -0,0 +1,77 @@
+/*
+ * highmem.c: virtual kernel memory mappings for high memory
+ *
+ * PowerPC version, stolen from the i386 version.
+ *
+ * Used in CONFIG_HIGHMEM systems for memory pages which
+ * are not addressable by direct kernel virtual addresses.
+ *
+ * Copyright (C) 1999 Gerhard Wichert, Siemens AG
+ * Gerhard.Wichert@pdb.siemens.de
+ *
+ *
+ * Redesigned the x86 32-bit VM architecture to deal with
+ * up to 16 Terrabyte physical memory. With current x86 CPUs
+ * we now support up to 64 Gigabytes physical RAM.
+ *
+ * Copyright (C) 1999 Ingo Molnar <mingo@redhat.com>
+ *
+ * Reworked for PowerPC by various contributors. Moved from
+ * highmem.h by Benjamin Herrenschmidt (c) 2009 IBM Corp.
+ */
+
+#include <linux/highmem.h>
+#include <linux/module.h>
+
+/*
+ * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
+ * gives a more generic (and caching) interface. But kmap_atomic can
+ * be used in IRQ contexts, so in some (very limited) cases we need
+ * it.
+ */
+void *kmap_atomic_prot(struct page *page, enum km_type type, pgprot_t prot)
+{
+ unsigned int idx;
+ unsigned long vaddr;
+
+ /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
+ pagefault_disable();
+ if (!PageHighMem(page))
+ return page_address(page);
+
+ debug_kmap_atomic(type);
+ idx = type + KM_TYPE_NR*smp_processor_id();
+ vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
+#ifdef CONFIG_DEBUG_HIGHMEM
+ BUG_ON(!pte_none(*(kmap_pte-idx)));
+#endif
+ __set_pte_at(&init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot), 1);
+ local_flush_tlb_page(NULL, vaddr);
+
+ return (void*) vaddr;
+}
+EXPORT_SYMBOL(kmap_atomic_prot);
+
+void kunmap_atomic(void *kvaddr, enum km_type type)
+{
+#ifdef CONFIG_DEBUG_HIGHMEM
+ unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
+ enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
+
+ if (vaddr < __fix_to_virt(FIX_KMAP_END)) {
+ pagefault_enable();
+ return;
+ }
+
+ BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
+
+ /*
+ * force other mappings to Oops if they'll try to access
+ * this pte without first remap it
+ */
+ pte_clear(&init_mm, vaddr, kmap_pte-idx);
+ local_flush_tlb_page(NULL, vaddr);
+#endif
+ pagefault_enable();
+}
+EXPORT_SYMBOL(kunmap_atomic);
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-06-19 5:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's another batch to finally drain my queue. There will be bug fixes
coming but they don't need to be before -rc1. The only "feature" I'm
still considering merging this time around and that isn't there yet is
the support for irqtrace/lockdep on ppc32 since it's a useful debug
tool, and mostly should be a nop unless lockdep is enabled.
The following changes since commit 0732f87761dbe417cb6e084b712d07e879e876ef:
Linus Torvalds (1):
Merge branch 'for_linus' of git://git.kernel.org/.../tytso/ext4
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Vorontsov (2):
powerpc/83xx: Update sdhci nodes per new bindings
powerpc/5200: convert mpc52xx_psc_spi to use cs_control callback
Becky Bruce (1):
powerpc: Add 86xx support for SWIOTLB
Benjamin Herrenschmidt (5):
powerpc: Fix invalid construct in our CPU selection Kconfig
powerpc: Add memory clobber to mtspr()
Merge commit 'origin/master' into next
Merge commit 'origin/master' into next
Merge commit 'gcl/merge' into next
Dave Liu (1):
serial: Make ucc_uart work in HW UART mode
Dave Mitchell (1):
of_serial: Add UPF_FIXED_TYPE flag
Geert Uytterhoeven (3):
net/ps3: gelic - Add missing annotations
ps3rom: Use ps3_system_bus_[gs]et_drvdata() instead of direct access
usb/ps3: Add missing annotations
Gerhard Pircher (1):
powerpc: Enable additional BAT registers in setup_745x_specifics()
Grant Likely (1):
fbdev/xilinxfb: Fix improper casting and tighen up probe path
Haiying Wang (1):
powerpc/85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
Heiko Schocher (1):
83xx: add support for the kmeter1 board.
Kevin Hao (1):
powerpc/85xx: Add nor flash partitions for mpc8569mds
Kumar Gala (1):
powerpc/85xx: Add SWIOTLB support to FSL boards
Martyn Welch (1):
powerpc/86xx: Add I2C device mappings in DTS for SBC610
Michael Ellerman (1):
powerpc: Add configurable -Werror for arch/powerpc
Mike Frysinger (1):
drivers/hvc: Add missing __devexit_p()
Nate Case (6):
powerpc/fsl-booke: Enable L1 cache on e500v1/e500v2/e500mc CPUs
powerpc/85xx: cuboot - Fix up ethernet3 MAC address on MPC85xx
powerpc/85xx: Add platform support for X-ES MPC85xx boards
powerpc/85xx: Add dts files for X-ES MPC85xx boards
powerpc/85xx: Add defconfig for X-ES MPC85xx boards
powerpc/bootwrapper: Custom build options for XPedite52xx targets
Peter Korsgaard (1):
powerpc/mpc83xx: Fix usb mux setup for mpc834x
Sean MacLennan (1):
powerpc/warp: Fix ISA_DMA_THRESHOLD default
Timur Tabi (1):
powerpc: Introduce macro spin_event_timeout()
Wolfgang Denk (2):
powerpc/mpc8272ads: fix device tree for 8 MB flash size
powerpc/5xxx: Add common mpc5xxx_get_bus_frequency() function
Wolfram Sang (2):
powerpc/5200: Update pcm030.dts to add i2c eeprom and delete cruft
powerpc/5121: make clock debug output more readable
Yang Li (1):
rio: warn_unused_result warnings fix
leon.woestenberg@gmail.com (1):
powerpc/83xx: Add MSI interrupts to DTS of MPC8315E-RDB
mware@internode.on.net (1):
powerpc/fsl: Increase the number of possible localbus banks
arch/powerpc/Kconfig.debug | 17 +
arch/powerpc/boot/cuboot-85xx.c | 2 +
arch/powerpc/boot/dts/asp834x-redboot.dts | 2 +-
arch/powerpc/boot/dts/gef_sbc610.dts | 10 +
arch/powerpc/boot/dts/kmeter1.dts | 520 ++++++
arch/powerpc/boot/dts/mpc8272ads.dts | 19 +-
arch/powerpc/boot/dts/mpc8315erdb.dts | 15 +
arch/powerpc/boot/dts/mpc8349emitx.dts | 2 +-
arch/powerpc/boot/dts/mpc834x_mds.dts | 2 +-
arch/powerpc/boot/dts/mpc8377_mds.dts | 2 +-
arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8378_mds.dts | 2 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8379_mds.dts | 2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8569mds.dts | 87 +-
arch/powerpc/boot/dts/pcm030.dts | 26 +-
arch/powerpc/boot/dts/sbc8349.dts | 2 +-
arch/powerpc/boot/dts/xcalibur1501.dts | 696 ++++++++
arch/powerpc/boot/dts/xpedite5200.dts | 466 ++++++
arch/powerpc/boot/dts/xpedite5200_xmon.dts | 506 ++++++
arch/powerpc/boot/dts/xpedite5301.dts | 640 ++++++++
arch/powerpc/boot/dts/xpedite5330.dts | 707 ++++++++
arch/powerpc/boot/dts/xpedite5370.dts | 638 ++++++++
arch/powerpc/boot/wrapper | 4 +
arch/powerpc/configs/83xx/kmeter1_defconfig | 908 ++++++++++
arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 1821 +++++++++++++++++++++
arch/powerpc/include/asm/delay.h | 36 +
arch/powerpc/include/asm/fsl_lbc.h | 4 +-
arch/powerpc/include/asm/mpc52xx.h | 2 +-
arch/powerpc/include/asm/{mpc512x.h => mpc5xxx.h} | 10 +-
arch/powerpc/include/asm/reg.h | 3 +-
arch/powerpc/include/asm/reg_booke.h | 2 +
arch/powerpc/kernel/Makefile | 2 +
arch/powerpc/kernel/cpu_setup_6xx.S | 3 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 49 +-
arch/powerpc/kvm/Makefile | 2 +
arch/powerpc/lib/Makefile | 2 +
arch/powerpc/mm/Makefile | 2 +
arch/powerpc/oprofile/Makefile | 2 +
arch/powerpc/platforms/44x/warp.c | 8 +-
arch/powerpc/platforms/512x/clock.c | 10 +-
arch/powerpc/platforms/512x/mpc512x.h | 1 -
arch/powerpc/platforms/512x/mpc512x_shared.c | 23 -
arch/powerpc/platforms/52xx/mpc52xx_common.c | 32 +-
arch/powerpc/platforms/83xx/Kconfig | 7 +
arch/powerpc/platforms/83xx/Makefile | 1 +
arch/powerpc/platforms/83xx/kmeter1.c | 191 +++
arch/powerpc/platforms/83xx/mpc83xx.h | 4 +-
arch/powerpc/platforms/83xx/usb.c | 10 +-
arch/powerpc/platforms/85xx/Kconfig | 13 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/mpc8536_ds.c | 17 +
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 19 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 20 +
arch/powerpc/platforms/85xx/xes_mpc85xx.c | 282 ++++
arch/powerpc/platforms/86xx/Kconfig | 1 +
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 15 +
arch/powerpc/platforms/Kconfig.cputype | 9 +-
arch/powerpc/platforms/Makefile | 2 +
arch/powerpc/sysdev/Makefile | 5 +
arch/powerpc/sysdev/mpc5xxx_clocks.c | 33 +
arch/powerpc/xmon/Makefile | 2 +
drivers/ata/pata_mpc52xx.c | 2 +-
drivers/char/hvc_iseries.c | 2 +-
drivers/char/hvc_vio.c | 2 +-
drivers/char/hvcs.c | 2 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/net/fec_mpc52xx.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 2 +-
drivers/net/ps3_gelic_net.c | 22 +-
drivers/net/ps3_gelic_wireless.c | 6 +-
drivers/rapidio/rio-scan.c | 43 +-
drivers/rapidio/rio-sysfs.c | 6 +-
drivers/scsi/ps3rom.c | 10 +-
drivers/serial/mpc52xx_uart.c | 5 +-
drivers/serial/of_serial.c | 2 +-
drivers/serial/ucc_uart.c | 19 +-
drivers/spi/mpc52xx_psc_spi.c | 22 +-
drivers/usb/host/ehci-ps3.c | 4 +-
drivers/usb/host/ohci-ps3.c | 4 +-
drivers/video/xilinxfb.c | 59 +-
drivers/watchdog/mpc5200_wdt.c | 2 +-
include/linux/fsl_devices.h | 4 -
84 files changed, 7916 insertions(+), 233 deletions(-)
create mode 100644 arch/powerpc/boot/dts/kmeter1.dts
create mode 100644 arch/powerpc/boot/dts/xcalibur1501.dts
create mode 100644 arch/powerpc/boot/dts/xpedite5200.dts
create mode 100644 arch/powerpc/boot/dts/xpedite5200_xmon.dts
create mode 100644 arch/powerpc/boot/dts/xpedite5301.dts
create mode 100644 arch/powerpc/boot/dts/xpedite5330.dts
create mode 100644 arch/powerpc/boot/dts/xpedite5370.dts
create mode 100644 arch/powerpc/configs/83xx/kmeter1_defconfig
create mode 100644 arch/powerpc/configs/85xx/xes_mpc85xx_defconfig
rename arch/powerpc/include/asm/{mpc512x.h => mpc5xxx.h} (65%)
create mode 100644 arch/powerpc/platforms/83xx/kmeter1.c
create mode 100644 arch/powerpc/platforms/85xx/xes_mpc85xx.c
create mode 100644 arch/powerpc/sysdev/mpc5xxx_clocks.c
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix FSL RapidIO probing on MDS boards
From: Kumar Gala @ 2009-06-19 5:58 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090618232208.GA11063@oksana.dev.rtsoft.ru>
On Jun 18, 2009, at 6:22 PM, Anton Vorontsov wrote:
> From: Randy Vinson <rvinson@mvista.com>
>
> FSL RapidIO won't probe without a proper compatible entry. This
> patch fixes the issue by adding fsl,rapidio-delta compatible to
> mpc85xx_ids.
>
> Signed-off-by: Randy Vinson <rvinson@mvista.com>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied
- k
^ permalink raw reply
* linux-next: origin tree build failure
From: Stephen Rothwell @ 2009-06-19 6:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: Uytterhoeven, linux-next, ppc-dev, linux-kernel, Geert
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
Hi all,
Today's linux-next build (powerpc64, gcc 4.1.3) failed like this:
drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a section type conflict
Caused by commit ae52bb2384f721562f15f719de1acb8e934733cb ("fbdev: move
logo externs to header file") but probably really a compiler bug as gcc
4.3 and 4.4 do not get this error. I have reverted that commit for
today, but we really need some workaround as gcc 4.1.3 is not uncommon.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH -mm v3][POWERPC] mpc8xxx : allow SPI without cs.
From: Rini van Zetten @ 2009-06-19 7:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: spi-devel-general, linuxppc-dev list
In-Reply-To: <EEB9B7B7-5456-4AE9-8BB9-96DA04320697@kernel.crashing.org>
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = <&pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
&pio2 2 0>; /* cs2 */
Signed-off-by: Rini van Zetten <rini@arvoo.nl>
---
Changes :
patch against 2.6.30-rc8-mm1
style updates
compiler warning fix
comment :
This feature is needed on our home made board to program an onboard fpga.
The fpga needs some special pin toggling to put it in programming mode.
That's why we want to skip the usual gpio cs and do the pin toggling
in our driver
diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
index 0fd0ec4..3a367ce 100644
--- a/drivers/spi/spi_mpc8xxx.c
+++ b/drivers/spi/spi_mpc8xxx.c
@@ -666,9 +666,12 @@ static void mpc8xxx_spi_cs_control(struct spi_device *spi, bool on)
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev->platform_data);
u16 cs = spi->chip_select;
int gpio = pinfo->gpios[cs];
- bool alow = pinfo->alow_flags[cs];
- gpio_set_value(gpio, on ^ alow);
+ if (gpio != -EEXIST) {
+ bool alow = pinfo->alow_flags[cs];
+
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
@@ -707,27 +710,31 @@ static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, &flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, "can't request gpio #%d: %d\n",
+ i, ret);
+ goto err_loop;
+ }
+
+ pinfo->gpios[i] = gpio;
+ pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo->gpios[i],
+ pinfo->alow_flags[i]);
+ if (ret) {
+ dev_err(dev, "can't set output direction for"
+ "gpio #%d: %d\n",
+ i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo->gpios[i] = -EEXIST;
+ } else {
dev_err(dev, "invalid gpio #%d: %d\n", i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
- goto err_loop;
- }
-
- pinfo->gpios[i] = gpio;
- pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
- if (ret) {
- dev_err(dev, "can't set output direction for gpio "
- "#%d: %d\n", i, ret);
- goto err_loop;
- }
}
pdata->max_chipselect = ngpios;
^ permalink raw reply related
* Re: [PATCH -mm v3][POWERPC] mpc8xxx : allow SPI without cs.
From: Kumar Gala @ 2009-06-19 7:45 UTC (permalink / raw)
To: Rini van Zetten; +Cc: spi-devel-general, linuxppc-dev list
In-Reply-To: <4A3B3D90.5030100@arvoo.nl>
On Jun 19, 2009, at 2:26 AM, Rini van Zetten wrote:
> This patch adds the possibility to have a spi device without a cs.
>
> For example, the dts file should look something like this:
>
> spi-controller {
> gpios = <&pio1 1 0 /* cs0 */
> 0 /* cs1, no GPIO */
> &pio2 2 0>; /* cs2 */
>
> Signed-off-by: Rini van Zetten <rini@arvoo.nl>
> ---
> Changes :
> patch against 2.6.30-rc8-mm1
> style updates
> compiler warning fix
> comment :
> This feature is needed on our home made board to program an onboard
> fpga.
> The fpga needs some special pin toggling to put it in programming
> mode.
> That's why we want to skip the usual gpio cs and do the pin toggling
> in our driver
>
Which FSL chip are you using?
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Add irqtrace support for 32-bit powerpc (v2)
From: Kumar Gala @ 2009-06-19 7:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20090618034439.0854ADDDB2@ozlabs.org>
On Jun 17, 2009, at 10:43 PM, Benjamin Herrenschmidt wrote:
> Based on initial work from: Dale Farnsworth <dale@farnsworth.org>
>
> Add the low level irq tracing hooks for 32-bit powerpc needed
> to enable full lockdep functionality.
>
> The approach taken to deal with the code in entry_32.S is that
> we don't trace all the transitions of MSR:EE when we just turn
> it off to peek at TI_FLAGS without races. Only when we are
> calling into C code or returning from exceptions with a state
> that have changed from what lockdep thinks.
>
> There's a little bugger though: If we take an exception that
> keeps interrupts enabled (such as an alignment exception) while
> interrupts are enabled, we will call trace_hardirqs_on() on the
> way back spurriously. Not a big deal, but to get rid of it would
> require remembering in pt_regs that the exception was one of the
> type that kept interrupts enabled which we don't know at this
> stage. (Well, we could test all cases for regs->trap but that
> sucks too much).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> This one fixes a bug, trace_hardirqs_on was too late in the
> restore: code path and would clobber things. This boots fine
> now on a PowerBook.
Tested-by: Kumar Gala <galak@kernel.crashing.org>
on SMP e500 based system (8572)
- k
^ permalink raw reply
* kilauea/405ex external interrupts
From: Lada Podivin @ 2009-06-19 8:00 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
Hi,
I'm writing a linux driver that uses an external interrupt (ppc 405ex). I'm
using GPIO pin 30 (external IRQ 1) connected to UIC1. I'm aware of the
virtual interrupt stuff, so I added a new node to my device tree in order to
get proper virtual IRQ number. This node describes an external event and its
connection to UIC via the mentioned ext. int. Here is a sample of the
divce-tree:
...
UIC1: interrupt-controller1 {
compatible = "ibm,uic-405ex","ibm,uic";
interrupt-controller;
cell-index = <1>;
dcr-reg = <0x0d0 0x009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
interrupt-parent = <&UIC0>;
};
EXTEVENT: external_event {
device_type = "external";
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <0x1e 0x1>;
interrupt-parent = <&UIC1>;
};
...
Then I use function "irq_of_parse_and_map()" which returns the virtual IRQ
number 22. So, "request_irq()" seems to be satisfied with this number. I can
see this interrupt in the /proc/interrupts. But! When I connect a signal
source to the pin 30, nothing happens - the interrupt service routine isn't
called.
Am I suppose to configure anything else? (e. g. pin multiplexing, further
device-tree tuning...) Thank you!
Best regards,
Ladi
[-- Attachment #2: Type: text/html, Size: 1664 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix mpic alloc warning
From: Kumar Gala @ 2009-06-19 8:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Since we can use kmalloc earlier we are getting the following since the
mpic_alloc() code calls alloc_bootmem(). Move to using kzalloc() to
remove the warning.
------------[ cut here ]------------
Badness at c0583248 [verbose debug info unavailable]
NIP: c0583248 LR: c0583210 CTR: 00000004
REGS: c0741de0 TRAP: 0700 Not tainted (2.6.30-06736-g12a31df)
MSR: 00021000 <ME,CE> CR: 22024024 XER: 00000000
TASK = c070d3b8[0] 'swapper' THREAD: c0740000 CPU: 0
<6>GPR00: 00000001 c0741e90 c070d3b8 00000001 00000210 00000020 3fffffff 00000000
<6>GPR08: 00000000 c0c85700 c04f8c40 0000002d 22044022 1004a388 7ffd9400 00000000
<6>GPR16: 00000000 7ffcd100 7ffcd100 7ffcd100 c04f8c40 00000000 c059f62c c075a0c0
<6>GPR24: c059f648 00000000 0000000f 00000210 00000020 00000000 3fffffff 00000210
NIP [c0583248] alloc_arch_preferred_bootmem+0x50/0x80
LR [c0583210] alloc_arch_preferred_bootmem+0x18/0x80
Call Trace:
[c0741e90] [c07343b0] devtree_lock+0x0/0x24 (unreliable)
[c0741ea0] [c0583b14] ___alloc_bootmem_nopanic+0x54/0x108
[c0741ee0] [c0583e18] ___alloc_bootmem+0x18/0x50
[c0741ef0] [c057b9cc] mpic_alloc+0x48/0x710
[c0741f40] [c057ecf4] mpc85xx_ds_pic_init+0x190/0x1b8
[c0741f90] [c057633c] init_IRQ+0x24/0x34
[c0741fa0] [c05738b8] start_kernel+0x260/0x3dc
[c0741ff0] [c00003c8] skpinv+0x2e0/0x31c
Instruction dump:
409e001c 7c030378 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c0c8
39295700 80090004 7c000034 5400d97e <0f000000> 2f800000 409e001c 38800000
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/mpic.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9c3af50..9e81157 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1052,11 +1052,10 @@ struct mpic * __init mpic_alloc(struct device_node *node,
int intvec_top;
u64 paddr = phys_addr;
- mpic = alloc_bootmem(sizeof(struct mpic));
+ mpic = kzalloc(sizeof(struct mpic), GFP_NOWAIT);
if (mpic == NULL)
return NULL;
-
- memset(mpic, 0, sizeof(struct mpic));
+
mpic->name = name;
mpic->hc_irq = mpic_irq_chip;
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH 6/6] perf_counter: tools: Makefile tweaks for 64-bit powerpc
From: Paul Mackerras @ 2009-06-19 8:16 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, Peter Zijlstra, linux-kernel
In-Reply-To: <20090618091334.GB21191@elte.hu>
Ingo Molnar writes:
> Note, i left out this bit from the commit - we need to find a better
> solution than to allow ugly warnings on PowerPC.
>
> Could we use the kernel's u64 type directly perhaps? That would
> allow us to change all __u64 to u64 in all of tools/perf/ which is a
> nice clean-up in any case.
This is userspace, we can use "u64" however we like. :) I'll cook up
a patch to add "typedef unsigned long long u64" and change __u64 to
u64.
Paul.
^ 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