* Re: [PATCH] powermac: support G5 CPU hotplug
From: Benjamin Herrenschmidt @ 2007-05-03 2:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <15a6025d58d0f62ee10efab20dc98278@kernel.crashing.org>
> Isn't it just a GPIO, like on older Macs? Of course, we
> cannot bring a CPU back online after doing that so it's
> pretty useless I suppose.
We don't know for sure what the gpio does... wether it does a CPU soft
reset or tickles the SPU to make it do special things that cause us to
branch at 0x100. We do get the CPU back after that though. We use that
to bring them in after boot.
Ben.
^ permalink raw reply
* Re: [PATCH 8/13] powerpc: Add arch/powerpc mv64x60_eth platform data setup
From: Stephen Rothwell @ 2007-05-03 2:03 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20070502214312.GC27253@xyzzy.farnsworth.org>
[-- Attachment #1: Type: text/plain, Size: 333 bytes --]
On Wed, 2 May 2007 14:43:12 -0700 "Dale Farnsworth" <dale@farnsworth.org> wrote:
>
> + const void *prop;
Since all uses of this are being cast to "int *" before being
dereferenced, maybe you should declare it as a "const int *".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 6/13] powerpc: Add arch/powerpc interrupt handler for mv64x60
From: Stephen Rothwell @ 2007-05-03 1:47 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20070502213830.GA27253@xyzzy.farnsworth.org>
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
On Wed, 2 May 2007 14:38:30 -0700 "Dale Farnsworth" <dale@farnsworth.org> wrote:
>
> +DEFINE_SPINLOCK(mv64x60_lock);
Does this need to be global (it is not declared in the header file)?
> +static u32 mv64x60_cached_low_mask = 0;
> +static u32 mv64x60_cached_high_mask = MV64X60_HIGH_GPP_GROUPS;
> +static u32 mv64x60_cached_gpp_mask = 0;
Don't initialise things to zero, please. If you feel it is necessary,
put the "= 0" in a comment. But generally we know that globals are
initially zero.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: change topology_init() to a subsys_initcall
From: Michael Ellerman @ 2007-05-03 1:11 UTC (permalink / raw)
To: Kevin Corry; +Cc: linuxppc-dev, Carl Love, linux-kernel, Stephane Eranian
In-Reply-To: <200705021211.49331.kevcorry@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
On Wed, 2007-05-02 at 12:11 -0500, Kevin Corry wrote:
> Change the powerpc version of topology_init() from an __initcall to
> a subsys_initcall to match all other architectures.
>
> Signed-off-by: Kevin Corry <kevcorry@us.ibm.com>
>
> Index: linux-2.6.21/arch/powerpc/kernel/sysfs.c
> ===================================================================
> --- linux-2.6.21.orig/arch/powerpc/kernel/sysfs.c
> +++ linux-2.6.21/arch/powerpc/kernel/sysfs.c
> @@ -498,4 +498,4 @@ static int __init topology_init(void)
>
> return 0;
> }
> -__initcall(topology_init);
> +subsys_initcall(topology_init);
topology_init() depends on the register_one_node() stuff being
available, which relies on register_node_type() being called AFAICT -
which is a postcore_initcall(). So that's OK.
It also creates sysfs files, which is OK because long before initcalls
run vfs_caches_init() called mnt_init() which called sysfs_init().
Just to be super safe it'd be good to diff your sysfs before and after
the change. But assuming that show's nothing this looks fine to me.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] uartlite driver MicroBlaze compatability
From: John Williams @ 2007-05-03 1:08 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <87647b5ofn.fsf@sleipner.barco.com>
Hi Peter,
Peter Korsgaard wrote:
> JW> The attached patch gets your uartlite driver going on MicroBlaze.
>
> Nice!
>
> JW> All readb/writeb ops are converted to ioread32/iowrite32.
>
> JW> On MicroBlaze readb/writeb are picking up the MSB, instead of LSB,
> JW> and thus reading all zeros instead of the 8-bit
> JW> control/status/FIFO registers that you intended.
>
> I take it that the microblaze is big endian? Then you just need to add
> 3 to the base address and everything should work without your patch.
I struggle to see adding 3 to the base address in the platform driver as
a clean solution. The base address of the peripheral is 0x10240000, or
whatever, not 0x10240003.
I understand the reasoning for it, but from the platform's perspective
it seems wrong.
If you read the opb_uartlite datasheet, it says that bits 0-26 of the
FIFO, CTRL and STATUS regs are "reserved". It doesn't say, this is an
8-bit peripheral that is mapped onto a 32bit bus with a stride of 4.
If you also read page 6 , under address map, it says
BASE_ADDRESS+0 : read from receive FIFO
BASE_ADDRESS+4 : write to transmit FIFO
and so on.
It is a 32-bit peripheral, it just so happens the 24 of those bits are
currently "reserved".
Grant's recanting may have been triggered by the figure on page 4 of the
datasheet, which is generic Xilnx IP Core datasheet material explaining
the endian interpretation for different data widths.
> JW> Can you please confirm if this works on PPC?
>
> It won't as ioread/write does big/little endian byte swapping. Isn't
> that done on microblaze?
Not presently, but I will fix that.
I think that's Grant's approach of using in/out_be32, and the real base
address (ie not +3) is the only logically correct solution.
Regards,
John
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Segher Boessenkool @ 2007-05-03 1:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <1178151690.17299.46.camel@localhost.localdomain>
>> The difference between doze and nap is that in nap mode
>> the bus interface unit is switched off; on the 970 and
>> 970FX this means that the L2 cache has to be flushed
>> before entering nap mode (or otherwise snoops will go
>> missing in action);
>
> BZZZT... incorrect... the 970FX and MP behave the same here.
Yeah I goofed here -- cache flush is only required if
you take a CPU offline.
> There is
> only one state you can "manually" enter and it's NAP.
BZZZT... incorrect... you can "manually" switch to
all of doze, nap, and deep nap.
> Transitions
> between DOZE and NAP are automatic to handle snooping in both cases.
> Cache flushing is never needed ... unless in our case the CPU gets
> actually powered down for suspend-to-ram.
Yeah. Or to hot-unplug it ;-)
>> the 970MP automatically transitions
>> from nap to doze mode if snoops are requested (and back
>> to nap again), so no L2 flush is required. The 970MP
>> also has a "deep nap" mode which saves more power by
>> automatically clocking the CPU down.
>
> Also deep nap only really works on 970MP DD3 and later I think
Yes, we put that knowledge into the kernel already.
>> One more thing -- perhaps keeping the CPU in reset
>> state saves even more power?
>
> Dunno... Somebody can try... but I don't think we have access to the
> reset line on 970's..
Isn't it just a GPIO, like on older Macs? Of course, we
cannot bring a CPU back online after doing that so it's
pretty useless I suppose.
Segher
^ permalink raw reply
* Re: RFC: new device types in the device tree (RE: [PATCH] powerpc: Add EDAC platform devices for 85xx)
From: Segher Boessenkool @ 2007-05-03 0:55 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, bluesmoke-devel, Yoder Stuart-B08248
In-Reply-To: <20070503001729.GB4331@localhost.localdomain>
> If there's an obvious new class, with common properties, then yes,
> sure. But I don't think we need to feel impelled to think up new
> classes (and therefore a device_type value) for each new device.
>
> And even in the case of new classes, I think we might be best off
> waiting for a few devices to appear so we can tell what's really
> common information before we define the class's device_type and
> required properties.
Nicely put, thanks.
Segher
^ permalink raw reply
* Re: RFC: new device types in the device tree (RE: [PATCH] powerpc: Add EDAC platform devices for 85xx)
From: Segher Boessenkool @ 2007-05-03 0:54 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev, bluesmoke-devel, David Gibson
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA302D5E1A9@az33exm25.fsl.freescale.net>
> But, don't we want to keep standardized sets of properties for
> certain classes/types of devices?
Sure.
> Defining a standardized,
> required set of properties for a "network", "rom", or "i2c"
> class of device is helpful.
Only if such a device binding is generic enough to actually
handle all such devices. Sure a specific device may have
some extra properties, but all the basic stuff should be
in standard properties.
> Without a standardized 'template'
> of properties, developers may make up whatever properties they
> want and things will work fine as long as the device tree and
> driver are in sync. It works, but you wind up with a plethora
> of properties each describing the same thing.
You might think this is bad, but IMO it is better to
have several drivers doing similar things in different
ways, than to force all drivers to use a binding that
doesn't fit them well.
> If we do away with device_type,
> what is it that defines a particular node to be a certain class
> of device.
The matching device driver knows (and it knows a great
deal more about the device, hopefully ;-) )
Segher
^ permalink raw reply
* Re: [PATCH] add smp_call_function_map and smp_call_function_single
From: Michael Ellerman @ 2007-05-03 0:53 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus, anton, Kevin Corry
In-Reply-To: <20070502171234.13831.8483.stgit@farscape.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
On Wed, 2007-05-02 at 12:12 -0500, Will Schmidt wrote:
> Add a new function named smp_call_function_single(). This matches a generic
> prototype from include/linux/smp.h.
>
> Add a function smp_call_function_map(). This is, for the most part, a rename
> of smp_call_function, with some added cpumask support. smp_call_function and
> smp_call_function_single call into smp_call_function_map.
>
> Lightly tested on 970mp (blade), power4 and power5.
>
> Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
> cc: Anton Blanchard <anton@samba.org>
> ---
>
> arch/powerpc/kernel/smp.c | 73 ++++++++++++++++++++++++++++++++-------------
> 1 files changed, 52 insertions(+), 21 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 924d692..4878588 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -176,10 +176,10 @@ static struct call_data_struct {
> #define SMP_CALL_TIMEOUT 8
>
> /*
> - * This function sends a 'generic call function' IPI to all other CPUs
> - * in the system.
> + * These functions send a 'generic call function' IPI to other online
> + * CPUS in the system.
> *
> - * [SUMMARY] Run a function on all other CPUs.
> + * [SUMMARY] Run a function on other CPUs.
> * <func> The function to run. This must be fast and non-blocking.
> * <info> An arbitrary pointer to pass to the function.
> * <nonatomic> currently unused.
While you're there, or as a separate patch, can you fix up this
not-quite-kernel-doc commenting?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RFC: new device types in the device tree (RE: [PATCH] powerpc: Add EDAC platform devices for 85xx)
From: Segher Boessenkool @ 2007-05-03 0:48 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev, david, bluesmoke-devel
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA302D5E195@az33exm25.fsl.freescale.net>
>>> The 1275 spec is 'Open Firmware centric' in that it says
>>> you don't need a device_type if the node is not used
>>> by Open Firmware.
>>
>> It is "Open firmware centric" in every way; it is
>> the Open firmware definition after all.
>>
>> "device_type" specifies what firmware interfaces a
>> node implements. "name" and "compatible" are for
>> the client (i.e., OS, bootloader, etc.) to use for
>> matching drivers to device nodes.
>
> The flat device tree standard (i.e. booting-without-of.txt)
> certainly inherited stuff from IEEE-1275, but can diverge
> if need be.
It shares the kernel interface. You cannot go diverge
on fundamental things.
> name is always optional (as defined by b-w-of.txt)
Where does it say that? "name" is always required! In
the newer flat tree format, it's even impossible to
create a node without "name".
> There are no interfaces or methods with the device trees
> defined in DTS files. Given that, does the the device_type
> property have any value at all?
Not much, but still a bit, like you can find all
"serial" devices if you want to. And of course,
many bindings require a specific "device_type",
so you should have one.
> There are a slew of device_types defined in the DTS files
> and in booting-without-of.txt. Should all these be
> removed?
Most should yes.
>> It typically makes no sense to create a new "device_type"
>> value for anything else than very generic classes of
>> device, where you can drive the device without knowing
>> anything else than what is defined in the binding for
>> that "device_type".
>
> What types devices get a device_type and which don't? Linux
> drives the devices based on "compatible".
No, Linux selects which driver to use based on "compatible".
That's a crucial difference.
>> And the associated methods and anything else that is
>> needed. It would be a big mistake to create incompatibilities
>> with "real OF" where those can be avoided just as easily.
>
> But there are no methods.
Again, you should not create incompatibilities where
not needed. Since "device_type" is primarily useful
for (talking to / using) the firmware, and hardly
useful at all for the flat device tree, the flat tree
"standard" shouldn't define new "device_type"s without
making it a real OF binding.
> Even if the kernel does not use 'device_type', the property
> still seems to have some value in that it specifies a
> required set of properties and their values for various
> classes of devices.
Sure. "network", "block", "serial", etc.
> Take a flash device for instance--
Yes, "flash" could be made into a nice generic binding
(except that no one has succeeded so far, there are just
way too many different kinds of flash/rom/nvram, and
many ways to hook them up).
> I suppose we can delete the device_type property and the
> kernel will still be happy, but it's nice to have a standard
> set of properties that everyone uses when describing a given
> class of device. The device_type is just a convenient
> identifer to refer to this device class and set of properties.
Unfortunately, there is no standard "device_type" for
flash yet.
Segher
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Benjamin Herrenschmidt @ 2007-05-03 0:24 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <1178151690.17299.46.camel@localhost.localdomain>
On Thu, 2007-05-03 at 10:21 +1000, Benjamin Herrenschmidt wrote:
> > The difference between doze and nap is that in nap mode
> > the bus interface unit is switched off; on the 970 and
> > 970FX this means that the L2 cache has to be flushed
> > before entering nap mode (or otherwise snoops will go
> > missing in action);
>
> BZZZT... incorrect... the 970FX and MP behave the same here. There is
> only one state you can "manually" enter and it's NAP.
Actually, I'm not totally correct here neither, that's what 745x does...
the 970 _do_ give manual access to DOZE. But the rest is still true, it
will transition automatically to do snoops.
> Transitions
> between DOZE and NAP are automatic to handle snooping in both cases.
> Cache flushing is never needed ... unless in our case the CPU gets
> actually powered down for suspend-to-ram.
>
> > the 970MP automatically transitions
> > from nap to doze mode if snoops are requested (and back
> > to nap again), so no L2 flush is required. The 970MP
> > also has a "deep nap" mode which saves more power by
> > automatically clocking the CPU down.
>
> Also deep nap only really works on 970MP DD3 and later I think
>
> > One more thing -- perhaps keeping the CPU in reset
> > state saves even more power?
>
> Dunno... Somebody can try... but I don't think we have access to the
> reset line on 970's..
>
> Ben.
>
>
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Benjamin Herrenschmidt @ 2007-05-03 0:21 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <f885d6b1472525fb5bebdd96ae4c3157@kernel.crashing.org>
> The difference between doze and nap is that in nap mode
> the bus interface unit is switched off; on the 970 and
> 970FX this means that the L2 cache has to be flushed
> before entering nap mode (or otherwise snoops will go
> missing in action);
BZZZT... incorrect... the 970FX and MP behave the same here. There is
only one state you can "manually" enter and it's NAP. Transitions
between DOZE and NAP are automatic to handle snooping in both cases.
Cache flushing is never needed ... unless in our case the CPU gets
actually powered down for suspend-to-ram.
> the 970MP automatically transitions
> from nap to doze mode if snoops are requested (and back
> to nap again), so no L2 flush is required. The 970MP
> also has a "deep nap" mode which saves more power by
> automatically clocking the CPU down.
Also deep nap only really works on 970MP DD3 and later I think
> One more thing -- perhaps keeping the CPU in reset
> state saves even more power?
Dunno... Somebody can try... but I don't think we have access to the
reset line on 970's..
Ben.
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Segher Boessenkool @ 2007-05-03 0:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <1178150936.17299.37.camel@localhost.localdomain>
> Ah... hrm... so it's possible that Darwin goes NAP but flushes the
> cache
> before suspend-to-ram bcs the CPU is going down... let me check.
>
> Nah, darwin uses HID0:sleep
Which bit # is that? I cannot find it :-)
Segher
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Benjamin Herrenschmidt @ 2007-05-03 0:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <3b16ca8bab1f2f05ea9c1f25e1010464@kernel.crashing.org>
On Thu, 2007-05-03 at 02:05 +0200, Segher Boessenkool wrote:
> >>> They have, but the cache flush is not trivial to do (and might imply
> >>> access to non documented bits).
> >>
> >> It is (publicly) documented just fine :-)
> >
> > Ah good... you happen to have a pointer ? Last I looked, it wasn't ...
>
> It's in the UM, search for "L2 cache flush".
Ah yes, it's there for recent UM.
So, to summarize:
- 970 only does NAP, not SLEEP
- We should probably still flush the cache when bringing a CPU down
because we might implement STR in which case the machine will go
down and we won't get a chance to flush that CPU cache then.
Also, I always wondered what happened if you entered NAP without MSR:EE,
and so I checked the 970 UM and it's clearly undefined behaviour. Thus
we must make sure we always set EE, and we can "use" the trick of having
soft-disable to just return where we came from and re-enter NAP if we
got woken up by the DEC. I agree with Paulus, Johannes, we should just
do a separate routine for the CPU going down vs. Idle. Among others,
we'll also add the cache flush there.
Cheers,
Ben.
^ permalink raw reply
* Re: RFC: new device types in the device tree (RE: [PATCH] powerpc: Add EDAC platform devices for 85xx)
From: David Gibson @ 2007-05-03 0:17 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev, bluesmoke-devel
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA302D5E1A9@az33exm25.fsl.freescale.net>
On Wed, May 02, 2007 at 12:04:11PM -0700, Yoder Stuart-B08248 wrote:
>
>
> > -----Original Message-----
> > From: David Gibson [mailto:david@gibson.dropbear.id.au]
> > Sent: Tuesday, May 01, 2007 8:20 PM
> > To: Segher Boessenkool
> > Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org;
> > bluesmoke-devel@lists.sourceforge.net
> > Subject: Re: RFC: new device types in the device tree (RE:
> > [PATCH] powerpc: Add EDAC platform devices for 85xx)
> >
> > On Wed, May 02, 2007 at 02:34:45AM +0200, Segher Boessenkool wrote:
> > > >> "name" = "memory-controller"
> > > >> "compatible" = "fsl,85xx-memory-controller"
> > > >> (or a more specific 85xx model if the controller
> > > >> isn't identical across those chips)
> > > >> No "device_type" at all, since there is no binding
> > > >> for this kind of device.
> > > >
> > > > Is "no device_type" really the approach that should be
> > > > taken?
> > >
> > > Yes.
> > >
> > > > booting-without-of.txt currently reads:
> > > >
> > > > Every node which actually represents an actual device
> > > > (that is, a node which isn't only a virtual "container"
> > > > for more nodes, like "/cpus" is) is also required to
> > > > have a "device_type" property indicating the type of
> > > > node
> > >
> > > That is wrong, IMNSHO.
> >
> > I tend to agree. Device drivers should generally be searching on the
> > "compatible" property, not "device_type". Defining new device_type
> > values isn't really of any use to the kernel, so we should just avoid
> > it.
>
> Right-- drivers search on "compatible".
>
> But, don't we want to keep standardized sets of properties for
> certain classes/types of devices? Defining a standardized,
> required set of properties for a "network", "rom", or "i2c"
> class of device is helpful. Without a standardized 'template'
> of properties, developers may make up whatever properties they
> want and things will work fine as long as the device tree and
> driver are in sync. It works, but you wind up with a plethora
> of properties each describing the same thing.
If there's an obvious new class, with common properties, then yes,
sure. But I don't think we need to feel impelled to think up new
classes (and therefore a device_type value) for each new device.
And even in the case of new classes, I think we might be best off
waiting for a few devices to appear so we can tell what's really
common information before we define the class's device_type and
required properties.
> If we do away with device_type,
> what is it that defines a particular node to be a certain class
> of device.
I'm not suggesting doing away with device_type, just making it
optional.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Segher Boessenkool @ 2007-05-03 0:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <17977.9796.15991.630737@cargo.ozlabs.ibm.com>
>>>> Ultimately we want to put the disabled cpus in sleep mode, but that
>>>> will require a suitable cache flush routine.
>>>
>>> I don't have any docs for the particular processors the G5s have, do
>>> they have a sleep mode?
>>
>> They have, but the cache flush is not trivial to do (and might imply
>> access to non documented bits). So let's put that on the to-do list
>> and
>> stick to NAP for now while I dig something.
>
> Hmmm, I went looking in the 970FX manual for sleep mode and didn't
> find it, only nap and doze...
"Sleep" is a generic term for both "doze" and "nap", heh.
The difference between doze and nap is that in nap mode
the bus interface unit is switched off; on the 970 and
970FX this means that the L2 cache has to be flushed
before entering nap mode (or otherwise snoops will go
missing in action); the 970MP automatically transitions
from nap to doze mode if snoops are requested (and back
to nap again), so no L2 flush is required. The 970MP
also has a "deep nap" mode which saves more power by
automatically clocking the CPU down.
One more thing -- perhaps keeping the CPU in reset
state saves even more power?
Segher
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Benjamin Herrenschmidt @ 2007-05-03 0:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <1178150936.17299.37.camel@localhost.localdomain>
> Ah... hrm... so it's possible that Darwin goes NAP but flushes the cache
> before suspend-to-ram bcs the CPU is going down... let me check.
>
> Nah, darwin uses HID0:sleep
Ahhh nooo .... there's a special code path for 64 bits CPUs and indeed,
it uses NAP.
Ben.
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Benjamin Herrenschmidt @ 2007-05-03 0:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <17977.9796.15991.630737@cargo.ozlabs.ibm.com>
On Thu, 2007-05-03 at 10:01 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > On Wed, 2007-05-02 at 16:33 +0200, Johannes Berg wrote:
> > > On Wed, 2007-05-02 at 20:55 +1000, Paul Mackerras wrote:
> > >
> > > > Ultimately we want to put the disabled cpus in sleep mode, but that
> > > > will require a suitable cache flush routine.
> > >
> > > I don't have any docs for the particular processors the G5s have, do
> > > they have a sleep mode?
> >
> > They have, but the cache flush is not trivial to do (and might imply
> > access to non documented bits). So let's put that on the to-do list and
> > stick to NAP for now while I dig something.
>
> Hmmm, I went looking in the 970FX manual for sleep mode and didn't
> find it, only nap and doze...
Ah... hrm... so it's possible that Darwin goes NAP but flushes the cache
before suspend-to-ram bcs the CPU is going down... let me check.
Nah, darwin uses HID0:sleep
Ben.
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Segher Boessenkool @ 2007-05-03 0:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <1178150380.17299.34.camel@localhost.localdomain>
>>> They have, but the cache flush is not trivial to do (and might imply
>>> access to non documented bits).
>>
>> It is (publicly) documented just fine :-)
>
> Ah good... you happen to have a pointer ? Last I looked, it wasn't ...
It's in the UM, search for "L2 cache flush".
Segher
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Paul Mackerras @ 2007-05-03 0:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <1178143429.17299.7.camel@localhost.localdomain>
Benjamin Herrenschmidt writes:
> On Wed, 2007-05-02 at 16:33 +0200, Johannes Berg wrote:
> > On Wed, 2007-05-02 at 20:55 +1000, Paul Mackerras wrote:
> >
> > > Ultimately we want to put the disabled cpus in sleep mode, but that
> > > will require a suitable cache flush routine.
> >
> > I don't have any docs for the particular processors the G5s have, do
> > they have a sleep mode?
>
> They have, but the cache flush is not trivial to do (and might imply
> access to non documented bits). So let's put that on the to-do list and
> stick to NAP for now while I dig something.
Hmmm, I went looking in the 970FX manual for sleep mode and didn't
find it, only nap and doze...
Paul.
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Benjamin Herrenschmidt @ 2007-05-02 23:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <8dffc34312d10f0f93c7adfe9ec60003@kernel.crashing.org>
On Thu, 2007-05-03 at 01:47 +0200, Segher Boessenkool wrote:
> >> I don't have any docs for the particular processors the G5s have, do
> >> they have a sleep mode?
> >
> > They have, but the cache flush is not trivial to do (and might imply
> > access to non documented bits).
>
> It is (publicly) documented just fine :-)
Ah good... you happen to have a pointer ? Last I looked, it wasn't ...
Ben.
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Segher Boessenkool @ 2007-05-02 23:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <1178143429.17299.7.camel@localhost.localdomain>
>> I don't have any docs for the particular processors the G5s have, do
>> they have a sleep mode?
>
> They have, but the cache flush is not trivial to do (and might imply
> access to non documented bits).
It is (publicly) documented just fine :-)
Segher
^ permalink raw reply
* Re: [PATCH v2] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Segher Boessenkool @ 2007-05-02 23:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <4638F734.2040809@freescale.com>
>>> And the driver is already ppc-specific; it uses in/out_be32.
>>
>> True, but its hidden behind the gfar_read/write accessors.
>>
>> Your change is a bit more blatant.
>
> Well, Segher doesn't want me to use iobarrier (because it's not I/O).
> Andy doesn't want me to use wmb() (because it's sync).
You should use wmb(), but unfortunately too strong
semantics are required for that (ordering wrt I/O)
so it's a full sync on PowerPC. I don't believe
a priori that that would be notably slower, but if
actually is, you could use eieio() I suppose since
you say the driver is powerpc specific -- but please
put a comment in the source code then saying why you
don't use wmb() there.
Segher
^ permalink raw reply
* Re: How do external irq's get mapped?
From: Andy Fleming @ 2007-05-02 22:43 UTC (permalink / raw)
To: Charles Krinke; +Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A201@MERCURY.inside.istor.com>
On May 2, 2007, at 17:11, Charles Krinke wrote:
>> The new problem is that if I set the irq to 112, when it is
>> insmodded, I
>> get an error from open_pic.c of the form:
>>
>> Open_pic.c:720 invalid irq 112
>>
>> This seems to be coming from the macro at line 144 in open_pic.c
>>
>> #define check_arg_irq(irq) \
>> if (irq < open_pic_irq_offset || irq >=
>> NumSources+open_pic_irq_offset \
>> || ISR[irq - open_pic_irq_offset] == 0) { \
>> printk("open_pic.c:%d: invalid irq %d\n", __LINE__, irq); \
>> dump_stack(); }
>
>
> Any chance you can identify:
>
> 1) Where this macro is being called from when it fails
>
> 2) Which of the 3 conditions above are actually true
>
> Andy
>
> Dear Andy:
>
> In our system, open_pic_irq_offset=80, numSources=60, *but* ISR[irq -
> open_pic_irq_offset]=NULL when irq 112 is enabled.
>
> It looks to me like each call to openpic_set_sources inits ISR[]
> elements according to the first two arguments. We have two calls to
> openpic_set_sources.
>
> Internal irqs 00..31, 1st openpic_set_sources(0, 32) -- ISR[0..32]
> External irqs 48..60, 2nd openpic_set_sources(48, 12) -- ISR[48..60]
Heh. Whoops! I didn't see the gap. 112-127 are, indeed, unmapped
in this implementation. Sorry about that. You're going to want 80
+48 = 128 for EXT0
>
> But ISR[112] is never initialized in the source base.
>
> I tried the cheap shot of adding a third openpic_set_sources(112, 12),
> but I suspect the real answer is a bit more complicated then that.
Yeah, that would set up interrupts from 192 to 203, which *also*
don't exist.
Andy
^ permalink raw reply
* RE: PTE entries
From: Benjamin Herrenschmidt @ 2007-05-02 22:12 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D762D0F8@corpexc01.corp.networkrobots.com>
On Wed, 2007-05-02 at 12:58 -0700, Siva Prasad wrote:
> Hi Ben,
>
> First,
> Are there any other places where we have self modifying code in Linux
> kernel, other than in arch/powerpc/mm/ppc_mmu_32.c:MMU_init_hw()
> (basically modified create_hpte and flush_hash_page)
There is the cpu feature fixup code, there might also be something
around the SMP code.
> Second,
> Instead of using addis, why can't we move it from SDR1 register and mask
> the second half. SDR1 has the required value. Right?
> May be I am missing something here.
Would be slower. Accessing SPRs is slow.
^ 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