* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Segher Boessenkool @ 2007-06-15 10:44 UTC (permalink / raw)
To: Vladislav D. Buzov; +Cc: linuxppc-dev list
In-Reply-To: <46725D02.9090806@ru.mvista.com>
>> Do fix the comment though ;-)
> Once somebody tests the patch on other 7450 processors I'll remove the
> comment and send a new patch. Is it ok? Or I should create a new patch
> first?
No, this is perfectly fine. Thanks!
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav D. Buzov @ 2007-06-15 9:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <a849b0caedb72f3799c095d3ab6cebd1@kernel.crashing.org>
Segher Boessenkool wrote:
>> Hrm. I don't think that cache invalidation should be skipped. It is
>> done after _set_L2CR() explicitly disabled the cache, in part of
>> cache enabling procedure. Note that cache is flushed only if
>> _set_L2CR() is called for already enabled cache. So, to skip cache
>> invalidation there is a need to somehow track whether the cache has
>> been flushed/invalidated before disabling or not. Since the manual
>> invalidation does not break anything I think it is better to leave it
>> as is rather than overload a _set_L2CR() logic.
>
> Yeah just leave it, it definitely is the safer thing to do.
> Do fix the comment though ;-)
Once somebody tests the patch on other 7450 processors I'll remove the
comment and send a new patch. Is it ok? Or I should create a new patch
first?
Vlad.
>
>
> Segher
>
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Michael Ellerman @ 2007-06-15 9:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Fri, 2007-06-15 at 14:50 +1000, Paul Mackerras wrote:
> I have created a for-2.6.23 branch in the powerpc.git repository
> (git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git)
> where I have started queueing up patches to go in once the 2.6.23
> merge window opens. For now at least it's the same as the master
> branch.
>
> The patches I put in are listed below. If you have a patch that
> should go in but isn't listed, remind me about it.
Hi Paul,
The first three patches in my MSI series from the other day are good to
go in, they even got Ack'ed:
http://patchwork.ozlabs.org/linuxppc/patch?id=11502
http://patchwork.ozlabs.org/linuxppc/patch?id=11503
http://patchwork.ozlabs.org/linuxppc/patch?id=11504
The comments on the first patch were actually directed at the last patch
in my series, which I'm still working on.
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/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Segher Boessenkool @ 2007-06-15 9:01 UTC (permalink / raw)
To: Vladislav D. Buzov; +Cc: linuxppc-dev list
In-Reply-To: <46725411.3080002@ru.mvista.com>
> Hrm. I don't think that cache invalidation should be skipped. It is
> done after _set_L2CR() explicitly disabled the cache, in part of cache
> enabling procedure. Note that cache is flushed only if _set_L2CR() is
> called for already enabled cache. So, to skip cache invalidation there
> is a need to somehow track whether the cache has been
> flushed/invalidated before disabling or not. Since the manual
> invalidation does not break anything I think it is better to leave it
> as is rather than overload a _set_L2CR() logic.
Yeah just leave it, it definitely is the safer thing to do.
Do fix the comment though ;-)
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-15 8:59 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linux-mtd, Milton Miller, David Gibson
In-Reply-To: <1181897276.25228.325.camel@pmac.infradead.org>
>> Yes, certainly. Or, the other way around I like better
>> ("bank-width" optional).
>
> No, we need bank-width. It's device-width which can be optional.
One is defaulted to the other so it doesn't really
matter _which_ you make optional, the OS device driver
can always get both values. For the device tree, it
seems more natural to have "device-width" a required
property. Feel free to disagree but I'd like to hear
arguments if so :-)
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Segher Boessenkool @ 2007-06-15 8:56 UTC (permalink / raw)
To: Vladislav D. Buzov; +Cc: linuxppc-dev list
In-Reply-To: <467250E1.8040507@ru.mvista.com>
>>> I've double checked this. All processors considered 7450 in the
>>> kernel are covered by MPC7450 RISC Microprocessor Family Reference
>>> Manual where hardware cache flushing procedure is described.
>>
>> Nice. Now all that remains to be done is for the patch to
>> be tested on actual hardware for at least a few of those
>> other CPUs. Any volunteers?
> Unfortunately I have only 7448 on hand :(
I was calling out for other list members to test your
patch :-)
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav D. Buzov @ 2007-06-15 8:55 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <c6cd3a9fe7713f081354cca9b4306811@kernel.crashing.org>
Segher Boessenkool wrote:
>>>>> /* TODO: use HW flush assist when available */
>>>>
>>>> You want to get rid of this old comment though -- and
>>>> perhaps branch over the non-hardware-assisted cache
>>>> flushing code.
>>>
>>> Ok, I agree that the comment is obsolete now. Would you please explain
>>> why the branch over non-hardware-assisted code should be removed as
>>> well. Technically the cache is flushed and there is no need to use
>>> extra
>>> commands to fill and then re-flush the cache.
>>
>> I think Segher is saying that you can skip the manual invalidation too
>> (although he said "flushing", I think he really meant "invalidation"--
>> the manual flushing is already skipped).
>
> Erm yes.
>
>> If I'm reading the manual
>> correctly, L2HWF does the invalidation as well so both the manual
>> flushing and invalidation can be skipped.
>
> Yeah. Not that it really matters of course.
Hrm. I don't think that cache invalidation should be skipped. It is done
after _set_L2CR() explicitly disabled the cache, in part of cache
enabling procedure. Note that cache is flushed only if _set_L2CR() is
called for already enabled cache. So, to skip cache invalidation there
is a need to somehow track whether the cache has been
flushed/invalidated before disabling or not. Since the manual
invalidation does not break anything I think it is better to leave it as
is rather than overload a _set_L2CR() logic.
Vlad.
>
>
> Segher
>
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Woodhouse @ 2007-06-15 8:47 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller, David Gibson
In-Reply-To: <6dcf3b4c6c7fcd8060baccf5374316c5@kernel.crashing.org>
On Fri, 2007-06-15 at 10:42 +0200, Segher Boessenkool wrote:
> Yes, certainly. Or, the other way around I like better
> ("bank-width" optional).
No, we need bank-width. It's device-width which can be optional.
--
dwmw2
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav D. Buzov @ 2007-06-15 8:42 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <6c416bf9f79a648fc82f64619aca86de@kernel.crashing.org>
Segher Boessenkool wrote:
>>> Are these errata 7448-only? If not, I wonder what is
>>> done on PowerMacs?
>>
>> This is a errata for 7448 only. I've looked through errata for other
>> 7450 processors (7450, 7457) and they contain the same erratum for L2
>> cache: "L2 hardware flush may not flush every line from the L2 cache"
>> The workaround for this problem is: "Set the IONLY and DONLY bits in
>> the L2CR prior to the L2 hardware flush", and the projected solution
>> is: "The workaround has been documented in the MPC7450 RISC
>> Microprocessor Family User’s Manual as the correct way to flush the
>> L2 cache"
>
> Okay, so it is for all members of the 7450 family. Good :-)
>
>>> Looks reasonable enough to me... if it works (on all
>>> things considered "7450" by the kernel).
>>
>> I've double checked this. All processors considered 7450 in the
>> kernel are covered by MPC7450 RISC Microprocessor Family Reference
>> Manual where hardware cache flushing procedure is described.
>
> Nice. Now all that remains to be done is for the patch to
> be tested on actual hardware for at least a few of those
> other CPUs. Any volunteers?
Unfortunately I have only 7448 on hand :(
>
>>>> /* TODO: use HW flush assist when available */
>>>
>>> You want to get rid of this old comment though -- and
>>> perhaps branch over the non-hardware-assisted cache
>>> flushing code.
>>
>> Ok, I agree that the comment is obsolete now. Would you please
>> explain why the branch over non-hardware-assisted code should be
>> removed as well. Technically the cache is flushed and there is no
>> need to use extra commands to fill and then re-flush the cache.
>
> I said such a branch should be added, not removed -- it
> appears from your reply that you are skipping it already
> and I just missed it?
I have a branch over a manual cache flushing code in the patch:
+ b 2f
END_FTR_SECTION_IFSET(CPU_FTR_SPEC7450)
That is a branch to the next step after cache flushing - cache disabling and setting up all the L2CR configuration bits passed to _set_L2CR()
Vlad.
>
>
> Segher
>
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-15 8:42 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
In-Reply-To: <20070615041423.GB30104@localhost.localdomain>
>> So I think the best thing to have would be
>>
>> compatible "cfi-flash"
>> bank-width like you said
>> device-width width of a single flash device
>> reg complete address range of this thing
>>
>> and then the Linux OF CFI flash code / MTD code just keeps
>> on probing devices from that address range until it has it
>> filled.
>>
>> Sounds good / comments / anything I missed?
>
> Slight revision suggestion. Can we make 'device-width' optional, with
> the default value being equal to the bank-width?
Yes, certainly. Or, the other way around I like better
("bank-width" optional).
I didn't say all these properties were required anyway,
this is still a very rough draft.
Segher
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-15 8:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Olaf Hering, paulus, Yoder Stuart-B08248
In-Reply-To: <1181866571.14818.416.camel@localhost.localdomain>
>> "node name" in flat device trees doesn't allow a proper
>> "name" property to exist for the root node. This is a
>> bug in the flat device tree tools, and either should be
>> fixed, or this should be clearly documented as a divergence
>> from "real" OF.
>>
>> "name" of the root node is a bit special, since it is
>> never displayed as part of a device path or used for
>> device selection (instead, "/" at start of a path is
>> handled specially, just like on unix filesystems).
>
> This 'special' behaviour, the fact that it's definition is out of sync
> with the generic name recommended practice, and finally, the fact that
> quite a lot of real OFs out there don't even bother having one, makes
> me
> think that it's a good idea to stick to what I did, which is to say the
> root node has no name in a flat device-tree.
Putting that info in "compatible" instead should work
fine enough.
> Now, what I -may- do to avoid information loss is tweak prom_init.c to
> actually extract that name if it exist and stick a "name" property in
> the root node in that case when flattening the tree.
Nice, thanks!
> But I still beleive as far as flat DTs for embedded are concerned, we
> shouldn't use and rely on having a name at the root of the tree.
There _has_ to be a "name" property. But you have one,
just not with interesting contents ;-)
>> Since anything that matches for "compatible" entries
>> also first should check the "name" contents, it should
>> be okay for flat device trees to have the information
>> that could/should be in "name" in "compatible", instead.
Segher
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-15 8:32 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA302F335E6@az33exm25.fsl.freescale.net>
>>> Guideline 2: The "compatible" property must be present.
>>
>> ...if "name" doesn't perform the same function yet, which
>> of course is almost always.
>
> But the recommended practice doesn't have an "...if". It says
> "compatible" must always be present.
If you read the r.p. more closely, you'll see this applies
to normal devices only. Either way, the r.p. says very
clearly that the "old way" of doing things is still supported.
> The reason an OS would need to support "name" as well as
> "compatbile" for device driver matching would be
> for _legacy_ device trees that don't follow the recommended
> practice.
No, the OS has to do this since that is what the OF spec
says has to be done. The generic names recommended practice
goes into this in some detail, too.
> For newly developed trees "compatible" should specify the programming
> model, if we are following that recommended practice.
Yes.
> So bottom line is that we shouldn't be moving toward using "name"
> to specify the programming model.
And no one suggested that.
>> Since anything that matches for "compatible" entries
>> also first should check the "name" contents, it should
>> be okay for flat device trees to have the information
>> that could/should be in "name" in "compatible", instead.
>
> As mentioned above, matching on "name" would seem to be
> needed to handle legacy device trees as I read some of
> the reasoning in the generic names recommended practice.
> Not sure if that applies to Linux or not...
Not all Linux systems use a flat device tree, some use a
"real" Open Firmware. Not doing the matching the way it
is described but differently is asking for problems, needing
unnecessary workarounds.
Segher
^ permalink raw reply
* RE: for-2.6.23 branch in powerpc.git created
From: Li Yang-r58472 @ 2007-06-15 8:24 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On Behalf
Of
> Paul Mackerras
> Sent: Friday, June 15, 2007 12:50 PM
> To: linuxppc-dev@ozlabs.org
> Subject: for-2.6.23 branch in powerpc.git created
>=20
> I have created a for-2.6.23 branch in the powerpc.git repository
> (git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git)
> where I have started queueing up patches to go in once the 2.6.23
> merge window opens. For now at least it's the same as the master
> branch.
>=20
> The patches I put in are listed below. If you have a patch that
> should go in but isn't listed, remind me about it.
[PATCH] qe_lib: export symbols for QE driver to compile as module
[PATCH v4] 83xx USB platform code rework
- Leo
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Segher Boessenkool @ 2007-06-15 8:16 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev list
In-Reply-To: <20070614222620.GA17382@mag.az.mvista.com>
>>>> /* TODO: use HW flush assist when available */
>>>
>>> You want to get rid of this old comment though -- and
>>> perhaps branch over the non-hardware-assisted cache
>>> flushing code.
>>
>> Ok, I agree that the comment is obsolete now. Would you please explain
>> why the branch over non-hardware-assisted code should be removed as
>> well. Technically the cache is flushed and there is no need to use
>> extra
>> commands to fill and then re-flush the cache.
>
> I think Segher is saying that you can skip the manual invalidation too
> (although he said "flushing", I think he really meant "invalidation"--
> the manual flushing is already skipped).
Erm yes.
> If I'm reading the manual
> correctly, L2HWF does the invalidation as well so both the manual
> flushing and invalidation can be skipped.
Yeah. Not that it really matters of course.
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Segher Boessenkool @ 2007-06-15 8:14 UTC (permalink / raw)
To: Vladislav Buzov; +Cc: linuxppc-dev list
In-Reply-To: <467176EB.7060404@ru.mvista.com>
>> Are these errata 7448-only? If not, I wonder what is
>> done on PowerMacs?
>
> This is a errata for 7448 only. I've looked through errata for other=20=
> 7450 processors (7450, 7457) and they contain the same erratum for L2=20=
> cache: "L2 hardware flush may not flush every line from the L2 cache"=20=
> The workaround for this problem is: "Set the IONLY and DONLY bits in=20=
> the L2CR prior to the L2 hardware flush", and the projected solution=20=
> is: "The workaround has been documented in the MPC7450 RISC=20
> Microprocessor Family User=92s Manual as the correct way to flush the =
L2=20
> cache"
Okay, so it is for all members of the 7450 family. Good :-)
>> Looks reasonable enough to me... if it works (on all
>> things considered "7450" by the kernel).
>
> I've double checked this. All processors considered 7450 in the kernel=20=
> are covered by MPC7450 RISC Microprocessor Family Reference Manual=20
> where hardware cache flushing procedure is described.
Nice. Now all that remains to be done is for the patch to
be tested on actual hardware for at least a few of those
other CPUs. Any volunteers?
>>> /* TODO: use HW flush assist when available */
>>
>> You want to get rid of this old comment though -- and
>> perhaps branch over the non-hardware-assisted cache
>> flushing code.
>
> Ok, I agree that the comment is obsolete now. Would you please explain=20=
> why the branch over non-hardware-assisted code should be removed as=20
> well. Technically the cache is flushed and there is no need to use=20
> extra commands to fill and then re-flush the cache.
I said such a branch should be added, not removed -- it
appears from your reply that you are skipping it already
and I just missed it?
Segher
^ permalink raw reply
* Re: 83xx GPIO/EXT int in arch/powerpc/
From: Marc Leeman @ 2007-06-15 8:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <F8BCBDB1-B699-4353-8FD8-A8FA60380C6F@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]
> Are you comparing 8245 on arch=ppc to 83xx on arch=powerpc or 83xx in
> both cases?
No, I'm comparing ARCH=ppc and ARCH=powerpc, both on 8347E. The
comparison with a 8245 is due to the fact that this 83xx platform is a
follow up of the 8245 design.
With the 8245, we got almost a doubling of the effective processing of
data through the network by replacing the eepro100 driver with the e100
driver from intel. Since data transfer rate from the network on a 83xx
seems to be slower than the 8245/e100 combination, there might be some
driver work to do too to get the same improvement; but that's currently
just speculation on my part; I hope to have a look into that after the
summer.
> Hmm, we really need to put SVR in there as well (add that to the todo
> list). Which 83xx is this?
MPC8347E
> Do you sense of how many calls you make to _hpi_set_hhwil &
> __hpi_read_hpid?
We're using a couple of GPIOs to toggle the first halfword and the
second halfword (running HPI 16-bit). Since we only have implemented
single beat accesses in the UPM, we also need to toggle between address
and data.
For every word, there are 4 similar calls; a DSP binary that is loaded
over HPI is around 400 kB, so in 500,000 order of magnitude per DSP
binary load.
During operation, HPI is used to get info from the DSPs @100-120 times per
second; just a couple of bytes though.
> I think I know why the ppc case was more efficient.
Wheee.
probably the ioremap and iounmap have something to do with it; in the
debugging version of the code, this was done for every GPIO access (cf.
supra) and there the slow down was from 3-4 secs to 1-2 mins.
> >Even after this change; the load of a streaming application was
> >something of 40% on ppc and 60% on powerpc.
>
> What's going on during the streaming?
Data is retreived from the network (UDP, TCP, mostly UDP/multicast
though) and partially decoded (converted to elementary stream). Data is
then transferred through an FPGA (over PCI) to a DSP with DMA (pushed
from the 83xx processor). The data is mapped from userspace into kernel
in blocks of 4096kB to avoid copying.
The transfer of data is pretty straighforward:
1. map user page into kernel
2. grab dma channel
3. init dma channel
4. dma data out
5. wait for interrupt
--
greetz, marc
You'll be happy to know I have a plan.
Crichton - Through the Looking Glass
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Michael Neuling @ 2007-06-15 5:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
> I have created a for-2.6.23 branch in the powerpc.git repository
> (git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git)
> where I have started queueing up patches to go in once the 2.6.23
> merge window opens. For now at least it's the same as the master
> branch.
>
> The patches I put in are listed below. If you have a patch that
> should go in but isn't listed, remind me about it.
Paul,
Can you take these two:
"do firmware feature fixups after features are initialised"
http://patchwork.ozlabs.org/linuxppc/patch?id=11617
"fix stolen time for SMT without LPAR"
http://patchwork.ozlabs.org/linuxppc/patch?id=11616
Thanks,
Mikey
^ permalink raw reply
* Split out asm-ppc/mmu.h portions for Freescale Book-E
From: David Gibson @ 2007-06-15 5:33 UTC (permalink / raw)
To: linuxppc-dev
arch/powerpc still relies on asm-ppc/mmu.h for some 32-bit MMU types.
This patch is another step towards fixing this. It takes the portions
of asm-ppc/mmu.h related to Freescale Book-E which are still relevant
in arch/powerpc and puts them in a new asm-powerpc/mmu-fsl-booke.h,
included when appropriate from asm-powerpc/mmu.h.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Could someone who actually has a Freescale Book-E board give this a
whirl? I've compile tested this, but not booted it.
Index: working-2.6/include/asm-powerpc/mmu-fsl-booke.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/include/asm-powerpc/mmu-fsl-booke.h 2007-05-30 16:22:30.000000000 +1000
@@ -0,0 +1,88 @@
+#ifndef _ASM_POWERPC_MMU_FSL_BOOKE_H_
+#define _ASM_POWERPC_MMU_FSL_BOOKE_H_
+/*
+ * Freescale Book-E MMU support
+ */
+
+/* Book-E defined page sizes */
+#define BOOKE_PAGESZ_1K 0
+#define BOOKE_PAGESZ_4K 1
+#define BOOKE_PAGESZ_16K 2
+#define BOOKE_PAGESZ_64K 3
+#define BOOKE_PAGESZ_256K 4
+#define BOOKE_PAGESZ_1M 5
+#define BOOKE_PAGESZ_4M 6
+#define BOOKE_PAGESZ_16M 7
+#define BOOKE_PAGESZ_64M 8
+#define BOOKE_PAGESZ_256M 9
+#define BOOKE_PAGESZ_1GB 10
+#define BOOKE_PAGESZ_4GB 11
+#define BOOKE_PAGESZ_16GB 12
+#define BOOKE_PAGESZ_64GB 13
+#define BOOKE_PAGESZ_256GB 14
+#define BOOKE_PAGESZ_1TB 15
+
+#define MAS0_TLBSEL(x) ((x << 28) & 0x30000000)
+#define MAS0_ESEL(x) ((x << 16) & 0x0FFF0000)
+#define MAS0_NV(x) ((x) & 0x00000FFF)
+
+#define MAS1_VALID 0x80000000
+#define MAS1_IPROT 0x40000000
+#define MAS1_TID(x) ((x << 16) & 0x3FFF0000)
+#define MAS1_TS 0x00001000
+#define MAS1_TSIZE(x) ((x << 8) & 0x00000F00)
+
+#define MAS2_EPN 0xFFFFF000
+#define MAS2_X0 0x00000040
+#define MAS2_X1 0x00000020
+#define MAS2_W 0x00000010
+#define MAS2_I 0x00000008
+#define MAS2_M 0x00000004
+#define MAS2_G 0x00000002
+#define MAS2_E 0x00000001
+
+#define MAS3_RPN 0xFFFFF000
+#define MAS3_U0 0x00000200
+#define MAS3_U1 0x00000100
+#define MAS3_U2 0x00000080
+#define MAS3_U3 0x00000040
+#define MAS3_UX 0x00000020
+#define MAS3_SX 0x00000010
+#define MAS3_UW 0x00000008
+#define MAS3_SW 0x00000004
+#define MAS3_UR 0x00000002
+#define MAS3_SR 0x00000001
+
+#define MAS4_TLBSELD(x) MAS0_TLBSEL(x)
+#define MAS4_TIDDSEL 0x000F0000
+#define MAS4_TSIZED(x) MAS1_TSIZE(x)
+#define MAS4_X0D 0x00000040
+#define MAS4_X1D 0x00000020
+#define MAS4_WD 0x00000010
+#define MAS4_ID 0x00000008
+#define MAS4_MD 0x00000004
+#define MAS4_GD 0x00000002
+#define MAS4_ED 0x00000001
+
+#define MAS6_SPID0 0x3FFF0000
+#define MAS6_SPID1 0x00007FFE
+#define MAS6_SAS 0x00000001
+#define MAS6_SPID MAS6_SPID0
+
+#define MAS7_RPN 0xFFFFFFFF
+
+#ifndef __ASSEMBLY__
+
+#ifndef CONFIG_PHYS_64BIT
+typedef unsigned long phys_addr_t;
+#else
+typedef unsigned long long phys_addr_t;
+#endif
+
+typedef struct {
+ unsigned long id;
+ unsigned long vdso_base;
+} mm_context_t;
+#endif /* !__ASSEMBLY__ */
+
+#endif /* _ASM_POWERPC_MMU_FSL_BOOKE_H_ */
Index: working-2.6/include/asm-powerpc/mmu.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/mmu.h 2007-05-30 16:03:50.000000000 +1000
+++ working-2.6/include/asm-powerpc/mmu.h 2007-05-30 16:04:22.000000000 +1000
@@ -11,6 +11,9 @@
#elif defined(CONFIG_44x)
/* 44x-style software loaded TLB */
# include <asm/mmu-44x.h>
+#elif defined(CONFIG_FSL_BOOKE)
+/* Freescale Book-E software loaded TLB */
+# include <asm/mmu-fsl-booke.h>
#else
/* Other 32-bit. FIXME: split up the other 32-bit MMU types, and
* revise for arch/powerpc */
--
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: for-2.6.23 branch in powerpc.git created
From: Sachin P. Sant @ 2007-06-15 5:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
Paul Mackerras wrote:
> The patches I put in are listed below. If you have a patch that
> should go in but isn't listed, remind me about it.
Paul, the following patch isn't listed. Please consider for merge.
[PATCH] Fix Kexec/Kdump for power6
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
Thanks
-Sachin
[-- Attachment #2: kexec-kdump-on-power6 --]
[-- Type: text/plain, Size: 3122 bytes --]
* On Power machines supporting VRMA, Kexec/Kdump does not work.
* Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables.
* Make sure these hpte entries are left untouched.
*
* This patch also adds plpar_pte_read_raw() on the lines of
* plpar_pte_remove_raw().
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
---
diff -Naurp old/arch/powerpc/platforms/pseries/lpar.c new/arch/powerpc/platforms/pseries/lpar.c
--- old/arch/powerpc/platforms/pseries/lpar.c 2007-06-05 06:27:25.000000000 +0530
+++ new/arch/powerpc/platforms/pseries/lpar.c 2007-06-07 15:28:07.000000000 +0530
@@ -373,12 +373,23 @@ static void pSeries_lpar_hptab_clear(voi
{
unsigned long size_bytes = 1UL << ppc64_pft_size;
unsigned long hpte_count = size_bytes >> 4;
- unsigned long dummy1, dummy2;
+ unsigned long dummy1, dummy2, dword0;
+ long lpar_rc;
int i;
/* TODO: Use bulk call */
- for (i = 0; i < hpte_count; i++)
- plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
+ for (i = 0; i < hpte_count; i++) {
+ /* dont remove HPTEs with VRMA mappings */
+ lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG,
+ &dummy1, &dummy2);
+ if (lpar_rc == H_NOT_FOUND) {
+ lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1);
+ if (!lpar_rc && ((dword0 & HPTE_V_VRMA_MASK)
+ != HPTE_V_VRMA_MASK))
+ /* Can be hpte for 1TB Seg. So remove it */
+ plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
+ }
+ }
}
/*
diff -Naurp old/arch/powerpc/platforms/pseries/plpar_wrappers.h new/arch/powerpc/platforms/pseries/plpar_wrappers.h
--- old/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-06-05 06:27:25.000000000 +0530
+++ new/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-06-07 15:28:07.000000000 +0530
@@ -108,6 +108,21 @@ static inline long plpar_pte_read(unsign
return rc;
}
+/* plpar_pte_read_raw can be called in real mode. It calls plpar_hcall_raw */
+static inline long plpar_pte_read_raw(unsigned long flags, unsigned long ptex,
+ unsigned long *old_pteh_ret, unsigned long *old_ptel_ret)
+{
+ long rc;
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ rc = plpar_hcall_raw(H_READ, retbuf, flags, ptex);
+
+ *old_pteh_ret = retbuf[0];
+ *old_ptel_ret = retbuf[1];
+
+ return rc;
+}
+
static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex,
unsigned long avpn)
{
diff -Naurp old/include/asm-powerpc/mmu-hash64.h new/include/asm-powerpc/mmu-hash64.h
--- old/include/asm-powerpc/mmu-hash64.h 2007-06-05 06:27:25.000000000 +0530
+++ new/include/asm-powerpc/mmu-hash64.h 2007-06-07 15:28:46.000000000 +0530
@@ -94,6 +94,9 @@ extern char initial_stab[];
#define HPTE_R_C ASM_CONST(0x0000000000000080)
#define HPTE_R_R ASM_CONST(0x0000000000000100)
+#define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000)
+#define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff000000)
+
/* Values for PP (assumes Ks=0, Kp=1) */
/* pp0 will always be 0 for linux */
#define PP_RWXX 0 /* Supervisor read/write, User none */
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-06-15 5:00 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get two more bug-fixes for powerpc.
Thanks,
Paul.
arch/powerpc/kernel/udbg.c | 8 +++++++-
arch/powerpc/platforms/powermac/setup.c | 13 ++++++++++++-
arch/powerpc/platforms/powermac/smp.c | 1 -
3 files changed, 19 insertions(+), 3 deletions(-)
commit 220ddc0847ebd42d18ee78c7e1c2f4c2e3be637d
Author: Milton Miller <miltonm@bga.com>
Date: Sun Jun 10 14:32:43 2007 +1000
[POWERPC] Fix console output getting dropped on platforms without udbg_putc
Previously, registering this early console would just result
in dropping early buffered printk output until a udbg_putc
was registered.
However, commit 69331af79cf29e26d1231152a172a1a10c2df511
clears the CON_PRINTBUFFER flag on the main console when a
CON_BOOT (early) console has been registered, resulting in
the buffered messages never being displayed to the user.
This fixes the problem by making sure we don't register udbg_console
on platforms that don't implement udbg_putc.
Signed-off-by: Milton Miller <miltonm@bga.com>
Acked-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit c63c4faa8cf055319c7ed557d2050c1c3776fac5
Author: Paul Mackerras <paulus@samba.org>
Date: Thu Jun 7 22:42:19 2007 +1000
[POWERPC] Fix per-cpu allocation on oldworld SMP powermacs
The per-cpu area(a) for the secondary CPU(s) isn't getting allocated
on old SMP powermacs that don't have the secondary CPU(s) listed in
the device tree, as per-cpu areas are now only allocated for CPUs in
the cpu_possible_map, and we aren't setting the bits for the secondary
CPU(s) until smp_prepare_cpus(), which is after per-cpu allocation.
Therefore this sets the bits for CPUs 1..3 in cpu_possible_map in
pmac_setup_arch, so they get per-cpu data allocated.
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* for-2.6.23 branch in powerpc.git created
From: Paul Mackerras @ 2007-06-15 4:50 UTC (permalink / raw)
To: linuxppc-dev
I have created a for-2.6.23 branch in the powerpc.git repository
(git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git)
where I have started queueing up patches to go in once the 2.6.23
merge window opens. For now at least it's the same as the master
branch.
The patches I put in are listed below. If you have a patch that
should go in but isn't listed, remind me about it.
Paul.
Documentation/cachetlb.txt | 2
arch/powerpc/Kconfig | 256 -------------------
arch/powerpc/boot/44x.c | 45 +++
arch/powerpc/boot/44x.h | 3
arch/powerpc/boot/Makefile | 4
arch/powerpc/boot/cuboot-83xx.c | 13 -
arch/powerpc/boot/cuboot-85xx.c | 13 -
arch/powerpc/boot/cuboot-ebony.c | 16 -
arch/powerpc/boot/cuboot.c | 35 +++
arch/powerpc/boot/cuboot.h | 14 +
arch/powerpc/boot/dcr.h | 37 +++
arch/powerpc/boot/dts/ebony.dts | 8 -
arch/powerpc/boot/dts/holly.dts | 52 ++--
arch/powerpc/boot/dts/mpc7448hpc2.dts | 33 +-
arch/powerpc/boot/ebony.c | 19 -
arch/powerpc/boot/of.c | 188 +-------------
arch/powerpc/boot/of.h | 15 +
arch/powerpc/boot/ofconsole.c | 45 +++
arch/powerpc/boot/oflib.c | 172 ++++++++++++
arch/powerpc/configs/holly_defconfig | 3
arch/powerpc/kernel/Makefile | 5
arch/powerpc/kernel/head_32.S | 122 ---------
arch/powerpc/kernel/irq.c | 1
arch/powerpc/kernel/isa-bridge.c | 271 ++++++++++++++++++++
arch/powerpc/kernel/misc_32.S | 10 -
arch/powerpc/kernel/of_platform.c | 8 -
arch/powerpc/kernel/pci_64.c | 358 +++++++++-----------------
arch/powerpc/kernel/process.c | 14 +
arch/powerpc/kernel/prom_init.c | 4
arch/powerpc/kernel/ptrace-common.h | 161 ------------
arch/powerpc/kernel/ptrace.c | 325 ++++++++++++++++--------
arch/powerpc/kernel/ptrace32.c | 239 ++++++++---------
arch/powerpc/kernel/rtas_pci.c | 7 -
arch/powerpc/kernel/setup_32.c | 12 -
arch/powerpc/kernel/signal.c | 180 +++++++++++++
arch/powerpc/kernel/signal.h | 55 ++++
arch/powerpc/kernel/signal_32.c | 191 ++------------
arch/powerpc/kernel/signal_64.c | 182 -------------
arch/powerpc/kernel/vdso.c | 2
arch/powerpc/mm/44x_mmu.c | 1
arch/powerpc/mm/4xx_mmu.c | 1
arch/powerpc/mm/Makefile | 3
arch/powerpc/mm/fault.c | 2
arch/powerpc/mm/fsl_booke_mmu.c | 1
arch/powerpc/mm/hash_native_64.c | 25 +-
arch/powerpc/mm/hash_utils_64.c | 2
arch/powerpc/mm/imalloc.c | 313 -----------------------
arch/powerpc/mm/init_32.c | 1
arch/powerpc/mm/init_64.c | 1
arch/powerpc/mm/mem.c | 1
arch/powerpc/mm/mmu_context_32.c | 1
arch/powerpc/mm/mmu_decl.h | 17 -
arch/powerpc/mm/pgtable_32.c | 123 ---------
arch/powerpc/mm/pgtable_64.c | 206 ++++-----------
arch/powerpc/mm/ppc_mmu_32.c | 7 -
arch/powerpc/mm/tlb_32.c | 1
arch/powerpc/mm/tlb_64.c | 57 ++++
arch/powerpc/platforms/Kconfig | 7 -
arch/powerpc/platforms/Kconfig.cputype | 252 ++++++++++++++++++
arch/powerpc/platforms/apus/Kconfig | 130 ---------
arch/powerpc/platforms/cell/io-workarounds.c | 2
arch/powerpc/platforms/cell/spufs/file.c | 27 ++
arch/powerpc/platforms/cell/spufs/run.c | 12 +
arch/powerpc/platforms/iseries/call_hpt.h | 9 -
arch/powerpc/platforms/iseries/htab.c | 8 -
arch/powerpc/platforms/iseries/pci.c | 5
arch/powerpc/platforms/maple/pci.c | 35 ---
arch/powerpc/platforms/pasemi/pci.c | 20 -
arch/powerpc/platforms/powermac/pci.c | 32 --
arch/powerpc/platforms/ps3/htab.c | 14 +
arch/powerpc/platforms/pseries/Makefile | 2
arch/powerpc/platforms/pseries/eeh.c | 19 +
arch/powerpc/platforms/pseries/eeh_cache.c | 5
arch/powerpc/platforms/pseries/eeh_driver.c | 6
arch/powerpc/platforms/pseries/eeh_sysfs.c | 87 ++++++
arch/powerpc/platforms/pseries/pci_dlpar.c | 9 -
arch/powerpc/platforms/pseries/pseries.h | 2
arch/powerpc/platforms/pseries/setup.c | 2
arch/powerpc/sysdev/tsi108_dev.c | 33 ++
arch/ppc/kernel/misc.S | 8 -
arch/ppc/kernel/setup.c | 2
drivers/pci/hotplug/rpadlpar_core.c | 6
include/asm-powerpc/cputable.h | 95 +++----
include/asm-powerpc/floppy.h | 6
include/asm-powerpc/io.h | 26 +-
include/asm-powerpc/lppaca.h | 2
include/asm-powerpc/mmu-hash32.h | 91 +++++++
include/asm-powerpc/mmu-hash64.h | 6
include/asm-powerpc/mmu.h | 3
include/asm-powerpc/pci-bridge.h | 23 +-
include/asm-powerpc/pci.h | 4
include/asm-powerpc/pgtable-ppc32.h | 50 ----
include/asm-powerpc/pgtable-ppc64.h | 50 +---
include/asm-powerpc/pgtable.h | 28 ++
include/asm-powerpc/ppc-pci.h | 9 -
include/asm-powerpc/ptrace.h | 22 +-
include/asm-powerpc/syscalls.h | 7 -
include/asm-powerpc/thread_info.h | 12 +
include/asm-powerpc/tlbflush.h | 5
include/linux/vmalloc.h | 3
mm/vmalloc.c | 13 +
101 files changed, 2299 insertions(+), 2773 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot.c
create mode 100644 arch/powerpc/boot/cuboot.h
create mode 100644 arch/powerpc/boot/of.h
create mode 100644 arch/powerpc/boot/ofconsole.c
create mode 100644 arch/powerpc/boot/oflib.c
create mode 100644 arch/powerpc/kernel/isa-bridge.c
delete mode 100644 arch/powerpc/kernel/ptrace-common.h
create mode 100644 arch/powerpc/kernel/signal.c
create mode 100644 arch/powerpc/kernel/signal.h
delete mode 100644 arch/powerpc/mm/imalloc.c
create mode 100644 arch/powerpc/platforms/Kconfig.cputype
delete mode 100644 arch/powerpc/platforms/apus/Kconfig
create mode 100644 arch/powerpc/platforms/pseries/eeh_sysfs.c
create mode 100644 include/asm-powerpc/mmu-hash32.h
Anton Blanchard (1):
[POWERPC] Reserve threadinfo flags for perfmon2
Arnd Bergmann (1):
[POWERPC] Split out CPU specific options into a new Kconfig file
Benjamin Herrenschmidt (18):
[POWERPC] unmap_vm_area becomes unmap_kernel_range for the public
[POWERPC] Rewrite IO allocation & mapping on powerpc64
[POWERPC] spufs: Add support for SPU single stepping
[POWERPC] spufs: Add a "capabilities" file to spu contexts
[POWERPC] Disable broken PPC_PTRACE_GETFPREGS on 32 bits
[POWERPC] ptrace cleanups
[POWERPC] ptrace updates & new, better requests
[POWERPC] Uninline common ptrace bits
[POWERPC] Remove some useless ifdef's in ptrace
[POWERPC] Allow ptrace write to pt_regs trap and orig_r3
[POWERPC] ptrace shouldn't touch FP exec mode
[POWERPC] powerpc: ptrace can set DABR on both 32 and 64 bits
[POWERPC] Always apply DABR changes on context switches
[POWERPC] Make syscall restart code more common
[POWERPC] Remove obsolete freezer bits
[POWERPC] Merge creation of signal frame
[POWERPC] Remove #ifdef around set_dabr in signal code
[POWERPC] Less ifdef's in signal.c/signal.h
Christoph Hellwig (3):
[POWERPC] Consolidate sys_sigaltstack
[POWERPC] Consolidate restore_sigmask
[POWERPC] Consolidate do_signal
David Gibson (13):
[POWERPC] Split low-level OF-related bootloader code into separate files
[POWERPC] Split out asm-ppc/mmu.h portions for the "classic" hash-based MMU
[POWERPC] Abolish iopa(), mm_ptov(), io_block_mapping() from arch/powerpc
[POWERPC] Remove the dregs of APUS support from arch/powerpc
[POWERPC] Remove a couple of unused definitions from pgtable_32.c
[POWERPC] Start factoring pgtable-ppc32.h and pgtable-ppc64.h
[POWERPC] Kill typedef-ed structs for hash PTEs and BATs
[POWERPC] Merge CPU features pertaining to icache coherency
[POWERPC] Factor zImage's 44x reset code out of ebony.c
[POWERPC] Derive ebc ranges property from EBC registers
[POWERPC] Consolidate cuboot initialization code
[POWERPC] Don't store a command line in the Holly device tree
[POWERPC] Fix problems with device tree representation of TSI-1xx bridges
Jake Moilanen (1):
[POWERPC] Donate idle CPU cycles on dedicated partitions
Jon Tollefson (1):
[POWERPC] Move common code out of if/else
Linas Vepstas (5):
[POWERPC] pseries: asm/pci-bridge.h CONFIG_ minor cleanup
[POWERPC] Add EEH sysfs blinkenlights
[POWERPC] Show EEH per-device false positives
[POWERPC] Remove dead EEH code
[POWERPC] Tweak EEH copyright info
Segher Boessenkool (1):
[POWERPC] Fix VDSO compile warning
will schmidt (1):
[POWERPC] During VM oom condition, kill all threads in process group
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Gibson @ 2007-06-15 4:14 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, David Woodhouse, Milton Miller, linux-mtd
In-Reply-To: <18fbfbaf113ab76b602d279848d9b405@kernel.crashing.org>
On Thu, Jun 07, 2007 at 05:55:44PM +0200, Segher Boessenkool wrote:
> > Any representation of flash devices in the device-tree should ideally
> > have 'bus width' and 'interleave' properties to contain this
> > information.
> >
> > The 'bus width' cannot necessarily be inferred, especially where a
> > given
> > bus can be configured to allow multiple sizes of access. It's purely a
> > function of how the flash chips are wired up. That's why we actually
> > call it 'bank width', not 'bus width' in the Linux code.
>
> Ah, "bank width" as in "bus width" per chip select. I see.
>
> So I think the best thing to have would be
>
> compatible "cfi-flash"
> bank-width like you said
> device-width width of a single flash device
> reg complete address range of this thing
>
> and then the Linux OF CFI flash code / MTD code just keeps
> on probing devices from that address range until it has it
> filled.
>
> Sounds good / comments / anything I missed?
Slight revision suggestion. Can we make 'device-width' optional, with
the default value being equal to the bank-width?
--
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] powerpc: Create "rom" (MTD) device prpmc2800
From: David Gibson @ 2007-06-15 4:12 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
In-Reply-To: <40446e5131495e077da798bc54843b2a@kernel.crashing.org>
On Wed, Jun 13, 2007 at 11:10:42AM +0200, Segher Boessenkool wrote:
> >> MTD does a lot of heuristic probing. It is pretty good,
> >> but it would be nice if you could skip that and hand it
> >> the exact values it needs. Also, this information should
> >> be in the device tree no matter what, even if Linux
> >> doesn't use it yet ;-)
> >
> > I agree. Of course, this means figuring out what the values actually
> > are for Ebony. I presently have no idea, since the heuristic probing
> > appears to work without problem.
>
> Doesn't it show it in sysfs, or in the dmesg at least?
> Maybe some other important stuff is there, too.
Not as far as I can tell. Only dmesg information I can see is:
1ff800000.large-fla: Found 1 x8 devices at 0x0 in 8-bit bank
1ff800000.large-fla: Found 1 x8 devices at 0x200000 in 8-bit bank
number of JEDEC chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code
brokenness.
--
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: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Rune Torgersen @ 2007-06-15 3:47 UTC (permalink / raw)
To: Li Yang-r58472, joakim.tjernlund
Cc: linuxppc-dev Development, Liu Dave-r63238
In-Reply-To: <989B956029373F45A0B8AF0297081890D2AE6C@zch01exm26.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
>From: Li Yang-r58472 [mailto:LeoLi@freescale.com]
>> if (assure_empty(info, 1) < 0)
>> return ERR_PTR(-ENOMEM);
>You also need to change this to assure_empty(info, 2), as you are very
>likely to need 2 slots afterward. You need to assure there are enough
>slots or grow the block number.
Ahh. I'll fix that in my code.
It was a quick&dirty hack to get the allocator to work wen we used most of the available DPRAM.
[-- Attachment #2: Type: text/html, Size: 1024 bytes --]
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Li Yang-r58472 @ 2007-06-15 2:44 UTC (permalink / raw)
To: Rune Torgersen, joakim.tjernlund
Cc: linuxppc-dev Development, Liu Dave-r63238
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0307485D@ismail.innsys.innovsys.com>
> -----Original Message-----
> From: Rune Torgersen [mailto:runet@innovsys.com]
> Sent: Friday, June 15, 2007 6:50 AM
> To: joakim.tjernlund@transmode.se; Li Yang-r58472
> Cc: linuxppc-dev Development; Liu Dave-r63238
> Subject: RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> Here is what I had to do to get best-fit + not allocating too much:
> (against 2.6.18)
> --- linux-innsys/arch/ppc/lib/rheap.c 2006/10/10 22:54:41 175
> +++ linux-innsys/arch/ppc/lib/rheap.c 2006/12/03 18:04:42 205
{snip}
> if (assure_empty(info, 1) < 0)
> return ERR_PTR(-ENOMEM);
You also need to change this to assure_empty(info, 2), as you are very
likely to need 2 slots afterward. You need to assure there are enough
slots or grow the block number.
- Leo
^ 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