* Re: Reminder: removal of arch/ppc
From: Josh Boyer @ 2008-01-26 3:22 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev list, Jon Loeliger, linuxppc-embedded
In-Reply-To: <fa686aa40801251907x710f1916y1fa8d8ac6913aae@mail.gmail.com>
On Fri, 25 Jan 2008 20:07:57 -0700
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On 1/25/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> > Just a reminder that the plan is to remove arch/ppc this summer (June
> > 2008).
>
> I strongly recommend that we delay removal by about a month...
> somewhere around July 23-26... so we can have a great big "ding, dong,
> arch/ppc is dead" party at OLS.
Ironically, that is where the original June date came from. Segher
suggested doing it at OLS, which for some reason we all thought was in
June.
But this is Linux. We never do anything on time, so I'm sure it'll
work out ;)
josh
^ permalink raw reply
* Re: [PATCH 063/196] kset: convert /sys/devices to use kset_create
From: Olof Johansson @ 2008-01-26 3:40 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, Kay Sievers, torvalds, linux-kernel
In-Reply-To: <1201245134-4876-63-git-send-email-gregkh@suse.de>
On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote:
> Dynamically create the kset instead of declaring it statically. We also
> rename devices_subsys to devices_kset to catch all users of the
> variable.
Guess what, you broke powerpc again!
olof@quad:~/work/linux/k.org $ git grep devices_subsys
arch/powerpc/kernel/vio.c:extern struct kset devices_subsys; /* needed for vio_find_name() */
arch/powerpc/kernel/vio.c: found = kset_find_obj(&devices_subsys, kobj_name);
Obviously causes build failues, even of ppc64_defconfig.
(I can unfortunately not boot test, since I lack hardware that uses vio)
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 19a5656..ee752ab 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -37,7 +37,7 @@
#include <asm/iseries/hv_call_xm.h>
#include <asm/iseries/iommu.h>
-extern struct kset devices_subsys; /* needed for vio_find_name() */
+extern struct kset *devices_kset; /* needed for vio_find_name() */
static struct bus_type vio_bus_type;
@@ -369,7 +369,7 @@ static struct vio_dev *vio_find_name(const char *kobj_name)
{
struct kobject *found;
- found = kset_find_obj(&devices_subsys, kobj_name);
+ found = kset_find_obj(devices_kset, kobj_name);
if (!found)
return NULL;
^ permalink raw reply related
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 4:07 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=,
linuxppc-dev
In-Reply-To: <1201251000.6341.108.camel@lappy>
On Fri, Jan 25, 2008 at 09:50:00AM +0100, Peter Zijlstra wrote:
>
> On Fri, 2008-01-25 at 18:25 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-01-25 at 18:03 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> > > >
> > > > Here, I do the test of running 4 times the repro-case provided by Michel
> > > > with nice 19 and a dd eating CPU with nice 0.
> > > >
> > > > Without this option, I get the dd at 100% and the nice 19 shells down
> > > > below it with whatever is left of the CPUs.
> > > >
> > > > With this option, dd gets about 50% of one CPU and the niced processes
> > > > still get most of the time.
Ben,
I presume you had CONFIG_FAIR_USER_SCHED turned on too? Also were the
dd process and the niced processes running under different user ids? If
so, that is expected behavior, that we divide CPU equally among
users first and then among the processes within each user.
> > > FYI. This is a 4 way G5 (ppc64)
> >
> > I also tested responsiveness of X running with or without that option
> > and with niced CPU eaters in the background (still 4 of them, one per
> > CPU), and I can confirm Michel observations, it gets very sluggish
> > (maybe not -as- bad as his but still pretty annoying) with the fair
> > group scheduler enabled.
When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not
enabled, X will be given higher priority for running on CPU when compared to
other niced tasks. When the above options are turned on, X (running
under root uid) would be given lesser priority to run when compared to other
niced tasks running user different uids. Hence I expect some drop in
interactivity-experience with FAIR_GROUP_SCHED on.
Can you pls let me know if any of these makes a difference:
1. Run niced tasks as root. This would bring X and niced tasks in the
same "scheduler group" domain, which would give X much more CPU power
when compared to niced tasks.
2. Keep the niced tasks running under a non-root uid, but increase root users
cpu share.
# echo 8192 > /sys/kernel/uids/0/cpu_share
This should bump up root user's priority for running on CPU and also
give a better desktop experience.
> > Here, X is running with nice=0
>
> Curious, sounds like an issue with the group load balancer, vatsa, any
> ideas?
The group scheduler's SMP-load balance in 2.6.24 is not the best it
could be. sched-devel has a better load balancer, which I am presuming
will go into 2.6.25 soon.
In this case, I suspect that's not the issue. If X and the niced processes are
running under different uids, this (niced processes getting more cpu power) is
on expected lines. Will wait for Ben to confirm this.
--
Regards,
vatsa
^ permalink raw reply
* Please pull for-2.6.25 branch of pasemi.git
From: Olof Johansson @ 2008-01-26 4:07 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
to receive the following updates:
arch/powerpc/kernel/smp.c | 49 +++++++++++++++++++++++++++++++++-------------
1 file changed, 36 insertions(+), 13 deletions(-)
Olof Johansson (2):
[POWERPC] smp_call_function_map should be static
[POWERPC] Make smp_send_stop() handle panic and xmon reboot
Those two patches are marked as "awaiting upstream" in patchwork, but
I didn't see them in powerpc.git for-2.6.25.
-Olof
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Benjamin Herrenschmidt @ 2008-01-26 4:13 UTC (permalink / raw)
To: vatsa; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra, Michel Dänzer
In-Reply-To: <20080126040734.GA21365@linux.vnet.ibm.com>
On Sat, 2008-01-26 at 09:37 +0530, Srivatsa Vaddagiri wrote:
>
> Ben,
> I presume you had CONFIG_FAIR_USER_SCHED turned on too?
Yes. It seems to be automatically turned on whenever FAIR_GROUP is
turned on. Considering how bad the behaviour is for a standard desktop
configuration, I'd be tempted to say to change it to default n.
> Also were the
> dd process and the niced processes running under different user ids? If
> so, that is expected behavior, that we divide CPU equally among
> users first and then among the processes within each user.
They were different users and that behaviour seems to be a very stupid
default behaviour for a desktop machine. Take this situation:
- X running as root
- User apps running as "user"
- Background crap (indexing daemons etc...) running as their own user
or nobody
Unless you can get some kind of grouping based on user sessions
including suid binaries, X etc... I think this shouldn't default y in
Kconfig.
Not that it seems that Michel reported far worse behaviour than what I
saw, including pretty hickup'ish X behaviour even without the fair group
scheduler compared to 2.6.23. It might be because he's running X niced
to -1 (I leave X at 0 and let the scheduler deal with it in general)
though.
> When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not
> enabled, X will be given higher priority for running on CPU when compared to
> other niced tasks. When the above options are turned on, X (running
> under root uid) would be given lesser priority to run when compared to other
> niced tasks running user different uids. Hence I expect some drop in
> interactivity-experience with FAIR_GROUP_SCHED on.
>
> Can you pls let me know if any of these makes a difference:
>
> 1. Run niced tasks as root. This would bring X and niced tasks in the
> same "scheduler group" domain, which would give X much more CPU power
> when compared to niced tasks.
I'll dbl check. My tests where indeed done with different users.
> 2. Keep the niced tasks running under a non-root uid, but increase root users
> cpu share.
> # echo 8192 > /sys/kernel/uids/0/cpu_share
>
> This should bump up root user's priority for running on CPU and also
> give a better desktop experience.
Allright, that's something that might need to be set by default by the
kernel ... as it will take some time to have knowledge of those knobs to
percolate to distros. Too bad you can't do the opposite by default for
"nobody" as there's no standard uid for it.
> The group scheduler's SMP-load balance in 2.6.24 is not the best it
> could be. sched-devel has a better load balancer, which I am presuming
> will go into 2.6.25 soon.
>
> In this case, I suspect that's not the issue. If X and the niced processes are
> running under different uids, this (niced processes getting more cpu power) is
> on expected lines. Will wait for Ben to confirm this.
I would suggest turning the fair group scheduler to default n in stable
for now.
Cheers,
Ben.
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Roland Dreier @ 2008-01-26 4:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <20080125202034.43556262@zod.rchland.ibm.com>
> Hm. Katmai is already in-tree. Theoretically I should be able to get
> the HW docs and do a new DTS and have it mostly "just work". Perhaps
> I'll give that a shot and have you give it a quick spin.
Yep, should be pretty easy. A while back I built a Katmai kernel in
arch/ppc based on the Yucca support and the differences were pretty
trivial -- as I recall, the Katmai has compact flash support that the
Yucca doesn't have, and the Yucca has a simple little FPGA with a few
registers that controls power to the PCI slots.
- R.
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 5:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
In-Reply-To: <1201320834.6815.160.camel@pasglop>
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> > I presume you had CONFIG_FAIR_USER_SCHED turned on too?
>
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> configuration, I'd be tempted to say to change it to default n.
If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same
time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group
scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not
available in mainline as the second option for grouping tasks.
Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default,
but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default.
That way all tasks belong to same group by default unless admin explicitly
creates groups and moves around tasks between them. This will be good for
desktop user who may choose to keep all tasks in one group by default, but also
giving him/her the flexibility of exploiting fair-group scheduler by creating
custom task groups and adjusting their cpu shares (for ex: kernel compile group
or multi-media group). If someone still needs the fair-user scheduler (as
provided by CONFIG_FAIR_USER_SCHED), they can still get it with
CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around
tasks into different task group based on userid.
Ingo/Peter, what do you think?
> > Also were the
> > dd process and the niced processes running under different user ids? If
> > so, that is expected behavior, that we divide CPU equally among
> > users first and then among the processes within each user.
>
> They were different users and that behaviour seems to be a very stupid
> default behaviour for a desktop machine. Take this situation:
>
> - X running as root
> - User apps running as "user"
> - Background crap (indexing daemons etc...) running as their own user
> or nobody
>
> Unless you can get some kind of grouping based on user sessions
> including suid binaries, X etc... I think this shouldn't default y in
> Kconfig.
yes, see above.
> Not that it seems that Michel reported far worse behaviour than what I
> saw, including pretty hickup'ish X behaviour even without the fair group
> scheduler compared to 2.6.23. It might be because he's running X niced
> to -1 (I leave X at 0 and let the scheduler deal with it in general)
> though.
Hmm ..with X niced to -1, it should get more cpu power leading to a
better desktop experience.
Michel,
You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
was the cause for this bad behavior. Do you see behavior change (from good->bad)
immediately after applying that patch during your bisect process?
> > 2. Keep the niced tasks running under a non-root uid, but increase root users
> > cpu share.
> > # echo 8192 > /sys/kernel/uids/0/cpu_share
> >
> > This should bump up root user's priority for running on CPU and also
> > give a better desktop experience.
>
> Allright, that's something that might need to be set by default by the
> kernel ... as it will take some time to have knowledge of those knobs to
> percolate to distros. Too bad you can't do the opposite by default for
> "nobody" as there's no standard uid for it.
>
> > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > could be. sched-devel has a better load balancer, which I am presuming
> > will go into 2.6.25 soon.
> >
> > In this case, I suspect that's not the issue. If X and the niced processes are
> > running under different uids, this (niced processes getting more cpu power) is
> > on expected lines. Will wait for Ben to confirm this.
>
> I would suggest turning the fair group scheduler to default n in stable
> for now.
I would prefer to have CONFIG_FAIR_GROUP_SCHED +
CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
think is the desktop experience with that combination?
Reference:
1. http://article.gmane.org/gmane.linux.kernel/553267
--
Regards,
vatsa
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 5:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
In-Reply-To: <1201320834.6815.160.camel@pasglop>
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> > I presume you had CONFIG_FAIR_USER_SCHED turned on too?
>
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> configuration, I'd be tempted to say to change it to default n.
If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same
time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group
scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not
available in mainline as the second option for grouping tasks.
Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default,
but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default.
That way all tasks belong to same group by default unless admin explicitly
creates groups and moves around tasks between them. This will be good for
desktop user who may choose to keep all tasks in one group by default, but also
giving him/her the flexibility of exploiting fair-group scheduler by creating
custom task groups and adjusting their cpu shares (for ex: kernel compile group
or multi-media group). If someone still needs the fair-user scheduler (as
provided by CONFIG_FAIR_USER_SCHED), they can still get it with
CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around
tasks into different task group based on userid.
Ingo/Peter, what do you think?
> > Also were the
> > dd process and the niced processes running under different user ids? If
> > so, that is expected behavior, that we divide CPU equally among
> > users first and then among the processes within each user.
>
> They were different users and that behaviour seems to be a very stupid
> default behaviour for a desktop machine. Take this situation:
>
> - X running as root
> - User apps running as "user"
> - Background crap (indexing daemons etc...) running as their own user
> or nobody
>
> Unless you can get some kind of grouping based on user sessions
> including suid binaries, X etc... I think this shouldn't default y in
> Kconfig.
yes, see above.
> Not that it seems that Michel reported far worse behaviour than what I
> saw, including pretty hickup'ish X behaviour even without the fair group
> scheduler compared to 2.6.23. It might be because he's running X niced
> to -1 (I leave X at 0 and let the scheduler deal with it in general)
> though.
Hmm ..with X niced to -1, it should get more cpu power leading to a
better desktop experience.
Michel,
You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
was the cause for this bad behavior. Do you see behavior change (from good->bad)
immediately after applying that patch during your bisect process?
> > 2. Keep the niced tasks running under a non-root uid, but increase root users
> > cpu share.
> > # echo 8192 > /sys/kernel/uids/0/cpu_share
> >
> > This should bump up root user's priority for running on CPU and also
> > give a better desktop experience.
>
> Allright, that's something that might need to be set by default by the
> kernel ... as it will take some time to have knowledge of those knobs to
> percolate to distros. Too bad you can't do the opposite by default for
> "nobody" as there's no standard uid for it.
>
> > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > could be. sched-devel has a better load balancer, which I am presuming
> > will go into 2.6.25 soon.
> >
> > In this case, I suspect that's not the issue. If X and the niced processes are
> > running under different uids, this (niced processes getting more cpu power) is
> > on expected lines. Will wait for Ben to confirm this.
>
> I would suggest turning the fair group scheduler to default n in stable
> for now.
I would prefer to have CONFIG_FAIR_GROUP_SCHED +
CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
think is the desktop experience with that combination?
Reference:
1. http://article.gmane.org/gmane.linux.kernel/553267
--
Regards,
vatsa
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Benjamin Herrenschmidt @ 2008-01-26 5:15 UTC (permalink / raw)
To: vatsa
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
In-Reply-To: <20080126050637.GA14177@linux.vnet.ibm.com>
> > Not that it seems that Michel reported far worse behaviour than what I
> > saw, including pretty hickup'ish X behaviour even without the fair group
> > scheduler compared to 2.6.23. It might be because he's running X niced
> > to -1 (I leave X at 0 and let the scheduler deal with it in general)
> > though.
>
> Hmm ..with X niced to -1, it should get more cpu power leading to a
> better desktop experience.
It depends as X can end up starving it's own clients, especially with a
compositing manager or other fancy window manager...
> Michel,
> You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> was the cause for this bad behavior. Do you see behavior change (from good->bad)
> immediately after applying that patch during your bisect process?
Also Michel, double check your .config in both cases.
> I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> think is the desktop experience with that combination?
I'm going to give that a try but unfortunately, it will have to wait
until I'm back from LCA in a bit more than a week.
Ben.
^ permalink raw reply
* Re: [PATCH 063/196] kset: convert /sys/devices to use kset_create
From: Greg KH @ 2008-01-26 5:24 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Kay Sievers, torvalds, linux-kernel
In-Reply-To: <20080126034055.GA28786@lixom.net>
On Fri, Jan 25, 2008 at 09:40:55PM -0600, Olof Johansson wrote:
> On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote:
> > Dynamically create the kset instead of declaring it statically. We also
> > rename devices_subsys to devices_kset to catch all users of the
> > variable.
>
> Guess what, you broke powerpc again!
I did this ON PURPOSE!!!
The linux-kernel archives hold the details, and I was told by the PPC64
IBM people that they would fix this properly for 2.6.25, and not to hold
back on my changes. This has been known for many months now.
> olof@quad:~/work/linux/k.org $ git grep devices_subsys
> arch/powerpc/kernel/vio.c:extern struct kset devices_subsys; /* needed for vio_find_name() */
> arch/powerpc/kernel/vio.c: found = kset_find_obj(&devices_subsys, kobj_name);
>
> Obviously causes build failues, even of ppc64_defconfig.
>
> (I can unfortunately not boot test, since I lack hardware that uses vio)
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index 19a5656..ee752ab 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -37,7 +37,7 @@
> #include <asm/iseries/hv_call_xm.h>
> #include <asm/iseries/iommu.h>
>
> -extern struct kset devices_subsys; /* needed for vio_find_name() */
> +extern struct kset *devices_kset; /* needed for vio_find_name() */
No, this just papers over the real problem here. For some reason, the
vio code thinks it is acceptable to walk the whole device tree and match
by a name and just assume that they got the correct device. You call
this "enterprise grade"? :)
You need to just put your device on a real bus, and then just walk the
bus. That's the ONLY way you can guarantee the proper name will return
what you want, and you get the pointer that you really think you are
getting.
There is a reason that devices_kset is not exported, don't make me go
and have to name it something like:
devices_kset_dont_touch_this_or_gregkh_will_make_fun_of_you
Or I'll just mush 3 files in the driver core together and keep the
symbol from being accessible at all.
So no, I'm going to leave the build broken for this code, because that
is what it really is.
Please fix it correctly.
thanks,
greg k-h
^ permalink raw reply
* [PATCH]warp.c
From: Sean MacLennan @ 2008-01-26 5:39 UTC (permalink / raw)
To: linuxppc-dev
While merging, I found a small bug that I forgot to send. I add an
offset to a value twice.
It is much easier to diff if it doesn't show the entire file as new.
Cheers,
Sean MacLennan
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 8f01563..da5b7b7 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -137,7 +137,7 @@ static int __init pika_dtm_start(void)
}
of_node_put(np);
- fpga = ioremap(res.start + 0x20, 4);
+ fpga = ioremap(res.start, 0x24);
if (fpga == NULL)
return -ENOENT;
^ permalink raw reply related
* i2c-ibm_iic.c fix
From: Sean MacLennan @ 2008-01-26 5:44 UTC (permalink / raw)
To: linuxppc-dev
If anybody is following this patch it needs to be updated. It was
recommended that the device_type be removed from the dts files. But the
table matches the type, so I changed the table to only match the
compatibility. I can give people a full blown patch if they want it. But
basically the table should look like follows:
static const struct of_device_id ibm_iic_match[] =
{
{ .compatible = "ibm,iic-405ex", },
{ .compatible = "ibm,iic-405gp", },
{ .compatible = "ibm,iic-440gp", },
{ .compatible = "ibm,iic-440gpx", },
{ .compatible = "ibm,iic-440grx", },
{}
};
Cheers,
Sean
^ permalink raw reply
* Re: xsysace.c oops on restart
From: Grant Likely @ 2008-01-26 6:03 UTC (permalink / raw)
To: Jean-Samuel Chenard, linuxppc-dev
In-Reply-To: <169c03cb0801252115q59b7e9c7g795cc35b7f252958@mail.gmail.com>
On 1/25/08, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> Hi Grant,
>
> I'm writing this e-mail directly to you before posting in the
> discussion forums because I found some issues with the xsysace.c
> driver. You are listed as the main author of the driver, so I'm
> assuming you might have a better clue than me as to what is happening.
Feel free to post to the mailing list regardless. It's better to have
a public record of our discussions. I certainly have no problem with
you pointing out issues with that driver in public. :-)
>
> When I built kernel 2.6.23.9 or the latest from your git tree, if I
> use the new system ACE driver that you wrote, I cannot reboot without
> a Oops in the kernel. The message happens very late before the CPU is
> supposed to reboot. If I compile the kernel with the old Xilinx
> driver, I don't get the oops on restart.
Yeah; that definitely sounds like a driver bug.
> Below are the details of the exception.
>
> The system is going down NOW!
> Sending SIGTERM to all processes
> Requesting system reboot
> [172545.229120] Restarting system.
> [172545.232346] <NULL>
> [172545.234663] Oops: Exception in kernel mode, sig: 8 [#1]
> [172545.239960] NIP: c7cb7e00 LR: c7cb7df0 CTR: 00000001
> [172545.245003] REGS: c7cb7d40 TRAP: 2007df0 Not tainted
> (2.6.23.9-jsc-vanilla)
> [172545.252291] MSR: 00000000 <> CR: 00000010 XER: 000a00d2
> [172545.257773] TASK =3D c02fb430[136] 'init' THREAD: c7cb6000
> [172545.262976] GPR00: 3c303e5b 31373235 34352e32 32393132 305d2000
> 00000000 00000000 7fa41efc
> [172545.271442] GPR08: 00000000 fee1dead 28121969 00000000 c7cb7df0
> c0016350 00000000 00000000
> [172545.279902] GPR16: 00000001 00000000 c0170000 c019a464 c000b1f0
> 00607b83 00000000 00000000
> [172545.288368] GPR24: 00000000 ffffffff 00000000 0002d030 00000001
> c0024ccc 00000000 00000000
> [172545.296999] NIP [c7cb7e00] 0xc7cb7e00
> [172545.300747] LR [c7cb7df0] 0xc7cb7df0
> [172545.304400] Call Trace:
> [172545.306925] Instruction dump:
> [172545.309965] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> XXXXXXXX XXXXXXXX
> [172545.317781] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> XXXXXXXX XXXXXXXX
This traceback doesn't help much without knowing where 0xc7cb7e00 is
in your kernel image. You could use gdb on the vmlinux image to
figure it out, but it would be simpler to enable
CONFIG_DEBUG_BUGVERBOSE and CONFIG_DEBUG_INFO and run it again. That
should give you a more meaningful traceback.
I've also got a rework patch for the sysace drive which makes it a bit
more robust. I'll post it to the list shortly.
> The only modification I had to make in the xsysace.c to make it work
> on my ML-310 is change the width of the systemACE bus:
> @@ -1126,7 +1127,7 @@ static void __devexit ace_free(struct device *dev)
> static int __devinit ace_probe(struct platform_device *dev)
> {
> unsigned long physaddr =3D 0;
> - int bus_width =3D ACE_BUS_WIDTH_16; /* FIXME: should not be hard =
coded */
> + int bus_width =3D ACE_BUS_WIDTH_8; /* FIXME: should not be hard c=
oded */
> int id =3D dev->id;
> int irq =3D NO_IRQ;
> int i;
>
> I would prefer to use the new systemACE driver because it seems to be
> faster (and the code is cleaner), but this oops on restart prevents me
> from doing a lot of work remotely since I need to press the reset
> button on my board. I get this error on both my ML-310 board and the
> BEE2 machine I have at school. I guess I could investigate a bit more
> by building the systemACE as a module and trying to load and unload it
> to see if I can make it crash. It may not even be related to that
> driver, but if I change to the older driver, I never get this problem.
> Every time I use the new driver, the problem shows up and this is the
> only setting that I change in the kernel. All the time, I have the
> driver built into the kernel (not as a loadable module).
>
> Also, thanks to your Wiki pages and discussions in the linux-ppc
> groups, I managed to get my BEE2 to boot Linux 2.6 with all the
> goodies. This is basically the only leftover issue with my system.
>
> Let me know if you have some insights as why this could happen. I can
> see if other people have seen a similar problem in the discussion
> forums.
>
> Regards,
>
> Jean-Samuel
> --
> Ph.D. candidate
> Integrated Microsystems Laboratory
> McGill University, Montr=E9al, QC, CANADA
> Web Page: http://chaos.ece.mcgill.ca
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Patches added to for-2.6.25/master branches of powerpc.git
From: Paul Mackerras @ 2008-01-26 6:16 UTC (permalink / raw)
To: linuxppc-dev
This includes commits pulled from Josh Boyer, Kumar Gala, Grant
Likely, and Olof Johansson. I reverted the "Fake NUMA emulation for
PowerPC" commit because it changed behaviour even when the fake numa
command-line option wasn't given.
I'll be asking Linus to pull within the next few days, so please
remind me about anything else that should go in 2.6.25.
Paul.
Anton Vorontsov (4):
libata: pata_platform: make probe and remove functions device type neutral
libata: pata_of_platform: OF-Platform PATA device driver
[POWERPC] booting-without-of: localbus should not include board name
[POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
Becky Bruce (1):
[POWERPC] Fixup use of phys_addr_t in mpic code
Benjamin Herrenschmidt (20):
[POWERPC] Reworking machine check handling and Fix 440/440A
[POWERPC] 4xx: Improve support for 4xx indirect DCRs
[POWERPC] 4xx: PLB to PCI-X support
[POWERPC] 4xx: PLB to PCI 2.x support
[POWERPC] 4xx: PLB to PCI Express support
[POWERPC] 4xx: PCI support for Ebony board
[POWERPC] 4xx: Add early udbg support for 40x processors
[POWERPC] 4xx: EP405 boards support for arch/powerpc
[POWERPC] 4xx: Add PCI to Walnut platform
[POWERPC] 4xx: Wire up PCI on Bamboo board
[POWERPC] 4xx: Wire up 440EP USB controller support to Bamboo board
[POWERPC] 4xx: Adds decoding of 440SPE memory size to boot wrapper library
[POWERPC] 4xx: Add mfspr/mtspr inline macros to 4xx bootwrapper
[POWERPC] 4xx: Add CPR0 accessors to boot wrapper
[POWERPC] 4xx: Rework clock probing in boot wrapper
[POWERPC] 4xx: Base support for 440SPe "Katmai" eval board
[POWERPC] 4xx: remove bogus "ranges" property in Bamboo EBC node
[POWERPC] 4xx: PCI-E Link setup improvements
[POWERPC] pci32: 4xx embedded platforms want to reassign all PCI resources
[POWERPC] Always hookup PHB IO resource even when empty
Cyrill Gorcunov (3):
[POWERPC] Use for_each macros in arch/powerpc/sysdev
[POWERPC] Use for_each macros in arch/powerpc/kernel
[POWERPC] Use for_each macros in arch/powerpc/platforms/powermac
Dale Farnsworth (1):
[POWERPC] 85xx: Respect KERNELBASE, PAGE_OFFSET, and PHYSICAL_START on e500
David Gibson (1):
[POWERPC] Enable RTC for Ebony and Walnut (v2)
Geert Uytterhoeven (10):
[POWERPC] Kill sparse warning in HPTE_V_COMPARE()
[POWERPC] PS3: Make bus_id and dev_id u64
[POWERPC] PS3: Add ps3_repository_find_device_by_id()
[POWERPC] PS3: Use the HVs storage device notification mechanism properly
[POWERPC] PS3: Add repository polling loop to work around timing bug
[POWERPC] PS3: Kill unused ps3_repository_bump_device()
[POWERPC] PS3: Refactor ps3_repository_find_device()
[POWERPC] PS3: Checkpatch cleanups for drivers/ps3/ps3-sys-manager.c
[POWERPC] PS3: Checkpatch cleanups for drivers/ps3/ps3-vuart.c
[POWERPC] PS3: Checkpatch cleanups for arch/powerpc/platforms/ps3/repository.c
Geoff Levand (5):
[POWERPC] Add definition of Cell bookmark SPR
[POWERPC] PS3: Add logical performance monitor device support
[POWERPC] PS3: Vuart: change semaphore to mutex
[POWERPC] PS3: Remove lpar address workaround
[POWERPC] PS3: Update ps3_defconfig
Grant Likely (8):
[POWERPC] 4xx: typo in calling machine_device_initcall() for Sequoia board
[POWERPC] pasemi: Use machine_*_initcall() hooks in platform code
[POWERPC] Add of_find_matching_node() helper function
[POWERPC] powermac: Use machine_*_initcall() hooks in platform code
[POWERPC] cell: Use machine_*_initcall() hooks in platform code
[POWERPC] mpc5200: eliminate mpc52xx_*_map_*() functions.
[POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
[POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
Hollis Blanchard (1):
[POWERPC] 4xx: enable built-in networking for Sequoia defconfig
Hugh Blemings (1):
[POWERPC] 4xx: Base support for 440GX Taishan eval board
Jochen Friedrich (2):
[POWERPC] Update .gitignore files
fs_enet: Add fixed-phy support for fs_enet
John Rigby (4):
[POWERPC] Separate MPC52xx PSC FIFO registers from rest of PSC
[POWERPC] mpc5200: Cleanup checkpatch.pl problems in mpc52xx_uart.c
[POWERPC] Add support for mpc512x interrupts to ipic
[POWERPC] Add IPIC Kconfig option
Jon Loeliger (5):
[POWERPC] Use <linux/of_{platform, device}.h> and not <asm/...> variants.
[POWERPC] Add _nmask_and_or_msr() declartion to asm-powerpc/system.h
[POWERPC] Add StorCenter DTS first draft.
[POWERPC] Add initial iomega StorCenter board port.
[POWERPC] Add initial storcenter config file.
Jon Tollefson (1):
[POWERPC] Add hugepagesz boot-time parameter
Joseph Fannin (1):
[POWERPC] Export copy_page() on 32bit
Josh Boyer (11):
[POWERPC] 4xx: Fix 440grx setup function to call 440A fixup
[POWERPC] 4xx: Include missing header
[POWERPC] 4xx: libfdt and pci fixes for Rainier
[POWERPC] 4xx: Rename CPU nodes to avoid dtc incompatibility
[POWERPC] 4xx: Update Kilauea, Rainier, and Walnut defconfigs
[POWERPC] 4xx: Mark of_bus structures as __initdata
[POWERPC] Conditionally compile e200 and e500 platforms in cputable
[POWERPC] Remove unneeded variable declarations from mpc837x_mds
[POWERPC] 4xx: Use machine_device_initcall for bus probe
[POWERPC] 4xx: Minor coding style cleanups for 4xx bootwrapper
[POWERPC] 4xx: Update defconfigs
Kumar Gala (13):
[POWERPC] Fix handling of memreserve if the range lands in highmem
[POWERPC] Ensure we only handle PowerMac PCI bus fixup for memory resources
[POWERPC] Fixup transparent P2P resources
[POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx
[POWERPC] Remove update_bridge_resource
[POWERPC] 85xx: convert boards to use machine_device_initcall
[POWERPC] 83xx: convert boards to use machine_device_initcall
[POWERPC] bootwrapper: Add find_node_by_alias and dt_fixup_mac_address_by_alias
[POWERPC] bootwrapper: convert cuboot-8{3,5}xx to dt_fixup_mac_address_by_alias
[POWERPC] Fix incorrect interrupt map on FSL reference boards
[RAPIDIO] Fix compile error and warning
[POWERPC] Move RapidIO support code from arch/ppc
[POWERPC] Fix compile error if CONFIG_STX_GP3 is defined
Li Yang (3):
[POWERPC] 83xx: add device trees for MPC837x MDS board
[POWERPC] 83xx: Add MPC837x USB platform support
[POWERPC] 83xx: USB device tree cleanups
Liu Yu (1):
[POWERPC] Fix carry bug in 128-bit unsigned integer adding
Marian Balakowicz (6):
[POWERPC] mpc5200: Add 'fsl,lpb' bus type for localplus bus
[POWERPC] mpc5200: Add common mpc52xx_setup_pci() routine
[POWERPC] mpc5200: Add TQM5200 DTS
[POWERPC] mpc5200: add CM5200 DTS
[POWERPC] mpc5200: Add Promess Motion-PRO DTS
[POWERPC] mpc5200: Add generic support for simple MPC5200 based boards
Mark A. Greer (1):
[POWERPC] #address-cells & #size-cells properties are not inherited
Matthias Fuchs (1):
[POWERPC] 4xx: Add 405GPr and 405EP support in boot wrapper
Michael Ellerman (8):
[POWERPC] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
[POWERPC] Add celleb_dma_dev_setup()
[POWERPC] Use archdata.dma_data in dma_direct_ops and add the offset
[POWERPC] Have cell use its own dma_direct_offset variable
[POWERPC] Have celleb use its own dma_direct_offset variable
[POWERPC] Remove the global dma_direct_offset
[POWERPC] Remove bogus comment in dma_direct_alloc_coherent()
[POWERPC] Make IOMMU code safe for > 132 GB of memory
Michael Neuling (2):
[POWERPC] Make setjmp/longjmp code usable outside of xmon
[POWERPC] kdump shutdown hook support
Olaf Hering (2):
[POWERPC] Revert chrp_pci_fixup_vt8231_ata devinit to fix libata on pegasos
[POWERPC] Autodetect serial console on pegasos2
Olof Johansson (7):
[POWERPC] pasemi: Implement NMI support
[POWERPC] pasemi: Distribute interrupts evenly across cpus
[POWERPC] Enable CONFIG_PCI_MSI and CONFIG_MD in pasemi_defconfig
[POWERPC] pasemi: Fix NMI handling check
[POWERPC] pasemi: Move electra-ide to pata_of_platform
[POWERPC] Make smp_call_function_map static
[POWERPC] Make smp_send_stop() handle panic and xmon reboot
Paul Gortmaker (1):
[POWERPC] 85xx: mpc85xx_ads: add in missing of_node_put()
Paul Mackerras (3):
Revert "[POWERPC] Disable PCI IO/Mem on a device when resources can't be allocated"
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Revert "[POWERPC] Fake NUMA emulation for PowerPC"
Roel Kluin (1):
[POWERPC] 4xx: logical/bitand typo in powerpc/boot/4xx.c
Scott Wood (7):
[POWERPC] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
[POWERPC] 8xx: Analogue & Micro Adder875 board support.
[POWERPC] 82xx: Embedded Planet EP8248E support
[POWERPC] 83xx: MPC8313e RBD add NAND to device tree
[POWERPC] 83xx: MPC8313e RDB - Add NOR flash to the device tree.
[POWERPC] 83xx: Update MPC8313e RDB defconfig for MTD, NAND, JFFS2.
[POWERPC] 8xx: adder875 - Fix flash bus-width and remove duplicate __initdata
Sean MacLennan (5):
[POWERPC] 4xx: Add PowerPC 440EP Rev C
[POWERPC] 4xx: PIKA Warp base platform
[POWERPC] 4xx: PIKA Warp DTS
[POWERPC] 4xx: PIKA Warp bootwrapper
[POWERPC] 4xx: PIKA Warp defconfig
Stefan Roese (15):
[POWERPC] 4xx: Add 440SPe revA runtime detection to PCIe
[POWERPC] 4xx: Fix TLB 0 problem with CONFIG_SERIAL_TEXT_DEBUG
[POWERPC] 4xx: Add 405EX CPU type needed for EMAC support on Kilauea
[POWERPC] 4xx: Change Kilauea dts to support new EMAC device tree properties
[POWERPC] 4xx: Add Kilauea PCIe support to dts and Kconfig
[POWERPC] 4xx: Set ibpre for 405EX in 4xx PCIe driver
[POWERPC] 4xx: Add aliases node to 4xx dts files
[POWERPC] 4xx: Change Kilauea PCIe bus ranges in dts file
[POWERPC] 4xx: Add AMCC Makalu board support to platforms/40x
[POWERPC] 4xx: Makalu dts
[POWERPC] 4xx: Makalu defconfig
[POWERPC] 4xx: Add EMAC support to Kilauea defconfig
[POWERPC] 4xx: PCIe: Increase max busses per port to 64
[POWERPC] 4xx: Add 405EXr to cputable
[POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
Stephen Neuendorffer (5):
[POWERPC] Xilinx: update compatible list for interrupt controller
[POWERPC] Xilinx: Add correct compatible list for device tree bus bindings.
[POWERPC] Xilinx: Update booting-without-of.
[POWERPC] Xilinx: updated device tree compatibility to match uboot bsp generator.
[POWERPC] Xilinx uartlite: Section type fixups
Stephen Rothwell (12):
[POWERPC] The pci_dn class_code is only used by EEH
[POWERPC] The pci_dn pcidev is only used by EEH
[POWERPC] iSeries: eliminate pci_dn bussubno
[POWERPC] eeh.c: Use for_each_child_of_node
[POWERPC] pci_32.c: Use for_each_child_of_node
[POWERPC] therm_pm72: Suppress some compile warnings
[POWERPC] arch/powerpc/kernel: Use for_each_child_of_node
[POWERPC] therm_windtunnel: Eliminate some build warnings
[POWERPC] therm_adt746x: Eliminate some build warnings
[POWERPC] Check that the syscall table matches the syscall numbers
[POWERPC] Make ibmebus use of_(un)register_driver
[POWERPC] Fix a couple of copyright symbols
Takashi Yamamoto (2):
[POWERPC] PS3: Add logical performance monitor repository routines
[POWERPC] PS3: Add logical performance monitor driver support
Timur Tabi (4):
[POWERPC] QE: Add ability to upload QE firmware
[POWERPC] QE: Add support for Freescale QUICCEngine UART
[POWERPC] qe-uart: add support for Freescale QUICCEngine UART
[POWERPC] Update MPC8610 HPCD to support audio drivers
Valentine Barshak (12):
[POWERPC] 4xx: 440EPx Sequoia USB OHCI DTS entry
[POWERPC] 4xx: 440GRx Rainier bootwrapper.
[POWERPC] 4xx: 440GRx Rainier DTS.
[POWERPC] 4xx: 440GRx Rainier board support.
[POWERPC] 4xx: 440GRx Rainier default config
[POWERPC] 4xx: make UIC use generic level irq handler
[POWERPC] 4xx: rework UIC cascade irq handling
[POWERPC] 4xx: Correct 440GRx machine_check callback
[POWERPC] 4xx: Add PCI entry to 440EPx Sequoia DTS.
[POWERPC] 44x: Sequoia and Rainier updates for 2.6.25
[POWERPC] 4xx: update 440EP(x)/440GR(x) identical PVR issue workaround
[POWERPC] 4xx: Add PCI entry to 440GRx Rainier DTS.
Vitaly Bordug (3):
phy/fixed.c: rework to not duplicate PHY layer functionality
[POWERPC] MPC8349E-mITX: Vitesse 7385 PHY is not connected to the MDIO bus
[POWERPC] fsl_soc: add support to gianfar for fixed-link property
Wade Farnsworth (2):
[POWERPC] 86xx: Add localbus and flash nodes to mpc8641_hpcn.dts
[POWERPC] 86xx: MPC8641 HPCN - call of_platform_bus_probe()
^ permalink raw reply
* [PATCH] FIXED_MII_100_FDX
From: Sean MacLennan @ 2008-01-26 6:54 UTC (permalink / raw)
To: linuxppc-dev
On the last git pull, FIXED_MII_100_FDX was removed from the phy
Kconfig, but the Kconfig for CPMAC still tried to select it.
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9af05a2..297a4b5 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1710,7 +1710,6 @@ config CPMAC
depends on NET_ETHERNET && EXPERIMENTAL && AR7
select PHYLIB
select FIXED_PHY
- select FIXED_MII_100_FDX
help
TI AR7 CPMAC Ethernet support
^ permalink raw reply related
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Balbir Singh @ 2008-01-26 7:13 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, LKML
In-Reply-To: <1200635099.7806.3.camel@concordia.ozlabs.ibm.com>
* Michael Ellerman <michael@ellerman.id.au> [2008-01-18 16:44:58]:
>
> This fixes it, although I'm a little worried about some of the
> removals/movings of node_set_online() in the patch.
>
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 1666e7d..dcedc26 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -49,7 +49,6 @@ static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
> static unsigned int fake_nid = 0;
> static unsigned long long curr_boundary = 0;
>
> - *nid = fake_nid;
> if (!p)
> return 0;
>
> @@ -60,6 +59,7 @@ static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
> if (mem < curr_boundary)
> return 0;
>
> + *nid = fake_nid;
> curr_boundary = mem;
>
> if ((end_pfn << PAGE_SHIFT) > mem) {
>
Hi, Michael,
Here's a better and more complete fix for the problem. Could you
please see if it works for you? I tested it on a real NUMA box and it
seemed to work fine there.
Description
-----------
This patch provides a fix for the problem found by
Michael Ellerman <michael@ellerman.id.au> while using fake NUMA nodes
on a cell box. The code modifies node id iff (as in if and only if)
fake NUMA nodes are created.
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---
arch/powerpc/mm/numa.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff -puN arch/powerpc/mm/numa.c~fix-fake-numa-nid-on-numa arch/powerpc/mm/numa.c
--- linux-2.6.24-rc8/arch/powerpc/mm/numa.c~fix-fake-numa-nid-on-numa 2008-01-26 12:20:29.000000000 +0530
+++ linux-2.6.24-rc8-balbir/arch/powerpc/mm/numa.c 2008-01-26 12:27:53.000000000 +0530
@@ -49,7 +49,12 @@ static int __cpuinit fake_numa_create_ne
static unsigned int fake_nid = 0;
static unsigned long long curr_boundary = 0;
- *nid = fake_nid;
+ /*
+ * If we did enable fake nodes and cross a node,
+ * remember the last node and start from there.
+ */
+ if (fake_nid)
+ *nid = fake_nid;
if (!p)
return 0;
_
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: Failed to mount rootfs
From: Heiko Schocher @ 2008-01-26 7:41 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A9FA@xmb-sjc-212.amer.cisco.com>
Hello Bizhan,
Bizhan Gholikhamseh (bgholikh) wrote:
>> "Bizhan Gholikhamseh (bgholikh)" <bgholikh@cisco.com> wrote:
>>> Our custom board is leveraged from MPC8541cds from freescale.
>>> We have been running Linux 2.6.11 on it recently I have
>> tried to boot
>>> the system with the latest Linux 2.6.22-rc4 from PowerPC git tree.
>>>
>>> I did ported the libfdt to our older version of the uboot and were
>>> able to
>> Hmm... why you didnt use actual code?
>>
>> [...]
>>> chosen {
>>> linux,stdout-path = "/soc8541@e0000000/serial@4600";
>>> };
>>> chosen {
>>> name = "chosen";
>>> bootargs = "root=/dev/ram rw console=ttyS1,115200";
>>> linux,platform = <600>;
>>> linux,initrd-start = <1ef33000>;
>>> linux,initrd-end = <1fe190aa>;
>>> linux,stdout-path = "/soc8541@e0000000/serial@4600";
>>> };
>>> };
>> Here is your problem, you have 2 choosen nodes:
>>
>> 64k data, 108k bss, 116k init) Mount-cache hash table entries: 512
>> device-tree: Duplicate name in /, renamed to "chosen#1"
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> -> Linux didnt find your commandline ...
>>
>> Hmm... do you have CONFIG_OF_FLAT_TREE and CONFIG_OF_LIBFDT defined?
>> If so, this would explain, why you have 2 choosen nodes.
>
> Yes I do have both CONFIG_OF_FLAT_TREE and CONFIG_OF_LIBFDT defined. Is
> there a document to tell more about these options please?
Yes, read the README in the U-Boot root. CONFIG_OF_FLAT_TREE is deprecated,
you should use CONFIG_OF_LIBFDT.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Zoltan HERPAI @ 2008-01-26 9:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <E83C3B2F-0FC4-4248-B718-0C45B56E969A@kernel.crashing.org>
Kumar Gala wrote:
> 4xx:
> EBONY
>
I have an Ebony at hand, so if no one takes it, I'll give it a try to
port it over.
Regards,
Zoltan HERPAI
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 9:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
=?iso-8859-1?Q?Michel=2ED=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=.=?iso-8859-1?B?QHNub3d5LmluLmlibS5jb20=?=,
Michel.Dänzer
In-Reply-To: <1201324552.6815.165.camel@pasglop>
On Sat, Jan 26, 2008 at 04:15:52PM +1100, Benjamin Herrenschmidt wrote:
> > Michel,
> > You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> > was the cause for this bad behavior. Do you see behavior change (from good->bad)
> > immediately after applying that patch during your bisect process?
>
> Also Michel, double check your .config in both cases.
And also Michel whether CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED
gives more or less same desktop exp as !CONFIG_FAIR_GROUP_SCHED pls!
> > I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> > CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> > think is the desktop experience with that combination?
>
> I'm going to give that a try but unfortunately, it will have to wait
> until I'm back from LCA in a bit more than a week.
--
Regards,
vatsa
^ permalink raw reply
* [PATCH v4] create modalias file in sysfs for bus of_platform
From: Olaf Hering @ 2008-01-26 10:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: sparclinux, linuxppc-dev
In-Reply-To: <18330.32110.449914.354218@cargo.ozlabs.ibm.com>
Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
of modules. modalias files are already present for many other bus types.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/of/device.c | 33 ++++++++++++++++++---------------
drivers/of/platform.c | 3 +++
2 files changed, 21 insertions(+), 15 deletions(-)
Index: linux-2.6/drivers/of/device.c
===================================================================
--- linux-2.6.orig/drivers/of/device.c
+++ linux-2.6/drivers/of/device.c
@@ -77,7 +77,7 @@ void of_dev_put(struct of_device *dev)
}
EXPORT_SYMBOL(of_dev_put);
-static ssize_t dev_show_devspec(struct device *dev,
+static ssize_t devspec_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct of_device *ofdev;
@@ -86,7 +86,22 @@ static ssize_t dev_show_devspec(struct d
return sprintf(buf, "%s", ofdev->node->full_name);
}
-static DEVICE_ATTR(devspec, S_IRUGO, dev_show_devspec, NULL);
+static ssize_t modalias_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ ssize_t len;
+
+ len = of_device_get_modalias(to_of_device(dev), buf, PAGE_SIZE - 2);
+ buf[len] = '\n';
+ buf[len+1] = 0;
+ return len+1;
+}
+
+struct device_attribute of_platform_device_attrs[] = {
+ __ATTR_RO(devspec),
+ __ATTR_RO(modalias),
+ __ATTR_NULL
+};
/**
* of_release_dev - free an of device structure when all users of it are finished.
@@ -107,25 +122,13 @@ EXPORT_SYMBOL(of_release_dev);
int of_device_register(struct of_device *ofdev)
{
- int rc;
-
BUG_ON(ofdev->node == NULL);
-
- rc = device_register(&ofdev->dev);
- if (rc)
- return rc;
-
- rc = device_create_file(&ofdev->dev, &dev_attr_devspec);
- if (rc)
- device_unregister(&ofdev->dev);
-
- return rc;
+ return device_register(&ofdev->dev);
}
EXPORT_SYMBOL(of_device_register);
void of_device_unregister(struct of_device *ofdev)
{
- device_remove_file(&ofdev->dev, &dev_attr_devspec);
device_unregister(&ofdev->dev);
}
EXPORT_SYMBOL(of_device_unregister);
Index: linux-2.6/drivers/of/platform.c
===================================================================
--- linux-2.6.orig/drivers/of/platform.c
+++ linux-2.6/drivers/of/platform.c
@@ -17,6 +17,8 @@
#include <linux/of_device.h>
#include <linux/of_platform.h>
+extern struct device_attribute of_platform_device_attrs[];
+
static int of_platform_bus_match(struct device *dev, struct device_driver *drv)
{
struct of_device *of_dev = to_of_device(dev);
@@ -93,6 +95,7 @@ int of_bus_type_init(struct bus_type *bu
bus->remove = of_platform_device_remove;
bus->suspend = of_platform_device_suspend;
bus->resume = of_platform_device_resume;
+ bus->dev_attrs = of_platform_device_attrs;
return bus_register(bus);
}
^ permalink raw reply
* [PATCH] windfarm: add PowerMac 12,1 support
From: Étienne Bersac @ 2008-01-26 11:55 UTC (permalink / raw)
To: linuxppc-dev
From: Étienne Bersac <bersace@gmail.com>
Implement a new driver named windfarm_pm121 which drive fans on PowerMac
12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
windfarm_pm81 driver from Benjamin Herrenschmidt.
Signed-off-by: Étienne Bersac <bersace@gmail.com>
---
Implement fan control for PowerMac 12,1 machines. This needs update to
windfarm_lm75 and windfarm_max6690 sensors drivers in order to properly
match sensors by their location. The code is based on windfarm_pm81
driver, adapted to the complexity of PowerMac 12,1 : 4 system control
loops instead of one, per-control target correction and per-model
control rubber-banding.
All the data are copied from Darwin 8.10 AppleMacRISC4PE-185.0.0 module
as well as correction formula.
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 3673dd2..4c048b3 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -667,6 +667,7 @@ CONFIG_WINDFARM=y
CONFIG_WINDFARM_PM81=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
+CONFIG_WINDFARM_PM121=y
# CONFIG_PMAC_RACKMETER is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 77f50b6..2d028e6 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -234,6 +234,14 @@ config WINDFARM_PM112
which are the recent dual and quad G5 machines using the
970MP dual-core processor.
+config WINDFARM_PM121
+ tristate "Support for thermal management on PowerMac12,1"
+ depends on WINDFARM && I2C && PMAC_SMU
+ select I2C_POWERMAC
+ help
+ This driver provides thermal control for the PowerMac12,1
+ which is the iMac G5 (iSight) 970MP
+
config ANSLCD
tristate "Support for ANS LCD display"
depends on ADB_CUDA && PPC_PMAC
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 2dfc3f4..e3132ef 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -42,4 +42,9 @@ obj-$(CONFIG_WINDFARM_PM112) += windfarm_pm112.o windfarm_smu_sat.o \
windfarm_smu_sensors.o \
windfarm_max6690_sensor.o \
windfarm_lm75_sensor.o windfarm_pid.o
+obj-$(CONFIG_WINDFARM_PM121) += windfarm_pm121.o windfarm_smu_sat.o \
+ windfarm_smu_controls.o \
+ windfarm_smu_sensors.o \
+ windfarm_max6690_sensor.o \
+ windfarm_lm75_sensor.o windfarm_pid.o
obj-$(CONFIG_PMAC_RACKMETER) += rack-meter.o
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c b/drivers/macintosh/windfarm_lm75_sensor.c
index 7e10c3a..b92b959 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -127,6 +127,12 @@ static struct wf_lm75_sensor *wf_lm75_create(struct i2c_adapter *adapter,
*/
if (!strcmp(loc, "Hard drive") || !strcmp(loc, "DRIVE BAY"))
lm->sens.name = "hd-temp";
+ else if (!strcmp(loc, "Incoming Air Temp"))
+ lm->sens.name = "incoming-air-temp";
+ else if (!strcmp(loc, "ODD Temp"))
+ lm->sens.name = "optical-drive-temp";
+ else if (!strcmp(loc, "HD Temp"))
+ lm->sens.name = "hard-drive-temp";
else
goto fail;
diff --git a/drivers/macintosh/windfarm_max6690_sensor.c b/drivers/macintosh/windfarm_max6690_sensor.c
index 5f03aab..e207a90 100644
--- a/drivers/macintosh/windfarm_max6690_sensor.c
+++ b/drivers/macintosh/windfarm_max6690_sensor.c
@@ -77,18 +77,28 @@ static struct wf_sensor_ops wf_max6690_ops = {
.owner = THIS_MODULE,
};
-static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr)
+static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr,
+ const char *loc)
{
struct wf_6690_sensor *max;
- char *name = "backside-temp";
+ char *name;
max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL);
if (max == NULL) {
printk(KERN_ERR "windfarm: Couldn't create MAX6690 sensor %s: "
- "no memory\n", name);
+ "no memory\n", loc);
return;
}
+ if (!strcmp(loc, "BACKSIDE"))
+ name = "backside-temp";
+ else if (!strcmp(loc, "NB Ambient"))
+ name = "north-bridge-temp";
+ else if (!strcmp(loc, "GPU Ambient"))
+ name = "gpu-temp";
+ else
+ goto fail;
+
max->sens.ops = &wf_max6690_ops;
max->sens.name = name;
max->i2c.addr = addr >> 1;
@@ -138,9 +148,7 @@ static int wf_max6690_attach(struct i2c_adapter *adapter)
if (loc == NULL || addr == 0)
continue;
printk("found max6690, loc=%s addr=0x%02x\n", loc, addr);
- if (strcmp(loc, "BACKSIDE"))
- continue;
- wf_max6690_create(adapter, addr);
+ wf_max6690_create(adapter, addr, loc);
}
return 0;
diff --git a/drivers/macintosh/windfarm_pm121.c b/drivers/macintosh/windfarm_pm121.c
new file mode 100644
index 0000000..5276156
--- /dev/null
+++ b/drivers/macintosh/windfarm_pm121.c
@@ -0,0 +1,1040 @@
+/*
+ * Windfarm PowerMac thermal control. iMac G5 iSight
+ *
+ * (c) Copyright 2007 Étienne Bersac <bersace@gmail.com>
+ *
+ * Bits & pieces from windfarm_pm81.c by (c) Copyright 2005 Benjamin
+ * Herrenschmidt, IBM Corp. <benh@kernel.crashing.org>
+ *
+ * Released under the term of the GNU GPL v2.
+ *
+ *
+ *
+ * PowerMac12,1
+ * ============
+ *
+ *
+ * The algorithm used is the PID control algorithm, used the same way
+ * the published Darwin code does, using the same values that are
+ * present in the Darwin 8.10 snapshot property lists (note however
+ * that none of the code has been re-used, it's a complete
+ * re-implementation
+ *
+ * There is two models using PowerMac12,1. Model 2 is iMac G5 iSight
+ * 17" while Model 3 is iMac G5 20". They do have both the same
+ * controls with a tiny difference. The control-ids of hard-drive-fan
+ * and cpu-fan is swapped.
+ *
+ *
+ * Target Correction :
+ *
+ * controls have a target correction calculated as :
+ *
+ * new_min = ((((average_power * slope) >> 16) + offset) >> 16) + min_value
+ * new_value = max(new_value, max(new_min, 0))
+ *
+ * OD Fan control correction.
+ *
+ * # model_id: 2
+ * offset : -19563152
+ * slope : 1956315
+ *
+ * # model_id: 3
+ * offset : -15650652
+ * slope : 1565065
+ *
+ * HD Fan control correction.
+ *
+ * # model_id: 2
+ * offset : -15650652
+ * slope : 1565065
+ *
+ * # model_id: 3
+ * offset : -19563152
+ * slope : 1956315
+ *
+ * CPU Fan control correction.
+ *
+ * # model_id: 2
+ * offset : -25431900
+ * slope : 2543190
+ *
+ * # model_id: 3
+ * offset : -15650652
+ * slope : 1565065
+ *
+ *
+ * Target rubber-banding :
+ *
+ * Some controls have a target correction which depends on another
+ * control value. The correction is computed in the following way :
+ *
+ * new_min = ref_value * slope + offset
+ *
+ * ref_value is the value of the reference control. If new_min is
+ * greater than 0, then we correct the target value using :
+ *
+ * new_target = max (new_target, new_min >> 16)
+ *
+ *
+ * # model_id : 2
+ * control : cpu-fan
+ * ref : optical-drive-fan
+ * offset : -15650652
+ * slope : 1565065
+ *
+ * # model_id : 3
+ * control : optical-drive-fan
+ * ref : hard-drive-fan
+ * offset : -32768000
+ * slope : 65536
+ *
+ *
+ * In order to have the moste efficient correction with those
+ * dependencies, we must trigger HD loop before OD loop before CPU
+ * loop.
+ *
+ *
+ * The various control loops found in Darwin config file are:
+ *
+ * HD Fan control loop.
+ *
+ * # model_id: 2
+ * control : hard-drive-fan
+ * sensor : hard-drive-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x002D70A3
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x370000
+ * Interval = 5s
+ *
+ * # model_id: 3
+ * control : hard-drive-fan
+ * sensor : hard-drive-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x002170A3
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x370000
+ * Interval = 5s
+ *
+ * OD Fan control loop.
+ *
+ * # model_id: 2
+ * control : optical-drive-fan
+ * sensor : optical-drive-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x001FAE14
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x320000
+ * Interval = 5s
+ *
+ * # model_id: 3
+ * control : optical-drive-fan
+ * sensor : optical-drive-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x001FAE14
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x320000
+ * Interval = 5s
+ *
+ * GPU Fan control loop.
+ *
+ * # model_id: 2
+ * control : hard-drive-fan
+ * sensor : gpu-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x002A6666
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x5A0000
+ * Interval = 5s
+ *
+ * # model_id: 3
+ * control : cpu-fan
+ * sensor : gpu-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x0010CCCC
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x500000
+ * Interval = 5s
+ *
+ * KODIAK (aka northbridge) Fan control loop.
+ *
+ * # model_id: 2
+ * control : optical-drive-fan
+ * sensor : north-bridge-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x003BD70A
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x550000
+ * Interval = 5s
+ *
+ * # model_id: 3
+ * control : hard-drive-fan
+ * sensor : north-bridge-temp
+ * PID params : G_d = 0x00000000
+ * G_p = 0x0030F5C2
+ * G_r = 0x00019999
+ * History = 2 entries
+ * Input target = 0x550000
+ * Interval = 5s
+ *
+ * CPU Fan control loop.
+ *
+ * control : cpu-fan
+ * sensors : cpu-temp, cpu-power
+ * PID params : from SDB partition
+ *
+ *
+ * CPU Slew control loop.
+ *
+ * control : cpufreq-clamp
+ * sensor : cpu-temp
+ *
+ */
+
+#undef DEBUG
+
+#include <linux/types.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/spinlock.h>
+#include <linux/wait.h>
+#include <linux/kmod.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <asm/prom.h>
+#include <asm/machdep.h>
+#include <asm/io.h>
+#include <asm/system.h>
+#include <asm/sections.h>
+#include <asm/smu.h>
+
+#include "windfarm.h"
+#include "windfarm_pid.h"
+
+#define VERSION "0.3"
+
+static int pm121_mach_model; /* machine model id */
+
+/* Controls & sensors */
+static struct wf_sensor *sensor_cpu_power;
+static struct wf_sensor *sensor_cpu_temp;
+static struct wf_sensor *sensor_cpu_voltage;
+static struct wf_sensor *sensor_cpu_current;
+static struct wf_sensor *sensor_gpu_temp;
+static struct wf_sensor *sensor_north_bridge_temp;
+static struct wf_sensor *sensor_hard_drive_temp;
+static struct wf_sensor *sensor_optical_drive_temp;
+static struct wf_sensor *sensor_incoming_air_temp; /* unused ! */
+
+enum {
+ FAN_CPU,
+ FAN_HD,
+ FAN_OD,
+ CPUFREQ,
+ N_CONTROLS
+};
+static struct wf_control *controls[N_CONTROLS] = {};
+
+/* Set to kick the control loop into life */
+static int pm121_all_controls_ok, pm121_all_sensors_ok, pm121_started;
+
+enum {
+ FAILURE_FAN = 1 << 0,
+ FAILURE_SENSOR = 1 << 1,
+ FAILURE_OVERTEMP = 1 << 2
+};
+
+/* All sys loops. Note the HD before the OD loop in order to have it
+ run before. */
+enum {
+ LOOP_GPU, /* control = hd or cpu, but luckily,
+ it doesn't matter */
+ LOOP_HD, /* control = hd */
+ LOOP_KODIAK, /* control = hd or od */
+ LOOP_OD, /* control = od */
+ N_LOOPS
+};
+
+static const char *loop_names[N_LOOPS] = {
+ "GPU",
+ "HD",
+ "KODIAK",
+ "OD",
+};
+
+#define PM121_NUM_CONFIGS 2
+
+static unsigned int pm121_failure_state;
+static int pm121_readjust, pm121_skipping;
+static s32 average_power;
+
+struct pm121_correction {
+ int offset;
+ int slope;
+};
+
+static struct pm121_correction corrections[N_CONTROLS][PM121_NUM_CONFIGS] = {
+ /* FAN_OD */
+ {
+ /* MODEL 2 */
+ { .offset = -19563152,
+ .slope = 1956315
+ },
+ /* MODEL 3 */
+ { .offset = -15650652,
+ .slope = 1565065
+ },
+ },
+ /* FAN_HD */
+ {
+ /* MODEL 2 */
+ { .offset = -15650652,
+ .slope = 1565065
+ },
+ /* MODEL 3 */
+ { .offset = -19563152,
+ .slope = 1956315
+ },
+ },
+ /* FAN_CPU */
+ {
+ /* MODEL 2 */
+ { .offset = -25431900,
+ .slope = 2543190
+ },
+ /* MODEL 3 */
+ { .offset = -15650652,
+ .slope = 1565065
+ },
+ },
+ /* CPUFREQ has no correction (and is not implemented at all) */
+};
+
+struct pm121_connection {
+ unsigned int control_id;
+ unsigned int ref_id;
+ struct pm121_correction correction;
+};
+
+static struct pm121_connection pm121_connections[] = {
+ /* MODEL 2 */
+ { .control_id = FAN_CPU,
+ .ref_id = FAN_OD,
+ { .offset = -32768000,
+ .slope = 65536
+ }
+ },
+ /* MODEL 3 */
+ { .control_id = FAN_OD,
+ .ref_id = FAN_HD,
+ { .offset = -32768000,
+ .slope = 65536
+ }
+ },
+};
+
+/* pointer to the current model connection */
+static struct pm121_connection *pm121_connection;
+
+/*
+ * ****** System Fans Control Loop ******
+ *
+ */
+
+/* Since each loop handles only one control and we want to avoid
+ * writing virtual control, we store the control correction with the
+ * loop params. Some data are not set, there are common to all loop
+ * and thus, hardcoded.
+ */
+struct pm121_sys_param {
+ /* purely informative since we use mach_model-2 as index */
+ int model_id;
+ struct wf_sensor **sensor; /* use sensor_id instead ? */
+ s32 gp, itarget;
+ unsigned int control_id;
+};
+
+static struct pm121_sys_param
+pm121_sys_all_params[N_LOOPS][PM121_NUM_CONFIGS] = {
+ /* GPU Fan control loop */
+ {
+ { .model_id = 2,
+ .sensor = &sensor_gpu_temp,
+ .gp = 0x002A6666,
+ .itarget = 0x5A0000,
+ .control_id = FAN_HD,
+ },
+ { .model_id = 3,
+ .sensor = &sensor_gpu_temp,
+ .gp = 0x0010CCCC,
+ .itarget = 0x500000,
+ .control_id = FAN_CPU,
+ },
+ },
+ /* HD Fan control loop */
+ {
+ { .model_id = 2,
+ .sensor = &sensor_hard_drive_temp,
+ .gp = 0x002D70A3,
+ .itarget = 0x370000,
+ .control_id = FAN_HD,
+ },
+ { .model_id = 3,
+ .sensor = &sensor_hard_drive_temp,
+ .gp = 0x002170A3,
+ .itarget = 0x370000,
+ .control_id = FAN_HD,
+ },
+ },
+ /* KODIAK Fan control loop */
+ {
+ { .model_id = 2,
+ .sensor = &sensor_north_bridge_temp,
+ .gp = 0x003BD70A,
+ .itarget = 0x550000,
+ .control_id = FAN_OD,
+ },
+ { .model_id = 3,
+ .sensor = &sensor_north_bridge_temp,
+ .gp = 0x0030F5C2,
+ .itarget = 0x550000,
+ .control_id = FAN_HD,
+ },
+ },
+ /* OD Fan control loop */
+ {
+ { .model_id = 2,
+ .sensor = &sensor_optical_drive_temp,
+ .gp = 0x001FAE14,
+ .itarget = 0x320000,
+ .control_id = FAN_OD,
+ },
+ { .model_id = 3,
+ .sensor = &sensor_optical_drive_temp,
+ .gp = 0x001FAE14,
+ .itarget = 0x320000,
+ .control_id = FAN_OD,
+ },
+ },
+};
+
+/* the hardcoded values */
+#define PM121_SYS_GD 0x00000000
+#define PM121_SYS_GR 0x00019999
+#define PM121_SYS_HISTORY_SIZE 2
+#define PM121_SYS_INTERVAL 5
+
+/* State data used by the system fans control loop
+ */
+struct pm121_sys_state {
+ int ticks;
+ s32 setpoint;
+ struct wf_pid_state pid;
+};
+
+struct pm121_sys_state *pm121_sys_state[N_LOOPS] = {};
+
+/*
+ * ****** CPU Fans Control Loop ******
+ *
+ */
+
+#define PM121_CPU_INTERVAL 1
+
+/* State data used by the cpu fans control loop
+ */
+struct pm121_cpu_state {
+ int ticks;
+ s32 setpoint;
+ struct wf_cpu_pid_state pid;
+};
+
+static struct pm121_cpu_state *pm121_cpu_state;
+
+
+
+/*
+ * ***** Implementation *****
+ *
+ */
+
+/* correction the value using the output-low-bound correction algo */
+static s32 pm121_correct(s32 new_setpoint,
+ unsigned int control_id,
+ s32 min)
+{
+ s32 new_min;
+ struct pm121_correction *correction;
+ correction = &corrections[control_id][pm121_mach_model - 2];
+
+ new_min = (average_power * correction->slope) >> 16;
+ new_min += correction->offset;
+ new_min = (new_min >> 16) + min;
+
+ return max(new_setpoint, max(new_min, 0));
+}
+
+static s32 pm121_connect(unsigned int control_id, s32 setpoint)
+{
+ s32 new_min, value, new_setpoint;
+
+ if (pm121_connection->control_id == control_id) {
+ controls[control_id]->ops->get_value(controls[control_id],
+ &value);
+ new_min = value * pm121_connection->correction.slope;
+ new_min += pm121_connection->correction.offset;
+ if (new_min > 0) {
+ new_setpoint = max(setpoint, (new_min >> 16));
+ if (new_setpoint != setpoint) {
+ pr_debug("pm121: %s depending on %s, "
+ "corrected from %d to %d RPM\n",
+ controls[control_id]->name,
+ controls[pm121_connection->ref_id]->name,
+ (int) setpoint, (int) new_setpoint);
+ }
+ } else
+ new_setpoint = setpoint;
+ }
+ /* no connection */
+ else
+ new_setpoint = setpoint;
+
+ return new_setpoint;
+}
+
+/* FAN LOOPS */
+static void pm121_create_sys_fans(int loop_id)
+{
+ struct pm121_sys_param *param = NULL;
+ struct wf_pid_param pid_param;
+ struct wf_control *control = NULL;
+ int i;
+
+ /* First, locate the params for this model */
+ for (i = 0; i < PM121_NUM_CONFIGS; i++) {
+ if (pm121_sys_all_params[loop_id][i].model_id == pm121_mach_model) {
+ param = &(pm121_sys_all_params[loop_id][i]);
+ break;
+ }
+ }
+
+ /* No params found, put fans to max */
+ if (param == NULL) {
+ printk(KERN_WARNING "pm121: %s fan config not found "
+ " for this machine model\n",
+ loop_names[loop_id]);
+ goto fail;
+ }
+
+ control = controls[param->control_id];
+
+ /* Alloc & initialize state */
+ pm121_sys_state[loop_id] = kmalloc(sizeof(struct pm121_sys_state),
+ GFP_KERNEL);
+ if (pm121_sys_state[loop_id] == NULL) {
+ printk(KERN_WARNING "pm121: Memory allocation error\n");
+ goto fail;
+ }
+ pm121_sys_state[loop_id]->ticks = 1;
+
+ /* Fill PID params */
+ pid_param.gd = PM121_SYS_GD;
+ pid_param.gp = param->gp;
+ pid_param.gr = PM121_SYS_GR;
+ pid_param.interval = PM121_SYS_INTERVAL;
+ pid_param.history_len = PM121_SYS_HISTORY_SIZE;
+ pid_param.itarget = param->itarget;
+ pid_param.min = control->ops->get_min(control);
+ pid_param.max = control->ops->get_max(control);
+
+ wf_pid_init(&pm121_sys_state[loop_id]->pid, &pid_param);
+
+ pr_debug("pm121: %s Fan control loop initialized.\n"
+ " itarged=%d.%03d, min=%d RPM, max=%d RPM\n",
+ loop_names[loop_id], FIX32TOPRINT(pid_param.itarget),
+ pid_param.min, pid_param.max);
+ return;
+
+ fail:
+ /* note that this is not optimal since another loop may still
+ control the same control */
+ printk(KERN_WARNING "pm121: failed to set up %s loop "
+ "setting \"%s\" to max speed.\n",
+ loop_names[loop_id], control->name);
+
+ if (control)
+ wf_control_set_max(control);
+}
+
+static void pm121_sys_fans_tick(int loop_id)
+{
+ struct pm121_sys_param *param;
+ struct pm121_sys_state *st;
+ struct wf_sensor *sensor;
+ struct wf_control *control;
+ s32 temp, new_setpoint;
+ int rc;
+
+ param = &(pm121_sys_all_params[loop_id][pm121_mach_model-2]);
+ st = pm121_sys_state[loop_id];
+ sensor = *(param->sensor);
+ control = controls[param->control_id];
+
+ if (--st->ticks != 0) {
+ if (pm121_readjust)
+ goto readjust;
+ return;
+ }
+ st->ticks = PM121_SYS_INTERVAL;
+
+ rc = sensor->ops->get_value(sensor, &temp);
+ if (rc) {
+ printk(KERN_WARNING "windfarm: %s sensor error %d\n",
+ sensor->name, rc);
+ pm121_failure_state |= FAILURE_SENSOR;
+ return;
+ }
+
+ pr_debug("pm121: %s Fan tick ! %s: %d.%03d\n",
+ loop_names[loop_id], sensor->name,
+ FIX32TOPRINT(temp));
+
+ new_setpoint = wf_pid_run(&st->pid, temp);
+
+ /* correction */
+ new_setpoint = pm121_correct(new_setpoint,
+ param->control_id,
+ st->pid.param.min);
+ /* linked corretion */
+ new_setpoint = pm121_connect(param->control_id, new_setpoint);
+
+ if (new_setpoint == st->setpoint)
+ return;
+ st->setpoint = new_setpoint;
+ pr_debug("pm121: %s corrected setpoint: %d RPM\n",
+ control->name, (int)new_setpoint);
+ readjust:
+ if (control && pm121_failure_state == 0) {
+ rc = control->ops->set_value(control, st->setpoint);
+ if (rc) {
+ printk(KERN_WARNING "windfarm: %s fan error %d\n",
+ control->name, rc);
+ pm121_failure_state |= FAILURE_FAN;
+ }
+ }
+}
+
+
+/* CPU LOOP */
+static void pm121_create_cpu_fans(void)
+{
+ struct wf_cpu_pid_param pid_param;
+ const struct smu_sdbp_header *hdr;
+ struct smu_sdbp_cpupiddata *piddata;
+ struct smu_sdbp_fvt *fvt;
+ struct wf_control *fan_cpu;
+ s32 tmax, tdelta, maxpow, powadj;
+
+ fan_cpu = controls[FAN_CPU];
+
+ /* First, locate the PID params in SMU SBD */
+ hdr = smu_get_sdb_partition(SMU_SDB_CPUPIDDATA_ID, NULL);
+ if (hdr == 0) {
+ printk(KERN_WARNING "pm121: CPU PID fan config not found.\n");
+ goto fail;
+ }
+ piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
+
+ /* Get the FVT params for operating point 0 (the only supported one
+ * for now) in order to get tmax
+ */
+ hdr = smu_get_sdb_partition(SMU_SDB_FVT_ID, NULL);
+ if (hdr) {
+ fvt = (struct smu_sdbp_fvt *)&hdr[1];
+ tmax = ((s32)fvt->maxtemp) << 16;
+ } else
+ tmax = 0x5e0000; /* 94 degree default */
+
+ /* Alloc & initialize state */
+ pm121_cpu_state = kmalloc(sizeof(struct pm121_cpu_state),
+ GFP_KERNEL);
+ if (pm121_cpu_state == NULL)
+ goto fail;
+ pm121_cpu_state->ticks = 1;
+
+ /* Fill PID params */
+ pid_param.interval = PM121_CPU_INTERVAL;
+ pid_param.history_len = piddata->history_len;
+ if (pid_param.history_len > WF_CPU_PID_MAX_HISTORY) {
+ printk(KERN_WARNING "pm121: History size overflow on "
+ "CPU control loop (%d)\n", piddata->history_len);
+ pid_param.history_len = WF_CPU_PID_MAX_HISTORY;
+ }
+ pid_param.gd = piddata->gd;
+ pid_param.gp = piddata->gp;
+ pid_param.gr = piddata->gr / pid_param.history_len;
+
+ tdelta = ((s32)piddata->target_temp_delta) << 16;
+ maxpow = ((s32)piddata->max_power) << 16;
+ powadj = ((s32)piddata->power_adj) << 16;
+
+ pid_param.tmax = tmax;
+ pid_param.ttarget = tmax - tdelta;
+ pid_param.pmaxadj = maxpow - powadj;
+
+ pid_param.min = fan_cpu->ops->get_min(fan_cpu);
+ pid_param.max = fan_cpu->ops->get_max(fan_cpu);
+
+ wf_cpu_pid_init(&pm121_cpu_state->pid, &pid_param);
+
+ pr_debug("pm121: CPU Fan control initialized.\n");
+ pr_debug(" ttarged=%d.%03d, tmax=%d.%03d, min=%d RPM, max=%d RPM,\n",
+ FIX32TOPRINT(pid_param.ttarget), FIX32TOPRINT(pid_param.tmax),
+ pid_param.min, pid_param.max);
+
+ return;
+
+ fail:
+ printk(KERN_WARNING "pm121: CPU fan config not found, max fan speed\n");
+
+ if (controls[CPUFREQ])
+ wf_control_set_max(controls[CPUFREQ]);
+ if (fan_cpu)
+ wf_control_set_max(fan_cpu);
+}
+
+
+static void pm121_cpu_fans_tick(struct pm121_cpu_state *st)
+{
+ s32 new_setpoint, temp, power;
+ struct wf_control *fan_cpu = NULL;
+ int rc;
+
+ if (--st->ticks != 0) {
+ if (pm121_readjust)
+ goto readjust;
+ return;
+ }
+ st->ticks = PM121_CPU_INTERVAL;
+
+ fan_cpu = controls[FAN_CPU];
+
+ rc = sensor_cpu_temp->ops->get_value(sensor_cpu_temp, &temp);
+ if (rc) {
+ printk(KERN_WARNING "pm121: CPU temp sensor error %d\n",
+ rc);
+ pm121_failure_state |= FAILURE_SENSOR;
+ return;
+ }
+
+ rc = sensor_cpu_power->ops->get_value(sensor_cpu_power, &power);
+ if (rc) {
+ printk(KERN_WARNING "pm121: CPU power sensor error %d\n",
+ rc);
+ pm121_failure_state |= FAILURE_SENSOR;
+ return;
+ }
+
+ pr_debug("pm121: CPU Fans tick ! CPU temp: %d.%03d°C, power: %d.%03d\n",
+ FIX32TOPRINT(temp), FIX32TOPRINT(power));
+
+ if (temp > st->pid.param.tmax)
+ pm121_failure_state |= FAILURE_OVERTEMP;
+
+ new_setpoint = wf_cpu_pid_run(&st->pid, power, temp);
+
+ /* correction */
+ new_setpoint = pm121_correct(new_setpoint,
+ FAN_CPU,
+ st->pid.param.min);
+
+ /* connected correction */
+ new_setpoint = pm121_connect(FAN_CPU, new_setpoint);
+
+ if (st->setpoint == new_setpoint)
+ return;
+ st->setpoint = new_setpoint;
+ pr_debug("pm121: CPU corrected setpoint: %d RPM\n", (int)new_setpoint);
+
+ readjust:
+ if (fan_cpu && pm121_failure_state == 0) {
+ rc = fan_cpu->ops->set_value(fan_cpu, st->setpoint);
+ if (rc) {
+ printk(KERN_WARNING "pm121: %s fan error %d\n",
+ fan_cpu->name, rc);
+ pm121_failure_state |= FAILURE_FAN;
+ }
+ }
+}
+
+/*
+ * ****** Common ******
+ *
+ */
+
+static void pm121_tick(void)
+{
+ unsigned int last_failure = pm121_failure_state;
+ unsigned int new_failure;
+ s32 total_power;
+ int i;
+
+ if (!pm121_started) {
+ pr_debug("pm121: creating control loops !\n");
+ for (i = 0; i < N_LOOPS; i++)
+ pm121_create_sys_fans(i);
+
+ pm121_create_cpu_fans();
+ pm121_started = 1;
+ }
+
+ /* skipping ticks */
+ if (pm121_skipping && --pm121_skipping)
+ return;
+
+ /* compute average power */
+ total_power = 0;
+ for (i = 0; i < pm121_cpu_state->pid.param.history_len; i++)
+ total_power += pm121_cpu_state->pid.powers[i];
+
+ average_power = total_power / pm121_cpu_state->pid.param.history_len;
+
+
+ pm121_failure_state = 0;
+ for (i = 0 ; i < N_LOOPS; i++) {
+ if (pm121_sys_state[i])
+ pm121_sys_fans_tick(i);
+ }
+
+ if (pm121_cpu_state)
+ pm121_cpu_fans_tick(pm121_cpu_state);
+
+ pm121_readjust = 0;
+ new_failure = pm121_failure_state & ~last_failure;
+
+ /* If entering failure mode, clamp cpufreq and ramp all
+ * fans to full speed.
+ */
+ if (pm121_failure_state && !last_failure) {
+ for (i = 0; i < N_CONTROLS; i++) {
+ if (controls[i])
+ wf_control_set_max(controls[i]);
+ }
+ }
+
+ /* If leaving failure mode, unclamp cpufreq and readjust
+ * all fans on next iteration
+ */
+ if (!pm121_failure_state && last_failure) {
+ if (controls[CPUFREQ])
+ wf_control_set_min(controls[CPUFREQ]);
+ pm121_readjust = 1;
+ }
+
+ /* Overtemp condition detected, notify and start skipping a couple
+ * ticks to let the temperature go down
+ */
+ if (new_failure & FAILURE_OVERTEMP) {
+ wf_set_overtemp();
+ pm121_skipping = 2;
+ }
+
+ /* We only clear the overtemp condition if overtemp is cleared
+ * _and_ no other failure is present. Since a sensor error will
+ * clear the overtemp condition (can't measure temperature) at
+ * the control loop levels, but we don't want to keep it clear
+ * here in this case
+ */
+ if (new_failure == 0 && last_failure & FAILURE_OVERTEMP)
+ wf_clear_overtemp();
+}
+
+
+static struct wf_control* pm121_register_control(struct wf_control *ct,
+ const char *match,
+ unsigned int id)
+{
+ if (controls[id] == NULL && !strcmp(ct->name, match)) {
+ if (wf_get_control(ct) == 0)
+ controls[FAN_OD] = ct;
+ }
+ return controls[id];
+}
+
+static void pm121_new_control(struct wf_control *ct)
+{
+ int all = 1;
+
+ if (pm121_all_controls_ok)
+ return;
+
+ all = all && pm121_register_control(ct, "optical-driver-fan", FAN_OD);
+ all = all && pm121_register_control(ct, "hard-driver-fan", FAN_HD);
+ all = all && pm121_register_control(ct, "cpu-driver-fan", FAN_CPU);
+ all = all && pm121_register_control(ct, "cpufreq-clamp", CPUFREQ);
+
+ if (all)
+ pm121_all_controls_ok = 1;
+}
+
+
+
+
+static struct wf_sensor* pm121_register_sensor(struct wf_sensor *sensor,
+ const char *match,
+ struct wf_sensor **var)
+{
+ if (*var == NULL && !strcmp(sensor->name, match)) {
+ if (wf_get_sensor(sensor) == 0)
+ *var = sensor;
+ }
+ return *var;
+}
+
+static void pm121_new_sensor(struct wf_sensor *sr)
+{
+ int all = 1;
+
+ if (pm121_all_sensors_ok)
+ return;
+
+ all = all && pm121_register_sensor(sr, "cpu-temp",
+ &sensor_cpu_temp);
+ all = all && pm121_register_sensor(sr, "cpu-current",
+ &sensor_cpu_current);
+ all = all && pm121_register_sensor(sr, "cpu-voltage",
+ &sensor_cpu_voltage);
+ all = all && pm121_register_sensor(sr, "cpu-power",
+ &sensor_cpu_power);
+ all = all && pm121_register_sensor(sr, "hard-drive-temp",
+ &sensor_hard_drive_temp);
+ all = all && pm121_register_sensor(sr, "optical-drive-temp",
+ &sensor_optical_drive_temp);
+ all = all && pm121_register_sensor(sr, "incoming-air-temp",
+ &sensor_incoming_air_temp);
+ all = all && pm121_register_sensor(sr, "north-bridge-temp",
+ &sensor_north_bridge_temp);
+ all = all && pm121_register_sensor(sr, "gpu-temp",
+ &sensor_gpu_temp);
+
+ if (all)
+ pm121_all_sensors_ok = 1;
+}
+
+
+
+static int pm121_notify(struct notifier_block *self,
+ unsigned long event, void *data)
+{
+ switch (event) {
+ case WF_EVENT_NEW_CONTROL:
+ pr_debug("pm121: new control %s detected\n",
+ ((struct wf_control *)data)->name);
+ pm121_new_control(data);
+ break;
+ case WF_EVENT_NEW_SENSOR:
+ pr_debug("pm121: new sensor %s detected\n",
+ ((struct wf_sensor *)data)->name);
+ pm121_new_sensor(data);
+ break;
+ case WF_EVENT_TICK:
+ if (pm121_all_controls_ok && pm121_all_sensors_ok)
+ pm121_tick();
+ break;
+ }
+
+ return 0;
+}
+
+static struct notifier_block pm121_events = {
+ .notifier_call = pm121_notify,
+};
+
+static int pm121_init_pm(void)
+{
+ const struct smu_sdbp_header *hdr;
+
+ hdr = smu_get_sdb_partition(SMU_SDB_SENSORTREE_ID, NULL);
+ if (hdr != 0) {
+ struct smu_sdbp_sensortree *st =
+ (struct smu_sdbp_sensortree *)&hdr[1];
+ pm121_mach_model = st->model_id;
+ }
+
+ pm121_connection = &pm121_connections[pm121_mach_model - 2];
+
+ printk(KERN_INFO "pm121: Initializing for iMac G5 iSight model ID %d\n",
+ pm121_mach_model);
+
+ return 0;
+}
+
+
+static int pm121_probe(struct platform_device *ddev)
+{
+ wf_register_client(&pm121_events);
+
+ return 0;
+}
+
+static int __devexit pm121_remove(struct platform_device *ddev)
+{
+ wf_unregister_client(&pm121_events);
+ return 0;
+}
+
+static struct platform_driver pm121_driver = {
+ .probe = pm121_probe,
+ .remove = __devexit_p(pm121_remove),
+ .driver = {
+ .name = "windfarm",
+ .bus = &platform_bus_type,
+ },
+};
+
+
+static int __init pm121_init(void)
+{
+ int rc = -ENODEV;
+
+ if (machine_is_compatible("PowerMac12,1"))
+ rc = pm121_init_pm();
+
+ if (rc == 0) {
+ request_module("windfarm_smu_controls");
+ request_module("windfarm_smu_sensors");
+ request_module("windfarm_smu_sat");
+ request_module("windfarm_lm75_sensor");
+ request_module("windfarm_max6690_sensor");
+ request_module("windfarm_cpufreq_clamp");
+ platform_driver_register(&pm121_driver);
+ }
+
+ return rc;
+}
+
+static void __exit pm121_exit(void)
+{
+
+ platform_driver_unregister(&pm121_driver);
+}
+
+
+module_init(pm121_init);
+module_exit(pm121_exit);
+
+MODULE_AUTHOR("Étienne Bersac <bersace@gmail.com>");
+MODULE_DESCRIPTION("Thermal control logic for iMac G5 (iSight)");
+MODULE_LICENSE("GPL");
+
diff --git a/drivers/macintosh/windfarm_smu_controls.c b/drivers/macintosh/windfarm_smu_controls.c
index 58c2590..961fa0e 100644
--- a/drivers/macintosh/windfarm_smu_controls.c
+++ b/drivers/macintosh/windfarm_smu_controls.c
@@ -218,6 +218,10 @@ static struct smu_fan_control *smu_fan_create(struct device_node *node,
fct->ctrl.name = "cpu-fan";
else if (!strcmp(l, "Hard Drive") || !strcmp(l, "Hard drive"))
fct->ctrl.name = "drive-bay-fan";
+ else if (!strcmp(l, "HDD Fan")) /* seen on iMac G5 iSight */
+ fct->ctrl.name = "hard-drive-fan";
+ else if (!strcmp(l, "ODD Fan")) /* same */
+ fct->ctrl.name = "optical-drive-fan";
/* Unrecognized fan, bail out */
if (fct->ctrl.name == NULL)
^ permalink raw reply related
* [BUILD FAILURE]2.6.24-git{1,2} kernel powerpc linkage failure
From: Kamalesh Babulal @ 2008-01-26 13:23 UTC (permalink / raw)
To: LKML, linuxppc-dev, Linus Torvalds, Andrew Morton, Greg KH,
Andy Whitcroft, Badari Pulavarty
Hi,
The 2.6.24-git2 kernel build fails on the power boxes with following build failure
LD init/built-in.o
LD .tmp_vmlinux1
arch/powerpc/kernel/built-in.o: In function `fphalf':
arch/powerpc/kernel/vector.S:(.toc+0x1428): undefined reference to `devices_subsys'
make: *** [.tmp_vmlinux1] Error 1
This built-failure was seen in the mm broken-out-2007-11-06-02-32, I have tested
the patch posted to lkml at http://lkml.org/lkml/2007/11/6/208 fixes this issue.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c
From: Stefan Roese @ 2008-01-26 13:37 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Roel Kluin, lkml
In-Reply-To: <20080123191704.2d74073a@zod.rchland.ibm.com>
On Thursday 24 January 2008, Josh Boyer wrote:
> On Wed, 23 Jan 2008 23:37:33 +0100
>
> Roel Kluin <12o3l@tiscali.nl> wrote:
> > logical/bitand typo
> >
> > Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
> > ---
> > diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
> > index ebf9e21..dcfb459 100644
> > --- a/arch/powerpc/boot/4xx.c
> > +++ b/arch/powerpc/boot/4xx.c
> > @@ -104,7 +104,7 @@ void ibm4xx_denali_fixup_memsize(void)
> > val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
> > cs = 0;
> > while (val) {
> > - if (val && 0x1)
> > + if (val & 0x1)
> > cs++;
> > val = val >> 1;
> > }
>
> Hm, good catch.
>
> Stefan, have you had problems with this code at all?
I'm not using the bootwrapper on a 4xx with Denali core.
Best regards,
Stefan
^ permalink raw reply
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Kumar Gala @ 2008-01-26 15:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18330.53318.857148.409675@cargo.ozlabs.ibm.com>
On Jan 26, 2008, at 12:16 AM, Paul Mackerras wrote:
> This includes commits pulled from Josh Boyer, Kumar Gala, Grant
> Likely, and Olof Johansson. I reverted the "Fake NUMA emulation for
> PowerPC" commit because it changed behaviour even when the fake numa
> command-line option wasn't given.
>
> I'll be asking Linus to pull within the next few days, so please
> remind me about anything else that should go in 2.6.25.
>
> Paul.
I've got a bunch of patches queued up in my tree that I'll ask you to
pull in the next day or so.
- k
^ permalink raw reply
* Re: [PATCH] FIXED_MII_100_FDX
From: Kumar Gala @ 2008-01-26 15:40 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list, Jeff Garzik, netdev
In-Reply-To: <479AD93D.30202@pikatech.com>
On Jan 26, 2008, at 12:54 AM, Sean MacLennan wrote:
> On the last git pull, FIXED_MII_100_FDX was removed from the phy
> Kconfig, but the Kconfig for CPMAC still tried to select it.
>
> Cheers,
> Sean
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 9af05a2..297a4b5 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1710,7 +1710,6 @@ config CPMAC
> depends on NET_ETHERNET && EXPERIMENTAL && AR7
> select PHYLIB
> select FIXED_PHY
> - select FIXED_MII_100_FDX
> help
> TI AR7 CPMAC Ethernet support
This patch isn't sufficient. AntonV has posted a proper fix that we
need Jeff to pick up.
http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050330.html
- k
^ 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