* Re: [PATCH 1/2] elf loader support for auxvec base platform string
From: Roland McGrath @ 2008-07-08 0:31 UTC (permalink / raw)
To: benh; +Cc: Nathan Lynch, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1215471393.8970.157.camel@pasglop>
> > The kernel does not have to come from the same place as the root
> > filesystem. You may want to run a new kernel with an old filesystem, or
> > vice-versa.
Well, it's not like these bits are really going to change in practice. My
point was just that this is a far "softer" ABI than the general kernel-user
contract. Sorry if my being precise about things gives you indigestion.
> I agree, I'm pretty dubious here...
Dubious about whether the dsocaps bit assignments are "part of the ABI"?
Fine. Let's talk again when you've used up 32 bits and want to figure out
what to do next.
Dubious about whether dsocaps is the right thing to do? I think you are
overlooking what the actual kernel-user compatibility reality is here.
Firstly, what is the "risk" in the "gone wrong" case? The risk is that a
DSO load via ld.so.cache will overlook a /lib/power99/foo.so match and get
a /lib/foo.so match instead because ldconfig doesn't know about "power99".
If foo.so wasn't in ld.so.cache at all, there is no problem.
If you used LD_LIBRARY_PATH, there is no problem.
If you used dlopen with an explicit file name (has /), there is no problem.
What happens if you boot a kernel that uses dsocaps with the new string
"power99", but you are missing the ld.so.conf.d file to match your kernel?
Then a DSO load via ld.so.cache will overlook "power99" matches.
How do you fix it?
Install the right (tiny text) file, and run ldconfig.
What happens now if you are using a new kernel that supplies a new string
"power99" in AT_PLATFORM or another auxv element used the same way, but
with an old root filesystem (say one including any glibc that exists today)?
Then a DSO load via ld.so.cache will overlook "power99" matches.
How do you fix it?
You add a bit assignment in the glibc sources, recompile glibc,
install a new whole glibc package. (Conceivably if you are extremely
careful you can manage to redo an otherwise completely identical
build to the glibc on your old system and replace only ld{64,}.so.1
and ldconfig.) Then run the new ldconfig.
In short, if you use a root filesystem from before kernels started using
the new string, then you will degenerate to default-platform library
matches from loads via ld.so.cache (i.e. /lib/foo.so, not /lib/somecpu/foo.so).
If you want to do better than that for this case, it's intractable using
AT_PLATFORM, and simple using dsocaps (probably simpler than booting a
special kernel was).
I haven't figured out what in this old-vs-new picture you think AT_PLATFORM
or something else like it would ever buy you.
Thanks,
Roland
^ permalink raw reply
* RAMDISK: ran out of compressed data
From: Siva Prasad @ 2008-07-08 0:21 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
Hi,
I am getting the following error when I tried to boot with ramdisk. Any
specific reason or clue why this is happening?
RAMDISK: Compressed image found at block 0
RAMDISK: ran out of compressed data
invalid compressed format (err=3D1)
I am running into this on 8641D runing 2.6.24-rc6 kernel. My .config
around block area are...
CONFIG_BLK_DEV=3Dy
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=3Dy
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=3Dy
CONFIG_BLK_DEV_RAM_COUNT=3D16
CONFIG_BLK_DEV_RAM_SIZE=3D49152
CONFIG_BLK_DEV_RAM_BLOCKSIZE=3D1024
Thanks
Siva
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
From: Benjamin Herrenschmidt @ 2008-07-08 0:46 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-dev, sr, jgarzik
In-Reply-To: <C497F939.104DB%gerickson@nuovations.com>
On Mon, 2008-07-07 at 16:47 -0700, Grant Erickson wrote:
>
> Would you prefer?
>
> +#define RGMII_FER_MII(idx) RGMII_FER_GMII(idx)
>
> Having the "extra" mnemonic makes the code end up looking less like a typo
> and more like a conscious decision: "Yes, we know MII and GMII are the same
> setting, but we're being explicit about it."
Yeah, that looks better. Either that or a comment.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] elf loader support for auxvec base platform string
From: Benjamin Herrenschmidt @ 2008-07-08 0:48 UTC (permalink / raw)
To: Roland McGrath
Cc: Steve Munroe, linux-kernel, linuxppc-dev, Nathan Lynch,
Paul Mackerras
In-Reply-To: <20080708003127.6D3B9154244@magilla.localdomain>
Adding Steve to the CC list as I'd like his input from the
glibc/powerpc side as he's the requester of that feature in the first
place.
Steve: Roland is proposing to ues dsocaps instead of AT_BASE_PLATFORM.
Cheers,
Ben.
On Mon, 2008-07-07 at 17:31 -0700, Roland McGrath wrote:
> > > The kernel does not have to come from the same place as the root
> > > filesystem. You may want to run a new kernel with an old filesystem, or
> > > vice-versa.
>
> Well, it's not like these bits are really going to change in practice. My
> point was just that this is a far "softer" ABI than the general kernel-user
> contract. Sorry if my being precise about things gives you indigestion.
>
> > I agree, I'm pretty dubious here...
>
> Dubious about whether the dsocaps bit assignments are "part of the ABI"?
> Fine. Let's talk again when you've used up 32 bits and want to figure out
> what to do next.
>
> Dubious about whether dsocaps is the right thing to do? I think you are
> overlooking what the actual kernel-user compatibility reality is here.
>
> Firstly, what is the "risk" in the "gone wrong" case? The risk is that a
> DSO load via ld.so.cache will overlook a /lib/power99/foo.so match and get
> a /lib/foo.so match instead because ldconfig doesn't know about "power99".
> If foo.so wasn't in ld.so.cache at all, there is no problem.
> If you used LD_LIBRARY_PATH, there is no problem.
> If you used dlopen with an explicit file name (has /), there is no problem.
>
> What happens if you boot a kernel that uses dsocaps with the new string
> "power99", but you are missing the ld.so.conf.d file to match your kernel?
> Then a DSO load via ld.so.cache will overlook "power99" matches.
>
> How do you fix it?
> Install the right (tiny text) file, and run ldconfig.
>
> What happens now if you are using a new kernel that supplies a new string
> "power99" in AT_PLATFORM or another auxv element used the same way, but
> with an old root filesystem (say one including any glibc that exists today)?
> Then a DSO load via ld.so.cache will overlook "power99" matches.
>
> How do you fix it?
> You add a bit assignment in the glibc sources, recompile glibc,
> install a new whole glibc package. (Conceivably if you are extremely
> careful you can manage to redo an otherwise completely identical
> build to the glibc on your old system and replace only ld{64,}.so.1
> and ldconfig.) Then run the new ldconfig.
>
> In short, if you use a root filesystem from before kernels started using
> the new string, then you will degenerate to default-platform library
> matches from loads via ld.so.cache (i.e. /lib/foo.so, not /lib/somecpu/foo.so).
> If you want to do better than that for this case, it's intractable using
> AT_PLATFORM, and simple using dsocaps (probably simpler than booting a
> special kernel was).
>
> I haven't figured out what in this old-vs-new picture you think AT_PLATFORM
> or something else like it would ever buy you.
>
>
> Thanks,
> Roland
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] powerpc: rework 4xx PTE access and TLB miss
From: Josh Boyer @ 2008-07-08 1:25 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1215468180.8970.124.camel@pasglop>
On Tue, 08 Jul 2008 08:03:00 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Mon, 2008-07-07 at 10:06 -0400, Josh Boyer wrote:
>
> > The setup is an tftp'd kernel via U-Boot using cuImage, nfsroot
> > filesystem. Sequoia has an FPU, and CONFIG_PPC_FPU is set.
> >
> > I reverted this patch and used the latest powerpc-next branch and it
> > boots fine.
> >
> > Seems something is wrong here still. I suspect the DSI handler
> > changes, but I have no proof and haven't debugged it yet. Until we
> > get it fixed, I don't feel overly comfortable putting it in the next
> > branch. Which board and setup did you test with?
>
> mambo and another board I don't remember which one precisely.
Unless you've seriously fixed mambo (which you probably have), I
wouldn't consider the 44x port to be useful as a true test platform. I
started that support like 3 years ago, and I abandoned it when I was
1/2 way finished. The exception precedence wasn't even right, and
userspace didn't start :)
> I'll have a look.
Cool, thanks. If I get some time, I'll poke around myself too.
josh
^ permalink raw reply
* Re: [PATCH] powerpc: rework 4xx PTE access and TLB miss
From: Benjamin Herrenschmidt @ 2008-07-08 1:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080707212523.24d2014f@zod.rchland.ibm.com>
> Unless you've seriously fixed mambo (which you probably have), I
> wouldn't consider the 44x port to be useful as a true test platform. I
> started that support like 3 years ago, and I abandoned it when I was
> 1/2 way finished. The exception precedence wasn't even right, and
> userspace didn't start :)
Yup, I fixed exception precedence a while back :-)
I don't use mambo much for 4xx. Mostly it was a way to get past the
trivial bugs before I tested on real HW.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/4] kdump : add support for ibm, dynamic-reconfiguration-memory for kexec/kdump
From: Stephen Rothwell @ 2008-07-08 1:36 UTC (permalink / raw)
To: Chandru; +Cc: linuxppc-dev, kexec
In-Reply-To: <200807080014.24910.chandru@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
Hi Chandru,
On Tue, 8 Jul 2008 00:14:24 +0530 Chandru <chandru@in.ibm.com> wrote:
>
> @@ -917,7 +918,33 @@ static int __init early_init_dt_scan_drc
> if ((base + size) > 0x80000000ul)
> size = 0x80000000ul - base;
> }
> - lmb_add(base, size);
> + strcpy(buf, "linux,usable-memory");
> + sprintf(t, "%d", (int)n);
> + strcat(buf, t);
Why don't you use
snprintf(buf, sizeof(buf), "linux,usable-memory%ld", n);
instead?
> + usm = (cell_t *)of_get_flat_dt_prop(node,
> + (const char *)buf, &l);
^^^^^^^^^^ ^^^^^^^^^^^^^^
unnecessary casts.
> static void __init parse_drconf_memory(struct device_node *memory)
> {
> + strcpy(buf, "linux,usable-memory");
> + sprintf(t, "%d", (int)n);
> + strcat(buf, t);
See snprint comment above.
> + usm = of_get_property(memory, (const char *)buf, &len);
^^^^^^^^^^^^^^
unnecessary cast.
> + if (usm != NULL) {
> + ranges = (len >> 2) / (n_mem_addr_cells +
^^^^^^^^^^
len / sizeof(u32) ?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: booting an ML405
From: Lorenzo T. Flores @ 2008-07-08 1:37 UTC (permalink / raw)
To: David Baird; +Cc: linuxppc-embedded
In-Reply-To: <440abda90807031902u766eb4dby932e8741e947488e@mail.gmail.com>
David,
Thanks for the response. I searched a little more and found that many
people recommend looking through __log_buf to see if info is getting
printed to memory. Below I've added the printouts I get both before and
after the system hangs. Also, I'm not using Uartlite. I'm using 16550;
however, I have created the same design with Uartlite and adjusted the
console parameter to reflect that change. In both instances the kernel
hangs. You're right too, this is common...I just need to figure out how
to read out this __log_buf address:
If I stop the processor after it hangs:
XMD% mrd 0xc0259fa4 10
C0259FA4: 3C353E5B
C0259FA8: 20202020
C0259FAC: 302E3030
C0259FB0: 30303030
C0259FB4: 5D204C69
C0259FB8: 6E757820
C0259FBC: 76657273
C0259FC0: 696F6E20
C0259FC4: 322E362E
C0259FC8: 32352D72
If I stop it before it hangs:
XMD% mrd 0xc0259fa4 10
C0259FA4: 00000000
C0259FA8: 00000000
C0259FAC: 00000000
C0259FB0: 00000000
C0259FB4: 00000000
C0259FB8: 00000000
C0259FBC: 00000000
C0259FC0: 00000000
C0259FC4: 00000000
C0259FC8: 00000000
according to my system.map file __log_buf is located at C0259FA4
If I cut off the 0xc0000000:
XMD% mrd 0x259fa4 10
259FA4: FFFFFFFF
259FA8: FFFFFFFF
259FAC: FFFFFFFF
259FB0: FFFFFFFF
259FB4: FFFFFFFF
259FB8: FFFFFFFF
259FBC: FFFFFFFF
259FC0: FFFFFFFF
259FC4: FFFFFFFF
259FC8: FFFFFFFF
Any insight as to how to figure out what these values mean using XMD
would be great. Or if you guys have any other recommendations for using
the JTAG (not with XMD) I would greatly appreciated!
thanks,
Lorenzo
David Baird wrote:
> On Thu, Jul 3, 2008 at 7:05 PM, Lorenzo T. Flores <lorenzo@alphagolf.com> wrote:
>
>> I'm trying to compile the Xilinx patched kernel tree (v2.6.25-rc9) and run
>> it on an ML405
>>
>> So far, I get to the following point in the boot sequence:
>>
>> loaded at: 00400000 005AF5A0
>> board data at: 005AD524 005AD5A0
>> relocated to: 00405058 004050D4
>> zimage at: 00405E90 0051D6CC
>> initrd at: 0051E000 005ACC0D
>> avail ram: 005B0000 80000000
>>
>> Linux/PPC load: console=ttyS0,9600 ip=on root=/dev/ram rw
>> Uncompressing Linux...done.
>> Now booting the kernel
>>
>> The system hangs after it says "Now booting the kernel."
>>
>
> This seems to come up a lot, so I'm surprised you didn't find it in
> the archives ;-)
>
> Are you using uartlite? You'll need to change the "console" option if you are.
>
> -David
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: the printk problem
From: Kyle McMartin @ 2008-07-08 1:44 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-ia64, linuxppc-dev, Peter Anvin, Andrew Morton,
Linus Torvalds, David S. Miller, parisc-linux
In-Reply-To: <20080704203620.GK14894@parisc-linux.org>
On Fri, Jul 04, 2008 at 02:36:21PM -0600, Matthew Wilcox wrote:
> It's also true for parisc, fwiw. Added a cc to them.
>
I posted a patch months ago for kallsyms on parisc, but it looks like
nobody ever responded or cared. Nice.
^ permalink raw reply
* (no subject)
From: Michael Neuling @ 2008-07-08 1:56 UTC (permalink / raw)
To: Chandru; +Cc: linuxppc-dev, kexec
In-Reply-To: <200807080014.24910.chandru@in.ibm.com>
> [PATCH 1/4] kdump : add support for ibm, dynamic-reconfiguration-memory for kexec/kdump
Please change the name of the individual patches
BTW this patch doesn't apply against the powerpc-next tree. Please use
that tree, not Linus tree.
In message <200807080014.24910.chandru@in.ibm.com> you wrote:
> kexec-tools adds crash, rtas, and tce memory regions as linux,usable-memory
> properties in device-tree. Following changes are made in the kernel to
> recognize these special properties in case of
> ibm,dynamic-reconfiguration-memory node of device-tree.
>
> Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
> ---
>
> diff -Naurp linux-2.6.26-rc9-orig/arch/powerpc/kernel/prom.c
> linux-2.6.26-rc9/arch/powerpc/kernel/prom.c
> --- linux-2.6.26-rc9-orig/arch/powerpc/kernel/prom.c 2008-07-06
> 04:23:22.000000000 +0530
> +++ linux-2.6.26-rc9/arch/powerpc/kernel/prom.c 2008-07-07 17:23:58.000
000000
> +0530
> @@ -884,9 +884,10 @@ static u64 __init dt_mem_next_cell(int s
> */
> static int __init early_init_dt_scan_drconf_memory(unsigned long node)
> {
> - cell_t *dm, *ls;
> + cell_t *dm, *ls, *endp, *usm;
> unsigned long l, n, flags;
> u64 base, size, lmb_size;
> + char buf[32], t[8];
>
> ls = (cell_t *)of_get_flat_dt_prop(node, "ibm,lmb-size", &l);
> if (ls == NULL || l < dt_root_size_cells * sizeof(cell_t))
> @@ -917,7 +918,33 @@ static int __init early_init_dt_scan_drc
> if ((base + size) > 0x80000000ul)
> size = 0x80000000ul - base;
> }
Please document what you are trying to achieve here
> - lmb_add(base, size);
> + strcpy(buf, "linux,usable-memory");
> + sprintf(t, "%d", (int)n);
> + strcat(buf, t);
sprintf(buf, "linux,usable-memory%d", (int)n);
??
> + usm = (cell_t *)of_get_flat_dt_prop(node,
> + (const char *)buf, &l);
> + if (usm != NULL) {
> + endp = usm + (l / sizeof(cell_t));
> + while ((endp - usm) >= (dt_root_addr_cells +
> + dt_root_size_cells)) {
> + base = dt_mem_next_cell(dt_root_addr_cells,
> + &usm);
> + size = dt_mem_next_cell(dt_root_size_cells,
> + &usm);
> + if (size == 0)
> + continue;
> + if (iommu_is_off) {
> + if ((base + size) > 0x80000000ul)
> + size = 0x80000000ul - base;
There is similar code to this above. Can this be merged? Why
0x80000000ul anyway?
> + }
> + lmb_add(base, size);
> + }
> +
> + /* Continue with next lmb entry */
> + continue;
Is this "continue" needed?
Also, this comment is useless. We know what a continue does :-)
> + } else {
> + lmb_add(base, size);
> + }
> }
> lmb_dump_all();
> return 0;
> diff -Naurp linux-2.6.26-rc9-orig/arch/powerpc/mm/numa.c
> linux-2.6.26-rc9/arch/powerpc/mm/numa.c
> --- linux-2.6.26-rc9-orig/arch/powerpc/mm/numa.c 2008-07-06 04:23:22.000
000000
> +0530
> +++ linux-2.6.26-rc9/arch/powerpc/mm/numa.c 2008-07-07 17:50:35.000000000
> +0530
> @@ -349,18 +349,33 @@ static unsigned long __init numa_enforce
> return lmb_end_of_DRAM() - start;
> }
>
> +static void set_nodeinfo(int nid, unsigned long start, unsigned long size)
> +{
> + fake_numa_create_new_node(((start + size) >> PAGE_SHIFT),
> + &nid);
> + node_set_online(nid);
> +
> + size = numa_enforce_memory_limit(start, size);
> + if (!size)
> + return;
> + add_active_range(nid, start >> PAGE_SHIFT,
> + (start >> PAGE_SHIFT) + (size >> PAGE_SHIFT));
> + return;
> +}
> +
> /*
> * Extract NUMA information from the ibm,dynamic-reconfiguration-memory
> * node. This assumes n_mem_{addr,size}_cells have been set.
> */
> static void __init parse_drconf_memory(struct device_node *memory)
> {
> - const unsigned int *lm, *dm, *aa;
> + const unsigned int *lm, *dm, *aa, *usm;
> unsigned int ls, ld, la;
> unsigned int n, aam, aalen;
> unsigned long lmb_size, size, start;
> int nid, default_nid = 0;
> - unsigned int ai, flags;
> + unsigned int ai, flags, len, ranges;
> + char buf[32], t[8];
>
> lm = of_get_property(memory, "ibm,lmb-size", &ls);
> dm = of_get_property(memory, "ibm,dynamic-memory", &ld);
> @@ -396,16 +411,27 @@ static void __init parse_drconf_memory(s
> nid = default_nid;
> }
>
> - fake_numa_create_new_node(((start + lmb_size) >> PAGE_SHIFT),
> - &nid);
> - node_set_online(nid);
> + strcpy(buf, "linux,usable-memory");
> + sprintf(t, "%d", (int)n);
> + strcat(buf, t);
Again, we can do this in a single sprintf, like above...
> + usm = of_get_property(memory, (const char *)buf, &len);
> + if (usm != NULL) {
> + ranges = (len >> 2) / (n_mem_addr_cells +
> + n_mem_size_cells);
> +
> +dr_new_range: start = read_n_cells(n_mem_addr_cells, &usm);
> + size = read_n_cells(n_mem_size_cells, &usm);
> + if (size == 0)
> + continue;
>
> - size = numa_enforce_memory_limit(start, lmb_size);
> - if (!size)
> - continue;
> + set_nodeinfo(nid, start, size);
> + if (--ranges)
> + goto dr_new_range;
Can you please use a while or for loop rather than a goto.
>
> - add_active_range(nid, start >> PAGE_SHIFT,
> - (start >> PAGE_SHIFT) + (size >> PAGE_SHIFT));
> + continue;
> + } else {
> + set_nodeinfo(nid, start, lmb_size);
> + }
> }
> }
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
^ permalink raw reply
* Re: booting an ML405
From: Grant Likely @ 2008-07-08 2:29 UTC (permalink / raw)
To: Lorenzo T. Flores; +Cc: David Baird, linuxppc-embedded
In-Reply-To: <4872C4D0.4060006@alphagolf.com>
On Mon, Jul 7, 2008 at 7:37 PM, Lorenzo T. Flores <lorenzo@alphagolf.com> wrote:
> David,
>
> Thanks for the response. I searched a little more and found that many people
> recommend looking through __log_buf to see if info is getting printed to
> memory. Below I've added the printouts I get both before and after the
> system hangs. Also, I'm not using Uartlite. I'm using 16550; however, I have
> created the same design with Uartlite and adjusted the console parameter to
> reflect that change. In both instances the kernel hangs. You're right too,
> this is common...I just need to figure out how to read out this __log_buf
> address:
>
> If I stop the processor after it hangs:
... This looks like ASCII text; let's try decoding it...
> XMD% mrd 0xc0259fa4 10
> C0259FA4: 3C353E5B '<5>['
> C0259FA8: 20202020 ' '
> C0259FAC: 302E3030 '0.00'
> C0259FB0: 30303030 '0000'
> C0259FB4: 5D204C69 '] Li'
> C0259FB8: 6E757820 'nux '
> C0259FBC: 76657273 'vers'
> C0259FC0: 696F6E20 'ion '
> C0259FC4: 322E362E '2.6.'
> C0259FC8: 32352D72 '25-r'
Looks like you've found how to read the logbuf; now you just need to
dump it to a file so tha tyou can read it. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 05/11] powerpc/cell: add spu aware cpufreq governor
From: Stephen Rothwell @ 2008-07-08 2:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <1215465477.20774.65.camel@weaponx>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
On Mon, 07 Jul 2008 17:17:57 -0400 Josh Boyer <jwboyer@gmail.com> wrote:
>
> On Mon, 2008-07-07 at 23:15 +0200, Arnd Bergmann wrote:
> > On Monday 07 July 2008, Josh Boyer wrote:
> > >
> > > On Mon, 2008-07-07 at 16:59 +0200, Arnd Bergmann wrote:
> > > > On Monday 07 July 2008, Stephen Rothwell wrote:
> > > > > > +#define POLL_TIME 100000 /* in us */
> > > > > ^
> > > > > How about μ ?
> > > >
> > > > Not sure, how about µ instead? ;-)
> > >
> > > Erm... don't get it. You have identical characters here.
> >
> > That depends on the tool you use to look at it.
> >
> > Stephen wrote a Unicode character U+03BC from the Greek alphabet part of
> > unicode, I wrote unicode character U+00B5 from the Latin-1 code page.
> > In my mail client, latin-1 characters get rendered in the default font,
> > but it has to change the font for less common scripts.
>
> I thought Unicode was supposed to _improve_ stuff like that... ;)
In fact, Arnd was right, I used the Greek letter mu (μ) while he chose the
micro sign (µ). So, the lartter (Unicode 0x00B5) it should be.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Roman Zippel @ 2008-07-08 2:55 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, linux-next, Paul Mackerras, Sam Ravnborg,
linuxppc-dev
In-Reply-To: <1215473798.8138.4.camel@localhost>
Hi,
On Tue, 8 Jul 2008, Michael Ellerman wrote:
> I don't really see why it "doesn't make sense" for users to input 64-bit
> values, they're configuring addresses for a 64-bit kernel, so some of
> the values are going to be 64 bit.
Do you really expect users to insert random 64bit addresses without making
a mistake?
Please make a realistic case, where the user input of a full 64bit value
is required (i.e. where it's not easier to just offer the user a few
choices).
Currently there is simply no need for this, as even powerpc only used them
as constants here.
> > Index: linux-2.6/arch/powerpc/Kconfig
> > ===================================================================
> > --- linux-2.6.orig/arch/powerpc/Kconfig
> > +++ linux-2.6/arch/powerpc/Kconfig
> > @@ -714,8 +714,8 @@ config PHYSICAL_START_BOOL
> >
> > config PHYSICAL_START
> > hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
> > - default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
> > - default "0x00000000"
> > + default "0x2000000" if PPC_STD_MMU && CRASH_DUMP
> > + default "0"
> >
> > config PHYSICAL_ALIGN
> > hex
> > @@ -763,7 +763,7 @@ config CONSISTENT_SIZE_BOOL
> >
> > config CONSISTENT_SIZE
> > hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
> > - default "0x00200000" if NOT_COHERENT_CACHE
> > + default "0x200000" if NOT_COHERENT_CACHE
> >
> > config PIN_TLB
> > bool "Pinned Kernel TLBs (860 ONLY)"
> > @@ -773,15 +773,11 @@ endmenu
> > if PPC64
> > config PAGE_OFFSET
> > hex
> > - default "0xc000000000000000"
> > -config KERNEL_START
> > - hex
> > - default "0xc000000002000000" if CRASH_DUMP
> > - default "0xc000000000000000"
> > + default "0xc0000000"
>
> I don't see where you cope with the "if CRASH_DUMP" case, and in fact my
> config changes for the worse when I apply your patch and regenerate my
> config:
>
> --- .config.orig 2008-07-08 09:30:00.000000000 +1000
> +++ .config 2008-07-08 09:30:43.000000000 +1000
> @@ -370,9 +370,8 @@
> CONFIG_HOTPLUG_PCI_RPA=m
> CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> # CONFIG_HAS_RAPIDIO is not set
> -CONFIG_PAGE_OFFSET=0xc000000000000000
> -CONFIG_KERNEL_START=0xc000000002000000
> -CONFIG_PHYSICAL_START=0x02000000
> +CONFIG_PAGE_OFFSET=0xc0000000
> +CONFIG_PHYSICAL_START=0x2000000
Why is this worse? These are constants, you're not supposed to change them
anyway.
The remaining values are generated in page.h and should be the same as
before. If that isn't the case and this patch produces a nonworking
kernel, I'd like to hear about it.
bye, Roman
^ permalink raw reply
* [PATCHv3] Power5,Power6 BSR driver
From: Sonny Rao @ 2008-07-08 2:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: sonnyrao, paulus, jschopp, Nathan Lynch, linuxppc-dev
In-Reply-To: <1215469617.8970.146.camel@pasglop>
On Tue, Jul 08, 2008 at 08:26:57AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2008-07-07 at 16:17 -0500, Sonny Rao wrote:
> > On Mon, Jul 07, 2008 at 02:59:35PM +1000, Benjamin Herrenschmidt wrote:
> > >
> > > > + cur->bsr_addr = reg[i * 2];
> > > > + cur->bsr_len = reg[i * 2 + 1];
> > >
> > > That's fishy... hand-reading of "reg" property without taking
> > > into account the parent's #size-cells/#address-cells... can't you
> > > use of_address_to_resource or something similar and carry a struct
> > > resource around instead ?
> >
> > So, with this suggestion I looked at the resource API... not very well
> > documented, and I get the feeling like it's more for carving up a PCI
> > memory address range. In the case of the BSR, everything is already
> > partitioned (by hardware) so I don't see the point of using this API
> > here. Or am I missing something about it?
>
> It's about properly parsing a "reg" property in OF. The format of the
> reg property depends on the parent #address-cells and #size-cells, and
> the addresses in there may need remapping (or not) depending on parent
> "ranges" properties. The special cases in prom_parse.c for PCI and ISA
> are purely to deal with the additional address space flags those add to
> addresses, but you shouldn't hit that with BSR.
>
> > > In fact, same goes with the way you do num_bsr_devs = reg_len / 16.
> > >
> > > You should rather use -another- property of well known lenght, or
> > > get the #address/#size-cells of the parent and use those appropriately.
> >
> > Well, I check to make sure the lengths are consistent with each other
> > right above there so we shouldn't walk off the end of anything, but I
> > will take a look at using #size-cells / #address-cells instead.
>
> The code in prom_parse.c will do it for you :-)
From: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
Adds a character driver for BSR support on IBM POWER systems including
Power5 and Power6. The BSR is an optional processor facility not currently
implemented by any other processors. It's primary purpose is fast large SMP
synchronization. More details on the BSR are in comments to the code which
follows. Patch adds BSR to pseries_defconfig
Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
Index: linux-dev/drivers/char/bsr.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-dev/drivers/char/bsr.c 2008-07-07 21:49:06.000000000 -0500
@@ -0,0 +1,313 @@
+/* IBM POWER Barrier Synchronization Register Driver
+ *
+ * Copyright IBM Corporation 2008
+ *
+ * Author: Sonny Rao <sonnyrao@us.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/module.h>
+#include <linux/cdev.h>
+#include <linux/list.h>
+#include <linux/mm.h>
+#include <asm/io.h>
+
+/*
+ This driver exposes a special register which can be used for fast
+ synchronization across a large SMP machine. The hardware is exposed
+ as an array of bytes where each process will write to one of the bytes to
+ indicate it has finished the current stage and this update is broadcast to
+ all processors without having to bounce a cacheline between them. In
+ POWER5 and POWER6 there is one of these registers per SMP, but it is
+ presented in two forms; first, it is given as a whole and then as a number
+ of smaller registers which alias to parts of the single whole register.
+ This can potentially allow multiple groups of processes to each have their
+ own private synchronization device.
+
+ Note that this hardware *must* be written to using *only* single byte writes.
+ It may be read using 1, 2, 4, or 8 byte loads which must be aligned since
+ this region is treated as cache-inhibited processes should also use a
+ full sync before and after writing to the BSR to ensure all stores and
+ the BSR update have made it to all chips in the system
+*/
+
+/* This is arbitrary number, up to Power6 it's been 17 or fewer */
+#define BSR_MAX_DEVS (32)
+
+struct bsr_dev {
+ u64 bsr_addr; /* Real address */
+ u64 bsr_len; /* length of mem region we can map */
+ unsigned bsr_bytes; /* size of the BSR reg itself */
+ unsigned bsr_stride; /* interval at which BSR repeats in the page */
+ unsigned bsr_type; /* maps to enum below */
+ unsigned bsr_num; /* bsr id number for its type */
+ int bsr_minor;
+
+ dev_t bsr_dev;
+ struct cdev bsr_cdev;
+ struct device *bsr_device;
+ char bsr_name[32];
+
+};
+
+static unsigned num_bsr_devs;
+static struct bsr_dev *bsr_devs;
+static struct class *bsr_class;
+static int bsr_major;
+
+enum {
+ BSR_8 = 0,
+ BSR_16 = 1,
+ BSR_64 = 2,
+ BSR_128 = 3,
+ BSR_UNKNOWN = 4,
+ BSR_MAX = 5,
+};
+
+static unsigned bsr_types[BSR_MAX];
+
+static ssize_t
+bsr_size_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct bsr_dev *bsr_dev = dev_get_drvdata(dev);
+ return sprintf(buf, "%u\n", bsr_dev->bsr_bytes);
+}
+
+static ssize_t
+bsr_stride_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct bsr_dev *bsr_dev = dev_get_drvdata(dev);
+ return sprintf(buf, "%u\n", bsr_dev->bsr_stride);
+}
+
+static ssize_t
+bsr_len_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct bsr_dev *bsr_dev = dev_get_drvdata(dev);
+ return sprintf(buf, "%lu\n", bsr_dev->bsr_len);
+}
+
+static struct device_attribute bsr_dev_attrs[] = {
+ __ATTR(bsr_size, S_IRUGO, bsr_size_show, NULL),
+ __ATTR(bsr_stride, S_IRUGO, bsr_stride_show, NULL),
+ __ATTR(bsr_length, S_IRUGO, bsr_len_show, NULL),
+ __ATTR_NULL
+};
+
+static int bsr_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+ unsigned long size = vma->vm_end - vma->vm_start;
+ struct bsr_dev *dev = filp->private_data;
+
+ 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))
+ return -EAGAIN;
+
+ return 0;
+}
+
+static int bsr_open(struct inode * inode, struct file * filp)
+{
+ struct cdev *cdev = inode->i_cdev;
+ struct bsr_dev *dev = container_of(cdev, struct bsr_dev, bsr_cdev);
+
+ filp->private_data = dev;
+ return 0;
+}
+
+const static struct file_operations bsr_fops = {
+ .owner = THIS_MODULE,
+ .mmap = bsr_mmap,
+ .open = bsr_open,
+};
+
+static void bsr_cleanup_devs(void)
+{
+ int i;
+ for (i=0 ; i < num_bsr_devs; i++) {
+ struct bsr_dev *cur = bsr_devs + i;
+ if (cur->bsr_device) {
+ cdev_del(&cur->bsr_cdev);
+ device_del(cur->bsr_device);
+ }
+ }
+
+ kfree(bsr_devs);
+}
+
+static int bsr_create_devs(struct device_node *bn)
+{
+ int bsr_stride_len, bsr_bytes_len;
+ const u32 *bsr_stride;
+ const u32 *bsr_bytes;
+ unsigned i;
+
+ bsr_stride = of_get_property(bn, "ibm,lock-stride", &bsr_stride_len);
+ bsr_bytes = of_get_property(bn, "ibm,#lock-bytes", &bsr_bytes_len);
+
+ if (!bsr_stride || !bsr_bytes ||
+ (bsr_stride_len != bsr_bytes_len)) {
+ printk(KERN_ERR "bsr of-node has missing/incorrect property\n");
+ return -ENODEV;
+ }
+
+ num_bsr_devs = bsr_bytes_len / sizeof(u32);
+
+ /* only a warning, its informational since we'll fail and exit */
+ WARN_ON(num_bsr_devs > BSR_MAX_DEVS);
+
+ bsr_devs = kzalloc(sizeof(struct bsr_dev) * num_bsr_devs, GFP_KERNEL);
+ if (!bsr_devs)
+ return -ENOMEM;
+
+ for (i = 0 ; i < num_bsr_devs; i++) {
+ struct bsr_dev *cur = bsr_devs + i;
+ struct resource res;
+ int result;
+
+ result = of_address_to_resource(bn, i, &res);
+ if (result < 0) {
+ printk(KERN_ERR "bsr of-node has invalid reg property\n");
+ goto out_err;
+ }
+
+ cur->bsr_minor = i;
+ cur->bsr_addr = res.start;
+ cur->bsr_len = res.end - res.start + 1;
+ cur->bsr_bytes = bsr_bytes[i];
+ cur->bsr_stride = bsr_stride[i];
+ cur->bsr_dev = MKDEV(bsr_major, i);
+
+ switch(cur->bsr_bytes) {
+ case 8:
+ cur->bsr_type = BSR_8;
+ break;
+ case 16:
+ cur->bsr_type = BSR_16;
+ break;
+ case 64:
+ cur->bsr_type = BSR_64;
+ break;
+ case 128:
+ cur->bsr_type = BSR_128;
+ 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];
+ bsr_types[cur->bsr_type] = cur->bsr_num + 1;
+ snprintf(cur->bsr_name, 32, "bsr%d_%d",
+ cur->bsr_bytes, cur->bsr_num);
+
+ cdev_init(&cur->bsr_cdev, &bsr_fops);
+ result = cdev_add(&cur->bsr_cdev, cur->bsr_dev, 1);
+ if (result)
+ goto out_err;
+
+ cur->bsr_device = device_create(bsr_class, NULL,
+ cur->bsr_dev,
+ cur->bsr_name);
+ if (!cur->bsr_device) {
+ printk(KERN_ERR "device_create failed for %s\n",
+ cur->bsr_name);
+ cdev_del(&cur->bsr_cdev);
+ goto out_err;
+ }
+ dev_set_drvdata(cur->bsr_device, cur);
+ }
+
+ return 0;
+
+ out_err:
+
+ bsr_cleanup_devs();
+ return -ENODEV;
+}
+
+static int __init bsr_init(void)
+{
+ struct device_node *np;
+ dev_t bsr_dev = MKDEV(bsr_major, 0);
+ int ret = -ENODEV;
+ int result;
+
+ np = of_find_compatible_node(NULL, "ibm,bsr", "ibm,bsr");
+ if (!np)
+ goto out_err;
+
+ bsr_class = class_create(THIS_MODULE, "bsr");
+ if (IS_ERR(bsr_class)) {
+ printk(KERN_ERR "class_create() failed for bsr_class\n");
+ goto out_err_1;
+ }
+ bsr_class->dev_attrs = bsr_dev_attrs;
+
+ result = alloc_chrdev_region(&bsr_dev, 0, BSR_MAX_DEVS, "bsr");
+ bsr_major = MAJOR(bsr_dev);
+ if (result < 0) {
+ printk(KERN_ERR "alloc_chrdev_region() failed for bsr\n");
+ goto out_err_2;
+ }
+
+ if ((ret = bsr_create_devs(np)) < 0)
+ goto out_err_3;
+
+ of_node_put(np);
+
+ return 0;
+
+ out_err_3:
+ unregister_chrdev_region(bsr_dev, BSR_MAX_DEVS);
+
+ out_err_2:
+ class_destroy(bsr_class);
+
+ out_err_1:
+ of_node_put(np);
+
+ out_err:
+
+ return ret;
+}
+
+static void __exit bsr_exit(void)
+{
+
+ bsr_cleanup_devs();
+
+ if (bsr_class)
+ class_destroy(bsr_class);
+
+ if (bsr_major)
+ unregister_chrdev_region(MKDEV(bsr_major, 0), BSR_MAX_DEVS);
+}
+
+module_init(bsr_init);
+module_exit(bsr_exit);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Sonny Rao <sonnyrao@us.ibm.com>");
Index: linux-dev/drivers/char/Makefile
===================================================================
--- linux-dev.orig/drivers/char/Makefile 2008-06-18 01:24:04.000000000 -0500
+++ linux-dev/drivers/char/Makefile 2008-06-18 01:38:30.000000000 -0500
@@ -57,6 +57,7 @@
obj-$(CONFIG_VIOCONS) += viocons.o
obj-$(CONFIG_VIOTAPE) += viotape.o
obj-$(CONFIG_HVCS) += hvcs.o
+obj-$(CONFIG_IBM_BSR) += bsr.o
obj-$(CONFIG_SGI_MBCS) += mbcs.o
obj-$(CONFIG_BRIQ_PANEL) += briq_panel.o
obj-$(CONFIG_BFIN_OTP) += bfin-otp.o
Index: linux-dev/drivers/char/Kconfig
===================================================================
--- linux-dev.orig/drivers/char/Kconfig 2008-06-18 01:24:04.000000000 -0500
+++ linux-dev/drivers/char/Kconfig 2008-06-18 01:38:30.000000000 -0500
@@ -649,6 +649,14 @@
which will also be compiled when this driver is built as a
module.
+config IBM_BSR
+ tristate "IBM POWER Barrier Synchronization Register support"
+ depends on PPC_PSERIES
+ help
+ This devices exposes a hardware mechanism for fast synchronization
+ of threads across a large system which avoids bouncing a cacheline
+ between several cores on a system
+
source "drivers/char/ipmi/Kconfig"
config DS1620
Index: linux-dev/arch/powerpc/configs/pseries_defconfig
===================================================================
--- linux-dev.orig/arch/powerpc/configs/pseries_defconfig 2008-07-07 20:44:42.000000000 -0500
+++ linux-dev/arch/powerpc/configs/pseries_defconfig 2008-07-07 20:45:21.000000000 -0500
@@ -946,6 +946,7 @@
CONFIG_HVC_CONSOLE=y
CONFIG_HVC_RTAS=y
CONFIG_HVCS=m
+CONFIG_IBM_BSR=m
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
CONFIG_GEN_RTC=y
^ permalink raw reply
* Re: [PATCH] [V2] powerpc: Xilinx: add dts file for ML507 board
From: David Gibson @ 2008-07-08 3:16 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080707180508.4E2CBE8081@mail72-dub.bigfish.com>
On Mon, Jul 07, 2008 at 11:04:59AM -0700, John Linn wrote:
> This new file adds support for the ML507 board which
> has a Virtex 5 FXT FPGA with a 440.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---
> V2
> Converted to dts-v1 format.
> Changed to match a newer reference design.
>
> arch/powerpc/boot/dts/virtex440-ml507.dts | 296 +++++++++++++++++++++++++++++
> 1 files changed, 296 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
>
> diff --git a/arch/powerpc/boot/dts/virtex440-ml507.dts b/arch/powerpc/boot/dts/virtex440-ml507.dts
> new file mode 100644
> index 0000000..d10a993
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/virtex440-ml507.dts
> @@ -0,0 +1,296 @@
> +/*
> + * This file supports the Xilinx ML507 board with the 440 processor.
> + * A reference design for the FPGA is provided at http://git.xilinx.com.
> + *
> + * (C) Copyright 2008 Xilinx, Inc.
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "xlnx,virtex440";
> + dcr-parent = <&ppc440_0>;
> + model = "testing";
> + DDR2_SDRAM: memory@0 {
> + device_type = "memory";
> + reg = < 0 0x10000000 >;
> + } ;
> + chosen {
> + bootargs = "console=ttyS0 ip=on root=/dev/ram";
Bootargs like this should not typically go in the dts file.
> + linux,stdout-path = "/plb@0/serial@83e00000";
> + } ;
> + cpus {
> + #address-cells = <1>;
> + #cpus = <1>;
> + #size-cells = <0>;
> + ppc440_0: cpu@0 {
> + clock-frequency = "";
Presumably this is supposed to be filled in by the bootloader. But in
any case it shouldn't be a string.
[snip]
> + DMA0: sdma@80 {
> + compatible = "xlnx,ll-dma-1.00.a";
> + dcr-reg = < 0x80 0x11 >;
> + interrupt-parent = <&xps_intc_0>;
> + interrupts = < 9 2 0xa 2 >;
> + } ;
Putting devices under the cpu node is certainly... atypical. It's not
obviously wrong, for a dcr device like this, but we probably want a
little more discussion before establishing a convention like this.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] Restore PERR/SERR bit settings during EEH device recovery
From: Mike Mason @ 2008-07-08 3:18 UTC (permalink / raw)
To: paulus, benh, linasvepstas, linuxppc-dev
The following patch restores the PERR and SERR bits in the PCI
command register during an EEH device recovery.
We have found at least one case (an Agilent test card) where the
PERR/SERR bits are set to 1 by firmware at boot time, but are
not restored to 1 during EEH recovery. The patch fixes the
Agilent card problem. It has been tested on several other
EEH-enabled cards with no regressions.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
--- linux-2.6.26-rc9/arch/powerpc/platforms/pseries/eeh.c 2008-07-07 16:06:57.000000000 -0700
+++ linux-2.6.26-rc9-new/arch/powerpc/platforms/pseries/eeh.c 2008-07-07 16:11:10.000000000 -0700
@@ -812,6 +812,7 @@
static inline void __restore_bars (struct pci_dn *pdn)
{
int i;
+ u32 cmd;
if (NULL==pdn->phb) return;
for (i=4; i<10; i++) {
@@ -832,6 +833,15 @@
/* max latency, min grant, interrupt pin and line */
rtas_write_config(pdn, 15*4, 4, pdn->config_space[15]);
+
+ /* Restore PERR & SERR bits, some devices require it,
+ don't touch the other command bits */
+ rtas_read_config(pdn, PCI_COMMAND, 4, &cmd);
+ if (pdn->config_space[1] & PCI_COMMAND_PARITY)
+ cmd |= PCI_COMMAND_PARITY;
+ if (pdn->config_space[1] & PCI_COMMAND_SERR)
+ cmd |= PCI_COMMAND_SERR;
+ rtas_write_config(pdn, PCI_COMMAND, 4, cmd);
}
/**
^ permalink raw reply
* Re: [PATCH] Add MPC5200B base board mvBC-P
From: David Gibson @ 2008-07-08 3:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-ppc list, Andre Schwarz
In-Reply-To: <fa686aa40807070712x77ff7aben4cf51731bb4f5985@mail.gmail.com>
On Mon, Jul 07, 2008 at 08:12:11AM -0600, Grant Likely wrote:
> On Mon, Jul 7, 2008 at 1:49 AM, Andre Schwarz
> <andre.schwarz@matrix-vision.de> wrote:
> > David,
> >
> > thanks - removed "device_type" from the DMA controller.
> >
> > Which nodes actually require "device_type" and which don't ?
> >
> > Is there some general rule ?
>
> Segher, David;
>
> In OF, what is the purpose of device_type? From what I understand
> right now, each value of device_type claims a software interface that
> the device supports. So for example, device_type = "serial" means
> that firmware supports using the device as a serial port, correct?
That's correct. And more specially allows using it as a serial port
using the OF defined method interface.
> So, similarly, if OF did not have a driver for the device, then the
> presence a device_type property would be a bug, right?
Um.. not precisely sure about this case, don't know if 1275 allows
device nodes with no OF driver / method interface.
> Does device_type indicated any other information other than firmware
> driver interface?
In theory, no. In practice... sort of, sometimes, maybe.
> I had an epiphany about device_type this weekend (and by epiphany, I
> mean realizing my own stupidity). If I'm correct about the above
> questions, then that would mean it is *always* a bug to have a
> device_type property in .dts file because there is no firmware
> interface. So, it seems to me that we shouldn't just be eliminating
> undefined device_type values, but also eliminate the ones that are
> defined in OF because .dts users do not support the firmware driver
> interface.
>
> Am I correct?
Again, in theory, yes. In practice.. maybe.
As you say, device_type is only supposed to describe the firmware
provided software-interface and should not be used for other device
identification purposes. However, because device_type used to be
present on basically everything, it sometimes is, by Linux and
presumably also by other OSes.
We certainly don't want to encourage or perpetuate that incorrect use,
which is why we're so insistent that people don't invent new
device_type values or use ones that aren't described in the existing
1275 bindings.
There are the few "special" devices that don't typically have
'compatible' values, so there isn't really any way to identify them
other than 'device_type' and name. That's the memory and cpu nodes
typically, and sometimes pci IIRC (PCI bridges really should have a
compatible value to describe their register interface, but I have a
feeling they fairly often don't). ISA nodes may fall in this category
too, I forget. I am strongly inclined to continue recommending
device_type be present in these cases rather than relying solely on
the name, or inventing a new way of marking these nodes.
Then there are the devices that do generally have 'compatible', but do
have long established device_type values: "serial" and "network" are
the main ones. We might be able to just drop the device_type values
here and have nothing break. Unfortunatly, I rather suspect some
drivers will check the device_type value, even though they shouldn't.
Therefore I'm mildly inclined to at least suggest that device_type be
optionally present for improved compatibility with legacy code.
> The only situation where I can see it being appropriate to specify
> device_type is to work around older bindings that are ambiguous with
> their other properties.
Exactly right. The important thing is to always be aware than *any*
presence of device_type in a flattened tree is basically a hack for
compatibility with code expecting real-OF-like trees; it has no
inherent purpose in a flattened tree.
Unfortunately getting people writing trees to realise this, when the
property has that name, and appears freqeutnly in existing trees,
seems to be a tricky problem.
--
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 v2] Add MPC5200B base board mvBC-P
From: David Gibson @ 2008-07-08 3:44 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <4871D065.8080709@matrix-vision.de>
On Mon, Jul 07, 2008 at 10:14:29AM +0200, Andre Schwarz wrote:
> The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit ethernet
> controller (using e1000). It's just another MPC5200_simple board.
[snip]
> + timer@600 { // General Purpose Timer
> + compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> + reg = <0x600 0x10>;
> + interrupts = <1 9 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + fsl,has-wdt;
> + };
> +
> + timer@610 { // General Purpose Timer
> + compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> + cell-index = <1>;
What shared resource is this cell-index value used to index?
Also why does it not appear on the timer@600 but does on all the
others.
--
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: powerpc: Add proper reference to dma_mask
From: Stephen Rothwell @ 2008-07-08 3:54 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20080708031256.57176084@vitb-lp>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
Hi Vitaly,
On Tue, 8 Jul 2008 03:12:56 +0400 Vitaly Bordug <vitb@kernel.crashing.org> wrote:
>
> +++ b/arch/powerpc/kernel/of_platform.c
> @@ -76,6 +76,9 @@ struct of_device* of_platform_device_create(struct device_node *np,
> return NULL;
>
> dev->dma_mask = 0xffffffffUL;
> + dev->dev.dma_mask = &dev->dma_mask;
That is done in of_device_alloc which is called just above.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Merging seperate FDT-blobs?
From: David Gibson @ 2008-07-08 4:15 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20080707092347.GB4409@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
On Mon, Jul 07, 2008 at 11:23:47AM +0200, Wolfram Sang wrote:
> On Mon, Jul 07, 2008 at 11:28:43AM +1000, David Gibson wrote:
>
> > > This function is surely needed in every case I considered so far. I am
> > > just sceptical if the boot-loader can determine a correct parentoffset
> > > all alone (which one of the two I2C busses is the correct one?). This is
> >
> > Hrm. "all alone". It's not clear to me what else there could be that
> > would have more information than the bootloader.
>
> What I meant is that all the information a bootloader has may not be
> sufficent. To solve this, some additional infos could be added to the
> tree. In this case, it could be a few aliases.
My point is that the dts and the bootloader will typically be built by
the same person as part of the same process. What is the rationale
for encoding this information into the tree fragments rather than the
code?
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Mikrotik RouterBoard 333
From: David Gibson @ 2008-07-08 4:26 UTC (permalink / raw)
To: linuxppc-dev
Does anyone on this list have contacts with the makers of this board?
Its firmware apparently provides a flattened device tree to the OS.
And while this step towards world domination is flattering, it's an
example of what I feared when people first got enthusiastic about the
idea of including flattened device trees in firmwares. The tree has
not, AFAIK, been past this list, and has apparently not been reviewed
by someone knowledgeable about device trees. In short, it's crap, and
now that it's embedded in the firware we can't really fix it.
So, to any embedded hardware/firmware vendors doing Linux ports out
there. I certainly encourage you to use flattened device trees, but
can I please suggest you put the blob into your kernel image (in the
bootwrapper strictly speaking), rather than into the flashed firmware.
It's a lot easier to fix mistakes that way.
There are situations where it's nice to have the device tree in
firmware, but there are many others where it buys little to nothing.
People seem to be a bit overenthusaistic on the concept at the moment.
--
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: powerpc: Add proper reference to dma_mask
From: Benjamin Herrenschmidt @ 2008-07-08 4:28 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20080708135426.43edb5dc.sfr@canb.auug.org.au>
On Tue, 2008-07-08 at 13:54 +1000, Stephen Rothwell wrote:
> Hi Vitaly,
>
> On Tue, 8 Jul 2008 03:12:56 +0400 Vitaly Bordug <vitb@kernel.crashing.org> wrote:
> >
> > +++ b/arch/powerpc/kernel/of_platform.c
> > @@ -76,6 +76,9 @@ struct of_device* of_platform_device_create(struct device_node *np,
> > return NULL;
> >
> > dev->dma_mask = 0xffffffffUL;
> > + dev->dev.dma_mask = &dev->dma_mask;
>
> That is done in of_device_alloc which is called just above.
So the problem might just be that coherent_dma_mask isn't set.
Ben.
^ permalink raw reply
* Re: [PATCHv3] Power5,Power6 BSR driver
From: Stephen Rothwell @ 2008-07-08 4:52 UTC (permalink / raw)
To: Sonny Rao; +Cc: jschopp, Nathan, sonnyrao, linuxppc-dev, paulus, Lynch
In-Reply-To: <20080708025812.GC15821@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
Hi Sonny,
On Mon, 7 Jul 2008 21:58:12 -0500 Sonny Rao <sonnyrao@us.ibm.com> wrote:
>
> +static int bsr_create_devs(struct device_node *bn)
> +{
> + cur->bsr_device = device_create(bsr_class, NULL,
> + cur->bsr_dev,
> + cur->bsr_name);
> + if (!cur->bsr_device) {
> + printk(KERN_ERR "device_create failed for %s\n",
> + cur->bsr_name);
> + cdev_del(&cur->bsr_cdev);
> + goto out_err;
> + }
> + dev_set_drvdata(cur->bsr_device, cur);
device_create() is being removed in 2.6.27 because the above introduces a
race, use device_create_drvdata() instead.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: rework 4xx PTE access and TLB miss
From: Benjamin Herrenschmidt @ 2008-07-08 4:58 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080707212523.24d2014f@zod.rchland.ibm.com>
> > I'll have a look.
>
> Cool, thanks. If I get some time, I'll poke around myself too.
Ok, I had no problem with my small initrd setup, strangely enough,
but I did reproduce something similar to what you describe with NFS
root on another machine.
I'll dig.
Cheers,
Ben.
^ permalink raw reply
* Correct hash flushing from huge_ptep_set_wrprotect()
From: David Gibson @ 2008-07-08 5:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
As Andy Whitcroft recently pointed out, the current powerpc version of
huge_ptep_set_wrprotect() has a bug. It just calls
ptep_set_wrprotect() which in turn calls pte_update() then
hpte_need_flush() with the 'huge' argument set to 0. This will cause
hpte_need_flush() to flush the wrong hash entries (of any). Andy's
fix for this is already in the powerpc tree as commit
016b33c4958681c24056abed8ec95844a0da80a3.
I have confirmed this is a real bug, not masked by some other
synchronization, with a new testcase for libhugetlbfs. A process
write a (MAP_PRIVATE) hugepage mapping, fork(), then alter the mapping
and have the child incorrectly see the second write.
Therefore, this should be fixed for 2.6.26, and for the stable tree.
Here is a suitable patch for 2.6.26, which I think will also be
suitable for the stable tree (neither of the headers in question has
been changed much recently). It is cut down slighlty from Andy's
original version, in that it does not include a 32-bit version of
huge_ptep_set_wrprotect(). Currently, hugepages are not supported on
any 32-bit powerpc platform. When they are, a suitable 32-bit version
can be added - the only 32-bit hardware which supports hugepages does
not use the conventional hashtable MMU and so will have different
needs anyway.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/include/asm-powerpc/hugetlb.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/hugetlb.h 2008-07-08 14:06:56.000000000 +1000
+++ working-2.6/include/asm-powerpc/hugetlb.h 2008-07-08 14:07:04.000000000 +1000
@@ -49,12 +49,6 @@ static inline pte_t huge_pte_wrprotect(p
return pte_wrprotect(pte);
}
-static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
- unsigned long addr, pte_t *ptep)
-{
- ptep_set_wrprotect(mm, addr, ptep);
-}
-
static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep,
pte_t pte, int dirty)
Index: working-2.6/include/asm-powerpc/pgtable-ppc64.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/pgtable-ppc64.h 2008-07-08 14:09:16.000000000 +1000
+++ working-2.6/include/asm-powerpc/pgtable-ppc64.h 2008-07-08 14:09:30.000000000 +1000
@@ -314,6 +314,16 @@ static inline void ptep_set_wrprotect(st
old = pte_update(mm, addr, ptep, _PAGE_RW, 0);
}
+static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
+ unsigned long addr, pte_t *ptep)
+{
+ unsigned long old;
+
+ if ((pte_val(*ptep) & _PAGE_RW) == 0)
+ return;
+ old = pte_update(mm, addr, ptep, _PAGE_RW, 1);
+}
+
/*
* We currently remove entries from the hashtable regardless of whether
* the entry was young or dirty. The generic routines only flush if the
--
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
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