* 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
* 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: 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
* [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: [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
* 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
* [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] 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
* 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 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: 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: 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
* [PATCH] powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS
From: Anton Vorontsov @ 2009-06-18 23:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
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(-)
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/boot/dts/mpc8569mds.dts
index 39c2927..63e8109 100644
--- a/arch/powerpc/boot/dts/mpc8569mds.dts
+++ b/arch/powerpc/boot/dts/mpc8569mds.dts
@@ -229,6 +229,7 @@
/* Filled in by U-Boot */
clock-frequency = <0>;
status = "disabled";
+ sdhci,1-bit-only;
};
crypto@30000 {
--
1.6.3.1
^ permalink raw reply related
* [PATCH] powerpc/85xx: Fix FSL RapidIO probing on MDS boards
From: Anton Vorontsov @ 2009-06-18 23:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
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(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index b2c0a43..daf6711 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -268,6 +268,7 @@ static struct of_device_id mpc85xx_ids[] = {
{ .type = "qe", },
{ .compatible = "fsl,qe", },
{ .compatible = "gianfar", },
+ { .compatible = "fsl,rapidio-delta", },
{},
};
--
1.6.3.1
^ permalink raw reply related
* Re: MPC83xx watchdog reset board dead lock
From: David Hawkins @ 2009-06-18 23:22 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: Linux PPC, Norbert van Bolhuis
In-Reply-To: <c384c5ea0906181601g28e3ac7frf2019b11bc34e057@mail.gmail.com>
Hi Leon,
>>> I'll be testing the design tomorrow on the reference board, I'll
>>> report results in this thread.
>> Interesting.
>> Looking forward to the results.
>>
> Design works as expected on the now slightly modified MPC8313E-RDB
> board.
That's great!
> Kudos to David.
I'm sure you would have come up with a similar solution,
had you had a chance to sleep on it :)
Glad to help out.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
From: Benjamin Herrenschmidt @ 2009-06-18 23:03 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Peter Zijlstra
In-Reply-To: <20090617142719.GC6846@elte.hu>
On Wed, 2009-06-17 at 16:27 +0200, Ingo Molnar wrote:
> I think it would be nice to have more platform support in .31.
> Perfcounters is a brand-new feature so there's no risk of
> regression. In the end it will depend on Linus to pull of course,
> and BenH can veto it too if he'd like no more PowerPC changes in
> this cycle. Worst-case it's all .32 material.
There have been little PowerPC changes in this cycle and I agree
with you on that it's a nice feature to have with little risk of
regression.
In fact, I also have an up-to-date (and hopefully working)
irqtrace/lockdep patch for 32-bit powerpc (we only do 64-bit right now)
that I'm considering merging this time around, the benefit it brings is
worth the risk I believe.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
From: Benjamin Herrenschmidt @ 2009-06-18 23:01 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, Paul Mackerras, Peter Zijlstra, linux-kernel
In-Reply-To: <20090617142151.GB6846@elte.hu>
On Wed, 2009-06-17 at 16:21 +0200, Ingo Molnar wrote:
> > This depends on the generic atomic64_t patches, which are now in
> > Linus' tree. Ingo, if you're putting these in, please pull Linus'
> > tree in first.
>
> Note, i've created a new branch, tip:perfcounters/powerpc, so we can
> keep these things separate and Ben can pull them too. I see there
> was some review feedback - do you want to send a v2 version perhaps?
At this stage, I'm happy for you to push them. I was thinking about
moving the files around but that can wait. No serious comments on the
patches themselves on my side.
Cheers
Ben
^ permalink raw reply
* Re: MPC83xx watchdog reset board dead lock
From: Leon Woestenberg @ 2009-06-18 23:01 UTC (permalink / raw)
To: Norbert van Bolhuis, David Hawkins; +Cc: Linux PPC
In-Reply-To: <4A38DE83.1010405@aimvalley.nl>
Hello,
On Wed, Jun 17, 2009 at 2:16 PM, Norbert van
Bolhuis<nvbolhuis@aimvalley.nl> wrote:
>>
>> I'll be testing the design tomorrow on the reference board, I'll
>> report results in this thread.
>
> Interesting.
> Looking forward to the results.
>
Design works as expected on the now slightly modified MPC8313E-RDB
board. Kudos to David.
Cheers,
--
Leon
^ permalink raw reply
* [PATCH v2] fsldma: Add DMA_SLAVE support
From: Ira Snyder @ 2009-06-18 22:53 UTC (permalink / raw)
To: linuxppc-dev, Kumar Gala, Dan Williams, Li Yang
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy data from several different
devices into a scatterlist at the same time.
This also adds support to enable some controller-specific features such as
external start and external pause for a DMA transaction.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
After discussion with Dan Williams, this is the second version of the
DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily
with both drivers I have written against this API, an FPGA programmer
and an FPGA data grabber.
Kumar, Dan asked me to add you to the CC list, so you can have a look at
this patch before he adds it to his tree.
The other two small patches I posted earlier are very helpful in testing
this functionality. They make the fsldma driver leave the BWC (bandwidth
control) bits alone on the 83xx controller, as well as making the
external start feature available on 83xx.
In order for the external start/pause features to be useful, the
bandwidth control bits (in the mode register) need to be set before
attempting to use the controller. I could spin a v3 of this patch that
adds a field to struct fsl_dma_slave to set the bits appropriately. Or I
could send another patch for that. Thoughts?
Many thanks to all that have participated in the discussion about this
patch.
v1 -> v2:
* move fsldma.h from include/linux to arch/powerpc/include/asm
* add kerneldoc documentation
arch/powerpc/include/asm/fsldma.h | 134 ++++++++++++++++++++++
drivers/dma/fsldma.c | 224 +++++++++++++++++++++++++++++++++++++
2 files changed, 358 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsldma.h
diff --git a/arch/powerpc/include/asm/fsldma.h b/arch/powerpc/include/asm/fsldma.h
new file mode 100644
index 0000000..1bc71fb
--- /dev/null
+++ b/arch/powerpc/include/asm/fsldma.h
@@ -0,0 +1,134 @@
+/*
+ * Freescale MPC83XX / MPC85XX DMA Controller
+ *
+ * Copyright (c) 2009 Ira W. Snyder <iws@ovro.caltech.edu>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef __ARCH_POWERPC_ASM_FSLDMA_H__
+#define __ARCH_POWERPC_ASM_FSLDMA_H__
+
+#include <linux/dmaengine.h>
+
+/*
+ * Definitions for the Freescale DMA controller's DMA_SLAVE implemention
+ *
+ * The Freescale DMA_SLAVE implementation was designed to handle many-to-many
+ * transfers. An example usage would be an accelerated copy between two
+ * scatterlists. Another example use would be an accelerated copy from
+ * multiple non-contiguous device buffers into a single scatterlist.
+ *
+ * A DMA_SLAVE transaction is defined by a struct fsl_dma_slave. This
+ * structure contains a list of hardware addresses that should be copied
+ * to/from the scatterlist passed into device_prep_slave_sg(). The structure
+ * also has some fields to enable hardware-specific features.
+ */
+
+/**
+ * struct fsl_dma_hw_addr
+ * @entry: linked list entry
+ * @address: the hardware address
+ * @length: length to transfer
+ *
+ * Holds a single physical hardware address / length pair for use
+ * with the DMAEngine DMA_SLAVE API.
+ */
+struct fsl_dma_hw_addr {
+ struct list_head entry;
+
+ dma_addr_t address;
+ size_t length;
+};
+
+/**
+ * struct fsl_dma_slave
+ * @addresses: a linked list of struct fsl_dma_hw_addr structures
+ * @src_loop_size: setup and enable constant source-address DMA transfers
+ * @dst_loop_size: setup and enable constant destination address DMA transfers
+ * @external_start: enable externally started DMA transfers
+ * @external_pause: enable externally paused DMA transfers
+ *
+ * Holds a list of address / length pairs for use with the DMAEngine
+ * DMA_SLAVE API implementation for the Freescale DMA controller.
+ */
+struct fsl_dma_slave {
+
+ /* List of hardware address/length pairs */
+ struct list_head addresses;
+
+ /* Support for extra controller features */
+ unsigned int src_loop_size;
+ unsigned int dst_loop_size;
+ bool external_start;
+ bool external_pause;
+};
+
+/**
+ * fsl_dma_slave_append - add an address/length pair to a struct fsl_dma_slave
+ * @slave: the &struct fsl_dma_slave to add to
+ * @address: the hardware address to add
+ * @length: the length of bytes to transfer from @address
+ *
+ * Add a hardware address/length pair to a struct fsl_dma_slave. Returns 0 on
+ * success, -ERRNO otherwise.
+ */
+static inline int fsl_dma_slave_append(struct fsl_dma_slave *slave,
+ dma_addr_t address, size_t length)
+{
+ struct fsl_dma_hw_addr *addr;
+
+ addr = kzalloc(sizeof(*addr), GFP_ATOMIC);
+ if (!addr)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&addr->entry);
+ addr->address = address;
+ addr->length = length;
+
+ list_add_tail(&addr->entry, &slave->addresses);
+ return 0;
+}
+
+/**
+ * fsl_dma_slave_free - free a struct fsl_dma_slave
+ * @slave: the struct fsl_dma_slave to free
+ *
+ * Free a struct fsl_dma_slave and all associated address/length pairs
+ */
+static inline void fsl_dma_slave_free(struct fsl_dma_slave *slave)
+{
+ struct fsl_dma_hw_addr *addr, *tmp;
+
+ if (slave) {
+ list_for_each_entry_safe(addr, tmp, &slave->addresses, entry) {
+ list_del(&addr->entry);
+ kfree(addr);
+ }
+
+ kfree(slave);
+ }
+}
+
+/**
+ * fsl_dma_slave_alloc - allocate a struct fsl_dma_slave
+ * @gfp: the flags to pass to kmalloc when allocating this structure
+ *
+ * Allocate a struct fsl_dma_slave for use by the DMA_SLAVE API. Returns a new
+ * struct fsl_dma_slave on success, or NULL on failure.
+ */
+static inline struct fsl_dma_slave *fsl_dma_slave_alloc(gfp_t gfp)
+{
+ struct fsl_dma_slave *slave;
+
+ slave = kzalloc(sizeof(*slave), gfp);
+ if (!slave)
+ return NULL;
+
+ INIT_LIST_HEAD(&slave->addresses);
+ return slave;
+}
+
+#endif /* __ARCH_POWERPC_ASM_FSLDMA_H__ */
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index f18d1bd..67c3c47 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -29,6 +29,7 @@
#include <linux/dmapool.h>
#include <linux/of_platform.h>
+#include <asm/fsldma.h>
#include "fsldma.h"
static void dma_init(struct fsl_dma_chan *fsl_chan)
@@ -531,6 +532,226 @@ fail:
}
/**
+ * fsl_dma_prep_slave_sg - prepare descriptors for a DMA_SLAVE transaction
+ * @chan: DMA channel
+ * @sgl: scatterlist to transfer to/from
+ * @sg_len: number of entries in @scatterlist
+ * @direction: DMA direction
+ * @flags: DMAEngine flags
+ *
+ * Prepare a set of descriptors for a DMA_SLAVE transaction. Following the
+ * DMA_SLAVE API, this gets the device-specific information from the
+ * chan->private variable.
+ */
+static struct dma_async_tx_descriptor *fsl_dma_prep_slave_sg(
+ struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
+ enum dma_data_direction direction, unsigned long flags)
+{
+ struct fsl_dma_chan *fsl_chan;
+ struct fsl_desc_sw *first = NULL, *prev = NULL, *new = NULL;
+ struct fsl_dma_slave *slave;
+ struct list_head *tx_list;
+ size_t copy;
+
+ int i;
+ struct scatterlist *sg;
+ size_t sg_used;
+ size_t hw_used;
+ struct fsl_dma_hw_addr *hw;
+ dma_addr_t dma_dst, dma_src;
+
+ if (!chan)
+ return NULL;
+
+ if (!chan->private)
+ return NULL;
+
+ fsl_chan = to_fsl_chan(chan);
+ slave = chan->private;
+
+ if (list_empty(&slave->addresses))
+ return NULL;
+
+ hw = list_first_entry(&slave->addresses, struct fsl_dma_hw_addr, entry);
+ hw_used = 0;
+
+ /*
+ * Build the hardware transaction to copy from the scatterlist to
+ * the hardware, or from the hardware to the scatterlist
+ *
+ * If you are copying from the hardware to the scatterlist and it
+ * takes two hardware entries to fill an entire page, then both
+ * hardware entries will be coalesced into the same page
+ *
+ * If you are copying from the scatterlist to the hardware and a
+ * single page can fill two hardware entries, then the data will
+ * be read out of the page into the first hardware entry, and so on
+ */
+ for_each_sg(sgl, sg, sg_len, i) {
+ sg_used = 0;
+
+ /* Loop until the entire scatterlist entry is used */
+ while (sg_used < sg_dma_len(sg)) {
+
+ /*
+ * If we've used up the current hardware address/length
+ * pair, we need to load a new one
+ *
+ * This is done in a while loop so that descriptors with
+ * length == 0 will be skipped
+ */
+ while (hw_used >= hw->length) {
+
+ /*
+ * If the current hardware entry is the last
+ * entry in the list, we're finished
+ */
+ if (list_is_last(&hw->entry, &slave->addresses))
+ goto finished;
+
+ /* Get the next hardware address/length pair */
+ hw = list_entry(hw->entry.next,
+ struct fsl_dma_hw_addr, entry);
+ hw_used = 0;
+ }
+
+ /* Allocate the link descriptor from DMA pool */
+ new = fsl_dma_alloc_descriptor(fsl_chan);
+ if (!new) {
+ dev_err(fsl_chan->dev, "No free memory for "
+ "link descriptor\n");
+ goto fail;
+ }
+#ifdef FSL_DMA_LD_DEBUG
+ dev_dbg(fsl_chan->dev, "new link desc alloc %p\n", new);
+#endif
+
+ /*
+ * Calculate the maximum number of bytes to transfer,
+ * making sure it is less than the DMA controller limit
+ */
+ copy = min_t(size_t, sg_dma_len(sg) - sg_used,
+ hw->length - hw_used);
+ copy = min_t(size_t, copy, FSL_DMA_BCR_MAX_CNT);
+
+ /*
+ * DMA_FROM_DEVICE
+ * from the hardware to the scatterlist
+ *
+ * DMA_TO_DEVICE
+ * from the scatterlist to the hardware
+ */
+ if (direction == DMA_FROM_DEVICE) {
+ dma_src = hw->address + hw_used;
+ dma_dst = sg_dma_address(sg) + sg_used;
+ } else {
+ dma_src = sg_dma_address(sg) + sg_used;
+ dma_dst = hw->address + hw_used;
+ }
+
+ /* Fill in the descriptor */
+ set_desc_cnt(fsl_chan, &new->hw, copy);
+ set_desc_src(fsl_chan, &new->hw, dma_src);
+ set_desc_dest(fsl_chan, &new->hw, dma_dst);
+
+ /*
+ * If this is not the first descriptor, chain the
+ * current descriptor after the previous descriptor
+ */
+ if (!first) {
+ first = new;
+ } else {
+ set_desc_next(fsl_chan, &prev->hw,
+ new->async_tx.phys);
+ }
+
+ new->async_tx.cookie = 0;
+ async_tx_ack(&new->async_tx);
+
+ prev = new;
+ sg_used += copy;
+ hw_used += copy;
+
+ /* Insert the link descriptor into the LD ring */
+ list_add_tail(&new->node, &first->async_tx.tx_list);
+ }
+ }
+
+finished:
+
+ /* All of the hardware address/length pairs had length == 0 */
+ if (!first || !new)
+ return NULL;
+
+ new->async_tx.flags = flags;
+ new->async_tx.cookie = -EBUSY;
+
+ /* Set End-of-link to the last link descriptor of new list */
+ set_ld_eol(fsl_chan, new);
+
+ /* Enable extra controller features */
+ if (fsl_chan->set_src_loop_size)
+ fsl_chan->set_src_loop_size(fsl_chan, slave->src_loop_size);
+
+ if (fsl_chan->set_dest_loop_size)
+ fsl_chan->set_dest_loop_size(fsl_chan, slave->dst_loop_size);
+
+ if (fsl_chan->toggle_ext_start)
+ fsl_chan->toggle_ext_start(fsl_chan, slave->external_start);
+
+ if (fsl_chan->toggle_ext_pause)
+ fsl_chan->toggle_ext_pause(fsl_chan, slave->external_pause);
+
+ return &first->async_tx;
+
+fail:
+ /* If first was not set, then we failed to allocate the very first
+ * descriptor, and we're done */
+ if (!first)
+ return NULL;
+
+ /*
+ * First is set, so all of the descriptors we allocated have been added
+ * to first->async_tx.tx_list, INCLUDING "first" itself. Therefore we
+ * must traverse the list backwards freeing each descriptor in turn
+ *
+ * We're re-using variables for the loop, oh well
+ */
+ tx_list = &first->async_tx.tx_list;
+ list_for_each_entry_safe_reverse(new, prev, tx_list, node) {
+ list_del_init(&new->node);
+ dma_pool_free(fsl_chan->desc_pool, new, new->async_tx.phys);
+ }
+
+ return NULL;
+}
+
+static void fsl_dma_device_terminate_all(struct dma_chan *chan)
+{
+ struct fsl_dma_chan *fsl_chan;
+ struct fsl_desc_sw *desc, *tmp;
+ unsigned long flags;
+
+ if (!chan)
+ return;
+
+ fsl_chan = to_fsl_chan(chan);
+
+ /* Halt the DMA engine */
+ dma_halt(fsl_chan);
+
+ spin_lock_irqsave(&fsl_chan->desc_lock, flags);
+
+ /* Remove and free all of the descriptors in the LD queue */
+ list_for_each_entry_safe(desc, tmp, &fsl_chan->ld_queue, node) {
+ list_del(&desc->node);
+ dma_pool_free(fsl_chan->desc_pool, desc, desc->async_tx.phys);
+ }
+
+ spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
+}
+
+/**
* fsl_dma_update_completed_cookie - Update the completed cookie.
* @fsl_chan : Freescale DMA channel
*/
@@ -955,12 +1176,15 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
+ dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_is_tx_complete = fsl_dma_is_complete;
fdev->common.device_issue_pending = fsl_dma_memcpy_issue_pending;
+ fdev->common.device_prep_slave_sg = fsl_dma_prep_slave_sg;
+ fdev->common.device_terminate_all = fsl_dma_device_terminate_all;
fdev->common.dev = &dev->dev;
fdev->irq = irq_of_parse_and_map(dev->node, 0);
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH 5/6] perf_counter: powerpc: Add processor back-end for MPC7450 family
From: Paul Mackerras @ 2009-06-18 21:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra, linux-kernel
In-Reply-To: <E57BFC08-F847-463A-9D0F-55979C4B0524@kernel.crashing.org>
Kumar Gala writes:
> In looking at doing this what suggestions do you have in implementing
> perf_instruction_pointer() if we don't have the equivalent of SIAR.
> Just use regs->nip ?
Yes, exactly. If you don't have SIAR/SDAR/MMCRA, the default
definitions for perf_instruction_pointer and perf_misc_flags in
include/linux/perf_counter.h are fine, and you get them if
perf_misc_flags is not defined.
Paul.
^ permalink raw reply
* Re: [PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.
From: Benjamin Herrenschmidt @ 2009-06-18 22:22 UTC (permalink / raw)
To: Geoff Thorpe; +Cc: linuxppc-dev
In-Reply-To: <4A3AA3FE.8090903@freescale.com>
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.
Cheers,
Ben.
^ permalink raw reply
* Re: killing use of ppc_md.init
From: Benjamin Herrenschmidt @ 2009-06-18 22:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <C81AEED1-5CEC-42B8-A893-5E6BDDD4EC54@kernel.crashing.org>
On Thu, 2009-06-18 at 09:38 -0500, Kumar Gala wrote:
> ppc_md.init only exists on ppc32 and seems like its pretty useless
> today. The users seem to fall into two classes:
>
> 1. called to do of_platform_bus_probe() - most platforms use
> machine_device_initcall() for this
> 2. some platform init code which seems like it could move into
> setup_arch().
>
> The second one seems to only be on amigaone and chrp. Anyone know if
> there is any harm in moving the amigaone_init() into
> amigaone_setup_arch() and similarly on chrp chrp_init2() into
> chrp_setup_arch().
We might kill it ... and revive it differently :-)
Yes, the current ppc_init() can probably just go.
However, we probably also want to add a call from init/main.c back to
the architectures and ppc_md. in our case that is right after mm_init().
Right now, we do way too many things at setup_arch() (or even before
that on ppc64) which induces all sorts of pain due to having to use
bootmem etc...
Now that slab is available much earlier, before init_IRQ() and
time_init(), we should consider moving a whole bunch of stuff somewhere
later in the boot process to simplify the code etc...
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
From: Dan Williams @ 2009-06-18 21:36 UTC (permalink / raw)
To: Ira Snyder; +Cc: linuxppc-dev@ozlabs.org, Li Yang
In-Reply-To: <20090618205024.GA16741@ovro.caltech.edu>
Ira Snyder wrote:
> So, I see a couple of ways of moving forward:
> 1) Keep my implementation, moving the includes to arch/powerpc/include.
> Do we drop the allocation functions?
+1 for option 1. Having it under arch/powerpc/include makes it clear
that it is a powerpc specific api, so keep the allocation routines.
Copy Kumar on the updated patch as I'll need a ppc-dev ack for carrying
this file addition through the dmaengine tree.
> Thanks for all the input Dan. I finally feel like we're getting
> somewhere :)
Thanks for the exchange it always helps to get a good picture of the
underlying design rationale.
Regards,
Dan
^ permalink raw reply
* [PATCH] powerpc: expose the multi-bit ops that underlie single-bit ops.
From: Geoff Thorpe @ 2009-06-18 20:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geoff Thorpe
The bitops.h functions that operate on a single bit in a bitfield are
implemented by operating on the corresponding word location. In all cases
the inner logic is valid if the mask being applied has more than one bit
set, so this patch exposes those inner operations. Indeed, set_bits() was
already available, but it duplicated code from set_bit() (rather than
making the latter a wrapper) - it was also missing the PPC405_ERR77()
workaround and the "volatile" address qualifier present in other APIs.
This corrects that, and exposes the other multi-bit equivalents.
One advantage of these multi-bit forms is that they allow word-sized
variables to essentially be their own spinlocks, eg. very useful for
state machines where an atomic "flags" variable can obviate the need for
any additional locking.
Signed-off-by: Geoff Thorpe <geoff@geoffthorpe.net>
---
arch/powerpc/include/asm/bitops.h | 194 ++++++++++++-------------------------
1 files changed, 61 insertions(+), 133 deletions(-)
diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
index 897eade..56f2f2e 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -56,174 +56,102 @@
#define BITOP_WORD(nr) ((nr) / BITS_PER_LONG)
#define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) & ~0x7)
+/* Macro for generating the ***_bits() functions */
+#define DEFINE_BITOP(fn, op, prefix, postfix) \
+static __inline__ void fn(unsigned long mask, \
+ volatile unsigned long *_p) \
+{ \
+ unsigned long old; \
+ unsigned long *p = (unsigned long *)_p; \
+ __asm__ __volatile__ ( \
+ prefix \
+"1:" PPC_LLARX "%0,0,%3\n" \
+ stringify_in_c(op) "%0,%0,%2\n" \
+ PPC405_ERR77(0,%3) \
+ PPC_STLCX "%0,0,%3\n" \
+ "bne- 1b\n" \
+ postfix \
+ : "=&r" (old), "+m" (*p) \
+ : "r" (mask), "r" (p) \
+ : "cc", "memory"); \
+}
+
+DEFINE_BITOP(set_bits, or, "", "")
+DEFINE_BITOP(clear_bits, andc, "", "")
+DEFINE_BITOP(clear_bits_unlock, andc, LWSYNC_ON_SMP, "")
+DEFINE_BITOP(change_bits, xor, "", "")
+
static __inline__ void set_bit(int nr, volatile unsigned long *addr)
{
- unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
-"1:" PPC_LLARX "%0,0,%3 # set_bit\n"
- "or %0,%0,%2\n"
- PPC405_ERR77(0,%3)
- PPC_STLCX "%0,0,%3\n"
- "bne- 1b"
- : "=&r" (old), "+m" (*p)
- : "r" (mask), "r" (p)
- : "cc" );
+ set_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr));
}
static __inline__ void clear_bit(int nr, volatile unsigned long *addr)
{
- unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
-"1:" PPC_LLARX "%0,0,%3 # clear_bit\n"
- "andc %0,%0,%2\n"
- PPC405_ERR77(0,%3)
- PPC_STLCX "%0,0,%3\n"
- "bne- 1b"
- : "=&r" (old), "+m" (*p)
- : "r" (mask), "r" (p)
- : "cc" );
+ clear_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr));
}
static __inline__ void clear_bit_unlock(int nr, volatile unsigned long *addr)
{
- unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
- LWSYNC_ON_SMP
-"1:" PPC_LLARX "%0,0,%3 # clear_bit_unlock\n"
- "andc %0,%0,%2\n"
- PPC405_ERR77(0,%3)
- PPC_STLCX "%0,0,%3\n"
- "bne- 1b"
- : "=&r" (old), "+m" (*p)
- : "r" (mask), "r" (p)
- : "cc", "memory");
+ clear_bits_unlock(BITOP_MASK(nr), addr + BITOP_WORD(nr));
}
static __inline__ void change_bit(int nr, volatile unsigned long *addr)
{
- unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
-"1:" PPC_LLARX "%0,0,%3 # change_bit\n"
- "xor %0,%0,%2\n"
- PPC405_ERR77(0,%3)
- PPC_STLCX "%0,0,%3\n"
- "bne- 1b"
- : "=&r" (old), "+m" (*p)
- : "r" (mask), "r" (p)
- : "cc" );
+ change_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr));
+}
+
+/* Like DEFINE_BITOP(), with changes to the arguments to 'op' and the output
+ * operands. */
+#define DEFINE_TESTOP(fn, op, prefix, postfix) \
+static __inline__ unsigned long fn( \
+ unsigned long mask, \
+ volatile unsigned long *_p) \
+{ \
+ unsigned long old, t; \
+ unsigned long *p = (unsigned long *)_p; \
+ __asm__ __volatile__ ( \
+ prefix \
+"1:" PPC_LLARX "%0,0,%3\n" \
+ stringify_in_c(op) "%1,%0,%2\n" \
+ PPC405_ERR77(0,%3) \
+ PPC_STLCX "%1,0,%3\n" \
+ "bne- 1b\n" \
+ postfix \
+ : "=&r" (old), "=&r" (t) \
+ : "r" (mask), "r" (p) \
+ : "cc", "memory"); \
+ return (old & mask); \
}
+DEFINE_TESTOP(test_and_set_bits, or, LWSYNC_ON_SMP, ISYNC_ON_SMP)
+DEFINE_TESTOP(test_and_set_bits_lock, or, "", ISYNC_ON_SMP)
+DEFINE_TESTOP(test_and_clear_bits, andc, LWSYNC_ON_SMP, ISYNC_ON_SMP)
+DEFINE_TESTOP(test_and_change_bits, xor, LWSYNC_ON_SMP, ISYNC_ON_SMP)
+
static __inline__ int test_and_set_bit(unsigned long nr,
volatile unsigned long *addr)
{
- unsigned long old, t;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
- LWSYNC_ON_SMP
-"1:" PPC_LLARX "%0,0,%3 # test_and_set_bit\n"
- "or %1,%0,%2 \n"
- PPC405_ERR77(0,%3)
- PPC_STLCX "%1,0,%3 \n"
- "bne- 1b"
- ISYNC_ON_SMP
- : "=&r" (old), "=&r" (t)
- : "r" (mask), "r" (p)
- : "cc", "memory");
-
- return (old & mask) != 0;
+ return test_and_set_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr)) != 0;
}
static __inline__ int test_and_set_bit_lock(unsigned long nr,
volatile unsigned long *addr)
{
- unsigned long old, t;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
-"1:" PPC_LLARX "%0,0,%3 # test_and_set_bit_lock\n"
- "or %1,%0,%2 \n"
- PPC405_ERR77(0,%3)
- PPC_STLCX "%1,0,%3 \n"
- "bne- 1b"
- ISYNC_ON_SMP
- : "=&r" (old), "=&r" (t)
- : "r" (mask), "r" (p)
- : "cc", "memory");
-
- return (old & mask) != 0;
+ return test_and_set_bits_lock(BITOP_MASK(nr),
+ addr + BITOP_WORD(nr)) != 0;
}
static __inline__ int test_and_clear_bit(unsigned long nr,
volatile unsigned long *addr)
{
- unsigned long old, t;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
- LWSYNC_ON_SMP
-"1:" PPC_LLARX "%0,0,%3 # test_and_clear_bit\n"
- "andc %1,%0,%2 \n"
- PPC405_ERR77(0,%3)
- PPC_STLCX "%1,0,%3 \n"
- "bne- 1b"
- ISYNC_ON_SMP
- : "=&r" (old), "=&r" (t)
- : "r" (mask), "r" (p)
- : "cc", "memory");
-
- return (old & mask) != 0;
+ return test_and_clear_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr)) != 0;
}
static __inline__ int test_and_change_bit(unsigned long nr,
volatile unsigned long *addr)
{
- unsigned long old, t;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
- LWSYNC_ON_SMP
-"1:" PPC_LLARX "%0,0,%3 # test_and_change_bit\n"
- "xor %1,%0,%2 \n"
- PPC405_ERR77(0,%3)
- PPC_STLCX "%1,0,%3 \n"
- "bne- 1b"
- ISYNC_ON_SMP
- : "=&r" (old), "=&r" (t)
- : "r" (mask), "r" (p)
- : "cc", "memory");
-
- return (old & mask) != 0;
-}
-
-static __inline__ void set_bits(unsigned long mask, unsigned long *addr)
-{
- unsigned long old;
-
- __asm__ __volatile__(
-"1:" PPC_LLARX "%0,0,%3 # set_bits\n"
- "or %0,%0,%2\n"
- PPC_STLCX "%0,0,%3\n"
- "bne- 1b"
- : "=&r" (old), "+m" (*addr)
- : "r" (mask), "r" (addr)
- : "cc");
+ return test_and_change_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr)) != 0;
}
#include <asm-generic/bitops/non-atomic.h>
--
1.5.6.3
^ permalink raw reply related
* Problem with memcpy on ppc8536
From: Fahd Abidi @ 2009-06-18 20:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]
Hello,
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":
memcpy:
rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */
addi r6,r3,-4
addi r4,r4,-4
beq 2f /* if less than 8 bytes to do */
andi. r0,r6,3 /* get dest word aligned */
mtctr r7
bne 5f
1: lwz r7,4(r4)
lwzu r8,8(r4)
stw r7,4(r6)
stwu r8,8(r6)
bdnz 1b
andi. r5,r5,7
2: cmplwi 0,r5,4
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?
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?
Fahd Abidi
Product Manager - Technical Tools and Development
Ultimate Solutions, Inc.
================================================================
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/>
[-- Attachment #2: Type: text/html, Size: 3136 bytes --]
^ 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