* Re: [PATCH] [2/2] POWERPC: Lower threshold for DART enablement to 1GB, V2
From: Benjamin Herrenschmidt @ 2006-04-13 22:38 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20060413222721.GN24769@pb15.lixom.net>
On Thu, 2006-04-13 at 17:27 -0500, Olof Johansson wrote:
> On Fri, Apr 14, 2006 at 06:51:55AM +1000, Benjamin Herrenschmidt wrote:
>
> > an improvement with the DART thanks to virtual merging. Currently, we
> > pay a cost due to our stupid invalidate mecanism that we should really
> > fix by shooting the TLB directly.
>
> What was keeping me from implementing this before was the lack of public
> documentation on how to do it. Has that changed? I'd be happy to do the
> implementation.
Darwin has the macros to access the TLB though it doesn't use them... I
suppose I can get the necessary doco bit from the microelectronics folks
for the CPC925, that should apply to U3 as well, though U4 has a
different format afaik. I'll dig and will come back to you.
> > Also have you made sure all your
> > additions for handling crappy hardware are nicely wrapped in unlikely()
> > statements ? :)
>
> I would expect the dynamic predictor to work quite well on this. I'm not
> worried about the overhead of the tests as much as the overhead of
> having to enable the DART for smaller configs. If benchmark profiling
> shows different down the road then we can add them.
Ok.
Ben.
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Olof Johansson @ 2006-04-13 22:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, Paul Mackerras,
linuxppc-dev list
In-Reply-To: <1144967841.4935.32.camel@localhost.localdomain>
On Fri, Apr 14, 2006 at 08:37:21AM +1000, Benjamin Herrenschmidt wrote:
> I need to verify what's up with the 970. I noticed Apple has some
970 keeps executing too. I guess it's never bitten hard enough to
trigger anything serious.
-Olof
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Benjamin Herrenschmidt @ 2006-04-13 23:12 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <5148225C-AE27-4365-A1C2-40C46491AF0D@watson.ibm.com>
On Wed, 2006-04-12 at 22:05 -0400, Jimi Xenidis wrote:
> A devtree compiler (dtc) generated devtree blob is "relocatable" and
> so does not contain a reserved_map entry for the blob itself.
> This means that if passed to Linux, Linux will not get lmb_reserve()
> the blob and it could be over.
> The following patch will explicitly reserve the "blob" as it was
> given to us and stops prom_init.c from creating a reserved mapping
> for the blob.
>
> NOTE: that the dtc must also not generate the blob reservation
> entry. Should we try to detect this redundant entry? Should we bump
> the DT version number?
We should make lmb_reserve() of redudant/overlapping entries become
harmless I think. We need to be backward compatible with earlier blobs
that do contain themselves in the reserve map
Ben.
^ permalink raw reply
* patch for powerpc lparcfg.c
From: Carl Love @ 2006-04-13 23:09 UTC (permalink / raw)
To: linuxppc-dev, cel
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
I created the attached patch to print the partition name along with the
other partition information reported in /proc/ppc64/lparcfg for the
powerpc systems. The patch adds a single line of code to the
arch/powerpc/kernel/lparcfg.c file. I tested the code on a power5 box.
I would suggest adding the same line to the I series code at line 101 so
the partition name is printed on I series hardware as well. Since I
don't have access to I series hardware to test on I did not include this
change in my patch file.
Carl Love
[-- Attachment #2: linux-2.6.17-rc1-git8-lparcfg.patch --]
[-- Type: text/x-patch, Size: 593 bytes --]
diff -rauN -X /home/carll/dontdiff linux-2.6.17-rc1-git8/arch/powerpc/kernel/lparcfg.c linux-2.6.17-rc1-git8-new/arch/powerpc/kernel/lparcfg.c
--- linux-2.6.17-rc1-git8/arch/powerpc/kernel/lparcfg.c 2006-04-13 12:25:11.000000000 -0700
+++ linux-2.6.17-rc1-git8-new/arch/powerpc/kernel/lparcfg.c 2006-04-13 15:29:02.000000000 -0700
@@ -360,6 +360,9 @@
seq_printf(m, "system_type=%s\n", model);
+ seq_printf(m, "partition_name=%s\n",
+ get_property(rootdn, "ibm,partition-name", NULL));
+
seq_printf(m, "partition_id=%d\n", (int)lp_index);
rtas_node = find_path_device("/rtas");
^ permalink raw reply
* Re: patch for powerpc lparcfg.c
From: Nathan Lynch @ 2006-04-14 0:25 UTC (permalink / raw)
To: Carl Love; +Cc: linuxppc-dev
In-Reply-To: <1144969793.5286.10.camel@dyn9047021119.beaverton.ibm.com>
Carl Love wrote:
>
> I created the attached patch to print the partition name along with the
> other partition information reported in /proc/ppc64/lparcfg for the
> powerpc systems.
> diff -rauN -X /home/carll/dontdiff linux-2.6.17-rc1-git8/arch/powerpc/kernel/lparcfg.c linux-2.6.17-rc1-git8-new/arch/powerpc/kernel/lparcfg.c
> --- linux-2.6.17-rc1-git8/arch/powerpc/kernel/lparcfg.c 2006-04-13 12:25:11.000000000 -0700
> +++ linux-2.6.17-rc1-git8-new/arch/powerpc/kernel/lparcfg.c 2006-04-13 15:29:02.000000000 -0700
> @@ -360,6 +360,9 @@
>
> seq_printf(m, "system_type=%s\n", model);
>
> + seq_printf(m, "partition_name=%s\n",
> + get_property(rootdn, "ibm,partition-name", NULL));
> +
Who or what is the intended consumer of this information?
You should probably check get_property's return value and print the
partition_name line only if it is non-NULL.
^ permalink raw reply
* Trouble with 2.6.16 on ppc8xx ?
From: David Jander @ 2006-04-14 8:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I just cg-update'd to the HEAD of the denx 2.6.x kernel tree (2.6.16 as
released).
Our board-support stuff was succesfully moved along from 2.6.14 (when
everything but the SCC3 and SCC4 uarts worked just fine).
I compiled a kernel without any special drivers, just console on ttyCPM0, but
after "Uncompressing Kernel Image ... OK" there is no more output and no
further activity on ethernet (it should boot from nfs-root) or any other
device.
After "cg-seek DENX-v2.6.15; make clean uImage", it works again (everything
seems fine, system boots).
Our board is based on a MPC852T and until now we used "MPC86X" as the
BOARD_CHIP_NAME and it worked just fine with 2.6.14 and 2.6.15, but not with
2.6.16 as described above.
When doing "cg-diff" and carfully examining it's output, I can only see our
board-support stuff (not very much, not very special) and some custom drivers
that are disabled anyway.
Any clue about where to start looking?
I didn't find any suspicious changes in arch/ppc/mm, arch/ppc/syslib and
arch/ppc/kernel. Neither in drivers/serial/cpm_uart.
Which change from 2.6.15 to 2.6.16 could have broken 8xx support for us?
Is there perhaps a known issue with 2.6.16 and ppc8xx I am unaware of?
Greetings,
--
David Jander
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch] cell: correctly detect systemsim host
From: Joel Schopp @ 2006-04-14 9:23 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Christian Krafft, cbe-oss-dev, linuxppc-dev
In-Reply-To: <200604131344.26392.arnd.bergmann@de.ibm.com>
>> Systemsim uses a different compatible property in the device tree.
>>
>> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
>
> Thanks.
>
> I'm wondering if we should have that upstream, since some
> more patches are currently required to run on systemsim
> anyway. For now, I'll keep it in my tree.
It is clean enough to go upstream and doesn't depend on anything else,
so I say put it upstream. That's just one less patch to carry outside
of mainline. No reason to punish perfectly good patches just because
the rest of the systemsim stuff isn't ready yet.
-Joel
Acked-by: Joel Schopp <jschopp@austin.ibm.com>
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jimi Xenidis @ 2006-04-14 12:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1144969933.4935.45.camel@localhost.localdomain>
On Apr 13, 2006, at 7:12 PM, Benjamin Herrenschmidt wrote:
>
> We should make lmb_reserve() of redudant/overlapping entries become
> harmless I think.
Hmm.. I think it would be worthy of a warning, no?
> We need to be backward compatible with earlier blobs
> that do contain themselves in the reserve map
Do you think it is possible that the blob may have a single
reservation that includes the blob but is larger? if not then we
could simply do..
--
diff -r eb0990a251a9 arch/powerpc/kernel/prom.c
--- a/arch/powerpc/kernel/prom.c Thu Mar 30 22:05:40 2006 -0500
+++ b/arch/powerpc/kernel/prom.c Fri Apr 14 08:44:10 2006 -0400
@@ -1129,9 +1129,17 @@ static void __init early_reserve_mem(voi
{
u64 base, size;
u64 *reserve_map;
+ unsigned long self_base;
+ unsigned long self_size;
reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
initial_boot_params->off_mem_rsvmap);
+
+ /* before we do anything, lets reserve the dt blob */
+ self_base = __pa((unsigned long)initial_boot_params);
+ self_size = initial_boot_params->totalsize;
+ lmb_reserve(self_base, self_size);
+
#ifdef CONFIG_PPC32
/*
* Handle the case where we might be booting from an old kexec
@@ -1146,6 +1154,9 @@ static void __init early_reserve_mem(voi
size_32 = *(reserve_map_32++);
if (size_32 == 0)
break;
+ /* skip if the reservation is for the blob */
+ if (base_32 == self_base && size_32 == self_size)
+ continue;
DBG("reserving: %x -> %x\n", base_32, size_32);
lmb_reserve(base_32, size_32);
}
@@ -1157,6 +1168,9 @@ static void __init early_reserve_mem(voi
size = *(reserve_map++);
if (size == 0)
break;
+ /* skip if the reservation is for the blob */
+ if (base == self_base && size == self_size)
+ continue;
DBG("reserving: %llx -> %llx\n", base, size);
lmb_reserve(base, size);
}
^ permalink raw reply
* Linux with CAN over SPI
From: Mike.Johnson @ 2006-04-14 12:37 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: Mike.Johnson
All,
I'm looking for some information about a CAN driver and how it might
nterface to an SPI port of the PPC 875 processor.
I am new to the linux world and am trying to write a CAN device driver that
uses SPI to communicate to the external CAN chip.
The latest kernel has some CAN and SPI support. I am beginning to put some
of the pieces together on how these work, but It's new to me how these are
truly instantiated and implemented in the kernel.
Does anyone know of a white paper or any documentation that may explain the
general process of a network device driver installation? (I do know that
the CAN driver is considered a network interface, not a "char" or "block"
interface.)
What is the order of steps to initialize the SPI driver? I'm guessing the
SPI driver need to be initialized before it can detect the presents of the
CAN chip.
Does the CAN driver try to talk to the CAN chip via SPI to determine its
existance?
These are the questions I'm hoping to fill in.
I have been reading the O'reilly book on device drivers...this helps
some.....but any other real world help would be appreciated.
Thank-you,
Mike
Michael Johnson
American Power Conversion
132 Fairgrounds Road
West Kingston, RI 02892
tele: (401) 789 - 5735 x2982
http://www.apc.com
http://www.netbotz.com
http://www.datacenteruniversity.com
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Mel Gorman @ 2006-04-14 13:12 UTC (permalink / raw)
To: Luck, Tony; +Cc: davej, linuxppc-dev, ak, bob.picco, linux-kernel, linux-mm
In-Reply-To: <20060413215358.GA15957@agluck-lia64.sc.intel.com>
On (13/04/06 14:53), Luck, Tony didst pronounce:
> On Thu, Apr 13, 2006 at 08:14:02PM +0100, Mel Gorman wrote:
> > When you get around to it later, there is one case you may hit that Bob
> > Picco encountered and fixed for me. It's where a "new" range is registered
> > that is inside an existing area; e.g.
> >
> > add_active_range: 0->10000
> > add_active_range: 9800->10000
> >
> > It ends up merging incorrectly and you end up with one region from
> > 9800-10000. The fix is below.
>
> I applied that fix on top of all the others and re-built and booted
> a "generic" kernel (using arch/ia64/defconfig) and a "sparse" kernel
> (based on arch/ia64/configs/gensparse_defconfig).
>
> Both booted just fine on my tiger, the memory amounts looked
> a bit suspicious though ... as if you are reporting *all* the
> memory in range for the zone, rather than the usable parts.
>
> Diffing console log from the boot of a 2.6.17-rc1 generic
> kernel against one with your patches the relevent bit is:
>
> < On node 0 totalpages: 259873
> < DMA zone: 128931 pages, LIFO batch:7
> < Normal zone: 130942 pages, LIFO batch:7
> ---
> > On node 0 totalpages: 262144
> > DMA zone: 131072 pages, LIFO batch:7
> > Normal zone: 131072 pages, LIFO batch:7
>
> That's a very precise 4G total, split exactly 2G+2G between
> DMA and normal zones. Same thing for the sparse kernel
> (though I didn't check what an unpatched kernel prints).
>
Interesting. I register active ranges inside count_node_pages() which is an
EFI memmap_walk callback. So, I'd expect to see one call to add_active_range()
for each active range in the EFI map;
> add_active_range(0, 0, 4096): New
> add_active_range(0, 0, 131072): Merging forward
> add_active_range(0, 0, 131072): Existing
> add_active_range(0, 393216, 523264): New
> add_active_range(0, 393216, 523264): Existing
> add_active_range(0, 393216, 524288): Merging forward
> add_active_range(0, 393216, 524288): Existing
That appears fine, but I call add_active_range() after a GRANULEROUNDUP and
GRANULEROUNDDOWN has taken place so that might be the problem, especially as
all those ranges are aligned on a 16MiB boundary. The following patch calls
add_active_range() before the rounding takes place. Can you try it out please?
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-zonesizing-v6/arch/ia64/mm/discontig.c linux-2.6.17-rc1-107-debug/arch/ia64/mm/discontig.c
--- linux-2.6.17-rc1-zonesizing-v6/arch/ia64/mm/discontig.c 2006-04-13 10:30:49.000000000 +0100
+++ linux-2.6.17-rc1-107-debug/arch/ia64/mm/discontig.c 2006-04-14 11:37:51.000000000 +0100
@@ -636,6 +636,7 @@ static __init int count_node_pages(unsig
{
unsigned long end = start + len;
+ add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);
mem_data[node].num_physpages += len >> PAGE_SHIFT;
if (start <= __pa(MAX_DMA_ADDRESS))
mem_data[node].num_dma_physpages +=
@@ -647,7 +648,6 @@ static __init int count_node_pages(unsig
end >> PAGE_SHIFT);
mem_data[node].min_pfn = min(mem_data[node].min_pfn,
start >> PAGE_SHIFT);
- add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);
return 0;
}
^ permalink raw reply
* Re: Freescale 8272ADS configuration
From: Krishnan @ 2006-04-14 13:40 UTC (permalink / raw)
To: Linuxppc-Embedded@Ozlabs. Org
Hi Carlos,
I found two interesting documents on the Web (one from a grad student and
other from Freescale website). Both are generic steps from U-BOOT porting to
Linux bring up. I don't know which kernel you decide to use but these are
quite useful to read to get very good inputs.
I have both these documents (they are for 860 and 8260 but as Wolfgang
mentioned) these are very closely related as they are the same family. I
cannot attach documents more than 100 KB on this list.
One more "WAR Story" for you too from helicontech
http://www.helicontech.co.il/whitepapers/LinuxBringUp.html
Cheers,
Krishnan
^ permalink raw reply
* bisect results for powerbook G4 not booting on latest git tree
From: Aristeu Sergio Rozanski Filho @ 2006-04-14 13:31 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I was unable to find someone who already did it, so here it
the possible culprit of latest git tree (pulled both Linus' and
Paul's tree) not booting on a powerbook G4:
a0652fc9a28c3ef8cd59264bfcb089c44d1b0e06 is first bad commit
diff-tree a0652fc9a28c3ef8cd59264bfcb089c44d1b0e06 (from 55aab8cd3a498201b769a19de861c77516bdfd45)
Author: Paul Mackerras <paulus@samba.org>
Date: Mon Mar 27 15:03:03 2006 +1100
powerpc: Unify the 32 and 64 bit idle loops
This unifies the 32-bit (ARCH=ppc and ARCH=powerpc) and 64-bit idle
loops. It brings over the concept of having a ppc_md.power_save
function from 32-bit to ARCH=powerpc, which lets us get rid of
native_idle(). With this we will also be able to simplify the idle
handling for pSeries and cell.
Signed-off-by: Paul Mackerras <paulus@samba.org>
:040000 040000 c6998a13a214b16c0cb936526d9e087095530eb39282cff1b1d6a5893c17319c0fbe13d93f5369f7 M arch
:040000 040000 44489477a1708a022f564892e233207434ab79ee78d125804d5c52fef1ebc089bce121773bc8f5b7 M include
if there's any other info that I can provide or a patch to try, please
let me know
--
Aristeu
^ permalink raw reply
* Re: [PATCH] [2/2] POWERPC: Lower threshold for DART enablement to 1GB, V2
From: Muli Ben-Yehuda @ 2006-04-14 14:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <1144961564.4935.24.camel@localhost.localdomain>
On Fri, Apr 14, 2006 at 06:52:44AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2006-04-13 at 20:31 +0300, Muli Ben-Yehuda wrote:
> > On Thu, Apr 13, 2006 at 11:07:12AM -0500, Olof Johansson wrote:
> >
> > > Walking the DT means we need to hardcode it on PCI IDs, since the Apple
> > > OF doesn't give the Airport device a logical name. It's probably easier
> > > to implement than walking PCI, but we'd need to maintain a table. My
> > > vote is for PCI walking, I'll give that a shot over the weekend.
> >
> > Cool! bonus points if you do it in drivers/pci and we can steal it
> > easily for Calgary on x8-64 :-)
>
> How so ? Anything remotely related to the iommu is totally different...
> Besides, on x86-64, laptops _are_ more common, and thus the problem of
> cardbus cards is much more significant.
What I had in mind is an interface that given a PCI bridge will tell
you what's the most restrictive DMA mask for a device on that bridge,
so that you'll know whether you need to enable the IOMMU for that
bridge. I'll even settle for a function that tells you what's the most
restrictive DMA mask in the system, preiod. There's nothing inherently
arch specific about this.
(and as a side note, the IOMMU we are working on on x86-64 is Calgary,
which is actually roughly the same chipset used in some PPC
machines...)
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
^ permalink raw reply
* Re: bisect results for powerbook G4 not booting on latest git tree
From: Aristeu Sergio Rozanski Filho @ 2006-04-14 16:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060414133138.GG16901@cathedrallabs.org>
> I was unable to find someone who already did it, so here it
> the possible culprit of latest git tree (pulled both Linus' and
> Paul's tree) not booting on a powerbook G4:
hm, checking for linuxppc-dev archives too would be smart. sorry for the
noise
--
Aristeu
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Michael Ellerman @ 2006-04-14 16:19 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <52F25F7B-ED3C-4A72-A8C9-3631D8D83357@watson.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2897 bytes --]
On Fri, 2006-04-14 at 08:45 -0400, Jimi Xenidis wrote:
> On Apr 13, 2006, at 7:12 PM, Benjamin Herrenschmidt wrote:
> >
> > We should make lmb_reserve() of redudant/overlapping entries become
> > harmless I think.
>
> Hmm.. I think it would be worthy of a warning, no?
Definitely. We had weird bugs in kexec because regions were overlapping.
I just haven't got 'round to writing the patch .. maybe I should :)
> > We need to be backward compatible with earlier blobs
> > that do contain themselves in the reserve map
>
> Do you think it is possible that the blob may have a single
> reservation that includes the blob but is larger? if not then we
> could simply do..
Well it's definitely possible, but I don't know if anyone actually does
it. But I guess we should try to be nice and not warn for old blobs.
This patch looks like a decent approach, although I'd want to add a
check so that if the blob is reserved _three_ times we do warn, it's
getting a bit silly isn't it :)
cheers
> --
> diff -r eb0990a251a9 arch/powerpc/kernel/prom.c
> --- a/arch/powerpc/kernel/prom.c Thu Mar 30 22:05:40 2006 -0500
> +++ b/arch/powerpc/kernel/prom.c Fri Apr 14 08:44:10 2006 -0400
> @@ -1129,9 +1129,17 @@ static void __init early_reserve_mem(voi
> {
> u64 base, size;
> u64 *reserve_map;
> + unsigned long self_base;
> + unsigned long self_size;
> reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
> initial_boot_params->off_mem_rsvmap);
> +
> + /* before we do anything, lets reserve the dt blob */
> + self_base = __pa((unsigned long)initial_boot_params);
> + self_size = initial_boot_params->totalsize;
> + lmb_reserve(self_base, self_size);
> +
> #ifdef CONFIG_PPC32
> /*
> * Handle the case where we might be booting from an old kexec
> @@ -1146,6 +1154,9 @@ static void __init early_reserve_mem(voi
> size_32 = *(reserve_map_32++);
> if (size_32 == 0)
> break;
> + /* skip if the reservation is for the blob */
> + if (base_32 == self_base && size_32 == self_size)
> + continue;
> DBG("reserving: %x -> %x\n", base_32, size_32);
> lmb_reserve(base_32, size_32);
> }
> @@ -1157,6 +1168,9 @@ static void __init early_reserve_mem(voi
> size = *(reserve_map++);
> if (size == 0)
> break;
> + /* skip if the reservation is for the blob */
> + if (base == self_base && size == self_size)
> + continue;
> DBG("reserving: %llx -> %llx\n", base, size);
> lmb_reserve(base, size);
> }
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Michael Ellerman
IBM OzLabs
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: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] [1/2] POWERPC: IOMMU support for honoring dma_mask
From: Olof Johansson @ 2006-04-14 18:55 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, plush, linux-kernel
In-Reply-To: <20060413020559.GC24769@pb15.lixom.net>
On Wed, Apr 12, 2006 at 09:05:59PM -0500, Olof Johansson wrote:
> Since time is somewhat of essense (if 2.6.17 is still an option), I went
> for the choice of sending now and follow up with a small bugfix later
> in case something shows up, especially since quick regression tests seem
> ok.
FYI, I now have a positive test report from a bcm43xx user with a 1.5GB G5.
(Thanks for testing this, Marc!).
-Olof
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Paul Mackerras @ 2006-04-14 19:07 UTC (permalink / raw)
To: Becky Bruce; +Cc: Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <21F7D7D8-B9BC-44EB-B07B-F888D89DCF25@freescale.com>
Becky Bruce writes:
> Actually, I think the problem is that the code linux is using to turn
> on nap mode is not guaranteed to put the processor in nap mode by the
> time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch fixes it for me. Comments, anyone?
Paul.
diff -urN powerpc-merge/arch/powerpc/kernel/idle_6xx.S pmac-2.6.17-rc1/arch/powerpc/kernel/idle_6xx.S
--- powerpc-merge/arch/powerpc/kernel/idle_6xx.S 2006-04-04 23:09:16.000000000 -0700
+++ pmac-2.6.17-rc1/arch/powerpc/kernel/idle_6xx.S 2006-04-14 10:29:54.000000000 -0700
@@ -151,41 +151,47 @@
isync
mtmsr r7
isync
- sync
- blr
+1: b 1b
/*
* Return from NAP/DOZE mode, restore some CPU specific registers,
* we are called with DR/IR still off and r2 containing physical
- * address of current.
+ * address of current. R11 and CR contain HID0. We have to preserve
+ * r10 and r12.
*/
_GLOBAL(power_save_6xx_restore)
+ tophys(r11, r1) /* Make the idle task do a blr */
+ lwz r9,_LINK(r11)
+ stw r9,_NIP(r11)
mfspr r11,SPRN_HID0
- rlwinm. r11,r11,0,10,8 /* Clear NAP & copy NAP bit !state to cr1 EQ */
- cror 4*cr1+eq,4*cr0+eq,4*cr0+eq
+ rlwinm r11,r11,0,10,8 /* Clear NAP */
BEGIN_FTR_SECTION
rlwinm r11,r11,0,9,7 /* Clear DOZE */
END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
mtspr SPRN_HID0, r11
#ifdef DEBUG
- beq cr1,1f
+ bf 9,1f
lis r11,(nap_return_count-KERNELBASE)@ha
lwz r9,nap_return_count@l(r11)
addi r9,r9,1
stw r9,nap_return_count@l(r11)
1:
#endif
-
+
+#ifdef CONFIG_SMP
rlwinm r9,r1,0,0,18
tophys(r9,r9)
lwz r11,TI_CPU(r9)
slwi r11,r11,2
+#else
+ li r11,0
+#endif
/* Todo make sure all these are in the same page
- * and load r22 (@ha part + CPU offset) only once
+ * and load r11 (@ha part + CPU offset) only once
*/
BEGIN_FTR_SECTION
- beq cr1,1f
+ bf 9,1f
addis r9,r11,(nap_save_msscr0-KERNELBASE)@ha
lwz r9,nap_save_msscr0@l(r9)
mtspr SPRN_MSSCR0, r9
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Olof Johansson @ 2006-04-14 19:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <17471.62187.774127.783000@cargo.ozlabs.ibm.com>
Hi,
On Fri, Apr 14, 2006 at 12:07:23PM -0700, Paul Mackerras wrote:
> Becky Bruce writes:
>
> > Actually, I think the problem is that the code linux is using to turn
> > on nap mode is not guaranteed to put the processor in nap mode by the
> > time the blr in ppc6xx_idle occurs.
>
> Thanks, Becky.
>
> This patch fixes it for me. Comments, anyone?
The bf mnemonics had me scratching my head a while, it's not listed as
a simplified mnemonic in the 64-bit PEM. Two questions below.
> _GLOBAL(power_save_6xx_restore)
> + tophys(r11, r1) /* Make the idle task do a blr */
> + lwz r9,_LINK(r11)
> + stw r9,_NIP(r11)
> mfspr r11,SPRN_HID0
> - rlwinm. r11,r11,0,10,8 /* Clear NAP & copy NAP bit !state to cr1 EQ */
> - cror 4*cr1+eq,4*cr0+eq,4*cr0+eq
> + rlwinm r11,r11,0,10,8 /* Clear NAP */
> BEGIN_FTR_SECTION
> rlwinm r11,r11,0,9,7 /* Clear DOZE */
> END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
> mtspr SPRN_HID0, r11
>
> #ifdef DEBUG
> - beq cr1,1f
> + bf 9,1f
Where is cr0 set now -- you took the dot off of rlwinm?
> lis r11,(nap_return_count-KERNELBASE)@ha
> lwz r9,nap_return_count@l(r11)
> addi r9,r9,1
> stw r9,nap_return_count@l(r11)
> 1:
> #endif
> -
> +
> +#ifdef CONFIG_SMP
> rlwinm r9,r1,0,0,18
> tophys(r9,r9)
> lwz r11,TI_CPU(r9)
> slwi r11,r11,2
> +#else
> + li r11,0
> +#endif
> /* Todo make sure all these are in the same page
> - * and load r22 (@ha part + CPU offset) only once
> + * and load r11 (@ha part + CPU offset) only once
> */
> BEGIN_FTR_SECTION
> - beq cr1,1f
> + bf 9,1f
Same comment as above w.r.t. cr0?
-Olof
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Becky Bruce @ 2006-04-14 20:00 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev list, Michael Schmitz, debian-powerpc,
Paul Mackerras
In-Reply-To: <20060414195436.GC24769@pb15.lixom.net>
He's being sneaky - there's a copy of HID0 in the CR at this point
from the caller, and bit 9 is the position for NAP.
-B
On Apr 14, 2006, at 2:54 PM, Olof Johansson wrote:
> Hi,
>
> On Fri, Apr 14, 2006 at 12:07:23PM -0700, Paul Mackerras wrote:
>> Becky Bruce writes:
>>
>>> Actually, I think the problem is that the code linux is using to
>>> turn
>>> on nap mode is not guaranteed to put the processor in nap mode by
>>> the
>>> time the blr in ppc6xx_idle occurs.
>>
>> Thanks, Becky.
>>
>> This patch fixes it for me. Comments, anyone?
>
> The bf mnemonics had me scratching my head a while, it's not listed as
> a simplified mnemonic in the 64-bit PEM. Two questions below.
>
>> _GLOBAL(power_save_6xx_restore)
>> + tophys(r11, r1) /* Make the idle task do a blr */
>> + lwz r9,_LINK(r11)
>> + stw r9,_NIP(r11)
>> mfspr r11,SPRN_HID0
>> - rlwinm. r11,r11,0,10,8 /* Clear NAP & copy NAP bit !state to cr1
>> EQ */
>> - cror 4*cr1+eq,4*cr0+eq,4*cr0+eq
>> + rlwinm r11,r11,0,10,8 /* Clear NAP */
>> BEGIN_FTR_SECTION
>> rlwinm r11,r11,0,9,7 /* Clear DOZE */
>> END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
>> mtspr SPRN_HID0, r11
>>
>> #ifdef DEBUG
>> - beq cr1,1f
>> + bf 9,1f
>
> Where is cr0 set now -- you took the dot off of rlwinm?
>
>> lis r11,(nap_return_count-KERNELBASE)@ha
>> lwz r9,nap_return_count@l(r11)
>> addi r9,r9,1
>> stw r9,nap_return_count@l(r11)
>> 1:
>> #endif
>> -
>> +
>> +#ifdef CONFIG_SMP
>> rlwinm r9,r1,0,0,18
>> tophys(r9,r9)
>> lwz r11,TI_CPU(r9)
>> slwi r11,r11,2
>> +#else
>> + li r11,0
>> +#endif
>> /* Todo make sure all these are in the same page
>> - * and load r22 (@ha part + CPU offset) only once
>> + * and load r11 (@ha part + CPU offset) only once
>> */
>> BEGIN_FTR_SECTION
>> - beq cr1,1f
>> + bf 9,1f
>
> Same comment as above w.r.t. cr0?
>
>
>
> -Olof
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Paul Mackerras @ 2006-04-14 20:19 UTC (permalink / raw)
To: Olof Johansson
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <20060414195436.GC24769@pb15.lixom.net>
Olof Johansson writes:
> Where is cr0 set now -- you took the dot off of rlwinm?
transfer_to_handler does mfspr r11,SPRN_HID0; mtcr r11 before jumping
to power_save_6xx_restore. The rlwinm. was wrong anyway since it was
setting cr0.eq based on all the *other* bits in HID0, not HID0_NAP
(doh!).
Paul.
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Olof Johansson @ 2006-04-14 20:24 UTC (permalink / raw)
To: Paul Mackerras
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <17472.984.760483.334447@cargo.ozlabs.ibm.com>
On Fri, Apr 14, 2006 at 01:19:36PM -0700, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > Where is cr0 set now -- you took the dot off of rlwinm?
>
> transfer_to_handler does mfspr r11,SPRN_HID0; mtcr r11 before jumping
> to power_save_6xx_restore. The rlwinm. was wrong anyway since it was
> setting cr0.eq based on all the *other* bits in HID0, not HID0_NAP
> (doh!).
Oh, right, you even updated the comment to reflect this. My bad.
Patch looks good to me then.
-Olof
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Luck, Tony @ 2006-04-14 20:53 UTC (permalink / raw)
To: Mel Gorman; +Cc: davej, linuxppc-dev, ak, bob.picco, linux-kernel, linux-mm
In-Reply-To: <20060414131235.GA19064@skynet.ie>
On Fri, Apr 14, 2006 at 02:12:35PM +0100, Mel Gorman wrote:
> That appears fine, but I call add_active_range() after a GRANULEROUNDUP and
> GRANULEROUNDDOWN has taken place so that might be the problem, especially as
> all those ranges are aligned on a 16MiB boundary. The following patch calls
> add_active_range() before the rounding takes place. Can you try it out please?
That's good. Now I see identical output before/after your patch for
the generic (DISCONTIG=y) kernel:
On node 0 totalpages: 259873
DMA zone: 128931 pages, LIFO batch:7
Normal zone: 130942 pages, LIFO batch:7
-Tony
^ permalink raw reply
* Re: [PATCH] [2/2] POWERPC: Lower threshold for DART enablement to 1GB, V2
From: Benjamin Herrenschmidt @ 2006-04-14 20:57 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: Olof Johansson, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20060414144830.GQ10412@granada.merseine.nu>
> What I had in mind is an interface that given a PCI bridge will tell
> you what's the most restrictive DMA mask for a device on that bridge,
> so that you'll know whether you need to enable the IOMMU for that
> bridge. I'll even settle for a function that tells you what's the most
> restrictive DMA mask in the system, preiod. There's nothing inherently
> arch specific about this.
>
> (and as a side note, the IOMMU we are working on on x86-64 is Calgary,
> which is actually roughly the same chipset used in some PPC
> machines...)
Not sure I ever heard about that... What chipsets ?
Ben.
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Benjamin Herrenschmidt @ 2006-04-14 21:01 UTC (permalink / raw)
To: Paul Mackerras
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <17471.62187.774127.783000@cargo.ozlabs.ibm.com>
On Fri, 2006-04-14 at 12:07 -0700, Paul Mackerras wrote:
> Becky Bruce writes:
>
> > Actually, I think the problem is that the code linux is using to turn
> > on nap mode is not guaranteed to put the processor in nap mode by the
> > time the blr in ppc6xx_idle occurs.
>
> Thanks, Becky.
>
> This patch fixes it for me. Comments, anyone?
Looks good to me except that we need the same for ppc64 since the 970
theorically has the same problem...
Ben.
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Becky Bruce @ 2006-04-14 21:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060414202452.GD24769@pb15.lixom.net>
On Fri, 2006-04-14 at 12:07 -0700, Paul Mackerras wrote:
> Becky Bruce writes:
>
>
>> Actually, I think the problem is that the code linux is using to turn
>> on nap mode is not guaranteed to put the processor in nap mode by the
>> time the blr in ppc6xx_idle occurs.
>>
>
> Thanks, Becky.
>
> This patch fixes it for me. Comments, anyone?
Patch LGTM, as well. I like the approach.
Thanks!
-Becky
^ 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