Re: [PATCH] Fake NUMA emulation for PowerPC
On Sat, 8 Dec 2007, Balbir Singh wrote: > > You're going to want to distribute the cpu's based on how they match up > > physically with the actual platform that you're running on. x86_64 does > > Could you explain this better, how does it match up CPU's with fake NUMA > memory? Is there some smartness there? I'll try and look at the code and > also see what I can do for PowerPC > numa_cpumask_lookup_table[] would return the correct cpumask for the fake node index. Then all the code that uses node_to_cpumask() in generic kernel code like the scheduler and VM still preserve their true NUMA affinity that matches the underlying hardware. I tried to make x86_64 fake NUMA as close to the real thing as possible. You also probably want to make all you changes dependent on CONFIG_NUMA_EMU like the x86_64 case. That'll probably be helpful as you extend this tool more and more. David ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
David Rientjes wrote: > On Sat, 8 Dec 2007, Balbir Singh wrote: > >> Yes, they all appear on node 0. We could have tweaks to distribute CPU's >> as well. >> > > You're going to want to distribute the cpu's based on how they match up > physically with the actual platform that you're running on. x86_64 does Could you explain this better, how does it match up CPU's with fake NUMA memory? Is there some smartness there? I'll try and look at the code and also see what I can do for PowerPC > this already and it makes fake NUMA more useful because it matches the > real-life case more often. Yes, I agree, but I don't want that to be the first step for fake NUMA nodes on PowerPC. I think we can incrementally add features. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
David Rientjes wrote: > On Sat, 8 Dec 2007, Balbir Singh wrote: > >> To be able to test the memory controller under NUMA, I use fake NUMA >> nodes. x86-64 has a similar feature, the code I have here is the >> simplest I could come up with for PowerPC. >> > > Magnus Damm had patches from over a year ago that, I believe, made much of > the x86_64 fake NUMA code generic so that it could be extended for > architectures such as i386. Perhaps he could resurrect those patches if > there is wider interest in such a tool. That would be a very interesting patch, but what I have here is the simplest patch and we could build on it incrementally. The interface is non-standard but it does amazing things for 59 lines of code change. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Thu, Dec 06, 2007 at 04:27:56PM -0700, Mark A. Greer wrote: > David, et. al., > > This is a big blob patch of what I've changed for the prpmc2800. It > includes the necessary changes in the kernel which you can probably > ignore but they're there for reference. If you like the dts, then I'll > split the blob up into logical pieces and Andrei can make similar > changes for the Katana Qp. > > Let me know what you think. Looks pretty reasonable. I would have preferred that labels be uppercase by convention, to make them easier to pick out by eyeball, but I think that's a lost cause at this stage. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Remove header information dumping
Currently, when used in -Idtb mode, dtc will dump information about
the input blob's header fields to stderr. This is kind of ugly, and
can get in the way of dtc's real output.
This patch, therefore, removes this. So that there's still a way of
getting this information for debugging purposes, it places something
similar to the removed code into ftdump, replacing the couple of
header fields it currently prints with a complete header dump.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/flattree.c
===
--- dtc.orig/flattree.c 2007-12-08 12:06:11.0 +1100
+++ dtc/flattree.c 2007-12-08 12:13:15.0 +1100
@@ -898,15 +898,6 @@
off_mem_rsvmap = be32_to_cpu(fdt->off_mem_rsvmap);
version = be32_to_cpu(fdt->version);
- fprintf(stderr, "\tmagic:\t\t\t0x%x\n", magic);
- fprintf(stderr, "\ttotalsize:\t\t%d\n", totalsize);
- fprintf(stderr, "\toff_dt_struct:\t\t0x%x\n", off_dt);
- fprintf(stderr, "\toff_dt_strings:\t\t0x%x\n", off_str);
- fprintf(stderr, "\toff_mem_rsvmap:\t\t0x%x\n", off_mem_rsvmap);
- fprintf(stderr, "\tversion:\t\t0x%x\n", version );
- fprintf(stderr, "\tlast_comp_version:\t0x%x\n",
- be32_to_cpu(fdt->last_comp_version));
-
if (off_mem_rsvmap >= totalsize)
die("Mem Reserve structure offset exceeds total size\n");
@@ -916,21 +907,15 @@
if (off_str > totalsize)
die("String table offset exceeds total size\n");
- if (version >= 2)
- fprintf(stderr, "\tboot_cpuid_phys:\t0x%x\n",
- be32_to_cpu(fdt->boot_cpuid_phys));
-
size_str = -1;
if (version >= 3) {
size_str = be32_to_cpu(fdt->size_dt_strings);
- fprintf(stderr, "\tsize_dt_strings:\t%d\n", size_str);
if (off_str+size_str > totalsize)
die("String table extends past total size\n");
}
if (version >= 17) {
size_dt = be32_to_cpu(fdt->size_dt_struct);
- fprintf(stderr, "\tsize_dt_struct:\t\t%d\n", size_dt);
if (off_dt+size_dt > totalsize)
die("Structure block extends past total size\n");
}
Index: dtc/ftdump.c
===
--- dtc.orig/ftdump.c 2007-12-08 12:06:23.0 +1100
+++ dtc/ftdump.c2007-12-08 12:15:09.0 +1100
@@ -81,11 +81,13 @@
static void dump_blob(void *blob)
{
struct fdt_header *bph = blob;
+ uint32_t off_mem_rsvmap = be32_to_cpu(bph->off_mem_rsvmap);
+ uint32_t off_dt = be32_to_cpu(bph->off_dt_struct);
+ uint32_t off_str = be32_to_cpu(bph->off_dt_strings);
struct fdt_reserve_entry *p_rsvmap =
- (struct fdt_reserve_entry *)(blob
-+
be32_to_cpu(bph->off_mem_rsvmap));
- char *p_struct = blob + be32_to_cpu(bph->off_dt_struct);
- char *p_strings = blob + be32_to_cpu(bph->off_dt_strings);
+ (struct fdt_reserve_entry *)(blob + off_mem_rsvmap);
+ char *p_struct = blob + off_dt;
+ char *p_strings = blob + off_str;
uint32_t version = be32_to_cpu(bph->version);
uint32_t totalsize = be32_to_cpu(bph->totalsize);
uint32_t tag;
@@ -98,8 +100,26 @@
depth = 0;
shift = 4;
- printf("// Version 0x%x tree\n", version);
- printf("// Totalsize 0x%x(%d)\n", totalsize, totalsize);
+ printf("// magic:\t\t0x%x\n", be32_to_cpu(bph->magic));
+ printf("// totalsize:\t\t0x%x (%d)\n", totalsize, totalsize);
+ printf("// off_dt_struct:\t0x%x\n", off_dt);
+ printf("// off_dt_strings:\t0x%x\n", off_str);
+ printf("// off_mem_rsvmap:\t0x%x\n", off_mem_rsvmap);
+ printf("// version:\t\t%d\n", version);
+ printf("// last_comp_version:\t%d\n",
+ be32_to_cpu(bph->last_comp_version));
+ if (version >= 2)
+ printf("// boot_cpuid_phys:\t0x%x\n",
+ be32_to_cpu(bph->boot_cpuid_phys));
+
+ if (version >= 3)
+ printf("// size_dt_strings:\t0x%x\n",
+ be32_to_cpu(bph->size_dt_strings));
+ if (version >= 17)
+ printf("// size_dt_struct:\t0x%x\n",
+ be32_to_cpu(bph->size_dt_struct));
+ printf("\n");
+
for (i = 0; ; i++) {
addr = be64_to_cpu(p_rsvmap[i].address);
size = be64_to_cpu(p_rsvmap[i].size);
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > > Behalf Of Grant Likely
> > > Sent: Sunday, November 25, 2007 2:47 PM
> > > To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;
> > > Jon Loeliger
> > > Cc: [EMAIL PROTECTED];
> > > linuxppc-dev@ozlabs.org; Michal Simek; git
> > > Subject: Re: Xilinx EDK BSP generation of device trees for
> > > microblaze and PowerPC
> > >
> > > On 11/24/07, Stephen Neuendorffer
> > > <[EMAIL PROTECTED]> wrote:
> > > >
> > >
> > > Thanks for all this work; comments below.
> > >
> > > >
> > > > Here's what I've gotten so far:
> > > >
> > > > Hard_Ethernet_MAC: [EMAIL PROTECTED] {
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > > [EMAIL PROTECTED] {
> > > > compatible =
> > > "xlnx,xps-ll-temac-1.00.a",
> > > > "xlnx,xps-ll-temac";
> > >
> > > Drop "xlnx,xps-ll-temac"; it's 100% made up. This should
> be simply:
> > > compatible = "xlnx,xps-ll-temac-1.00.a" for version
> 1.00.a and
> > > compatible =
> > > "xlnx,xps-ll-temac-","xlnx,xps-ll-temac-1.00.a"
> for a future
> > > version if it maintains register level compatibility.
> > >
> > > "xlnx,xps-ll-temac" is far to ambiguous.
> >
> > What if it was: compatible = "xlnx,xps-ll-temac-1.00.a",
> > "xlnx,xps-ll-temac-1"?
>
> Here's what I've learned: There is no such thing as a perfect device
> tree. Either hardware bugs will be discovered at a later date which
> make compatible inaccurate, or a better understanding of the device
> will come along which will change the understood best practices for
> describing the device.
>
> My opinion is the best strategy against claiming something that's not
> true, or won't be true in the fucture, is to strive for uniqueness and
> describe only what you are certain of. Be conservative instead of
> liberal in the compatible case; ie. it's easier to teach the driver
> about other versions it can bind against than it is to teach it about
> exceptions to certain versions of the hardware (when binding).
>
> In this particular case the problem still stands that the VHDL
> engineer may make a non backward compatible change in version
> xlnx,xps-ll-temac-1.00.c or -1.03.c. You just don't know until it
> happens. Stick with what is known and don't try to extrapolate to a
> 'generic' version when there is no guarantee that it will remain
> generic.
>
> When sticking with real version numbers, it is quite safe to claim
> compatibility with an older version number because you've probably
> tested it; something which isn't so safe when you attempt to make up
> generic versions.
I think you've convinced me... :) I think the only reason to ever put
more than one thing in the compatible list, is if you want to declare
that you are compatible with an established, standard driver and you
don't have control over the driver. ns16550 is a great example of this,
where it is so ubiquitous that the driver is likely to be much more
stable over time than any particular hardware.
I did some quick scripting around in various versions of EDK. For the
record, Xilinx shipped about 369 distinct versions of processor IP with
the EDK, since EDK 6.3:
369 /home/stephenn/iplist_combined
And there's obviously alot of overlap between the different versions:
202 EDK 6.3
227 EDK 7.1
268 EDK 8.2
297 EDK 9.2
But the total number of drivers is much smaller:
87 EDK 6.3
91 EDK 7.1
86 EDK 8.2
112 EDK 9.2
And it appears that there are a relatively small number of changes which
the drivers claim are not forwards compatible (not to say that there
aren't other incompatibilities, but this is the compatibility that we
can infer based on what the drivers claim).
opb_ethernet_v1_01_a -> opb_ethernet_v1_02_a -> opb_ethernet_v1_04_[a-z]
opb_ethernetlite_v1_00_a -> opb_ethernetlite_v1_01_a
opb_pci_v1_00_c -> opb_pci_v1_01_a
plb_temac_v2_00_a -> plb_temac_v3_00_a
opb_deltasigma_dac_v1_00_a -> opb_deltasigma_dac_v1_01_a
opb_deltasigma_adc_v1_01_a -> opb_deltasigma_dac_v1_01_a
opb_hwicap_v1_00_b -> opb_hwicap_v1_10_a
In any event, my plan is to put only the exact version name in the
device tree and list all the compatible versions in the driver match.
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [DTC][PATCH] Fix cross-compile building
On Fri, Dec 07, 2007 at 12:28:20PM -0600, Kumar Gala wrote: > From: Stuart Hughes <[EMAIL PROTECTED]> > > This patch allows you to build the DTC source without making the > tests directory. This is necessary when cross compiling as the > dumptest (and other) files cannot be run/used on the host system. > To use this use: 'make TESTS=' I think this is a silly way of doing this. Instead create a new target which builds everything but the tests. Say, all: cross tests cross: dtc ftdump libfdt -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Convert #address-cells and #size-cells related checks
On Fri, Dec 07, 2007 at 02:05:55PM +1100, David Gibson wrote: > This patch converts checks related to #address-cells and #size-cells > to the new framework. Specifically, it reimplements the check that > "reg" properties have a valid size based on the relevant > #address-cells and #size-cells values. The new implementation uses > the correct default value, unlike the old-style check which assumed > the values were inherited by default. > > It also implements a new, similar test for "ranges" properties. > > Finally, since relying on the default values of these variables is > considered not-good-practice these days, it implements a "style" check > which will give a warning if the tree ever relies on the default > values (that is if any node with either "reg" or "ranges" appears > under a parent which has no #address-cells or #size-cells property). Oops, that should, of course, be: Signed-off-by: David Gibson <[EMAIL PROTECTED]> -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
On Sat, 8 Dec 2007, Balbir Singh wrote: > Yes, they all appear on node 0. We could have tweaks to distribute CPU's > as well. > You're going to want to distribute the cpu's based on how they match up physically with the actual platform that you're running on. x86_64 does this already and it makes fake NUMA more useful because it matches the real-life case more often. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
On Sat, 8 Dec 2007, Balbir Singh wrote: > To be able to test the memory controller under NUMA, I use fake NUMA > nodes. x86-64 has a similar feature, the code I have here is the > simplest I could come up with for PowerPC. > Magnus Damm had patches from over a year ago that, I believe, made much of the x86_64 fake NUMA code generic so that it could be extended for architectures such as i386. Perhaps he could resurrect those patches if there is wider interest in such a tool. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
On Fri, 7 Dec 2007, Olof Johansson wrote: > > Comments are as always welcome! > > Care to explain what this is useful for? (Not saying it's a stupid idea, > just wondering what the reason for doing it is). > Fake NUMA has always been useful for testing NUMA code without having to have a wide range of hardware available to you. It's a clever tool on x86_64 intended for kernel developers that simply makes it easier to test code and adds an increased level of robustness to the kernel. I think it's a valuable addition. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fake NUMA emulation for PowerPC (Take 2)
Changelog
1. Get rid of the constant 5 (based on comments from
[EMAIL PROTECTED])
2. Implement suggestions from Olof Johannson
3. Check if cmdline is NULL in fake_numa_create_new_node()
Tested with additional parameters from Olof
numa=debug,fake=
numa=foo,fake=bar
Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
NUMA nodes can be specified using the following command line option
numa=fake=
node range is of the format ,,...
Each of the rangeX parameters is passed using memparse(). I find the patch
useful for fake NUMA emulation on my simple PowerPC machine. I've tested it
on a non-numa box with the following arguments
numa=fake=1G
numa=fake=1G,2G
name=fake=1G,512M,2G
numa=fake=1500M,2800M mem=3500M
numa=fake=1G mem=512M
numa=fake=1G mem=1G
This patch applies on top of 2.6.24-rc4.
All though I've tried my best to handle some of the architecture specific
details of PowerPC, I might have overlooked something obvious, like the usage
of an API or some architecture tweaks. The patch depends on CONFIG_NUMA and
I decided against creating a separate config option for fake NUMA to keep
the code simple.
Comments are as always welcome!
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
arch/powerpc/mm/numa.c | 59 -
1 file changed, 54 insertions(+), 5 deletions(-)
diff -puN arch/powerpc/mm/numa.c~ppc-fake-numa-easy arch/powerpc/mm/numa.c
--- linux-2.6.24-rc4-mm1/arch/powerpc/mm/numa.c~ppc-fake-numa-easy
2007-12-07 21:25:55.0 +0530
+++ linux-2.6.24-rc4-mm1-balbir/arch/powerpc/mm/numa.c 2007-12-08
03:19:46.0 +0530
@@ -24,6 +24,8 @@
static int numa_enabled = 1;
+static char *cmdline __initdata;
+
static int numa_debug;
#define dbg(args...) if (numa_debug) { printk(KERN_INFO args); }
@@ -39,6 +41,43 @@ static bootmem_data_t __initdata plat_no
static int min_common_depth;
static int n_mem_addr_cells, n_mem_size_cells;
+static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
+ unsigned int *nid)
+{
+ unsigned long long mem;
+ char *p = cmdline;
+ static unsigned int fake_nid = 0;
+ static unsigned long long curr_boundary = 0;
+
+ *nid = fake_nid;
+ if (!p)
+ return 0;
+
+ mem = memparse(p, &p);
+ if (!mem)
+ return 0;
+
+ if (mem < curr_boundary)
+ return 0;
+
+ curr_boundary = mem;
+
+ if ((end_pfn << PAGE_SHIFT) > mem) {
+ /*
+* Skip commas and spaces
+*/
+ while (*p == ',' || *p == ' ' || *p == '\t')
+ p++;
+
+ cmdline = p;
+ fake_nid++;
+ *nid = fake_nid;
+ dbg("created new fake_node with id %d\n", fake_nid);
+ return 1;
+ }
+ return 0;
+}
+
static void __cpuinit map_cpu_to_node(int cpu, int node)
{
numa_cpu_lookup_table[cpu] = node;
@@ -344,12 +383,14 @@ static void __init parse_drconf_memory(s
if (nid == 0x || nid >= MAX_NUMNODES)
nid = default_nid;
}
- node_set_online(nid);
size = numa_enforce_memory_limit(start, lmb_size);
if (!size)
continue;
+ fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
+ node_set_online(nid);
+
add_active_range(nid, start >> PAGE_SHIFT,
(start >> PAGE_SHIFT) + (size >> PAGE_SHIFT));
}
@@ -429,7 +470,6 @@ new_range:
nid = of_node_to_nid_single(memory);
if (nid < 0)
nid = default_nid;
- node_set_online(nid);
if (!(size = numa_enforce_memory_limit(start, size))) {
if (--ranges)
@@ -438,6 +478,9 @@ new_range:
continue;
}
+ fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
+ node_set_online(nid);
+
add_active_range(nid, start >> PAGE_SHIFT,
(start >> PAGE_SHIFT) + (size >> PAGE_SHIFT));
@@ -461,7 +504,7 @@ static void __init setup_nonnuma(void)
unsigned long top_of_ram = lmb_end_of_DRAM();
unsigned long total_ram = lmb_phys_mem_size();
unsigned long start_pfn, end_pfn;
- unsigned int i;
+ unsigned int i, nid = 0;
printk(KERN_DEBUG "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
top_of_ram, total_ram);
@@ -471,9 +514,11 @@ static void __init setup_nonnuma(void)
for (i = 0; i < lmb.memory.cnt; ++i) {
start_pfn = lmb.memory.region[i].base >> PAGE_SHIFT;
end_pfn = start_pfn + lmb_size_pages(&lmb.memory, i);
-
Re: [PATCH] Fake NUMA emulation for PowerPC
Nathan Lynch wrote: > Hi Balbir- > > Balbir Singh wrote: >> >> Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake >> NUMA nodes can be specified using the following command line option >> >> numa=fake= >> >> node range is of the format ,,... >> >> Each of the rangeX parameters is passed using memparse(). I find the patch >> useful for fake NUMA emulation on my simple PowerPC machine. I've tested it >> on a non-numa box with the following arguments >> >> numa=fake=1G >> numa=fake=1G,2G >> name=fake=1G,512M,2G >> numa=fake=1500M,2800M mem=3500M >> numa=fake=1G mem=512M >> numa=fake=1G mem=1G > > So this doesn't appear to allow one to assign cpus to fake nodes? Do > all cpus just get assigned to node 0 with numa=fake? > Yes, they all appear on node 0. We could have tweaks to distribute CPU's as well. > A different approach that occurs to me is to use kexec with a doctored > device tree (i.e. with the ibm,associativity properties modified to > reflect your desired topology). Perhaps a little bit obscure, but it > seems more flexible. > That would be interesting, but it always means that we need to run kexec, which might involve two boots. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
Arnd Bergmann wrote: > On Friday 07 December 2007, Balbir Singh wrote: >> Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake >> NUMA nodes can be specified using the following command line option >> >> numa=fake= >> >> node range is of the format ,,... > > Excellent idea! I'd love to have this in RHEL5u1, because that would make > that distro boot on certain machines that have more memory than is supported > without an iommu driver. The problem we have is that when you simply > say mem=1G but all of the first gigabyte is on the first node, you end > up with a memoryless node, which is not supported. > > Unfortunately, it comes too late for me now, as all new distros already boot > on Cell machines that need an IOMMU. Very interesting use case! I am sure there are others were fake NUMA nodes can be applied. I just listed one other in another email, apart from using it for playing around with NUMA like machines. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
Kumar Gala wrote: > > On Dec 7, 2007, at 4:12 PM, Balbir Singh wrote: > >> Kumar Gala wrote: >>> >>> On Dec 7, 2007, at 3:35 PM, Balbir Singh wrote: >>> Olof Johansson wrote: > Hi, > > On Sat, Dec 08, 2007 at 02:44:25AM +0530, Balbir Singh wrote: > >> Comments are as always welcome! > > Care to explain what this is useful for? (Not saying it's a stupid > idea, > just wondering what the reason for doing it is). > In my case, I use it to test parts of my memory controller patches on an emulated NUMA machine. I plan to use it to test out page migration across nodes. >>> >>> Can you explain that further. I'm still not clear on why this is >>> useful. >>> >>> - k >> >> Sure. In my case I need to emulate NUMA nodes to do some NUMA specific >> testing. The memory controller I've written has some interesting data >> structures like per node, per zone LRU lists. To be able to test those >> features on a non-numa box is a problem, since we get just the default >> node. > > Maybe I'm missing something, what do you mean by memory controller > you've written? (I'm use to the term 'memory controller' meaning the > actual RAM control). > Ah! that explains the disconnect. If you look at the latest -mm tree. We have a memory controller under control groups, we use it to control how much memory a group of process can access at a time. >> To be able to test the memory controller under NUMA, I use fake NUMA >> nodes. x86-64 has a similar feature, the code I have here is the >> simplest I could come up with for PowerPC. >> >> I just thought of another very interesting use case, it can be used to >> split up the zone's lru lock which is highly contended. > > - k -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
On Dec 7, 2007, at 4:12 PM, Balbir Singh wrote: > Kumar Gala wrote: >> >> On Dec 7, 2007, at 3:35 PM, Balbir Singh wrote: >> >>> Olof Johansson wrote: Hi, On Sat, Dec 08, 2007 at 02:44:25AM +0530, Balbir Singh wrote: > Comments are as always welcome! Care to explain what this is useful for? (Not saying it's a stupid idea, just wondering what the reason for doing it is). >>> >>> In my case, I use it to test parts of my memory controller patches >>> on an >>> emulated NUMA machine. I plan to use it to test out page migration >>> across nodes. >> >> Can you explain that further. I'm still not clear on why this is >> useful. >> >> - k > > Sure. In my case I need to emulate NUMA nodes to do some NUMA specific > testing. The memory controller I've written has some interesting data > structures like per node, per zone LRU lists. To be able to test those > features on a non-numa box is a problem, since we get just the > default node. Maybe I'm missing something, what do you mean by memory controller you've written? (I'm use to the term 'memory controller' meaning the actual RAM control). > To be able to test the memory controller under NUMA, I use fake NUMA > nodes. x86-64 has a similar feature, the code I have here is the > simplest I could come up with for PowerPC. > > I just thought of another very interesting use case, it can be used to > split up the zone's lru lock which is highly contended. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
Kumar Gala wrote: > > On Dec 7, 2007, at 3:35 PM, Balbir Singh wrote: > >> Olof Johansson wrote: >>> Hi, >>> >>> On Sat, Dec 08, 2007 at 02:44:25AM +0530, Balbir Singh wrote: >>> Comments are as always welcome! >>> >>> Care to explain what this is useful for? (Not saying it's a stupid idea, >>> just wondering what the reason for doing it is). >>> >> >> In my case, I use it to test parts of my memory controller patches on an >> emulated NUMA machine. I plan to use it to test out page migration >> across nodes. > > Can you explain that further. I'm still not clear on why this is useful. > > - k Sure. In my case I need to emulate NUMA nodes to do some NUMA specific testing. The memory controller I've written has some interesting data structures like per node, per zone LRU lists. To be able to test those features on a non-numa box is a problem, since we get just the default node. To be able to test the memory controller under NUMA, I use fake NUMA nodes. x86-64 has a similar feature, the code I have here is the simplest I could come up with for PowerPC. I just thought of another very interesting use case, it can be used to split up the zone's lru lock which is highly contended. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
Arnd Bergmann wrote:
> On Friday 07 December 2007, Balbir Singh wrote:
>> Balbir Singh wrote:
>>> Geert Uytterhoeven wrote:
On Sat, 8 Dec 2007, Balbir Singh wrote:
> + if (strstr(p, "fake="))
> + cmdline = p + 5;/* 5 is faster than strlen("fake=") */
Really? My gcc is smart enough to replace the `strlen("fake=")' by 5, even
without -O.
>>> Thanks for pointing that out, but I am surprised that a compiler would
>>> interpret library routines like strlen.
>>>
>> I just tested it and it turns out that you are right. I'll go hunt to
>> see where gcc gets its magic powers from.
>>
>
> Even if it wasn't: Why the heck would you want to optimize this? The function
> is run _once_ at boot time and the object code gets thrown away afterwards!
>
> Arnd <><
Cause, I see no downside of doing it. The strlen of fake= is fixed.
But having said that, I am not a purist about the approach, I just want
cmdline to point after "fake="
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
On Friday 07 December 2007, Balbir Singh wrote: > Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake > NUMA nodes can be specified using the following command line option > > numa=fake= > > node range is of the format ,,... Excellent idea! I'd love to have this in RHEL5u1, because that would make that distro boot on certain machines that have more memory than is supported without an iommu driver. The problem we have is that when you simply say mem=1G but all of the first gigabyte is on the first node, you end up with a memoryless node, which is not supported. Unfortunately, it comes too late for me now, as all new distros already boot on Cell machines that need an IOMMU. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
On Friday 07 December 2007, Balbir Singh wrote:
> Balbir Singh wrote:
> > Geert Uytterhoeven wrote:
> >> On Sat, 8 Dec 2007, Balbir Singh wrote:
> >>> + if (strstr(p, "fake="))
> >>> + cmdline = p + 5;/* 5 is faster than strlen("fake=") */
> >> Really? My gcc is smart enough to replace the `strlen("fake=")' by 5, even
> >> without -O.
> >>
> >
> > Thanks for pointing that out, but I am surprised that a compiler would
> > interpret library routines like strlen.
> >
>
> I just tested it and it turns out that you are right. I'll go hunt to
> see where gcc gets its magic powers from.
>
Even if it wasn't: Why the heck would you want to optimize this? The function
is run _once_ at boot time and the object code gets thrown away afterwards!
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
On Dec 7, 2007, at 3:35 PM, Balbir Singh wrote: > Olof Johansson wrote: >> Hi, >> >> On Sat, Dec 08, 2007 at 02:44:25AM +0530, Balbir Singh wrote: >> >>> Comments are as always welcome! >> >> Care to explain what this is useful for? (Not saying it's a stupid >> idea, >> just wondering what the reason for doing it is). >> > > In my case, I use it to test parts of my memory controller patches > on an > emulated NUMA machine. I plan to use it to test out page migration > across nodes. Can you explain that further. I'm still not clear on why this is useful. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
Balbir Singh wrote:
> Geert Uytterhoeven wrote:
>> On Sat, 8 Dec 2007, Balbir Singh wrote:
>>> + if (strstr(p, "fake="))
>>> + cmdline = p + 5;/* 5 is faster than strlen("fake=") */
>> Really? My gcc is smart enough to replace the `strlen("fake=")' by 5, even
>> without -O.
>>
>
> Thanks for pointing that out, but I am surprised that a compiler would
> interpret library routines like strlen.
>
I just tested it and it turns out that you are right. I'll go hunt to
see where gcc gets its magic powers from.
>> With kind regards,
>>
>> Geert Uytterhoeven
>> Software Architect
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
Geert Uytterhoeven wrote:
> On Sat, 8 Dec 2007, Balbir Singh wrote:
>> +if (strstr(p, "fake="))
>> +cmdline = p + 5;/* 5 is faster than strlen("fake=") */
>
> Really? My gcc is smart enough to replace the `strlen("fake=")' by 5, even
> without -O.
>
Thanks for pointing that out, but I am surprised that a compiler would
interpret library routines like strlen.
> With kind regards,
>
> Geert Uytterhoeven
> Software Architect
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
Olof Johansson wrote:
> Hi,
>
> On Sat, Dec 08, 2007 at 02:44:25AM +0530, Balbir Singh wrote:
>
>> Comments are as always welcome!
>
> Care to explain what this is useful for? (Not saying it's a stupid idea,
> just wondering what the reason for doing it is).
>
In my case, I use it to test parts of my memory controller patches on an
emulated NUMA machine. I plan to use it to test out page migration
across nodes.
>> diff -puN arch/powerpc/mm/numa.c~ppc-fake-numa-easy arch/powerpc/mm/numa.c
>> --- linux-2.6.24-rc4-mm1/arch/powerpc/mm/numa.c~ppc-fake-numa-easy
>> 2007-12-07 21:25:55.0 +0530
>> +++ linux-2.6.24-rc4-mm1-balbir/arch/powerpc/mm/numa.c 2007-12-08
>> 02:36:02.0 +0530
>> @@ -24,6 +24,8 @@
>>
>> static int numa_enabled = 1;
>>
>> +char *cmdline __initdata;
>> +
>
> Looks like this should be static.
>
Yes, good catch!
>> @@ -702,6 +744,9 @@ static int __init early_numa(char *p)
>> if (strstr(p, "debug"))
>> numa_debug = 1;
>>
>> +if (strstr(p, "fake="))
>> +cmdline = p + 5;/* 5 is faster than strlen("fake=") */
>
> This doesn't look right.
>
> You check if it contains fake=, not if it starts with it. So if someone
> did: "numa=foo,fake=bar", or even "numa=debug,fake=", things wouldn't
> work right.
>
Yes, you are right. I merely followed the strstr convention already
present, which as you righly point out is wrong. I suspect I need to do
something like
p = strstr(p, "fake=")
if (p)
cmdline = p + 5;
This would still allow us to do things like
numa=foo,fake=bar but the memparse() utility would fail at fake=bar
^^^
or even
numa=debug,fake=1G
I suspect that this should be good enough for a command line option.
>
> -Olof
--
Thanks,
Balbir Singh
Linux Technology Center
IBM, ISTL
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
On Sat, 8 Dec 2007, Balbir Singh wrote:
> + if (strstr(p, "fake="))
> + cmdline = p + 5;/* 5 is faster than strlen("fake=") */
Really? My gcc is smart enough to replace the `strlen("fake=")' by 5, even
without -O.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fake NUMA emulation for PowerPC
Hi,
On Sat, Dec 08, 2007 at 02:44:25AM +0530, Balbir Singh wrote:
> Comments are as always welcome!
Care to explain what this is useful for? (Not saying it's a stupid idea,
just wondering what the reason for doing it is).
> diff -puN arch/powerpc/mm/numa.c~ppc-fake-numa-easy arch/powerpc/mm/numa.c
> --- linux-2.6.24-rc4-mm1/arch/powerpc/mm/numa.c~ppc-fake-numa-easy
> 2007-12-07 21:25:55.0 +0530
> +++ linux-2.6.24-rc4-mm1-balbir/arch/powerpc/mm/numa.c2007-12-08
> 02:36:02.0 +0530
> @@ -24,6 +24,8 @@
>
> static int numa_enabled = 1;
>
> +char *cmdline __initdata;
> +
Looks like this should be static.
> @@ -702,6 +744,9 @@ static int __init early_numa(char *p)
> if (strstr(p, "debug"))
> numa_debug = 1;
>
> + if (strstr(p, "fake="))
> + cmdline = p + 5;/* 5 is faster than strlen("fake=") */
This doesn't look right.
You check if it contains fake=, not if it starts with it. So if someone
did: "numa=foo,fake=bar", or even "numa=debug,fake=", things wouldn't
work right.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fake NUMA emulation for PowerPC
Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
NUMA nodes can be specified using the following command line option
numa=fake=
node range is of the format ,,...
Each of the rangeX parameters is passed using memparse(). I find the patch
useful for fake NUMA emulation on my simple PowerPC machine. I've tested it
on a non-numa box with the following arguments
numa=fake=1G
numa=fake=1G,2G
name=fake=1G,512M,2G
numa=fake=1500M,2800M mem=3500M
numa=fake=1G mem=512M
numa=fake=1G mem=1G
This patch applies on top of 2.6.24-rc4.
All though I've tried my best to handle some of the architecture specific
details of PowerPC, I might have overlooked something obvious, like the usage
of an API or some architecture tweaks. The patch depends on CONFIG_NUMA and
I decided against creating a separate config option for fake NUMA to keep
the code simple.
Comments are as always welcome!
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
arch/powerpc/mm/numa.c | 55 -
1 file changed, 50 insertions(+), 5 deletions(-)
diff -puN arch/powerpc/mm/numa.c~ppc-fake-numa-easy arch/powerpc/mm/numa.c
--- linux-2.6.24-rc4-mm1/arch/powerpc/mm/numa.c~ppc-fake-numa-easy
2007-12-07 21:25:55.0 +0530
+++ linux-2.6.24-rc4-mm1-balbir/arch/powerpc/mm/numa.c 2007-12-08
02:36:02.0 +0530
@@ -24,6 +24,8 @@
static int numa_enabled = 1;
+char *cmdline __initdata;
+
static int numa_debug;
#define dbg(args...) if (numa_debug) { printk(KERN_INFO args); }
@@ -39,6 +41,40 @@ static bootmem_data_t __initdata plat_no
static int min_common_depth;
static int n_mem_addr_cells, n_mem_size_cells;
+static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
+ unsigned int *nid)
+{
+ unsigned long long mem;
+ char *p = cmdline;
+ static unsigned int fake_nid = 0;
+ static unsigned long long curr_boundary = 0;
+
+ *nid = fake_nid;
+ mem = memparse(p, &p);
+ if (!mem)
+ return 0;
+
+ if (mem < curr_boundary)
+ return 0;
+
+ curr_boundary = mem;
+
+ if ((end_pfn << PAGE_SHIFT) > mem) {
+ /*
+* Skip commas and spaces
+*/
+ while (*p == ',' || *p == ' ' || *p == '\t')
+ p++;
+
+ cmdline = p;
+ fake_nid++;
+ *nid = fake_nid;
+ dbg("created new fake_node with id %d\n", fake_nid);
+ return 1;
+ }
+ return 0;
+}
+
static void __cpuinit map_cpu_to_node(int cpu, int node)
{
numa_cpu_lookup_table[cpu] = node;
@@ -344,12 +380,14 @@ static void __init parse_drconf_memory(s
if (nid == 0x || nid >= MAX_NUMNODES)
nid = default_nid;
}
- node_set_online(nid);
size = numa_enforce_memory_limit(start, lmb_size);
if (!size)
continue;
+ fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
+ node_set_online(nid);
+
add_active_range(nid, start >> PAGE_SHIFT,
(start >> PAGE_SHIFT) + (size >> PAGE_SHIFT));
}
@@ -429,7 +467,6 @@ new_range:
nid = of_node_to_nid_single(memory);
if (nid < 0)
nid = default_nid;
- node_set_online(nid);
if (!(size = numa_enforce_memory_limit(start, size))) {
if (--ranges)
@@ -438,6 +475,9 @@ new_range:
continue;
}
+ fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
+ node_set_online(nid);
+
add_active_range(nid, start >> PAGE_SHIFT,
(start >> PAGE_SHIFT) + (size >> PAGE_SHIFT));
@@ -461,7 +501,7 @@ static void __init setup_nonnuma(void)
unsigned long top_of_ram = lmb_end_of_DRAM();
unsigned long total_ram = lmb_phys_mem_size();
unsigned long start_pfn, end_pfn;
- unsigned int i;
+ unsigned int i, nid = 0;
printk(KERN_DEBUG "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
top_of_ram, total_ram);
@@ -471,9 +511,11 @@ static void __init setup_nonnuma(void)
for (i = 0; i < lmb.memory.cnt; ++i) {
start_pfn = lmb.memory.region[i].base >> PAGE_SHIFT;
end_pfn = start_pfn + lmb_size_pages(&lmb.memory, i);
- add_active_range(0, start_pfn, end_pfn);
+
+ fake_numa_create_new_node(end_pfn, &nid);
+ add_active_range(nid, start_pfn, end_pfn);
+ node_set_online(nid);
}
- node_set_online(0);
}
void __init dump_numa_cpu_topology(void)
@@ -702,6 +744,9 @@ static int __init early_numa(char *p)
Re: [PATCH 1/11] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
Benjamin Herrenschmidt wrote: > From: Stefan Roese <[EMAIL PROTECTED]> > > This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver. > These PHY chips are used on PowerPC 440EPx boards. > The PHY code is based on the previous work by Stefan Roese <[EMAIL PROTECTED]> > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > > drivers/net/ibm_newemac/phy.c | 39 +++ > 1 file changed, 39 insertions(+) applied 1-11 #upstream-fixes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
Add support for UART serial ports using a Freescale QUICC Engine
(found on some MPC83xx and MPC85xx SOCs).
Updated booting-without-of.txt to define new properties for a QE UART node,
and a new node definition that describes uploaded QE firmware.
Because of a silicon bug in some QE-enabled SOCs (e.g. 8323 and 8360), a new
microcode is required. This microcode implements UART via a work-around,
hence it's called "Soft-UART". This driver can use the QE firmware upload
feature to upload the correct microcode to the QE.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
Made selection of Soft-UART dynamic. Updated to reflect changes in
prerequisite patches. Added support for 'firmware' node in device tree.
This patch is for Kumar's for-2.6.25 branch, and it applies on top of my
previous patches, "qe: add ability to upload QE firmware" and
"qe: add function qe_clock_source()".
Documentation/powerpc/booting-without-of.txt |9 +-
arch/powerpc/boot/dts/mpc832x_mds.dts| 49 +
arch/powerpc/sysdev/qe_lib/Kconfig |2 +-
arch/powerpc/sysdev/qe_lib/ucc_slow.c| 10 +-
drivers/serial/Kconfig | 10 +
drivers/serial/Makefile |1 +
drivers/serial/ucc_uart.c| 1498 ++
7 files changed, 1576 insertions(+), 3 deletions(-)
create mode 100644 drivers/serial/ucc_uart.c
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 00fd333..9de0a97 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1616,7 +1616,7 @@ platforms are moved over to use the flattened-device-tree
model.
Required properties:
- device_type : should be "network", "hldc", "uart", "transparent"
-"bisync" or "atm".
+ "bisync", "atm", or "serial".
- compatible : could be "ucc_geth" or "fsl_atm" and so on.
- model : should be "UCC".
- device-id : the ucc number(1-8), corresponding to UCCx in UM.
@@ -1629,6 +1629,13 @@ platforms are moved over to use the
flattened-device-tree model.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
- pio-handle : The phandle for the Parallel I/O port configuration.
+ - port-number : for UART drivers, the port number to use, between 0 and 3.
+ This usually corresponds to the /dev/ttyQE device, e.g. <0> = /dev/ttyQE0.
+ The port number is added to the minor number of the device. Unlike the
+ CPM UART driver, the port-number is required for the QE UART driver.
+ - soft-uart : for UART drivers, if specified this means the QE UART device
+ driver should use "Soft-UART" mode, which is needed on some SOCs that have
+ broken UART hardware. Soft-UART is provided via a microcode upload.
- rx-clock-name: the UCC receive clock source
"none": clock source is disabled
"brg1" through "brg16": clock source is BRG1-BRG16, respectively
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts
b/arch/powerpc/boot/dts/mpc832x_mds.dts
index fe54489..f6dd945 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -7,6 +7,18 @@
* 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.
+
+ * To enable external serial I/O on a Freescale MPC 8323 SYS/MDS board, do
+ * this:
+ *
+ * 1) On chip U61, lift (disconnect) pins 21 (TXD) and 22 (RXD) from the board.
+ * 2) Solder a wire from U61-21 to P19A-23. P19 is a grid of pins on the board
+ *next to the serial ports.
+ * 3) Solder a wire from U61-22 to P19K-22.
+ *
+ * Note that there's a typo in the schematic. The board labels the last column
+ * of pins "P19K", but in the schematic, that column is called "P19J". So if
+ * you're going by the schematic, the pin is called "P19J-K22".
*/
/ {
@@ -159,6 +171,23 @@
1 1e 1 0 1 0/* TX_EN */
1 1f 2 0 1 0>;/* CRS */
};
+ pio5: [EMAIL PROTECTED] {
+ pio-map = <
+ /*
+*open has
+* port pin dir drain sel irq
+*/
+ 201 020 /* TxD5 */
+ 282 020 /* RxD5 */
+
+ 2 1d2 000 /* CTS5 */
+ 2 1f1 020 /* RTS5 */
+
+ 2 182 000 /* CD */
+
+ >;
+ };
+
Re: [PATCH] IB/ehca: Serialize HCA-related hCalls on POWER5
Roland Dreier <[EMAIL PROTECTED]> wrote on 06.12.2007 19:27:09: > > > + ehca_lock_hcalls = !(cur_cpu_spec->cpu_user_features > > > +& PPC_FEATURE_ARCH_2_05); > > > We already talked about this yesterday, but I still feel that checking the > > instruction set of the CPU should not be used to determine whether a > > specific device driver implementation is used int hypervisor. > > I had the same reaction... is testing cpu_user_features really the > best way to detect this issue? I concur it's not nice, but it was the only feasible method we could find without adding a "bug fixed" feature flag to the partition<->firmware interface. The firmware version reported in the OFDT is not a reliable enough source, and even if it were, it would require a lot of string parsing and matching against tables. We're taking this to the firmware architects at the moment, but they're not very fond of the idea of reporting the absence of bugs through capability flags, as this could quickly lead to the exhaustion of flag bits. We'll let the discussion stew for a bit, but if we don't get this flag, we'll have to resort to the CPU features. > I'll hold off applying this for a few days so you guys can decide the > best thing to do. We'll definitely get some fix into 2.6.24 but we > have time to make a good decision. Right. > > Regarding the performance problem, have you checked whether converting all > > your spin_lock_irqsave to spin_lock/spin_lock_irq improves your performance > > on the older machines? Maybe it's already fast enough that way. > > It does seem that the only places that the hcall_lock is taken also > use msleep, so they must always be in process context. So you can > safely just use spin_lock(), right? As Arnd said, there are hCalls that will never return H_LONG_BUSY_*, such as H_QUERY_PORT and chums, so they will never sleep. The surrounding functions, though, are not prepared to be called from interrupt context (GFP_KERNEL comes to mind), so I agree that a simple spin_lock() will suffice. Thanks, Arnd, for pointing this out. We'll keep you guys posted on the feature flag discussion. Until then, have a nice weekend! Joachim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] qe: add ability to upload QE firmware
Define the layout of a binary blob that contains a QE firmware and instructions
on how to upload it. Add function qe_upload_firmware() to parse the blob
and perform the actual upload. Fully define 'struct rsp' in immap_qe.h to
include the actual RISC Special Registers. Added description of a new
QE firmware node to booting-without-of.txt.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
Fixed mismatch between code and documentation in booting-without-of.txt.
This patch is for Kumar's for-2.6.25 branch. This code is necessary for
my QE UART driver.
Documentation/powerpc/00-INDEX |3 +
Documentation/powerpc/booting-without-of.txt | 33 +++-
Documentation/powerpc/qe_firmware.txt| 295 ++
arch/powerpc/platforms/Kconfig |1 +
arch/powerpc/sysdev/qe_lib/qe.c | 240 +
include/asm-powerpc/immap_qe.h | 34 +++-
include/asm-powerpc/qe.h | 61 ++
7 files changed, 663 insertions(+), 4 deletions(-)
create mode 100644 Documentation/powerpc/qe_firmware.txt
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 94a3c57..3be84aa 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -28,3 +28,6 @@ sound.txt
- info on sound support under Linux/PPC
zImage_layout.txt
- info on the kernel images for Linux/PPC
+qe_firmware.txt
+ - describes the layout of firmware binaries for the Freescale QUICC
+ Engine and the code that parses and uploads the microcode therein.
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..6546b81 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -52,7 +52,10 @@ Table of Contents
i) Freescale QUICC Engine module (QE)
j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
- l) Xilinx IP cores
+ l) Freescale Communications Processor Module
+ m) Chipselect/Local Bus
+ n) 4xx/Axon EMAC ethernet nodes
+ o) Xilinx IP cores
VII - Specifying interrupt information for devices
1) interrupts property
@@ -1772,6 +1775,32 @@ platforms are moved over to use the
flattened-device-tree model.
};
};
+ viii) Uploaded QE firmware
+
+If a new firwmare has been uploaded to the QE (usually by the
+boot loader), then a 'firmware' child node should be added to the QE
+node. This node provides information on the uploaded firmware that
+device drivers may need.
+
+Required properties:
+- id: The string name of the firmware. This is taken from the 'id'
+ member of the qe_firmware structure of the uploaded firmware.
+ Device drivers can search this string to determine if the
+ firmware they want is already present.
+- extended_modes: The Extended Modes bitfield, taken from the
+ firmware binary. It is a 64-bit number represented
+ as an array of two 32-bit numbers.
+- virtual_traps: The virtual traps, taken from the firmware binary.
+ It is an array of 16 32-bit numbers.
+
+Example:
+
+ firmware {
+ id = "Soft-UART";
+ extended_modes = <0 0>;
+ virtual_traps = <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ }
+
j) CFI or JEDEC memory-mapped NOR flash
Flash chips (Memory Technology Devices) are often used for solid state
@@ -2254,7 +2283,7 @@ platforms are moved over to use the flattened-device-tree
model.
available.
For Axon: 0x012a
- l) Xilinx IP cores
+ o) Xilinx IP cores
The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
diff --git a/Documentation/powerpc/qe_firmware.txt
b/Documentation/powerpc/qe_firmware.txt
new file mode 100644
index 000..8962664
--- /dev/null
+++ b/Documentation/powerpc/qe_firmware.txt
@@ -0,0 +1,295 @@
+ Freescale QUICC Engine Firmware Uploading
+ -
+
+(c) 2007 Timur Tabi ,
+Freescale Semiconductor
+
+Table of Contents
+=
+
+ I - Software License for Firmware
+
+ II - Microcode Availability
+
+ III - Description and Terminology
+
+ IV - Microcode Programming Details
+
+ V - Firmware Structure Layout
+
+ VI - Sample Code for Creating Firmware Files
+
+Revision Information
+
+
+November 30, 2007: Rev 1.0 - Initial version
+
+I - Software License for Firmware
+=
+
+Each firmware file comes with its own software license. For information on
+the particular license, pl
Re: [RFC][POWERPC] Provide a way to protect 4k subpages when using 64k pages
On Friday 07 December 2007, Paul Mackerras wrote: > I have re-purposed the ioperm system call for this. The old ioperm > system call never did anything (except return an ENOSYS error) and in > fact never could have actually been useful for anything on the PowerPC > architecture, so nothing ever used it. Couldn't there be a program that relies on ioperm to return -ENOSYS on powerpc in order to fall back on some other method of I/O access? The risk of actually breaking something is certainly low, but I think you can never be sure here, so why not use a new syscall number? Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 0/10] powerpc: PCI updates & merges
On Thursday 06 December 2007, Benjamin Herrenschmidt wrote: > This serie of patches converts the 32 bits PCI code to use the generic > pci_assign_unassigned_resources() instead of its own assignment code > which was unable to deal with unassigned PCI<->PCI bridges among > other issues. > > It then merges the resource fixup and allocation code between 32 and > 64 bits (mostly making 64 bits use the 32 bits code with a few fixups), > hopefully fixing the longstanding issue that not setting pci_probe_only > on ppc64 would generally not work. > > We also add flags to control the behaviour of the PCI code, such as > letting some platforms force a full re-assignment (similar to what > pci-auto used to provide in arch/ppc) and remove a whole bunch of > hackish code that is made obsolete by that change. > > 32 bits platforms with 64 bits resources support will also need my > separate patch to fix the generic setup-bus.c for that situation. > > Note that the patch that updates 4xx platforms to enable full resource > assignments applied on top of my 4xx series for which I'll post a new > version soon. You can apply the other ones and ignore this one if you > want to test on some other platform without the other patch serie. No problems on Katmai (440SPe) and Kilauea (405EX) so far. Apart from DEBUG still enabled in patch 8/10 as Olof already pointed out. Tested-by: Stefan Roese <[EMAIL PROTECTED]> Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IB/ehca: Serialize HCA-related hCalls on POWER5
On Thursday 06 December 2007, Roland Dreier wrote: > > Regarding the performance problem, have you checked whether converting all > > your spin_lock_irqsave to spin_lock/spin_lock_irq improves your performance > > on the older machines? Maybe it's already fast enough that way. > > It does seem that the only places that the hcall_lock is taken also > use msleep, so they must always be in process context. So you can > safely just use spin_lock(), right? I think it needs some more inspection. The msleep in there is only called for hcalls that return H_IS_LONG_BUSY(). In theory, you can call ehca_plpar_hcall_norets() from inside an interrupt handler if the hcall in question never returns long busy. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] [POWERPC] 4xx: Add Kilauea PCIe support to dts and Kconfig
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/kilauea.dts | 82
arch/powerpc/platforms/40x/Kconfig |1 +
2 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index 1ffb6e3..0a3fbfa 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -254,5 +254,87 @@
has-new-stacr-staopc;
};
};
+
+ PCIE0: [EMAIL PROTECTED] {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-405ex", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = ; /* Registers */
+ dcr-reg = <040 020>;
+ sdr-base = <400>;
+
+ /* Outbound ranges, one memory and one IO,
+* later cannot be changed
+*/
+ ranges = <0200 0 8000 9000 0 0800
+ 0100 0 e000 0 0001>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <4200 0 0 0 0 8000>;
+
+ /* This drives busses 0x00 to 0x0f */
+ bus-range = <00 0f>;
+
+ /* Legacy interrupts (note the weird polarity, the
bridge seems
+* to invert PCIe legacy interrupts).
+* We are de-swizzling here because the numbers are
actually for
+* port of the root complex virtual P2P bridge. But I
want
+* to avoid putting a node for it in the tree, so the
numbers
+* below are basically de-swizzled numbers.
+* The real slot is on idsel 0, so the swizzling is 1:1
+*/
+ interrupt-map-mask = < 0 0 7>;
+ interrupt-map = <
+ 0 0 1 &UIC2 0 4 /* swizzled int A */
+ 0 0 2 &UIC2 1 4 /* swizzled int B */
+ 0 0 3 &UIC2 2 4 /* swizzled int C */
+ 0 0 4 &UIC2 3 4 /* swizzled int D */>;
+ };
+
+ PCIE1: [EMAIL PROTECTED] {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-405ex", "ibm,plb-pciex";
+ primary;
+ port = <1>; /* port number */
+ reg = ; /* Registers */
+ dcr-reg = <060 020>;
+ sdr-base = <440>;
+
+ /* Outbound ranges, one memory and one IO,
+* later cannot be changed
+*/
+ ranges = <0200 0 8000 9800 0 0800
+ 0100 0 e001 0 0001>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <4200 0 0 0 0 8000>;
+
+ /* This drives busses 0x10 to 0x1f */
+ bus-range = <10 1f>;
+
+ /* Legacy interrupts (note the weird polarity, the
bridge seems
+* to invert PCIe legacy interrupts).
+* We are de-swizzling here because the numbers are
actually for
+* port of the root complex virtual P2P bridge. But I
want
+* to avoid putting a node for it in the tree, so the
numbers
+* below are basically de-swizzled numbers.
+* The real slot is on idsel 0, so the swizzling is 1:1
+*/
+ interrupt-map-mask = < 0 0 7>;
+ interrupt-map = <
+ 0 0 1 &UIC2 b 4 /* swizzled int A */
+ 0 0 2 &UIC2 c 4 /* swizzled int B */
+ 0 0 3 &UIC2 d 4 /* swizzled int C */
+ 0 0 4 &UIC2 e 4 /* swizzled int D */>;
+ };
};
};
diff --git a/arch/powerpc/platforms/40x/Kconfig
b/arch/powerpc/platforms/40x/Kconfig
index 5d2ca0d..0ac1b0b 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -27,6 +27,7 @@ config KILAUEA
depends on 40x
default n
select 4
[PATCH 3/3] [POWERPC] 4xx: Enable PCIe support in the Kilauea defconfig file
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> --- arch/powerpc/configs/kilauea_defconfig | 755 ++-- 1 files changed, 225 insertions(+), 530 deletions(-) diff --git a/arch/powerpc/configs/kilauea_defconfig b/arch/powerpc/configs/kilauea_defconfig index 1340871..40bc442 100644 --- a/arch/powerpc/configs/kilauea_defconfig +++ b/arch/powerpc/configs/kilauea_defconfig @@ -1,22 +1,53 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.23 -# Sat Dec 1 07:52:20 2007 +# Linux kernel version: 2.6.24-rc3 +# Fri Dec 7 09:14:11 2007 # +# CONFIG_PPC64 is not set + +# +# Processor support +# +# CONFIG_6xx is not set +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +CONFIG_40x=y +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_4xx=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_NOT_COHERENT_CACHE=y +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y -# CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y -CONFIG_PPC32=y +CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y -CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +CONFIG_PPC_DCR_NATIVE=y +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_PPC_DCR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # @@ -34,9 +65,14 @@ CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +# CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y @@ -45,22 +81,24 @@ CONFIG_INITRAMFS_SOURCE="" CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y -# CONFIG_KALLSYMS is not set -# CONFIG_HOTPLUG is not set +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_ALL=y +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y CONFIG_PRINTK=y -# CONFIG_LOGBUFFER is not set CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y -# CONFIG_EPOLL is not set +CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y -CONFIG_SLAB=y -# CONFIG_SLUB is not set +CONFIG_SLUB_DEBUG=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set @@ -72,7 +110,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y -# CONFIG_LBD is not set +CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set @@ -89,60 +127,42 @@ CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" +CONFIG_PPC4xx_PCI_EXPRESS=y # -# Processor +# Platform support # -# CONFIG_6xx is not set -CONFIG_40x=y -# CONFIG_44x is not set -# CONFIG_8xx is not set -# CONFIG_E200 is not set -# CONFIG_E500 is not set -CONFIG_PPC_DCR_NATIVE=y -CONFIG_PPC_DCR=y -# CONFIG_MATH_EMULATION is not set -# CONFIG_KEXEC is not set -# CONFIG_CPU_FREQ is not set -CONFIG_4xx=y -CONFIG_WANT_EARLY_SERIAL=y - -# -# IBM 4xx options -# -# CONFIG_ACADIA is not set -# CONFIG_BUBINGA is not set -# CONFIG_CPCI405 is not set +# CONFIG_PPC_MPC52xx is not set +# CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set # CONFIG_EP405 is not set CONFIG_KILAUEA=y -# CONFIG_MAKALU is not set -# CONFIG_PPChameleonEVB is not set -# CONFIG_REDWOOD_5 is not set -# CONFIG_REDWOOD_6 is not set -# CONFIG_SC3 is not set -# CONFIG_SYCAMORE is not set -# CONFIG_TAIHU is not set # CONFIG_WALNUT is not set -# CONFIG_XILINX_ML300 is not set -# CONFIG_XILINX_ML403 is not set -CONFIG_IBM405_ERR77=y -CONFIG_IBM405_ERR51=y -CONFIG_IBM_OCP=y -CONFIG_IBM_EMAC4=y -CONFIG_IBM_EMAC4V4=y +# CONFIG_XILINX_VIRTEX_GENERIC_BOARD is not set CONFIG_405EX=y -# CONFIG_PPC4xx_DMA is not set -CONFIG_PPC_GEN550=y -CONFIG_UART0_TTYS0=y -# CONFIG_UART0_TTYS1 is not set -CONFIG_NOT_COHERENT_CACHE=y +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is no
[PATCH 2/3] [POWERPC] 4xx: Set ibpre for 405EX in 4xx PCIe driver
This patch sets the ibpre flag (Inbound Presence) for the 405EX in the 4xx PCIe driver. Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/ppc4xx_pci.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c index 29fa095..bd85a40 100644 --- a/arch/powerpc/sysdev/ppc4xx_pci.c +++ b/arch/powerpc/sysdev/ppc4xx_pci.c @@ -842,6 +842,8 @@ static int ppc405ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port) dcr_write(port->dcrs, DCRO_PEGPL_CFG, 0x1000); /* guarded on */ + port->has_ibpre = 1; + return 0; } -- 1.5.3.7.949.g2221a6 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix swapper_pg_dir size when CONFIG_PTE_64BIT=y on FSL_BOOKE
Thanks Kumar for this much better patch! Cedric Kumar Gala wrote: > The size of swapper_pg_dir is 8k instead of 4k when using 64-bit PTEs > (CONFIG_PTE_64BIT). > > This was reported by Cedric Hombourger <[EMAIL PROTECTED]> > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > --- > > This is in my git tree, branch for-2.6.24 and I'll forward on a pull > request to Paul & Linus for it. > > arch/powerpc/kernel/asm-offsets.c|3 +-- > arch/powerpc/kernel/head_32.S|2 +- > arch/powerpc/kernel/head_40x.S |2 +- > arch/powerpc/kernel/head_44x.S |2 +- > arch/powerpc/kernel/head_fsl_booke.S |2 +- > include/asm-powerpc/pgtable-ppc32.h |5 + > 6 files changed, 10 insertions(+), 6 deletions(-) > > diff --git a/arch/powerpc/kernel/asm-offsets.c > b/arch/powerpc/kernel/asm-offsets.c > index d67bcd8..ed083fe 100644 > --- a/arch/powerpc/kernel/asm-offsets.c > +++ b/arch/powerpc/kernel/asm-offsets.c > @@ -326,8 +326,7 @@ int main(void) > DEFINE(VMALLOC_START_VSID, KERNEL_VSID(VMALLOC_START)); > #endif > > -#ifdef CONFIG_PPC64 > DEFINE(PGD_TABLE_SIZE, PGD_TABLE_SIZE); > -#endif > + > return 0; > } > diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S > index a5b13ae..0f4fac5 100644 > --- a/arch/powerpc/kernel/head_32.S > +++ b/arch/powerpc/kernel/head_32.S > @@ -1311,7 +1311,7 @@ empty_zero_page: > > .globl swapper_pg_dir > swapper_pg_dir: > - .space 4096 > + .space PGD_TABLE_SIZE > > .globl intercept_table > intercept_table: > diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S > index cfefc2d..8552e67 100644 > --- a/arch/powerpc/kernel/head_40x.S > +++ b/arch/powerpc/kernel/head_40x.S > @@ -994,7 +994,7 @@ empty_zero_page: > .space 4096 > .globl swapper_pg_dir > swapper_pg_dir: > - .space 4096 > + .space PGD_TABLE_SIZE > > > /* Stack for handling critical exceptions from kernel mode */ > diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S > index 409db61..56aba84 100644 > --- a/arch/powerpc/kernel/head_44x.S > +++ b/arch/powerpc/kernel/head_44x.S > @@ -722,7 +722,7 @@ empty_zero_page: > */ > .globl swapper_pg_dir > swapper_pg_dir: > - .space 8192 > + .space PGD_TABLE_SIZE > > /* Reserved 4k for the critical exception stack & 4k for the machine > * check stack per CPU for kernel mode exceptions */ > diff --git a/arch/powerpc/kernel/head_fsl_booke.S > b/arch/powerpc/kernel/head_fsl_booke.S > index 4b98227..7aecb39 100644 > --- a/arch/powerpc/kernel/head_fsl_booke.S > +++ b/arch/powerpc/kernel/head_fsl_booke.S > @@ -1035,7 +1035,7 @@ empty_zero_page: > .space 4096 > .globl swapper_pg_dir > swapper_pg_dir: > - .space 4096 > + .space PGD_TABLE_SIZE > > /* Reserved 4k for the critical exception stack & 4k for the machine > * check stack per CPU for kernel mode exceptions */ > diff --git a/include/asm-powerpc/pgtable-ppc32.h > b/include/asm-powerpc/pgtable-ppc32.h > index fea2d8f..d1332bb 100644 > --- a/include/asm-powerpc/pgtable-ppc32.h > +++ b/include/asm-powerpc/pgtable-ppc32.h > @@ -86,6 +86,11 @@ extern int icache_44x_need_flush; > * entries per page directory level: our page-table tree is two-level, so > * we don't really have any PMD directory. > */ > +#ifndef __ASSEMBLY__ > +#define PTE_TABLE_SIZE (sizeof(pte_t) << PTE_SHIFT) > +#define PGD_TABLE_SIZE (sizeof(pgd_t) << (32 - PGDIR_SHIFT)) > +#endif /* __ASSEMBLY__ */ > + > #define PTRS_PER_PTE (1 << PTE_SHIFT) > #define PTRS_PER_PMD 1 > #define PTRS_PER_PGD (1 << (32 - PGDIR_SHIFT)) > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
