* Re: [PATCH] Fix fake numa on ppc
From: Benjamin Herrenschmidt @ 2009-09-02 5:52 UTC (permalink / raw)
To: balbir; +Cc: linuxppc-dev, Ankita Garg, linux-kernel
In-Reply-To: <20090901142729.GA5022@balbir.in.ibm.com>
On Tue, 2009-09-01 at 19:57 +0530, Balbir Singh wrote:
> >
> > Heres the updated patch:
> >
> > Signed-off-by: Ankita Garg <ankita@in.ibm.com>
The thread is too messy. Please Ankita can you re-submit in proper
form (ie. subject, cset, signed-off & patch) please ?
In general, don't mix reply to comments and new patch submission,
or patchwork gets really confuse. Post a new name, with something
like [PATCH v2] <name of the patch> in the subject.
Thanks.
Cheers,
Ben.
> > Index: linux-2.6.31-rc5/arch/powerpc/mm/numa.c
> > ===================================================================
> > --- linux-2.6.31-rc5.orig/arch/powerpc/mm/numa.c
> > +++ linux-2.6.31-rc5/arch/powerpc/mm/numa.c
> > @@ -26,6 +26,13 @@
> > #include <asm/smp.h>
> >
> > static int numa_enabled = 1;
> > +static int fake_enabled = 1;
> > +
> > +/*
> > + * The array maps a real numa node to the first fake node that gets
> > + * created on it
> > + */
> > +int fake_numa_node_mapping[MAX_NUMNODES];
> >
> > static char *cmdline __initdata;
> >
> > @@ -49,14 +56,29 @@ static int __cpuinit fake_numa_create_ne
> > unsigned long long mem;
> > char *p = cmdline;
> > static unsigned int fake_nid;
> > + static unsigned int prev_nid = 0;
> > static unsigned long long curr_boundary;
> >
> > /*
> > * Modify node id, iff we started creating NUMA nodes
> > * We want to continue from where we left of the last time
> > */
> > - if (fake_nid)
> > + if (fake_nid) {
> > + /*
> > + * Moved over to the next real numa node, increment fake
> > + * node number and store the mapping of the real node to
> > + * the fake node
> > + */
> > + if (prev_nid != *nid) {
> > + fake_nid++;
> > + fake_numa_node_mapping[*nid] = fake_nid;
> > + prev_nid = *nid;
> > + *nid = fake_nid;
> > + return 0;
> > + }
> > *nid = fake_nid;
> > + }
> > +
> > /*
> > * In case there are no more arguments to parse, the
> > * node_id should be the same as the last fake node id
> > @@ -440,7 +462,7 @@ static int of_drconf_to_nid_single(struc
> > */
> > static int __cpuinit numa_setup_cpu(unsigned long lcpu)
> > {
> > - int nid = 0;
> > + int nid = 0, new_nid;
> > struct device_node *cpu = of_get_cpu_node(lcpu, NULL);
> >
> > if (!cpu) {
> > @@ -450,8 +472,15 @@ static int __cpuinit numa_setup_cpu(unsi
> >
> > nid = of_node_to_nid_single(cpu);
> >
> > + if (fake_enabled && nid) {
> > + new_nid = fake_numa_node_mapping[nid];
> > + if (new_nid > 0)
> > + nid = new_nid;
> > + }
> > +
> > if (nid < 0 || !node_online(nid))
> > nid = any_online_node(NODE_MASK_ALL);
> > +
> > out:
> > map_cpu_to_node(lcpu, nid);
> >
> > @@ -1005,8 +1034,12 @@ static int __init early_numa(char *p)
> > numa_debug = 1;
> >
> > p = strstr(p, "fake=");
> > - if (p)
> > + if (p) {
> > cmdline = p + strlen("fake=");
> > + if (numa_enabled) {
> > + fake_enabled = 1;
> > + }
> > + }
> >
> > return 0;
> > }
> >
>
>
> Looks good to me
>
>
> Reviewed-by: Balbir Singh <balbir@linux.vnet.ibm.com>
>
>
>
^ permalink raw reply
* Re: [PATCH] Fix fake numa on ppc
From: Benjamin Herrenschmidt @ 2009-09-02 5:53 UTC (permalink / raw)
To: Ankita Garg; +Cc: linuxppc-dev, linux-kernel, Balbir Singh
In-Reply-To: <20090902053653.GA3806@in.ibm.com>
On Wed, 2009-09-02 at 11:06 +0530, Ankita Garg wrote:
> > Oh! interesting.. cpuless nodes :) I think we need to fix this in the
> > longer run and distribute cpus between fake numa nodes of a real node
> > using some acceptable heuristic.
> >
>
> True. Presently this is broken on both x86 and ppc systems. It would be
> interesting to find a way to map, for example, 4 cpus to >4 number of
> fake nodes created from a single real numa node!
Since I'm pretty sure there could be CPU less nodes just like there
could be memory-less nodes, it would be good if fake numa could
simulate them too :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-booke: Use HW PTE format if CONFIG_PTE_64BIT
From: Kumar Gala @ 2009-09-02 6:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1251870487.14675.416.camel@pasglop>
On Sep 2, 2009, at 12:48 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2009-09-01 at 20:48 -0500, Kumar Gala wrote:
>> Switch to using the Power ISA defined PTE format when we have a 64-
>> bit
>> PTE. This makes the code handling between fsl-booke and book3e-64
>> similiar for TLB faults.
>>
>> Additionally this lets use take advantage of the page size
>> encodings and
>> full permissions that the HW PTE defines.
>>
>> Also defined _PMD_PRESENT, _PMD_PRESENT_MASK, and _PMD_BAD since the
>> 32-bit ppc arch code expects them.
>
> No immediate problem with the patch, though I can't test it so I
> assume you did :-)
Yes, I tested it.
> Is this 2.6.32 material ? I'm going to stick it into my test branch
> for now regardless.
Yes this is .32 material
- k
^ permalink raw reply
* Re: [PATCH] Fix fake numa on ppc
From: David Rientjes @ 2009-09-02 5:58 UTC (permalink / raw)
To: Ankita Garg; +Cc: linuxppc-dev, linux-kernel, Balbir Singh
In-Reply-To: <20090902053653.GA3806@in.ibm.com>
On Wed, 2 Sep 2009, Ankita Garg wrote:
> > > With the patch,
> > >
> > > # cat /proc/cmdline
> > > root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
> > > # cat /sys/devices/system/node/node0/cpulist
> > > 0-3
> > > # cat /sys/devices/system/node/node1/cpulist
> > >
> >
> > Oh! interesting.. cpuless nodes :) I think we need to fix this in the
> > longer run and distribute cpus between fake numa nodes of a real node
> > using some acceptable heuristic.
> >
>
> True. Presently this is broken on both x86 and ppc systems. It would be
> interesting to find a way to map, for example, 4 cpus to >4 number of
> fake nodes created from a single real numa node!
>
We've done it for years on x86_64. It's quite trivial to map all fake
nodes within a physical node to the cpus to which they have affinity both
via node_to_cpumask_map() and cpu_to_node_map(). There should be no
kernel space dependencies on a cpu appearing in only a single node's
cpumask and if you map each fake node to its physical node's pxm, you can
index into the slit and generate local NUMA distances amongst fake nodes.
So if you map the apicids and pxms appropriately depending on the
physical topology of the machine, that is the only emulation necessary on
x86_64 for the page allocator zonelist ordering, task migration, etc. (If
you use CONFIG_SLAB, you'll need to avoid the exponential growth of alien
caches, but that's an implementation detail and isn't really within the
scope of numa=fake's purpose to modify.)
^ permalink raw reply
* [PATCH v2] Fix fake numa on ppc
From: Ankita Garg @ 2009-09-02 6:09 UTC (permalink / raw)
To: LKML, linuxppc-dev, Benjamin Herrenschmidt, Balbir Singh; +Cc: ankita
Hi,
Below is a patch to fix a couple of issues with fake numa node creation
on ppc:
1) Presently, fake nodes could be created such that real numa node
boundaries are not respected. So a node could have lmbs that belong to
different real nodes.
2) The cpu association is broken. On a JS22 blade for example, which is
a 2-node numa machine, I get the following:
# cat /proc/cmdline
root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
# cat /sys/devices/system/node/node0/cpulist
0-3
# cat /sys/devices/system/node/node1/cpulist
4-7
# cat /sys/devices/system/node/node4/cpulist
#
So, though the cpus 4-7 should have been associated with node4, they
still belong to node1. The patch works by recording a real numa node
boundary and incrementing the fake node count. At the same time, a
mapping is stored from the real numa node to the first fake node that
gets created on it.
Tested the patch with the following commandlines:
numa=fake=2G,4G,6G,8G,10G,12G,14G,16G
numa=fake=3G,6G,10G,16G
numa=fake=4G
numa=fake=
For testing if the fake nodes respect the real node boundaries, I added
some debug printks in the node creation path. Without the patch, for the
commandline numa=fake=2G,4G,6G,8G,10G,12G,14G,16G, this is what I got:
fake id: 1 nid: 0
fake id: 1 nid: 0
...
fake id: 2 nid: 0
fake id: 2 nid: 0
...
fake id: 2 nid: 0
created new fake_node with id 3
fake id: 3 nid: 0
fake id: 3 nid: 0
...
fake id: 3 nid: 0
fake id: 3 nid: 0
fake id: 3 nid: 1
fake id: 3 nid: 1
...
created new fake_node with id 4
fake id: 4 nid: 1
fake id: 4 nid: 1
...
and so on. So, fake node 3 encompasses real node 0 & 1. Also,
# cat /sys/devices/system/node/node3/meminfo
Node 0 MemTotal: 2097152 kB
...
# # cat /sys/devices/system/node/node4/meminfo
Node 0 MemTotal: 2097152 kB
...
With the patch, I get:
fake id: 1 nid: 0
fake id: 1 nid: 0
...
fake id: 2 nid: 0
fake id: 2 nid: 0
...
fake id: 2 nid: 0
created new fake_node with id 3
fake id: 3 nid: 0
fake id: 3 nid: 0
...
fake id: 3 nid: 0
fake id: 3 nid: 0
created new fake_node with id 4
fake id: 4 nid: 1
fake id: 4 nid: 1
...
and so on. With the patch, the fake node sizes are slightly different
from that specified by the user.
# cat /sys/devices/system/node/node3/meminfo
Node 3 MemTotal: 1638400 kB
...
# cat /sys/devices/system/node/node4/meminfo
Node 4 MemTotal: 458752 kB
...
CPU association was tested as mentioned in the previous mail:
Without the patch,
# cat /proc/cmdline
root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
# cat /sys/devices/system/node/node0/cpulist
0-3
# cat /sys/devices/system/node/node1/cpulist
4-7
# cat /sys/devices/system/node/node4/cpulist
#
With the patch,
# cat /proc/cmdline
root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
# cat /sys/devices/system/node/node0/cpulist
0-3
# cat /sys/devices/system/node/node1/cpulist
# cat /sys/devices/system/node/node4/cpulist
4-7
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Reviewed-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Index: linux-2.6.31-rc5/arch/powerpc/mm/numa.c
===================================================================
--- linux-2.6.31-rc5.orig/arch/powerpc/mm/numa.c
+++ linux-2.6.31-rc5/arch/powerpc/mm/numa.c
@@ -26,6 +26,13 @@
#include <asm/smp.h>
static int numa_enabled = 1;
+static int fake_enabled = 1;
+
+/*
+ * The array maps a real numa node to the first fake node that gets
+ * created on it
+ */
+int fake_numa_node_mapping[MAX_NUMNODES];
static char *cmdline __initdata;
@@ -49,14 +56,29 @@ static int __cpuinit fake_numa_create_ne
unsigned long long mem;
char *p = cmdline;
static unsigned int fake_nid;
+ static unsigned int prev_nid = 0;
static unsigned long long curr_boundary;
/*
* Modify node id, iff we started creating NUMA nodes
* We want to continue from where we left of the last time
*/
- if (fake_nid)
+ if (fake_nid) {
+ /*
+ * Moved over to the next real numa node, increment fake
+ * node number and store the mapping of the real node to
+ * the fake node
+ */
+ if (prev_nid != *nid) {
+ fake_nid++;
+ fake_numa_node_mapping[*nid] = fake_nid;
+ prev_nid = *nid;
+ *nid = fake_nid;
+ return 0;
+ }
*nid = fake_nid;
+ }
+
/*
* In case there are no more arguments to parse, the
* node_id should be the same as the last fake node id
@@ -440,7 +462,7 @@ static int of_drconf_to_nid_single(struc
*/
static int __cpuinit numa_setup_cpu(unsigned long lcpu)
{
- int nid = 0;
+ int nid = 0, new_nid;
struct device_node *cpu = of_get_cpu_node(lcpu, NULL);
if (!cpu) {
@@ -450,8 +472,15 @@ static int __cpuinit numa_setup_cpu(unsi
nid = of_node_to_nid_single(cpu);
+ if (fake_enabled && nid) {
+ new_nid = fake_numa_node_mapping[nid];
+ if (new_nid > 0)
+ nid = new_nid;
+ }
+
if (nid < 0 || !node_online(nid))
nid = any_online_node(NODE_MASK_ALL);
+
out:
map_cpu_to_node(lcpu, nid);
@@ -1005,8 +1034,12 @@ static int __init early_numa(char *p)
numa_debug = 1;
p = strstr(p, "fake=");
- if (p)
+ if (p) {
cmdline = p + strlen("fake=");
+ if (numa_enabled) {
+ fake_enabled = 1;
+ }
+ }
return 0;
}
--
Regards,
Ankita Garg (ankita@in.ibm.com)
Linux Technology Center
IBM India Systems & Technology Labs,
Bangalore, India
^ permalink raw reply
* Re: [PATCH] Fix fake numa on ppc
From: David Rientjes @ 2009-09-02 6:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ankita Garg, linux-kernel, Balbir Singh
In-Reply-To: <1251870823.14675.420.camel@pasglop>
On Wed, 2 Sep 2009, Benjamin Herrenschmidt wrote:
> Since I'm pretty sure there could be CPU less nodes just like there
> could be memory-less nodes, it would be good if fake numa could
> simulate them too :-)
>
You don't want to simulate cpu less nodes since they do have affinity to
ranges of memory, you want to map each fake node to a cpumask including
all cpus with affinity to its memory, map each cpu to one fake node (with
memory) that it has physical affinity to, and then give all fake nodes
local NUMA distance to those on the same physical node. Memoryless nodes
take care of themselves since they rely purely on node_distance(), so the
index into the slit for all fake nodes to those without memory will be the
same.
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Fix to handle slb resize across migration
From: Benjamin Herrenschmidt @ 2009-09-02 6:21 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev
In-Reply-To: <200908282206.n7SM6UK1011114@d03av01.boulder.ibm.com>
On Fri, 2009-08-28 at 17:06 -0500, Brian King wrote:
> The SLB can change sizes across a live migration, which was not
> being handled, resulting in possible machine crashes during
> migration if migrating to a machine which has a smaller max SLB
> size than the source machine. Fix this by first reducing the
> SLB size to the minimum possible value, which is 32, prior to
> migration. Then during the device tree update which occurs after
> migration, we make the call to ensure the SLB gets updated. Also
> add the slb_size to the lparcfg output so that the migration
> tools can check to make sure the kernel has this capability
> before allowing migration in scenarios where the SLB size will change.
The patch causes a build error on 32-bit hash in rtas.c due to this:
> diff -puN arch/powerpc/kernel/rtas.c~powerpc_slb_resize arch/powerpc/kernel/rtas.c
> --- linux-2.6/arch/powerpc/kernel/rtas.c~powerpc_slb_resize 2009-08-21 16:14:41.000000000 -0500
> +++ linux-2.6-bjking1/arch/powerpc/kernel/rtas.c 2009-08-21 16:14:41.000000000 -0500
> @@ -39,6 +39,7 @@
> #include <asm/smp.h>
> #include <asm/atomic.h>
> #include <asm/time.h>
> +#include <asm/mmu-hash64.h>
This should just be asm/mmu.h
This is true of all occurences, ie, mmu-hash64.h isn't meant to be
directly included (though it causes no breakage in the other cases)
I'm going to commit a fixed version to powerpc-next today, you may want
to update the version you are sending to distros.
Cheers,
Ben.
^ permalink raw reply
* why do we need reloc_offset ??
From: HongWoo Lee @ 2009-09-02 6:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]
Hi everyone~
In ther linux kernel code, I found the reloc_offset.
{{{
// file : misc.S
/* Returns (address we are running at) - (address we were linked at)
* for use before the text and data are mapped to KERNELBASE.
*/
_GLOBAL(reloc_offset)
}}}
I couldn't understand the comment saying "Returns (address we are running
at) - (address we were linked at)".
For now, I'm studying each instruction.
And below is best comment I can explain for each instruction.
_GLOBAL(reloc_offset)
mflr r0 // move from link register, save the
return address
bl 1f // bl 1f
1: mflr r3 // move from link register, r3 is just
return address pointing itself
LOAD_REG_IMMEDIATE(r4,1b) // get the 1b address, r4 is the
address
subf r3,r4,r3 // r3 = r3 – r4
mtlr r0 // restore return address
blr
After this, I still don't know why "r3-r4" is the offset.
And what does it mean ??
Please explain to me the reason why we need reloc_offset and the code.
Or let me know any helpful reference about this.
Thank in advance.
HongWoo.
[-- Attachment #2: Type: text/html, Size: 1324 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Fix fake numa on ppc
From: David Rientjes @ 2009-09-02 6:37 UTC (permalink / raw)
To: Ankita Garg; +Cc: linuxppc-dev, LKML
In-Reply-To: <20090902060911.GA5728@in.ibm.com>
On Wed, 2 Sep 2009, Ankita Garg wrote:
> Hi,
>
> Below is a patch to fix a couple of issues with fake numa node creation
> on ppc:
>
> 1) Presently, fake nodes could be created such that real numa node
> boundaries are not respected. So a node could have lmbs that belong to
> different real nodes.
>
On x86_64, we can use numa=off to completely disable NUMA so that all
memory and all cpus are mapped to a single node 0. That's an extreme
example of the above and is totally permissible.
> 2) The cpu association is broken. On a JS22 blade for example, which is
> a 2-node numa machine, I get the following:
>
> # cat /proc/cmdline
> root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
> # cat /sys/devices/system/node/node0/cpulist
> 0-3
> # cat /sys/devices/system/node/node1/cpulist
> 4-7
> # cat /sys/devices/system/node/node4/cpulist
>
> #
>
This doesn't show what the true NUMA topology of the machine is, could you
please post the output of
$ cat /sys/devices/system/node/node*/cpulist
$ cat /sys/devices/system/node/node*/distance
$ ls -d /sys/devices/system/node/node*/cpu[0-8]
from a normal boot without any numa=fake?
> So, though the cpus 4-7 should have been associated with node4, they
> still belong to node1. The patch works by recording a real numa node
> boundary and incrementing the fake node count. At the same time, a
> mapping is stored from the real numa node to the first fake node that
> gets created on it.
>
If there are multiple fake nodes on a real physical node, all cpus in that
node should appear in the cpulist for each fake node for which it has
local distance.
^ permalink raw reply
* Re: [PATCH v2] Fix fake numa on ppc
From: Ankita Garg @ 2009-09-02 8:03 UTC (permalink / raw)
To: David Rientjes; +Cc: linuxppc-dev, LKML
In-Reply-To: <alpine.DEB.1.00.0909012326290.31814@chino.kir.corp.google.com>
Hi David,
On Tue, Sep 01, 2009 at 11:37:05PM -0700, David Rientjes wrote:
> On Wed, 2 Sep 2009, Ankita Garg wrote:
>
> > Hi,
> >
> > Below is a patch to fix a couple of issues with fake numa node creation
> > on ppc:
> >
> > 1) Presently, fake nodes could be created such that real numa node
> > boundaries are not respected. So a node could have lmbs that belong to
> > different real nodes.
> >
>
> On x86_64, we can use numa=off to completely disable NUMA so that all
> memory and all cpus are mapped to a single node 0. That's an extreme
> example of the above and is totally permissible.
>
> > 2) The cpu association is broken. On a JS22 blade for example, which is
> > a 2-node numa machine, I get the following:
> >
> > # cat /proc/cmdline
> > root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
> > # cat /sys/devices/system/node/node0/cpulist
> > 0-3
> > # cat /sys/devices/system/node/node1/cpulist
> > 4-7
> > # cat /sys/devices/system/node/node4/cpulist
> >
> > #
> >
>
> This doesn't show what the true NUMA topology of the machine is, could you
> please post the output of
>
> $ cat /sys/devices/system/node/node*/cpulist
> $ cat /sys/devices/system/node/node*/distance
> $ ls -d /sys/devices/system/node/node*/cpu[0-8]
>
> from a normal boot without any numa=fake?
>
Heres the output as requested by you:
# ls /sys/devices/system/node/
has_cpu has_normal_memory node0 node1 online possible
# cat /sys/devices/system/node/node*/cpulist
0-3
4-7
# cat /sys/devices/system/node/node*/distance
10 20
20 10
# ls -d /sys/devices/system/node/node*/cpu[0-8]
/sys/devices/system/node/node0/cpu0 /sys/devices/system/node/node0/cpu3
/sys/devices/system/node/node1/cpu6
/sys/devices/system/node/node0/cpu1 /sys/devices/system/node/node1/cpu4
/sys/devices/system/node/node1/cpu7
/sys/devices/system/node/node0/cpu2 /sys/devices/system/node/node1/cpu5
> > So, though the cpus 4-7 should have been associated with node4, they
> > still belong to node1. The patch works by recording a real numa node
> > boundary and incrementing the fake node count. At the same time, a
> > mapping is stored from the real numa node to the first fake node that
> > gets created on it.
> >
>
> If there are multiple fake nodes on a real physical node, all cpus in that
> node should appear in the cpulist for each fake node for which it has
> local distance.
Currently, the behavior of fake numa is not so on x86 as well? Below is
a sample output from a single node x86 system booted with numa=fake=8:
# cat node0/cpulist
# cat node1/cpulist
...
# cat node6/cpulist
# cat node7/cpulist
0-7
Presently, just fixing the cpu association issue with ppc, as explained
in my previous mail.
--
Regards,
Ankita Garg (ankita@in.ibm.com)
Linux Technology Center
IBM India Systems & Technology Labs,
Bangalore, India
^ permalink raw reply
* Re: [PATCH] Fix fake numa on ppc
From: Benjamin Herrenschmidt @ 2009-09-02 8:51 UTC (permalink / raw)
To: David Rientjes; +Cc: linuxppc-dev, Ankita Garg, linux-kernel, Balbir Singh
In-Reply-To: <alpine.DEB.1.00.0909012259050.26930@chino.kir.corp.google.com>
On Tue, 2009-09-01 at 23:03 -0700, David Rientjes wrote:
> On Wed, 2 Sep 2009, Benjamin Herrenschmidt wrote:
>
> > Since I'm pretty sure there could be CPU less nodes just like there
> > could be memory-less nodes, it would be good if fake numa could
> > simulate them too :-)
> >
>
> You don't want to simulate cpu less nodes since they do have affinity to
> ranges of memory, you want to map each fake node to a cpumask including
> all cpus with affinity to its memory, map each cpu to one fake node (with
> memory) that it has physical affinity to, and then give all fake nodes
> local NUMA distance to those on the same physical node. Memoryless nodes
> take care of themselves since they rely purely on node_distance(), so the
> index into the slit for all fake nodes to those without memory will be the
> same.
Ok, makes sense, thanks.
Cheers,
Ben.
^ permalink raw reply
* mpc512x USB non-working after kexec
From: Sebastian Andrzej Siewior @ 2009-09-02 9:44 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
Hi John,
on my mpc512x custom board I have non-working USB after the kexec
syscall. I've traced it down to the ehci_turn_off_all_ports() which is
called from within ehci_shutdown(). If I omit ehci_turn_off_all_ports()
it works fine. The content of the portstatus register is the same after
the setup prior the usb-stack takes over so I don't see any difference
here.
Do you see such a behaviour on your board? Unfortunately I don't have
any other "official"/FSL board where I could cross-check and say it is
the HW.
Sebastian
^ permalink raw reply
* [RFC] net/fs_enet: send a reset request to the PHY on init
From: Sebastian Andrzej Siewior @ 2009-09-02 11:04 UTC (permalink / raw)
To: Pantelis Antoniou, Vitaly Bordug; +Cc: linuxppc-dev, netdev
Usually u-boot sends a phy request in its network init routine. An uboot
without network support doesn't do it and I endup without working
network. I still can switch between 10/100Mbit (according to the LED on
the hub and phy registers) but I can't send or receive any data.
At this point I'm not sure if the PowerON Reset takes the PHY a few
nsecs too early out of reset or if this reset is required and everyone
relies on U-boot performing this reset.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
This is done on a custom mpc512x board. Unfortunately I don't have other
boards to check. The PHY is a AMD Am79C874, phylib uses the generic one.
drivers/net/fs_enet/fs_enet-main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index ee15402..a3c962b 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -823,7 +823,8 @@ static int fs_init_phy(struct net_device *dev)
}
fep->phydev = phydev;
-
+ phy_write(phydev, MII_BMCR, BMCR_RESET);
+ udelay(1);
return 0;
}
--
1.6.4.GIT
^ permalink raw reply related
* Re: [RFC][POWERPC] WDT: added support for the WDT Chain driver.
From: Detlev Zundel @ 2009-09-02 11:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <20090902004928.132974c9@vitb-lp>
Hello Vitaly,
> From: Heiko Schocher <hs@denx.de>
>
> [POWERPC] WDT: added support for the WDT Chain driver.
>
> This new driver implements a character device with major number 10
> and minor number 130. It is a software abstraction of the hardware
> watchdog with two different APIs. While the driver periodically
> triggers the hardware watchdog, the software can setup independent
> timeout periods.
>
> More info in Documentation/watchdog/wdt_chain.txt
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
> This code was (and is) originally residing in DENX public git repo. I
> think it would be useful upstream, to prevent reinventing the same
> thing.
Thanks a lot for taking an interest in this piece of code. I would
suggest however that you coordinate with Heiko as he has worked some
more on this driver in the meantime. This new code however is not in
our repository. We should start the RFC discussion with current code.
For the casual reader this means, don't invest time into reviewing this
but wait for a cleaned up version instead.
Thanks
Detlev
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* RE: [PATCH] [V3] net: add Xilinx emac lite device driver
From: John Linn @ 2009-09-02 13:33 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Michal Simek, netdev, Sadanand Mutyala, linuxppc-dev, jgarzik,
davem, John Williams
In-Reply-To: <20090820094914.46f1db9c@nehalam>
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Thursday, August 20, 2009 5:49 PM
> To: John Linn
> Cc: netdev@vger.kernel.org; linuxppc-dev@ozlabs.org;
davem@davemloft.net; jgarzik@pobox.com; John
> Linn; grant.likely@secretlab.ca; Josh Boyer; John Williams; Michal
Simek; Sadanand Mutyala
> Subject: Re: [PATCH] [V3] net: add Xilinx emac lite device driver
> =
> On Thu, 20 Aug 2009 03:49:51 -0600
> John Linn <john.linn@xilinx.com> wrote:
> =
> > +/**
> > + * xemaclite_ioctl - Perform IO Control operations on the network
device
> > + * @dev: Pointer to the network device
> > + * @rq: Pointer to the interface request structure
> > + * @cmd: IOCTL command
> > + *
> > + * The only IOCTL operation supported by this function is setting
the MAC
> > + * address. An error is reported if any other operations are
requested.
> > + *
> > + * Return: 0 to indicate success, or a negative error for failure.
> > + */
> > +static int xemaclite_ioctl(struct net_device *dev, struct ifreq
*rq, int cmd)
> > +{
> > + struct net_local *lp =3D (struct net_local *) netdev_priv(dev);
> > + struct hw_addr_data *hw_addr =3D (struct hw_addr_data *)
&rq->ifr_hwaddr;
> > +
> > + switch (cmd) {
> > + case SIOCETHTOOL:
> > + return -EIO;
> > +
> > + case SIOCSIFHWADDR:
> > + dev_err(&lp->ndev->dev, "SIOCSIFHWADDR\n");
> > +
> > + /* Copy MAC address in from user space */
> > + copy_from_user((void __force *) dev->dev_addr,
> > + (void __user __force *) hw_addr,
> > + IFHWADDRLEN);
> > + xemaclite_set_mac_address(lp, dev->dev_addr);
> > + break;
> > + default:
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + return 0;
> > +}
> =
> Do you really need this? I doubt the SIOCSIFHWADDR even reaches
driver!
> =
> The normal call path for setting hardware address is:
> dev_ifsioc
> dev_set_mac_address
> ops->ndo_set_mac_address -->
> =
> The driver should be:
> 1. defining new code to do ndo_set_mac_address
> 2. remove existing xmaclite_ioctl - all ioctl's handled by upper
layers
> =
> FYI - the only ioctl's that make it to network device ndo_ioctl
> are listed in dev_ifsioc
> SIOCDEVPRIVATE ... SIOCDEVPRIVATE + 15
> SIOCBOND*
> SIOCMII*
> SIOCBR*
> SIOCHWTSTAMP
> SIOCWANDEV
> =
> =
We agree and will be updating the driver for this change. Sorry about
the delay as I was on vacation.
Thanks,
John
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH v2] Fix fake numa on ppc
From: David Rientjes @ 2009-09-02 19:36 UTC (permalink / raw)
To: Ankita Garg; +Cc: linuxppc-dev, LKML
In-Reply-To: <20090902080346.GB3806@in.ibm.com>
On Wed, 2 Sep 2009, Ankita Garg wrote:
> Currently, the behavior of fake numa is not so on x86 as well? Below is
> a sample output from a single node x86 system booted with numa=fake=8:
>
> # cat node0/cpulist
>
> # cat node1/cpulist
>
> ...
> # cat node6/cpulist
>
> # cat node7/cpulist
> 0-7
>
> Presently, just fixing the cpu association issue with ppc, as explained
> in my previous mail.
>
Right, I'm proposing an alternate mapping scheme (which we've used for
years) for both platforms such that a cpu is bound (and is set in
cpumask_of_node()) to each fake node with which it has physical affinity.
That is the only way for zonelist ordering in node order, task migration
from offlined cpus, correct sched domains, etc. I can propose a patchset
for x86_64 to do exactly this if there aren't any objections and I hope
you'll help do ppc.
^ permalink raw reply
* Re: [PATCH v2 0/2] cpu: pseries: Offline state framework.
From: Pavel Machek @ 2009-09-02 20:02 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel, linuxppc-dev,
Darrick J. Wong
In-Reply-To: <1251869611.7547.38.camel@twins>
On Wed 2009-09-02 07:33:31, Peter Zijlstra wrote:
> On Fri, 2009-08-28 at 15:30 +0530, Gautham R Shenoy wrote:
> > Hi,
> >
> > This is the version 2 of the patch series to provide a cpu-offline framework
> > that enables the administrators choose the state the offline CPU must be put
> > into when multiple such states are exposed by the underlying architecture.
> >
> > Version 1 of the Patch can be found here:
> > http://lkml.org/lkml/2009/8/6/236
> >
> > The patch-series exposes the following sysfs tunables to
> > allow the system-adminstrator to choose the state of a CPU:
> >
> > To query the available hotplug states, one needs to read the sysfs tunable:
> > /sys/devices/system/cpu/cpu<number>/available_hotplug_states
> > To query or set the current state, on needs to read/write the sysfs tunable:
> > /sys/devices/system/cpu/cpu<number>/current_states
> >
> > The patchset ensures that the writes to the "current_state" sysfs file are
> > serialized against the writes to the "online" file.
> >
> > This patchset also contains the offline state driver implemented for
> > pSeries. For pSeries, we define three available_hotplug_states. They are:
> >
> > online: The processor is online.
> >
> > deallocate: This is the the default behaviour when the cpu is offlined
> > even in the absense of this driver. The CPU would call make an
> > rtas_stop_self() call and hand over the CPU back to the resource pool,
> > thereby effectively deallocating that vCPU from the LPAR.
> > NOTE: This would result in a configuration change to the LPAR
> > which is visible to the outside world.
> >
> > deactivate: This cedes the vCPU to the hypervisor which
> > in turn can put the vCPU time to the best use.
> > NOTE: This option DOES NOT result in a configuration change
> > and the vCPU would be still entitled to the LPAR to which it earlier
> > belong to.
> >
> > Awaiting your feedback.
>
> I'm still thinking this is a bad idea.
>
> The OS should only know about online/offline.
>
> Use the hypervisor interface to deal with the cpu once its offline.
>
> That is, I think this interface you propose is a layering violation.
Agreed. Plus having interface like 'go to this state during offliine'
then 'go offline' is strange/stupid. For hypervisor case, you might
want to change 'state' of cpu that is already offline.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v2] Fix fake numa on ppc
From: Balbir Singh @ 2009-09-02 19:56 UTC (permalink / raw)
To: David Rientjes; +Cc: linuxppc-dev, Ankita Garg, LKML
In-Reply-To: <alpine.DEB.1.00.0909021226160.10279@chino.kir.corp.google.com>
On Thu, Sep 3, 2009 at 1:06 AM, David Rientjes<rientjes@google.com> wrote:
> On Wed, 2 Sep 2009, Ankita Garg wrote:
>
>> Currently, the behavior of fake numa is not so on x86 as well? Below is
>> a sample output from a single node x86 system booted with numa=3Dfake=3D=
8:
>>
>> # cat node0/cpulist
>>
>> # cat node1/cpulist
>>
>> ...
>> # cat node6/cpulist
>>
>> # cat node7/cpulist
>> 0-7
>>
>> Presently, just fixing the cpu association issue with ppc, as explained
>> in my previous mail.
>>
>
> Right, I'm proposing an alternate mapping scheme (which we've used for
> years) for both platforms such that a cpu is bound (and is set in
> cpumask_of_node()) to each fake node with which it has physical affinity.
> That is the only way for zonelist ordering in node order, task migration
> from offlined cpus, correct sched domains, etc. =A0I can propose a patchs=
et
> for x86_64 to do exactly this if there aren't any objections and I hope
> you'll help do ppc.
Sounds interesting, I'd definitely be interested in seeing your
proposal, but I would think of that as additional development on top
of this patch
Balbir Singh.
^ permalink raw reply
* Re: [PATCH v2] Fix fake numa on ppc
From: David Rientjes @ 2009-09-02 20:09 UTC (permalink / raw)
To: Balbir Singh; +Cc: linuxppc-dev, Ankita Garg, LKML
In-Reply-To: <661de9470909021256i569261bxbe1523d8e37b5b14@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1023 bytes --]
On Thu, 3 Sep 2009, Balbir Singh wrote:
> > Right, I'm proposing an alternate mapping scheme (which we've used for
> > years) for both platforms such that a cpu is bound (and is set in
> > cpumask_of_node()) to each fake node with which it has physical affinity.
> > That is the only way for zonelist ordering in node order, task migration
> > from offlined cpus, correct sched domains, etc. I can propose a patchset
> > for x86_64 to do exactly this if there aren't any objections and I hope
> > you'll help do ppc.
>
> Sounds interesting, I'd definitely be interested in seeing your
> proposal, but I would think of that as additional development on top
> of this patch
>
Absolutely. I'm not familiar with numa=fake on ppc, but if cpus are being
bound to nodes with which they don't have affinity, it definitely warrants
a fix such as this (although the initial value for fake_enabled looks
wrong and fake_numa_node_mapping[] can be __cpuinitdata). I'll cc you,
Ben, and Ankita on the x86_64 patches. Thanks.
^ permalink raw reply
* Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Adam Zilkie @ 2009-09-02 21:22 UTC (permalink / raw)
To: chris.pringle, linuxppc-dev; +Cc: Tom Burns, Andrea Zypchen
Hi Chris,
I am having a problem similar to what you described in this discussion.
We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with compiles
arch/ppc/kernel/head_44x.c (quite different
from /arch/powerpc/kernel/head_32.S). I would like to apply your
backporting patch to this architecture. Any help would be appreciated.
Regards,
Adam
--
Adam Zilkie
Software Designer,
International Datacasting Corp.
This message and the documents attached hereto are intended only for the addressee and may contain privileged or confidential information. Any unauthorized disclosure is strictly prohibited. If you have received this message in error, please notify us immediately so that we may correct our internal records. Please then delete the original message. Thank you.
^ permalink raw reply
* [PATCH 1/2] powerpc: rename get_dma_direct_offset get_dma_offset
From: Becky Bruce @ 2009-09-02 22:23 UTC (permalink / raw)
To: linuxppc-dev
The former is no longer really accurate with the swiotlb case now
a possibility. I also move it into dma-mapping.h - it no longer
needs to be in dma.c, and there are about to be some more accessors
that should all end up in the same place.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
arch/powerpc/include/asm/dma-mapping.h | 13 ++++++++++---
arch/powerpc/kernel/dma.c | 15 ++++-----------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index cb2ca41..eef4db1 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -26,7 +26,6 @@ extern void *dma_direct_alloc_coherent(struct device *dev, size_t size,
extern void dma_direct_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle);
-extern unsigned long get_dma_direct_offset(struct device *dev);
#ifdef CONFIG_NOT_COHERENT_CACHE
/*
@@ -90,6 +89,14 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
dev->archdata.dma_ops = ops;
}
+static inline unsigned long get_dma_offset(struct device *dev)
+{
+ if (dev)
+ return (unsigned long)dev->archdata.dma_data;
+
+ return PCI_DRAM_OFFSET;
+}
+
/* this will be removed soon */
#define flush_write_buffers()
@@ -181,12 +188,12 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
{
- return paddr + get_dma_direct_offset(dev);
+ return paddr + get_dma_offset(dev);
}
static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
{
- return daddr - get_dma_direct_offset(dev);
+ return daddr - get_dma_offset(dev);
}
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 21b784d..6215062 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -21,13 +21,6 @@
* default the offset is PCI_DRAM_OFFSET.
*/
-unsigned long get_dma_direct_offset(struct device *dev)
-{
- if (dev)
- return (unsigned long)dev->archdata.dma_data;
-
- return PCI_DRAM_OFFSET;
-}
void *dma_direct_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
@@ -37,7 +30,7 @@ void *dma_direct_alloc_coherent(struct device *dev, size_t size,
ret = __dma_alloc_coherent(dev, size, dma_handle, flag);
if (ret == NULL)
return NULL;
- *dma_handle += get_dma_direct_offset(dev);
+ *dma_handle += get_dma_offset(dev);
return ret;
#else
struct page *page;
@@ -51,7 +44,7 @@ void *dma_direct_alloc_coherent(struct device *dev, size_t size,
return NULL;
ret = page_address(page);
memset(ret, 0, size);
- *dma_handle = virt_to_abs(ret) + get_dma_direct_offset(dev);
+ *dma_handle = virt_to_abs(ret) + get_dma_offset(dev);
return ret;
#endif
@@ -75,7 +68,7 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
int i;
for_each_sg(sgl, sg, nents, i) {
- sg->dma_address = sg_phys(sg) + get_dma_direct_offset(dev);
+ sg->dma_address = sg_phys(sg) + get_dma_offset(dev);
sg->dma_length = sg->length;
__dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
@@ -110,7 +103,7 @@ static inline dma_addr_t dma_direct_map_page(struct device *dev,
{
BUG_ON(dir == DMA_NONE);
__dma_sync_page(page, offset, size, dir);
- return page_to_phys(page) + offset + get_dma_direct_offset(dev);
+ return page_to_phys(page) + offset + get_dma_offset(dev);
}
static inline void dma_direct_unmap_page(struct device *dev,
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/2] powerpc: Change archdata dma_data to a union
From: Becky Bruce @ 2009-09-02 22:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1251930200-4796-1-git-send-email-beckyb@kernel.crashing.org>
Sometimes this is used to hold a simple offset, and sometimes
it is used to hold a pointer. This patch changes it to a union containing
void * and dma_addr_t. get/set accessors are also provided, because it was
getting a bit ugly to get to the actual data.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
arch/powerpc/include/asm/device.h | 11 ++++++++++-
arch/powerpc/include/asm/dma-mapping.h | 10 ++++++++--
arch/powerpc/include/asm/iommu.h | 10 ++++++++++
arch/powerpc/kernel/dma-iommu.c | 16 ++++++++--------
arch/powerpc/kernel/pci-common.c | 2 +-
arch/powerpc/kernel/vio.c | 2 +-
arch/powerpc/platforms/cell/beat_iommu.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 9 +++------
arch/powerpc/platforms/iseries/iommu.c | 2 +-
arch/powerpc/platforms/pasemi/iommu.c | 2 +-
arch/powerpc/platforms/pseries/iommu.c | 8 ++++----
arch/powerpc/sysdev/dart_iommu.c | 2 +-
12 files changed, 49 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h b/arch/powerpc/include/asm/device.h
index 67fcd7f..07ca8b5 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -15,7 +15,16 @@ struct dev_archdata {
/* DMA operations on that device */
struct dma_map_ops *dma_ops;
- void *dma_data;
+
+ /*
+ * When an iommu is in use, dma_data is used as a ptr to the base of the
+ * iommu_table. Otherwise, it is a simple numerical offset.
+ */
+ union {
+ dma_addr_t dma_offset;
+ void *iommu_table_base;
+ } dma_data;
+
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index eef4db1..e9f4fe9 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -89,14 +89,20 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
dev->archdata.dma_ops = ops;
}
-static inline unsigned long get_dma_offset(struct device *dev)
+static inline dma_addr_t get_dma_offset(struct device *dev)
{
if (dev)
- return (unsigned long)dev->archdata.dma_data;
+ return dev->archdata.dma_data.dma_offset;
return PCI_DRAM_OFFSET;
}
+static inline void set_dma_offset(struct device *dev, dma_addr_t off)
+{
+ if (dev)
+ dev->archdata.dma_data.dma_offset = off;
+}
+
/* this will be removed soon */
#define flush_write_buffers()
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 7464c0d..edfc980 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -70,6 +70,16 @@ struct iommu_table {
struct scatterlist;
+static inline void set_iommu_table_base(struct device *dev, void *base)
+{
+ dev->archdata.dma_data.iommu_table_base = base;
+}
+
+static inline void *get_iommu_table_base(struct device *dev)
+{
+ return dev->archdata.dma_data.iommu_table_base;
+}
+
/* Frees table for an individual device node */
extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 87ddb3f..37771a5 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -18,7 +18,7 @@
static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
- return iommu_alloc_coherent(dev, dev->archdata.dma_data, size,
+ return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
dma_handle, device_to_mask(dev), flag,
dev_to_node(dev));
}
@@ -26,7 +26,7 @@ static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
static void dma_iommu_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle)
{
- iommu_free_coherent(dev->archdata.dma_data, size, vaddr, dma_handle);
+ iommu_free_coherent(get_iommu_table_base(dev), size, vaddr, dma_handle);
}
/* Creates TCEs for a user provided buffer. The user buffer must be
@@ -39,8 +39,8 @@ static dma_addr_t dma_iommu_map_page(struct device *dev, struct page *page,
enum dma_data_direction direction,
struct dma_attrs *attrs)
{
- return iommu_map_page(dev, dev->archdata.dma_data, page, offset, size,
- device_to_mask(dev), direction, attrs);
+ return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
+ size, device_to_mask(dev), direction, attrs);
}
@@ -48,7 +48,7 @@ static void dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
size_t size, enum dma_data_direction direction,
struct dma_attrs *attrs)
{
- iommu_unmap_page(dev->archdata.dma_data, dma_handle, size, direction,
+ iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
attrs);
}
@@ -57,7 +57,7 @@ static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
int nelems, enum dma_data_direction direction,
struct dma_attrs *attrs)
{
- return iommu_map_sg(dev, dev->archdata.dma_data, sglist, nelems,
+ return iommu_map_sg(dev, get_iommu_table_base(dev), sglist, nelems,
device_to_mask(dev), direction, attrs);
}
@@ -65,14 +65,14 @@ static void dma_iommu_unmap_sg(struct device *dev, struct scatterlist *sglist,
int nelems, enum dma_data_direction direction,
struct dma_attrs *attrs)
{
- iommu_unmap_sg(dev->archdata.dma_data, sglist, nelems, direction,
+ iommu_unmap_sg(get_iommu_table_base(dev), sglist, nelems, direction,
attrs);
}
/* We support DMA to/from any memory page via the iommu */
static int dma_iommu_dma_supported(struct device *dev, u64 mask)
{
- struct iommu_table *tbl = dev->archdata.dma_data;
+ struct iommu_table *tbl = get_iommu_table_base(dev);
if (!tbl || tbl->it_offset > mask) {
printk(KERN_INFO
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index e9f4840..bb8209e 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1117,7 +1117,7 @@ void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
/* Hook up default DMA ops */
sd->dma_ops = pci_dma_ops;
- sd->dma_data = (void *)PCI_DRAM_OFFSET;
+ set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
/* Additional platform DMA/iommu setup */
if (ppc_md.pci_dma_dev_setup)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index bc7b41e..8d9275f 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1233,7 +1233,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
vio_cmo_set_dma_ops(viodev);
else
viodev->dev.archdata.dma_ops = &dma_iommu_ops;
- viodev->dev.archdata.dma_data = vio_build_iommu_table(viodev);
+ set_iommu_table_base(&viodev->dev, vio_build_iommu_table(viodev));
set_dev_node(&viodev->dev, of_node_to_nid(of_node));
/* init generic 'struct device' fields: */
diff --git a/arch/powerpc/platforms/cell/beat_iommu.c b/arch/powerpc/platforms/cell/beat_iommu.c
index 93b0efd..39d361c 100644
--- a/arch/powerpc/platforms/cell/beat_iommu.c
+++ b/arch/powerpc/platforms/cell/beat_iommu.c
@@ -77,7 +77,7 @@ static void __init celleb_init_direct_mapping(void)
static void celleb_dma_dev_setup(struct device *dev)
{
dev->archdata.dma_ops = get_pci_dma_ops();
- dev->archdata.dma_data = (void *)celleb_dma_direct_offset;
+ set_dma_offset(dev, celleb_dma_direct_offset);
}
static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 416db17..ca5bfdf 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -657,15 +657,13 @@ static void cell_dma_dev_setup_fixed(struct device *dev);
static void cell_dma_dev_setup(struct device *dev)
{
- struct dev_archdata *archdata = &dev->archdata;
-
/* Order is important here, these are not mutually exclusive */
if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
cell_dma_dev_setup_fixed(dev);
else if (get_pci_dma_ops() == &dma_iommu_ops)
- archdata->dma_data = cell_get_iommu_table(dev);
+ set_iommu_table_base(dev, cell_get_iommu_table(dev));
else if (get_pci_dma_ops() == &dma_direct_ops)
- archdata->dma_data = (void *)cell_dma_direct_offset;
+ set_dma_offset(dev, cell_dma_direct_offset);
else
BUG();
}
@@ -973,11 +971,10 @@ static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
static void cell_dma_dev_setup_fixed(struct device *dev)
{
- struct dev_archdata *archdata = &dev->archdata;
u64 addr;
addr = cell_iommu_get_fixed_address(dev) + dma_iommu_fixed_base;
- archdata->dma_data = (void *)addr;
+ set_dma_offset(dev, addr);
dev_dbg(dev, "iommu: fixed addr = %llx\n", addr);
}
diff --git a/arch/powerpc/platforms/iseries/iommu.c b/arch/powerpc/platforms/iseries/iommu.c
index 6c1e101..9d53cb4 100644
--- a/arch/powerpc/platforms/iseries/iommu.c
+++ b/arch/powerpc/platforms/iseries/iommu.c
@@ -193,7 +193,7 @@ static void pci_dma_dev_setup_iseries(struct pci_dev *pdev)
pdn->iommu_table = iommu_init_table(tbl, -1);
else
kfree(tbl);
- pdev->dev.archdata.dma_data = pdn->iommu_table;
+ set_iommu_table_base(&pdev->dev, pdn->iommu_table);
}
#else
#define pci_dma_dev_setup_iseries NULL
diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
index a0ff03a..7b1d608 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -189,7 +189,7 @@ static void pci_dma_dev_setup_pasemi(struct pci_dev *dev)
}
#endif
- dev->dev.archdata.dma_data = &iommu_table_iobmap;
+ set_iommu_table_base(&dev->dev, &iommu_table_iobmap);
}
static void pci_dma_bus_setup_null(struct pci_bus *b) { }
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 661c8e0..1a0000a 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -482,7 +482,7 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
phb->node);
iommu_table_setparms(phb, dn, tbl);
PCI_DN(dn)->iommu_table = iommu_init_table(tbl, phb->node);
- dev->dev.archdata.dma_data = PCI_DN(dn)->iommu_table;
+ set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
return;
}
@@ -494,7 +494,7 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
dn = dn->parent;
if (dn && PCI_DN(dn))
- dev->dev.archdata.dma_data = PCI_DN(dn)->iommu_table;
+ set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
else
printk(KERN_WARNING "iommu: Device %s has no iommu table\n",
pci_name(dev));
@@ -538,7 +538,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
*/
if (dma_window == NULL || pdn->parent == NULL) {
pr_debug(" no dma window for device, linking to parent\n");
- dev->dev.archdata.dma_data = PCI_DN(pdn)->iommu_table;
+ set_iommu_table_base(&dev->dev, PCI_DN(pdn)->iommu_table);
return;
}
@@ -554,7 +554,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
pr_debug(" found DMA window, table: %p\n", pci->iommu_table);
}
- dev->dev.archdata.dma_data = pci->iommu_table;
+ set_iommu_table_base(&dev->dev, pci->iommu_table);
}
#else /* CONFIG_PCI */
#define pci_dma_bus_setup_pSeries NULL
diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index 89639ec..ae3c4db 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -297,7 +297,7 @@ static void pci_dma_dev_setup_dart(struct pci_dev *dev)
/* We only have one iommu table on the mac for now, which makes
* things simple. Setup all PCI devices to point to this table
*/
- dev->dev.archdata.dma_data = &iommu_table_dart;
+ set_iommu_table_base(&dev->dev, &iommu_table_dart);
}
static void pci_dma_bus_setup_dart(struct pci_bus *bus)
--
1.6.0.6
^ permalink raw reply related
* PPC PCI bus registers
From: Eddie Dawydiuk @ 2009-09-02 23:44 UTC (permalink / raw)
To: linuxppc-dev, Grant Likely
Hello,
I have a question regarding reading PCI bus registers from a user space
application running on a PPC SBC. Seeing as though the PCI bus is little endian
and PPC is big endian is it typical that one must perform a byte swap on all 16
and 32 bit register reads?
I've found this is true on a custom board I am working on(with an FPGA connected
via the PCI bus) and as a result I've added a byte swap command in busybox to
accommodate this feature...
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
^ permalink raw reply
* Re: PPC PCI bus registers
From: Grant Likely @ 2009-09-02 23:56 UTC (permalink / raw)
To: Eddie Dawydiuk; +Cc: linuxppc-dev
In-Reply-To: <4A9F0377.1070606@embeddedarm.com>
On Wed, Sep 2, 2009 at 5:44 PM, Eddie Dawydiuk<eddie@embeddedarm.com> wrote:
> Hello,
>
> I have a question regarding reading PCI bus registers from a user space
> application running on a PPC SBC. Seeing as though the PCI bus is little
> endian and PPC is big endian is it typical that one must perform a byte swap
> on all 16 and 32 bit register reads?
Yes, this is correct.
g.
^ permalink raw reply
* Re: why do we need reloc_offset ??
From: Michael Ellerman @ 2009-09-03 2:19 UTC (permalink / raw)
To: HongWoo Lee; +Cc: linuxppc-dev
In-Reply-To: <5e2889710909012333q69874b24qf6e3c0abfceb8dfd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]
On Wed, 2009-09-02 at 15:33 +0900, HongWoo Lee wrote:
> Hi everyone~
>
> In ther linux kernel code, I found the reloc_offset.
>
> {{{
> // file : misc.S
> /* Returns (address we are running at) - (address we were linked at)
> * for use before the text and data are mapped to KERNELBASE.
> */
> _GLOBAL(reloc_offset)
> }}}
>
> I couldn't understand the comment saying "Returns (address we are
> running at) - (address we were linked at)".
> For now, I'm studying each instruction.
>
> And below is best comment I can explain for each instruction.
>
> _GLOBAL(reloc_offset)
> mflr r0 // move from link register, save the return address
> bl 1f // bl 1f
> 1: mflr r3 // move from link register, r3 is just return address pointing itself
At this point r3 contains the value of LR based on the branch we just
did. So it's the address of the current instruction, based on where the
code is _running_.
> LOAD_REG_IMMEDIATE(r4,1b) // get the 1b address, r4 is the address
Here we load into r4 the address of the previous instruction, but based
on the label "1b". The address of the label is calculated by the linker,
so r4 contains the address the instruction was linked at.
> subf r3,r4,r3 // r3 = r3 – r4
So here we calculate any difference between the address the code was
linked at and the address it's running at.
> mtlr r0 // restore return address
> blr
>
> After this, I still don't know why "r3-r4" is the offset.
> And what does it mean ??
The offset is just the difference between the address the code was
linked at and the address it's running it. It's used in places where the
code might be (or is always) running at an address other than the
address it was linked at.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox