[PATCH] powerpc: Track backing pages used allocated by vmemmap_populate()
We need to keep track of the backing pages that get allocated by
vmemmap_populate() so that when we use kdump, the dump-capture kernel can
find these pages in memory.
We use a linked list of structures that contain the physical address of the
backing page and corresponding virtual address to track the backing pages.
And we use a simple spinlock to protect the vmemmap_list.
Signed-off-by: Mark Nelson
---
arch/powerpc/include/asm/pgalloc-64.h |7 +++
arch/powerpc/mm/init_64.c | 27 +++
2 files changed, 34 insertions(+)
Index: upstream/arch/powerpc/include/asm/pgalloc-64.h
===
--- upstream.orig/arch/powerpc/include/asm/pgalloc-64.h
+++ upstream/arch/powerpc/include/asm/pgalloc-64.h
@@ -10,6 +10,13 @@
#include
#include
#include
+#include
+
+struct vmemmap_backing {
+ unsigned long phys;
+ unsigned long virt_addr;
+ struct list_head list;
+};
/*
* Functions that deal with pagetables that could be at any level of
Index: upstream/arch/powerpc/mm/init_64.c
===
--- upstream.orig/arch/powerpc/mm/init_64.c
+++ upstream/arch/powerpc/mm/init_64.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -251,6 +252,30 @@ static void __meminit vmemmap_create_map
}
#endif /* CONFIG_PPC_BOOK3E */
+LIST_HEAD(vmemmap_list);
+DEFINE_SPINLOCK(vmemmap_list_lock);
+
+static __meminit void vmemmap_list_populate(unsigned long phys,
+ unsigned long start,
+ int node)
+{
+ struct vmemmap_backing *vmem_back;
+
+ vmem_back = vmemmap_alloc_block(sizeof(struct vmemmap_backing), node);
+ if (unlikely(!vmem_back)) {
+ WARN_ON(1);
+ return;
+ }
+
+ vmem_back->phys = phys;
+ vmem_back->virt_addr = start;
+ INIT_LIST_HEAD(&vmem_back->list);
+
+ spin_lock(&vmemmap_list_lock);
+ list_add(&vmem_back->list, &vmemmap_list);
+ spin_unlock(&vmemmap_list_lock);
+}
+
int __meminit vmemmap_populate(struct page *start_page,
unsigned long nr_pages, int node)
{
@@ -275,6 +300,8 @@ int __meminit vmemmap_populate(struct pa
if (!p)
return -ENOMEM;
+ vmemmap_list_populate(__pa(p), start, node);
+
pr_debug(" * %016lx..%016lx allocated at %p\n",
start, start + page_size, p);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
[please do not top-post] >> Do you now ever get two consecutive time readings that are closer >> that 64 tick together? If not, it's simply hiding the problem. >> >> Do you ever now read a value that does not have the bit with value >> 0x40 set? > I enabled the printing of all values. There is bigger gap between two > reading, it seems isync bring to performance drop. Yes exactly, which is to be expected. > Could you elaborate what does "closer that 64 tick together" mean? It means I cannot type -- "closer than 64 ticks". My concern was that the sync;isync thing might slow down things so much that you always get readings 64 or more cycles apart. But you don't. > You can see the attached log, the 0x40 is not always set. Yes indeed. Could you post the relevant piece if disassembly from your original binary (the one that has the problem)? Or send me the binary (not to the mailing list), I'll do it then. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
> Yes indeed. Could you post the relevant piece if disassembly from > your original binary (the one that has the problem)? Or send me the > binary (not to the mailing list), I'll do it then. Ah scratch that. I compiled your original code (after fixing the compile errors -- there is no such type as "bool" in C). The problem is that (upper << 32) | lower thing. "upper" is a 32-bit type, so shifting it by 32 or more bits is undefined. GCC compiles this to (shortened): 0: mftbu 9 ; mftbl 11 ; mftbu 0 ; cmpw 0,9 ; bne 0b # so far so good slwi 0,0,0 ; or 4,0,11 ; li 3,0 ; blr so it shifts by 0, i.e. it does upper | lower . Case closed, no hardware problem :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove
Amit Shah wrote:
On (Sun) Mar 21 2010 [10:07:25], Amit Shah wrote:
On (Sun) Mar 21 2010 [08:04:39], Benjamin Herrenschmidt wrote:
On Fri, 2010-03-19 at 08:18 -0700, Greg Kroah-Hartman wrote:
From: Amit Shah
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
This causes hangs during boot on pseries machines. Haven't had a chance
to track that down yet, but please revert
e74d098c66543d0731de62eb747ccd5b636a6f4c for now.
And this suggests that hvc_kick() is called before hvc_task is
initialised, ie, before hvc_init() is called.
Does this help?
Hi Amit,
I too ran into this issue as reported by Anton. Unfortunately in my
case the following suggested patch does not help boot the powerpc
box successfully. The boot still hangs with following messages
/dev/sda5: clean, 229739/2097152 files, 2485598/8377888 blocks (check in 4
mounts)
fsck succeeded. Mounting root device read-write.
Mounting root /dev/sda5
mount -o rw,acl,user_xattr -t ext3 /dev/sda5 /root
kjournald starting. Commit interval 5 seconds
EXT3-fs (sda5): using internal journal
EXT3-fs (sda5): mounted filesystem with writeback data mode
mount: can't find /root/proc in /etc/fstab or /etc/mtab
/sbin/smart_agetty: can not determine 'console' speed
Just to confirm i too am facing same issue as reported by Anton,
reverted commit e74d098c66543d0731de62eb747ccd5b636a6f4c and that allowed
by box to boot successfully.
Thanks
-Sachin
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index ba55bba..50ac983 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -285,6 +285,9 @@ EXPORT_SYMBOL_GPL(hvc_instantiate);
/* Wake the sleeping khvcd */
void hvc_kick(void)
{
+ if (!hvc_task)
+ return;
+
hvc_kicked = 1;
wake_up_process(hvc_task);
}
Amit
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove
On (Fri) Mar 26 2010 [14:43:56], Sachin Sant wrote: >> And this suggests that hvc_kick() is called before hvc_task is >> initialised, ie, before hvc_init() is called. >> >> Does this help? >> > Hi Amit, > > I too ran into this issue as reported by Anton. Unfortunately in my > case the following suggested patch does not help boot the powerpc > box successfully. The boot still hangs with following messages Was the hang you saw before applying this patch at the same place / for the same reason? > /dev/sda5: clean, 229739/2097152 files, 2485598/8377888 blocks (check in 4 > mounts) > fsck succeeded. Mounting root device read-write. > Mounting root /dev/sda5 > mount -o rw,acl,user_xattr -t ext3 /dev/sda5 /root > kjournald starting. Commit interval 5 seconds > EXT3-fs (sda5): using internal journal > EXT3-fs (sda5): mounted filesystem with writeback data mode > mount: can't find /root/proc in /etc/fstab or /etc/mtab > /sbin/smart_agetty: can not determine 'console' speed OK, this gets even murkier. I don't know why taking a few krefs modifies hvc_console behaviour to such an extent. > Just to confirm i too am facing same issue as reported by Anton, > reverted commit e74d098c66543d0731de62eb747ccd5b636a6f4c and that allowed > by box to boot successfully. Which module uses hvc_console in your case? Amit ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Booting headless PowerMac G5
2010/3/25 Michel Dänzer : > On Wed, 2010-03-24 at 11:32 +0100, Romain Goyet wrote: >> >> Here's a summary about "how to boot a PowerMac G5 without a screen >> attached". As many people have noticed, default yaboot install won't >> boot unless a screen is attached. >> >> Actually, the workaround is really simple. Thing is, that's the >> "ofboot.b" script that messes things up. This script is a "bridge", >> that actually either starts yaboot or let you boot off of a CD. I >> don't know what's the point, since OpenFirmware already lets you boot >> off of the CD by pressing C on boot… >> >> So basically, to boot headless, all you have to do is to tell >> OpenFirmware to boot straight off the yaboot binary, and to skip the >> ofboot.b >> Just boot into OpenFirmware (Command-Option-O-F), and type : >> setenv boot-device hd:2,yaboot (where 2 is the number of the partition >> containing yaboot) >> boot >> >> And here you go, you can unplug that useless monitor :-) >> >> References : >> http://saintaardvarkthecarpeted.com/blog/archive/2005/02/THE_WINE_OF_BOOT.html >> http://grub.enbug.org/TestingOnPowerPC > > That's good to know, thanks. > You're welcome. Actually I also wrote this as a memo for myself :-) > >> By the way, as of writing this, grub2 on PPC from debian gives a "out >> of memory" issue. Known bug. > > That's on the G5? It's working on my PowerBook, but I haven't updated > the grub2 binaries on the bootstrap partition in a while... > > Yeah, that's on a PowerMac QuadG5. I think that's a known issue : http://www.mail-archive.com/grub-de...@gnu.org/msg04455.html However it might be another one since it's working for you. I'm using grub2 from Debian stable. > -- > Earthling Michel Dänzer | http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove
Hi Amit, On Fri, 26 Mar 2010 15:28:21 +0530 Amit Shah wrote: > > On (Fri) Mar 26 2010 [14:43:56], Sachin Sant wrote: > > > > I too ran into this issue as reported by Anton. Unfortunately in my > > case the following suggested patch does not help boot the powerpc > > box successfully. The boot still hangs with following messages I have been getting this on my linux-next boot tests for a while as well. > Was the hang you saw before applying this patch at the same place / for > the same reason? I get the same hangs with and without the patch. Paulus bisected it (again) to the commit below and reverting that commit fixes the problem. > OK, this gets even murkier. I don't know why taking a few krefs modifies > hvc_console behaviour to such an extent. > > > Just to confirm i too am facing same issue as reported by Anton, > > reverted commit e74d098c66543d0731de62eb747ccd5b636a6f4c and that allowed > > by box to boot successfully. > > Which module uses hvc_console in your case? I assume hcv_vio. I also tested using "init=/bin/bash" as a kernel command line option and the console worked while I was running bash, but everything was very sluggish. Then when I did "exec /sbin/init" the console hung completely - sysrq (^O) didn't even work any more (it did while I was running bash). -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpSccUETLmh5.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove
Amit Shah wrote:
On (Fri) Mar 26 2010 [14:43:56], Sachin Sant wrote:
And this suggests that hvc_kick() is called before hvc_task is
initialised, ie, before hvc_init() is called.
Does this help?
Hi Amit,
I too ran into this issue as reported by Anton. Unfortunately in my
case the following suggested patch does not help boot the powerpc
box successfully. The boot still hangs with following messages
Was the hang you saw before applying this patch at the same place / for
the same reason?
Yes the machine hangs at the same place with or without the patch.
mount: can't find /root/proc in /etc/fstab or /etc/mtab
/sbin/smart_agetty: can not determine 'console' speed
OK, this gets even murkier. I don't know why taking a few krefs modifies
hvc_console behaviour to such an extent.
Looking at the commit e74d098c66543d0731de62eb747ccd5b636a6f4c,
i see that for every tty_kref_get() there is a corresponding
tty_kref_put() except maybe for the one in the following patch snippet
spin_lock_irqsave(&hp->lock, flags);
/* Check and then increment for fast path open. */
if (hp->count++ > 0) {
+ tty_kref_get(tty);
spin_unlock_irqrestore(&hp->lock, flags);
hvc_kick();
return 0;
I don't know this code very well but we might be missing a
corresponding tty_kref_put() some place ?
If i comment out the above tty_kref_get() call, the machine
boots fine with or without the suggested patch.
Thanks
-Sachin
Just to confirm i too am facing same issue as reported by Anton,
reverted commit e74d098c66543d0731de62eb747ccd5b636a6f4c and that allowed
by box to boot successfully.
Which module uses hvc_console in your case?
Amit
--
-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove
> >> mount: can't find /root/proc in /etc/fstab or /etc/mtab > >> /sbin/smart_agetty: can not determine 'console' speed > >> > > > > OK, this gets even murkier. I don't know why taking a few krefs modifies > > hvc_console behaviour to such an extent. Can you see if the agetty is getting a hangup or open failing. I wonder if its just a timing change ? Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
Yes, the missing 64-bit conversion is the key problem, I will try removing isync later. Thanks for your support. 2010/3/26 Segher Boessenkool > > Yes indeed. Could you post the relevant piece if disassembly from > > your original binary (the one that has the problem)? Or send me the > > binary (not to the mailing list), I'll do it then. > > Ah scratch that. I compiled your original code (after fixing the > compile errors -- there is no such type as "bool" in C). > > The problem is that (upper << 32) | lower thing. "upper" is a 32-bit > type, so shifting it by 32 or more bits is undefined. GCC compiles this > to (shortened): > > 0: mftbu 9 ; mftbl 11 ; mftbu 0 ; cmpw 0,9 ; bne 0b # so far so good > slwi 0,0,0 ; or 4,0,11 ; li 3,0 ; blr > > so it shifts by 0, i.e. it does upper | lower . > > Case closed, no hardware problem :-) > > > Segher > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Booting headless PowerMac G5
On Fri, 2010-03-26 at 11:20 +0100, Romain Goyet wrote: > 2010/3/25 Michel Dänzer : > > On Wed, 2010-03-24 at 11:32 +0100, Romain Goyet wrote: > >> > >> By the way, as of writing this, grub2 on PPC from debian gives a "out > >> of memory" issue. Known bug. > > > > That's on the G5? It's working on my PowerBook, but I haven't updated > > the grub2 binaries on the bootstrap partition in a while... > > Yeah, that's on a PowerMac QuadG5. > I think that's a known issue : > http://www.mail-archive.com/grub-de...@gnu.org/msg04455.html > However it might be another one since it's working for you. I'm using > grub2 from Debian stable. According to http://packages.debian.org/stable/grub2 that's version 1.96 +20080724-16, which is pretty old. Current in sid is 1.98, and it's only become usable for me in the course of the last year or so. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove
On (Fri) Mar 26 2010 [17:12:22], Sachin Sant wrote:
> Amit Shah wrote:
>> On (Fri) Mar 26 2010 [14:43:56], Sachin Sant wrote:
>>
And this suggests that hvc_kick() is called before hvc_task is
initialised, ie, before hvc_init() is called.
Does this help?
>>> Hi Amit,
>>>
>>> I too ran into this issue as reported by Anton. Unfortunately in my
>>> case the following suggested patch does not help boot the powerpc
>>> box successfully. The boot still hangs with following messages
>>>
>>
>> Was the hang you saw before applying this patch at the same place / for
>> the same reason?
>>
> Yes the machine hangs at the same place with or without the patch.
OK.
>>> mount: can't find /root/proc in /etc/fstab or /etc/mtab
>>> /sbin/smart_agetty: can not determine 'console' speed
>>>
>>
>> OK, this gets even murkier. I don't know why taking a few krefs modifies
>> hvc_console behaviour to such an extent.
>>
> Looking at the commit e74d098c66543d0731de62eb747ccd5b636a6f4c,
> i see that for every tty_kref_get() there is a corresponding
> tty_kref_put() except maybe for the one in the following patch snippet
>
>spin_lock_irqsave(&hp->lock, flags);
>/* Check and then increment for fast path open. */
>if (hp->count++ > 0) {
> + tty_kref_get(tty);
>spin_unlock_irqrestore(&hp->lock, flags);
>hvc_kick();
>return 0;
>
> I don't know this code very well but we might be missing a
> corresponding tty_kref_put() some place ?
See hvc_hangup:
temp_open_count = hp->count;
...
while(temp_open_count) {
--temp_open_count;
tty_kref_put(tty);
kref_put(&hp->kref, destroy_hvc_struct);
}
> If i comment out the above tty_kref_get() call, the machine
> boots fine with or without the suggested patch.
Hm, so as Alan suggests, it could be a timing issue in getting the ref
and returning back from hvc_open(). I don't know how the tty layer
works, but delays in getting the open() succeed results in badness?
Guess we'll have to poke at the other drivers to see how they handle
open() calls.
Amit
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove
On (Fri) Mar 26 2010 [11:52:33], Alan Cox wrote: > > >> mount: can't find /root/proc in /etc/fstab or /etc/mtab > > >> /sbin/smart_agetty: can not determine 'console' speed > > >> > > > > > > OK, this gets even murkier. I don't know why taking a few krefs modifies > > > hvc_console behaviour to such an extent. > > Can you see if the agetty is getting a hangup or open failing. I wonder > if its just a timing change ? Can someone please try this? Looks like it only reproduces on ppc, I can't get it to reproduce in my kvm vm. I'm trying to get hold of a ppc box, though. (btw ppc, ppc64, both should trigger this, right?) Amit ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Grant Likely wrote:
> +- fsl,firmware:
> +Usage: Optional.
> +Value type: , encoded array of bytes
> +Definition: Contains the QUICC engine firmware blob.
> [plus any other properties needed for firmware metadata]
This would place the firmware metadata properties inside the QE node itself,
which would break the QE binding.
> +Example:
> + qe1: q...@e008 {
> + compatible = "fsl,qe";
> + fsl,firmware = /bininc/("firmware-blob.bin"); /* Or
> squirted in by firmware */
> + ...
> + }
> +
> + q...@e009 {
> + compatible = "fsl,qe";
> + fsl,firmware-phandle = <&qe1>;
> + ...
> + }
>
> Putting the blob into just one of the qe nodes keeps everything nicely
> contained with the device it actually applies to. No debates about
> the best place to put device firmware blobs or new compatible values,
> and it is applicable to any device where firmware needs to be passed
> via the tree.
Except when you actually need to add metadata properties:
qe1: q...@e008 {
compatible = "fsl,qe";
fsl,firmware = /bininc/("firmware-blob.bin");
fsl,qe-firmware-eccr = <0x 0x1230>;
...
}
(The ECCR is stored in the QE firmware blob, but let's pretend it isn't and I
need to specify it)
Here, the fsl,qe-firmware-eccr property is associated with the QE itself. This
is why I want a compatible property for the firmware node, no matter where it
is. Then you can do this:
qe1: q...@e008 {
compatible = "fsl,qe";
fsl,qe_firmware {
compatible="fsl,qe-firmware";
fsl,firmware = /bininc/("firmware-blob.bin");
fsl,qe-firmware-eccr = <0x 0x1230>;
}
...
}
Without the compatible property, the only way I'd know that the child node
contains a firmware is to look at the actual name of the child node, which (as
Scott and I believe) is not better than a compatible property.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
mpc5121 MBX support
Greetings, I am new to the mpc5121 and MBX...wondering if anyone has been successful with ELDK and MBX and MPC5121 platform. What are the gotchas? Does the Flattened Device Tree (fdt) need to be modified for support? Thanks for your help, any pointers would be appreciated. Jayne ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
On Fri, Mar 26, 2010 at 9:17 AM, Timur Tabi wrote:
> Grant Likely wrote:
>
>> +- fsl,firmware:
>> + Usage: Optional.
>> + Value type: , encoded array of bytes
>> + Definition: Contains the QUICC engine firmware blob.
>> [plus any other properties needed for firmware metadata]
>
> This would place the firmware metadata properties inside the QE node itself,
> which would break the QE binding.
Not really true. Adding extra properties seldom breaks a binding.
It's a wash when compared with compared with adding a node. But
that's not really an important debate.
> Here, the fsl,qe-firmware-eccr property is associated with the QE itself.
> This is why I want a compatible property for the firmware node, no matter
> where it is. Then you can do this:
>
> qe1: q...@e008 {
> compatible = "fsl,qe";
> fsl,qe_firmware {
> compatible="fsl,qe-firmware";
> fsl,firmware = /bininc/("firmware-blob.bin");
> fsl,qe-firmware-eccr = <0x 0x1230>;
> }
> ...
> }
>
> Without the compatible property, the only way I'd know that the child node
> contains a firmware is to look at the actual name of the child node, which
> (as Scott and I believe) is not better than a compatible property.
If it is always a child of a qe node, then I've got no objections.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
On Tue, Mar 16, 2010 at 11:17 PM, Josh Triplett wrote:
> Hello,
>
> We've tried both 2.6.33 and DENX-v2.6.33.1, and we haven't managed to
> successfully use any form of DMA with the TQM5200 and a CompactFlash
> card. We know the CF card supports DMA (or, at least, it says "UDMA"
> right on the card, and various reports say Lexar Professional CF cards
> do DMA), but the kernel always puts the card in PIO4 mode. We tried
> libata.force=mwdma2 and libata.force=udma2 , and many other modes, but
> this always led to failures like this:
>
> [ 31.994311] ata1: lost interrupt (Status 0x58)
> [ 32.020435] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 32.027712] ata1.00: failed command: READ DMA
> [ 32.032236] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma
> 4096 in
> [ 32.032249] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
> (timeout)
> [ 32.047212] ata1.00: status: { DRDY }
> [ 32.051050] ata1: soft resetting link
> [ 32.218796] ata1.00: FORCE: xfer_mask set to udma2
> [ 32.230618] ata1.00: configured for UDMA/33
> [ 32.235000] ata1.00: device reported invalid CHS sector 0
> [ 32.240629] ata1: EH complete
> [ 62.994310] ata1: lost interrupt (Status 0x58)
> [ 63.020443] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 63.027722] ata1.00: failed command: READ DMA
> [ 63.032246] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma
> 4096 in
> [ 63.032259] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
> (timeout)
> [ 63.047221] ata1.00: status: { DRDY }
> [ 63.051060] ata1: soft resetting link
> [ 63.218778] ata1.00: FORCE: xfer_mask set to udma2
> [ 63.238603] ata1.00: configured for UDMA/33
> [ 63.242978] ata1.00: device reported invalid CHS sector 0
> [ 63.248609] ata1: EH complete
>
> We have the MPC5200C revision of the silicon.
>
> Does this sound like a known issue? Can we do anything to troubleshoot
> this further?
Not all CF adapters have all the pins wired up that are needed for
*DMA modes. That is the most likely problem.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
On 2010-03-25, at 17:46, Timur Tabi wrote: > The more I think about it, the more I believe that this is how we're going to > have to do it. Whether or not Freescale can embed a non-GPL firmware into a > device tree is still undecided. It may require relicensing all of our device > trees as dual bsd/gpl first. Technically, we should probably do that anyway. The dual-licensing process has already started, see the following :-) http://p4db.freebsd.org/changeView.cgi?CH=173836 http://p4db.freebsd.org/changeView.cgi?CH=174365 Rafal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Grant Likely wrote:
>> Without the compatible property, the only way I'd know that the child node
>> contains a firmware is to look at the actual name of the child node, which
>> (as Scott and I believe) is not better than a compatible property.
> If it is always a child of a qe node, then I've got no objections.
I have no problem with putting the firmware node as a child of the QE node and
skipping the phandle property, but only as long as there's only one QE node.
Would you agree that this is bad:
qe1: q...@e008 {
compatible = "fsl,qe";
qefw: fsl,qe_firmware {
compatible="fsl,qe-firmware";
fsl,firmware = /bininc/("firmware-blob.bin");
fsl,qe-firmware-eccr = <0x 0x1230>;
}
...
}
qe2: q...@e009 {
compatible = "fsl,qe";
fsl,firmware-phandle = <&qefw>;
...
}
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
On Fri, Mar 26, 2010 at 12:39 PM, Timur Tabi wrote:
> Grant Likely wrote:
>>> Without the compatible property, the only way I'd know that the child node
>>> contains a firmware is to look at the actual name of the child node, which
>>> (as Scott and I believe) is not better than a compatible property.
>> If it is always a child of a qe node, then I've got no objections.
>
> I have no problem with putting the firmware node as a child of the QE node
> and skipping the phandle property, but only as long as there's only one QE
> node. Would you agree that this is bad:
>
> qe1: q...@e008 {
> compatible = "fsl,qe";
> qefw: fsl,qe_firmware {
> compatible="fsl,qe-firmware";
> fsl,firmware = /bininc/("firmware-blob.bin");
> fsl,qe-firmware-eccr = <0x 0x1230>;
> }
> ...
> }
>
> qe2: q...@e009 {
> compatible = "fsl,qe";
> fsl,firmware-phandle = <&qefw>;
> ...
> }
Nah. That looks totally fine. Not having the firmware under a qe
node would look bad to me.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Timur Tabi wrote:
Grant Likely wrote:
Without the compatible property, the only way I'd know that the child node
contains a firmware is to look at the actual name of the child node, which (as
Scott and I believe) is not better than a compatible property.
If it is always a child of a qe node, then I've got no objections.
I have no problem with putting the firmware node as a child of the QE node and
skipping the phandle property, but only as long as there's only one QE node.
Would you agree that this is bad:
qe1: q...@e008 {
compatible = "fsl,qe";
qefw: fsl,qe_firmware {
compatible="fsl,qe-firmware";
fsl,firmware = /bininc/("firmware-blob.bin");
fsl,qe-firmware-eccr = <0x 0x1230>;
}
...
}
qe2: q...@e009 {
compatible = "fsl,qe";
fsl,firmware-phandle = <&qefw>;
...
}
It not any worse than having the firmware blob anywhere else that is not
hierarchically related.
If one insists on purity of hierarchy, one could introduce a node above
qe1 and qe2 and put the firmware blob in that parent node. That
captures the assertion that the two qe devices are in fact identical so
the same firmware is suitable for both.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Grant Likely wrote: > Nah. That looks totally fine. Not having the firmware under a qe > node would look bad to me. You don't think it weird to have one QE node reference data from another QE node, or that the DTS implies that the firmware belongs to one QE more than it belongs to the other? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
On Fri, Mar 26, 2010 at 12:48 PM, Timur Tabi wrote: > Grant Likely wrote: > >> Nah. That looks totally fine. Not having the firmware under a qe >> node would look bad to me. > > You don't think it weird to have one QE node reference data from another QE > node, or that the DTS implies that the firmware belongs to one QE more than > it belongs to the other? Nope. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Timur Tabi wrote: Grant Likely wrote: Nah. That looks totally fine. Not having the firmware under a qe node would look bad to me. You don't think it weird to have one QE node reference data from another QE node, or that the DTS implies that the firmware belongs to one QE more than it belongs to the other? It is certainly not symmetric. Putting the firmware blob somewhere completely unrelated to either node maintains the symmetry between the two qe nodes, but only weakly captures the relationship between the firmware blob and the qe nodes. It is then necessary to invoke a strong naming convention for the firmware blob, because you don't have the hierarchy to do the name space disambiguation for you. As I see it, the three possibilities, and their disadvantages, are: a) Firmware blob in some random place - requires strong naming of either firmware blob property or node containing it. b) Firmware blob within first qe node - asymmetric. c) Firmware blob in new parent of both qe nodes - requires introduction of otherwise-unneeded hierarchy level. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
On Fri, Mar 26, 2010 at 12:58 PM, Mitch Bradley wrote: > a) Firmware blob in some random place - requires strong naming of either > firmware blob property or node containing it. BTW, this exactly the reason for all the bikesheding earlier; but I don't care at all if it is under a QE node. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Getting MPC5200 up and running - Media5200 and 2.6.33.1
[cc'ing linuxppc-...@lists.ozlabs.org] On Wed, Mar 17, 2010 at 3:30 PM, Mark Schaefer wrote: > Hi Grant, > > I was able to get kernel 2.6.16 running on a Media5200 using ltib, but > what I would really like to do is build a current kernel with SocketCAN. > I've read and read the various groups and I know that I have to do > cuImage.media5200 to get around the ancient u-boot, but I still get nothing > after the kernel is uncompressed. There are probably some properties that you need to add to the device tree so that the kernel can find the console. I can't remember off the top of my head exactly what you need to do here. But even then the cuImage was very unstable on the media5200. I ended up having to upgrade U-Boot on the media5200 because it just couldn't reliably boot the kernel. Unfortunately I lost the source to the u-boot port, so I'd have to do it over. > The Media5200 runs u-boot 1.1.5, so my > options are limited. What I'm really trying to do, however, is get it up on > a custom 5200 board that has u-boot 1.3 running on it. My thought was that > if I could get the kernel up on a well-known board I would have a much > better time getting it on a custom board. > > Questions: > 1) is there a "board startup" guide for powerpc? Not really. I kind of did a presentation on this for ELC last year. Here's are the links: http://www.embeddedlinuxconference.com/elc_2009/sessions.html#Likely http://free-electrons.com/blog/elc-2009-videos/ > 2) What is the best recent kernel to work from? I definitely like the > additional low-level 5200 drivers, but what are they being tested against? Use Linus' mainline. > 3) How far am I going to be able to get without a BDI3000 / JTAG emulator? Not very far. You need to get firmware on the board and without JTAG you're either by doing nasty tricks with the bus on reset (which you need to build custom hardware to do) or popping flash chips off the board for reprogramming. > P.S. I would be happy to put this on a mailing list if you think others > will benefit. Just wasn't sure which list is best. linuxppc-dev@lists.ozlabs.org g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [v2] powerpc/fsl: add device tree binding for QE firmware
Define a binding for embedding a QE firmware blob into the device tree. Also
define a new property for the QE node that links to a firmware node.
Signed-off-by: Timur Tabi
---
.../powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 54
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
index 6e37be1..865a2ef 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
@@ -21,6 +21,15 @@ Required properties:
- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
threads.
+Optional properties:
+- fsl,firmware-phandle:
+Usage: required only if there is no fsl,qe-firmware child node
+Value type:
+Definition: Points to a firmware node (see "QE Firmware Node" below)
+that contains the firmware that should be uploaded for this QE.
+The compatible property for the firmware node should say,
+"fsl,qe-firmware".
+
Recommended properties
- brg-frequency : the internal clock source frequency for baud-rate
generators in Hz.
@@ -59,3 +68,48 @@ Example:
reg = <0 c000>;
};
};
+
+* QE Firmware Node
+
+This node defines a firmware binary that is embedded in the device tree, for
+the purpose of passing the firmware from bootloader to the kernel, or from
+the hypervisor to the guest.
+
+The firmware node itself contains the firmware binary contents, a compatible
+property, and any firmware-specific properties. The node itself can be located
+anywhere, but should probably be placed inside a QE node. Doing so eliminates
+the need for a fsl,firmware-phandle property. Other QE nodes that need the
+firmware should define a fsl,firmware-phandle property that points to the
+firmware node in the first QE node.
+
+The fsl,firmware property can be specified in the DTS (possibly using incbin)
+or can be inserted by the boot loader at boot time.
+
+Required properties:
+ - compatible
+ Usage: required
+ Value type:
+ Definition: A standard property. Specify a string that indicates what
+ kind of firmware it is. For QE, this should be "fsl,qe-firmware".
+
+ - fsl,firmware
+ Usage: required
+ Value type: , encoded as an array of bytes
+ Definition: A standard property. This property contains the firmware
+ binary "blob".
+
+Example:
+ q...@e008 {
+ compatible = "fsl,qe";
+ qe_firmware:qe-firmware {
+ compatible = "fsl,qe-firmware";
+ fsl,firmware = <0x70 0xcd 0x00 0x00 0x01 0x46 0x45 ...>
+ }
+ ...
+ }
+
+ q...@e009 {
+ compatible = "fsl,qe";
+ fsl,firmware-phandle = <&qe_firmware>;
+ ...
+ }
--
1.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] powerpc/fsl: add device tree binding for QE firmware
On Fri, Mar 26, 2010 at 1:35 PM, Timur Tabi wrote: > Define a binding for embedding a QE firmware blob into the device tree. Also > define a new property for the QE node that links to a firmware node. > > Signed-off-by: Timur Tabi > --- > .../powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 54 > > 1 files changed, 54 insertions(+), 0 deletions(-) > > diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt > b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt > index 6e37be1..865a2ef 100644 > --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt > +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt > @@ -21,6 +21,15 @@ Required properties: > - fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for > the > threads. > > +Optional properties: > +- fsl,firmware-phandle: > + Usage: required only if there is no fsl,qe-firmware child node > + Value type: > + Definition: Points to a firmware node (see "QE Firmware Node" below) > + that contains the firmware that should be uploaded for this QE. > + The compatible property for the firmware node should say, > + "fsl,qe-firmware". > + > Recommended properties > - brg-frequency : the internal clock source frequency for baud-rate > generators in Hz. > @@ -59,3 +68,48 @@ Example: > reg = <0 c000>; > }; > }; > + > +* QE Firmware Node > + > +This node defines a firmware binary that is embedded in the device tree, for > +the purpose of passing the firmware from bootloader to the kernel, or from > +the hypervisor to the guest. > + > +The firmware node itself contains the firmware binary contents, a compatible > +property, and any firmware-specific properties. The node itself can be > located > +anywhere, but should probably be placed inside a QE node. The node must be a child of a QE node. A QE node can reference the firmware from another QE node by using the fsl,firmware-phandle property. With that change; Acked-by: Grant Likely g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] powerpc/fsl: add device tree binding for QE firmware
Grant Likely wrote: > The node must be a child of a QE node. A QE node can reference the > firmware from another QE node by using the fsl,firmware-phandle > property. Ok. I'll post a V3 once everyone else has a chance to comment. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] powerpc/fsl: add device tree binding for QE firmware
On Fri, Mar 26, 2010 at 1:50 PM, Timur Tabi wrote: > Grant Likely wrote: >> The node must be a child of a QE node. A QE node can reference the >> firmware from another QE node by using the fsl,firmware-phandle >> property. > > Ok. > > I'll post a V3 once everyone else has a chance to comment. Also, since it is a documentation only change, I'll pick it up into the branch that I'm about to ask Linus to merge in the next day or so. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
u-boot build errors on LTIB 20100115 for MSP8572DS
Hi, I am having trouble building u-boot (from u-boot-2009.11-mpc8572ds.spec) from LTIB for the MPC8572DS platform using just the Makefile and freescale cross tools. The build machine is CentOS 5.3. This is procedure I am following (on LTIB for MPC8572DS, 20100115): # cd ltib-mpc8572ds-20100115 # ./ltib -m prep -p u-boot-2009.11-mpc8572ds.spec # ./ltib -m scbuild -p u-boot-2009.11-mpc8572ds.spec # cd rpm/BUILD/ 2. confirm configuration and make # cd u-boot-2009.11-rc1-19 # make ARCH=powerpc CROSS_COMPILE=//bin/powerpc-none-linux-gnuspe- MPC8572DS_NAND_config # make ARCH=powerpc CROSS_COMPILE=//bin/powerpc-none-linux-gnuspe- all but i'm getting (several) compile errors from the make. It goes for a while, then gets errors at different points, depending on how much it has to build: Usually, just syntax errors or something like: make -C lib_powerpc/ make: *** lib_powerpc/: No such file or directory. Stop. make: *** [lib_powerpc/libpowerpc.a] Error 2 however I can still build using ./ltib??? shouldn't I be able to build from make? (as per the MPC8572DS NAND bootloader User Manual HTML doc)?Is there some other way I should be building? Any help would be much appreciated! Thanks very much, Troy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Tue, 2010-03-23 at 19:37 +0530, K.Prasad wrote: > plain text document attachment (ppc64_hbkpt_02) > Implement perf-events based hw-breakpoint interfaces for PPC64 processors. > These interfaces help arbitrate requests from various users and schedules > them as appropriate. > > Signed-off-by: K.Prasad SNIP > Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h > === > --- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/cputable.h > +++ linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h > @@ -511,6 +511,13 @@ static inline int cpu_has_feature(unsign > & feature); > } > > +#define CPU_FTR_HAS_DABR (defined(CONFIG_PPC64) && \ > + !defined(CONFIG_PPC_ADV_DEBUG_REGS)) > +#ifdef CPU_FTR_HAS_DABR > +/* Number of physical HW breakpoint registers */ > +#define HBP_NUM 1 > +#endif > + > #endif /* !__ASSEMBLY__ */ > > #endif /* __KERNEL__ */ These new defines don't really correlate to the cpu table. One would expect cpu_has_feature(CPU_FTR_HAS_DABR) to have meaning, but it would have to be defined similar to the other CPU_FTR_ constants, and or-ed with CPU_FTRS_ALWAYS (when appropriate). Similarly, I would expect the cpu_spec structure to have a new field, hbp_num, which is initialized in cputable.c. Maybe a longer name would be better, num_hw_brkpts? When I added the PPC_ADV_DEBUG config options for the bookE features, I didn't see an immediate need to clutter the cputable since their values are fixed at compile time. We should be consistent with these, but unless we are going to determine any of these at run-time, I don't know that they belong in the cpu table. Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
On Fri, Mar 26, 2010 at 12:22:32PM -0600, Grant Likely wrote:
> On Tue, Mar 16, 2010 at 11:17 PM, Josh Triplett wrote:
> > Hello,
> >
> > We've tried both 2.6.33 and DENX-v2.6.33.1, and we haven't managed to
> > successfully use any form of DMA with the TQM5200 and a CompactFlash
> > card. We know the CF card supports DMA (or, at least, it says "UDMA"
> > right on the card, and various reports say Lexar Professional CF cards
> > do DMA), but the kernel always puts the card in PIO4 mode. We tried
> > libata.force=mwdma2 and libata.force=udma2 , and many other modes, but
> > this always led to failures like this:
> >
> > [ 31.994311] ata1: lost interrupt (Status 0x58)
> > [ 32.020435] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> > frozen
> > [ 32.027712] ata1.00: failed command: READ DMA
> > [ 32.032236] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma
> > 4096 in
> > [ 32.032249] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
> > (timeout)
> > [ 32.047212] ata1.00: status: { DRDY }
> > [ 32.051050] ata1: soft resetting link
> > [ 32.218796] ata1.00: FORCE: xfer_mask set to udma2
> > [ 32.230618] ata1.00: configured for UDMA/33
> > [ 32.235000] ata1.00: device reported invalid CHS sector 0
> > [ 32.240629] ata1: EH complete
> > [ 62.994310] ata1: lost interrupt (Status 0x58)
> > [ 63.020443] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> > frozen
> > [ 63.027722] ata1.00: failed command: READ DMA
> > [ 63.032246] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma
> > 4096 in
> > [ 63.032259] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
> > (timeout)
> > [ 63.047221] ata1.00: status: { DRDY }
> > [ 63.051060] ata1: soft resetting link
> > [ 63.218778] ata1.00: FORCE: xfer_mask set to udma2
> > [ 63.238603] ata1.00: configured for UDMA/33
> > [ 63.242978] ata1.00: device reported invalid CHS sector 0
> > [ 63.248609] ata1: EH complete
> >
> > We have the MPC5200C revision of the silicon.
> >
> > Does this sound like a known issue? Can we do anything to troubleshoot
> > this further?
>
> Not all CF adapters have all the pins wired up that are needed for
> *DMA modes. That is the most likely problem.
True, but we bought a card that specifically advertises support for
UDMA, and says UDMA right on the card's label.
http://store.lexar.com/?productid=CF8GB-300-381
It seems unlikely, though not impossible, that they would have screwed
up that badly. :)
By the way, we've also tested an IDE hard drive on this board, and it
does UDMA2 just fine.
Any thoughts on how we could try to solve this problem?
- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
On Fri, Mar 26, 2010 at 3:32 PM, Josh Triplett wrote:
> On Fri, Mar 26, 2010 at 12:22:32PM -0600, Grant Likely wrote:
>> On Tue, Mar 16, 2010 at 11:17 PM, Josh Triplett
>> wrote:
>> > Hello,
>> >
>> > We've tried both 2.6.33 and DENX-v2.6.33.1, and we haven't managed to
>> > successfully use any form of DMA with the TQM5200 and a CompactFlash
>> > card. We know the CF card supports DMA (or, at least, it says "UDMA"
>> > right on the card, and various reports say Lexar Professional CF cards
>> > do DMA), but the kernel always puts the card in PIO4 mode. We tried
>> > libata.force=mwdma2 and libata.force=udma2 , and many other modes, but
>> > this always led to failures like this:
>> >
>> > [ 31.994311] ata1: lost interrupt (Status 0x58)
>> > [ 32.020435] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>> > frozen
>> > [ 32.027712] ata1.00: failed command: READ DMA
>> > [ 32.032236] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma
>> > 4096 in
>> > [ 32.032249] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
>> > (timeout)
>> > [ 32.047212] ata1.00: status: { DRDY }
>> > [ 32.051050] ata1: soft resetting link
>> > [ 32.218796] ata1.00: FORCE: xfer_mask set to udma2
>> > [ 32.230618] ata1.00: configured for UDMA/33
>> > [ 32.235000] ata1.00: device reported invalid CHS sector 0
>> > [ 32.240629] ata1: EH complete
>> > [ 62.994310] ata1: lost interrupt (Status 0x58)
>> > [ 63.020443] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>> > frozen
>> > [ 63.027722] ata1.00: failed command: READ DMA
>> > [ 63.032246] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma
>> > 4096 in
>> > [ 63.032259] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
>> > (timeout)
>> > [ 63.047221] ata1.00: status: { DRDY }
>> > [ 63.051060] ata1: soft resetting link
>> > [ 63.218778] ata1.00: FORCE: xfer_mask set to udma2
>> > [ 63.238603] ata1.00: configured for UDMA/33
>> > [ 63.242978] ata1.00: device reported invalid CHS sector 0
>> > [ 63.248609] ata1: EH complete
>> >
>> > We have the MPC5200C revision of the silicon.
>> >
>> > Does this sound like a known issue? Can we do anything to troubleshoot
>> > this further?
>>
>> Not all CF adapters have all the pins wired up that are needed for
>> *DMA modes. That is the most likely problem.
>
> True, but we bought a card that specifically advertises support for
> UDMA, and says UDMA right on the card's label.
>
> http://store.lexar.com/?productid=CF8GB-300-381
>
> It seems unlikely, though not impossible, that they would have screwed
> up that badly. :)
>
> By the way, we've also tested an IDE hard drive on this board, and it
> does UDMA2 just fine.
>
> Any thoughts on how we could try to solve this problem?
Not off the top of my head. I'd have to get onto the board and poke
around to figure out what is going on.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/7] arch/powerpc/kernel: Use set_cpus_allowed_ptr
From: Julia Lawall Use set_cpus_allowed_ptr rather than set_cpus_allowed. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression E1,E2; @@ - set_cpus_allowed(E1, cpumask_of_cpu(E2)) + set_cpus_allowed_ptr(E1, cpumask_of(E2)) @@ expression E; identifier I; @@ - set_cpus_allowed(E, I) + set_cpus_allowed_ptr(E, &I) // Signed-off-by: Julia Lawall --- arch/powerpc/kernel/smp.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -u -p a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@ -561,12 +561,12 @@ void __init smp_cpus_done(unsigned int m * se we pin us down to CPU 0 for a short while */ old_mask = current->cpus_allowed; - set_cpus_allowed(current, cpumask_of_cpu(boot_cpuid)); + set_cpus_allowed_ptr(current, cpumask_of(boot_cpuid)); if (smp_ops && smp_ops->setup_cpu) smp_ops->setup_cpu(boot_cpuid); - set_cpus_allowed(current, old_mask); + set_cpus_allowed_ptr(current, &old_mask); snapshot_timebases(); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
Hi Josh, On Fri, Mar 26, 2010 at 02:32:02PM -0700, Josh Triplett wrote: > On Fri, Mar 26, 2010 at 12:22:32PM -0600, Grant Likely wrote: > > > > Not all CF adapters have all the pins wired up that are needed for > > *DMA modes. That is the most likely problem. > > True, but we bought a card that specifically advertises support for > UDMA, and says UDMA right on the card's label. > > http://store.lexar.com/?productid=CF8GB-300-381 Grant was referring to the adapter, not the card! In fact I still have to see a single CF-to-IDE adapter that does have the wires needed for (U)DMA without me soldering them in place... Regards, Wolfgang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [v3] powerpc/fsl: add device tree binding for QE firmware
Define a binding for embedding a QE firmware blob into the device tree. Also
define a new property for the QE node that links to a firmware node.
Signed-off-by: Timur Tabi
---
.../powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 54
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
index 6e37be1..8b7246b 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
@@ -21,6 +21,15 @@ Required properties:
- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
threads.
+Optional properties:
+- fsl,firmware-phandle:
+Usage: required only if there is no fsl,qe-firmware child node
+Value type:
+Definition: Points to a firmware node (see "QE Firmware Node" below)
+that contains the firmware that should be uploaded for this QE.
+The compatible property for the firmware node should say,
+"fsl,qe-firmware".
+
Recommended properties
- brg-frequency : the internal clock source frequency for baud-rate
generators in Hz.
@@ -59,3 +68,48 @@ Example:
reg = <0 c000>;
};
};
+
+* QE Firmware Node
+
+This node defines a firmware binary that is embedded in the device tree, for
+the purpose of passing the firmware from bootloader to the kernel, or from
+the hypervisor to the guest.
+
+The firmware node itself contains the firmware binary contents, a compatible
+property, and any firmware-specific properties. The node should be placed
+inside a QE node that needs it. Doing so eliminates the need for a
+fsl,firmware-phandle property. Other QE nodes that need the same firmware
+should define an fsl,firmware-phandle property that points to the firmware node
+in the first QE node.
+
+The fsl,firmware property can be specified in the DTS (possibly using incbin)
+or can be inserted by the boot loader at boot time.
+
+Required properties:
+ - compatible
+ Usage: required
+ Value type:
+ Definition: A standard property. Specify a string that indicates what
+ kind of firmware it is. For QE, this should be "fsl,qe-firmware".
+
+ - fsl,firmware
+ Usage: required
+ Value type: , encoded as an array of bytes
+ Definition: A standard property. This property contains the firmware
+ binary "blob".
+
+Example:
+ q...@e008 {
+ compatible = "fsl,qe";
+ qe_firmware:qe-firmware {
+ compatible = "fsl,qe-firmware";
+ fsl,firmware = <0x70 0xcd 0x00 0x00 0x01 0x46 0x45 ...>
+ }
+ ...
+ }
+
+ q...@e009 {
+ compatible = "fsl,qe";
+ fsl,firmware-phandle = <&qe_firmware>;
+ ...
+ }
--
1.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
On Fri, Mar 26, 2010 at 4:17 PM, Wolfgang Wegner wrote: > Hi Josh, > > On Fri, Mar 26, 2010 at 02:32:02PM -0700, Josh Triplett wrote: >> On Fri, Mar 26, 2010 at 12:22:32PM -0600, Grant Likely wrote: >> > >> > Not all CF adapters have all the pins wired up that are needed for >> > *DMA modes. That is the most likely problem. >> >> True, but we bought a card that specifically advertises support for >> UDMA, and says UDMA right on the card's label. >> >> http://store.lexar.com/?productid=CF8GB-300-381 > > Grant was referring to the adapter, not the card! > > In fact I still have to see a single CF-to-IDE adapter that does > have the wires needed for (U)DMA without me soldering them in place... I found one at logic supply a while back, but I can't remember which one! g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v3] powerpc/fsl: add device tree binding for QE firmware
On Fri, Mar 26, 2010 at 4:42 PM, Timur Tabi wrote:
> Define a binding for embedding a QE firmware blob into the device tree. Also
> define a new property for the QE node that links to a firmware node.
>
> Signed-off-by: Timur Tabi
> ---
> .../powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 54
>
> 1 files changed, 54 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
> b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
> index 6e37be1..8b7246b 100644
> --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
> @@ -21,6 +21,15 @@ Required properties:
> - fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for
> the
> threads.
>
> +Optional properties:
> +- fsl,firmware-phandle:
> + Usage: required only if there is no fsl,qe-firmware child node
> + Value type:
> + Definition: Points to a firmware node (see "QE Firmware Node" below)
> + that contains the firmware that should be uploaded for this QE.
> + The compatible property for the firmware node should say,
> + "fsl,qe-firmware".
> +
> Recommended properties
> - brg-frequency : the internal clock source frequency for baud-rate
> generators in Hz.
> @@ -59,3 +68,48 @@ Example:
> reg = <0 c000>;
> };
> };
> +
> +* QE Firmware Node
> +
> +This node defines a firmware binary that is embedded in the device tree, for
> +the purpose of passing the firmware from bootloader to the kernel, or from
> +the hypervisor to the guest.
> +
> +The firmware node itself contains the firmware binary contents, a compatible
> +property, and any firmware-specific properties. The node should be placed
> +inside a QE node that needs it. Doing so eliminates the need for a
> +fsl,firmware-phandle property. Other QE nodes that need the same firmware
> +should define an fsl,firmware-phandle property that points to the firmware
> node
> +in the first QE node.
> +
> +The fsl,firmware property can be specified in the DTS (possibly using incbin)
> +or can be inserted by the boot loader at boot time.
> +
> +Required properties:
> + - compatible
> + Usage: required
> + Value type:
> + Definition: A standard property. Specify a string that indicates what
> + kind of firmware it is. For QE, this should be "fsl,qe-firmware".
> +
> + - fsl,firmware
> + Usage: required
> + Value type: , encoded as an array of bytes
> + Definition: A standard property. This property contains the firmware
> + binary "blob".
> +
> +Example:
> + q...@e008 {
> + compatible = "fsl,qe";
> + qe_firmware:qe-firmware {
> + compatible = "fsl,qe-firmware";
> + fsl,firmware = <0x70 0xcd 0x00 0x00 0x01 0x46 0x45
> ...>
This should actually be square brackets for 8-bit data (as opposed to
cells). I'll fix it up when I merge the patch.
> + }
> + ...
> + }
> +
> + q...@e009 {
> + compatible = "fsl,qe";
> + fsl,firmware-phandle = <&qe_firmware>;
> + ...
> + }
> --
> 1.6.5
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
On Fri, Mar 26, 2010 at 11:17:07PM +0100, Wolfgang Wegner wrote: > Hi Josh, > > On Fri, Mar 26, 2010 at 02:32:02PM -0700, Josh Triplett wrote: > > On Fri, Mar 26, 2010 at 12:22:32PM -0600, Grant Likely wrote: > > > > > > Not all CF adapters have all the pins wired up that are needed for > > > *DMA modes. That is the most likely problem. > > > > True, but we bought a card that specifically advertises support for > > UDMA, and says UDMA right on the card's label. > > > > http://store.lexar.com/?productid=CF8GB-300-381 > > Grant was referring to the adapter, not the card! > > In fact I still have to see a single CF-to-IDE adapter that does > have the wires needed for (U)DMA without me soldering them in place... Oh! OK, that makes more sense. However, according to one of our hardware hackers, Andrew Greenberg (CCed), the STK5200 development breakout board for the TQM5200 *does* have the DMA pins wired up correctly, at least according to its schematic. That doesn't guarantee that the board matches the schematic, of course. Any other ideas for things we could check to try to track down this problem? - Josh Triplett ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Xilinx MPMC SDMA subsystem
I've not got time to review this patch right now, but Sergey and Steven, you both posted MPMC drivers on the same day; Steven on the microblaze list and Sergey on the powerpc list. Can you two please coordinate and figure out how to mork toward a single driver that will meet both your needs? I don't want to have 2 drivers (3 if you count the ll_temac driver) in mainline for the same hardware interface. Thanks, g. On Wed, Mar 17, 2010 at 12:18 PM, Sergey Temerkhanov wrote: > This patch adds generic support for Xilinx MPMC SoftDMA channels which are > used by, e.g., LLTEMAC and other IP cores (including custom cores). So, the > implemented functions include only SDMA channels enumeration and control > (finding device by phandle property, channel reset, initialization of RX/TX > links, enabling/disabling IRQs, IRQ coalescing control and submission of > descriptors (struct sdma_desc). > > The users of this subsystem are supposed to get the pointer to the struct > sdma_device by phandle (using sdma_find_device() function), fill the struct > sdma_client with pointers to the callback functions which are called on rx/tx > completion, on error, and when sdma_reset is called by any client and then > register the client with add_client() (sdma_del_client can be used to > unregister the struct sdma_client) > > Also, some auxiliary functions are provided to check the status of descriptors > (busy, done, start of packet, end of packet). > > The user is also responsible for maintenance of linked descriptors queue, > proper initialization of their fields, and submission of the descriptors list > to SDMA channel. IRQ acknowledge must be performed by user too (calling > sdma_[rx|tx]_irq_ack respectively in [rx|tx]_complete callbacks). Also on RX > side user must check the __be32 user[4] fields of descriptors to get the > information supplied by SDMA channel. > > This code uses SDMA channels in "Tail pointer fashion", i.e. the call to > sdma_[rx|tx]_init is performed only once after reset and then only sdma_[rx| > tx]_submit calls are used to update the pointer to the last descriptor in SDMA > channel. > > Simple bus driver for MPMC is also added by this patch. > > This code is in production use with our internal LLTEMAC driver implementation > since 2008 and with a few custom cores drivers since 2009. > > This code currently supports only soft MPMCs, i.e., only SDMA channels with > memory-mapped registers. In order to support channels with DCR, a few > modifications are needed. > > Any comments and suggestions are appreciated. > > Regards, Sergey Temerkhanov, Cifronic ZAO > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc52xx_lpbfifo: flag DMA irqs as enabled after requesting them
On Thu, Mar 11, 2010 at 10:58 PM, Roman Fietze wrote: > Hello, > > This patch avoids unbalanced enable/disable messages for the DMA > interrupts when running the 5200 platform SCLPC/BestComm driver in DMA > mode. > > > Signed-off-by: Roman Fietze Applied, thanks. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc512x uart: testers wanted
On Mon, Mar 8, 2010 at 9:53 AM, Grant Likely wrote: > On Mon, Mar 8, 2010 at 9:32 AM, Albrecht Dreà wrote: >> Hi Anatolij: >> >>> > Anatolij, could you please look into this? >>> >>> I'll look into this tomorrow, need to finish USB support now. >>> Unfortunately the patch doesn't apply on top of Linus' tree as >>> patches for reworked MPC5121 PSC UART support have been merged. >>> Albrecht, could you please rebase your patch? >> >> Against linux/kernel/git/torvalds/linux-2.6.git?  Will do that tomorrow...  >> Grant, do you need a patch against Linus' tree, or against a released >> version, or against your tree? > > I won't be picking this up until after -rc1 or -rc2 anyway, and it > won't get merged into Linus' tree until the 2.6.35 merge window, so > I'm not going to even touch it for a couple of weeks.  When I do get > to it I'll need it against Linus' tree. Ping? I was looking at this tonight but it of course doesn't apply. Have you gotten a chance to rebase this patch yet? Thanks, g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
