* Re: [PATCH 13/13] Fix problems with device tree representation of TSI-1xx bridges
From: Segher Boessenkool @ 2007-06-14 14:24 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070613045301.111A1DDEBB@ozlabs.org>
> The ethernet, i2c, bridge and PCI nodes were
> given only as "tsi-*" which is somewhat inprecise, we replace with
> "tsi108-*" in the case of Taiga (which has a TSI108 bridge), and
> "tsi109-*", "tsi108-*" in the case of Holly (which has a TSI109
> bridge).
To be sure -- are all those ts109 devices actually
compatible to their ancestors on tsi108?
Since I _have_ to complain about _something_ -- don't
you run a spellchecker on your commit messages? :-)
Perfect patch as far as I can see, thank you David!
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Re: [PATCH 10/13] Derive ebc ranges property from EBC registers
From: Segher Boessenkool @ 2007-06-14 14:14 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070613045259.CFD2FDDF15@ozlabs.org>
> This patch replaces the hardcoded mappings with code in the zImage to
> read the EBC configuration registers and create an appropriate ranges
> property based on them.
Perhaps you should only do this if the device tree passed
to the bootwrapper doesn't already have a "ranges" property?
Segher
^ permalink raw reply
* Re: [PATCH 10/13] Derive ebc ranges property from EBC registers
From: Segher Boessenkool @ 2007-06-14 14:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070613045259.CFD2FDDF15@ozlabs.org>
> + // ranges property is supplied by zImage
> + // based on firmware's configuration of the
> + // EBC bridge
s/zImage/the bootwrapper/ ?
Segher
^ permalink raw reply
* Re: [PATCH 6/13] Start factoring pgtable-ppc32.h and pgtable-ppc64.h
From: Segher Boessenkool @ 2007-06-14 14:05 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070613045256.E9CA3DDE25@ozlabs.org>
+#define io_remap_pfn_range(vma, vaddr, pfn, size, prot) \
+ remap_pfn_range(vma, vaddr, pfn, size, prot)
Patch is mangled... This is from the raw source I
received, it isn't my mail reader this time ;-)
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Segher Boessenkool @ 2007-06-14 13:56 UTC (permalink / raw)
To: Vladislav Buzov; +Cc: linuxppc-dev list
In-Reply-To: <1181729973.25586.31.camel@dolphin.spb.rtsoft.ru>
> I read the MPC7450 reference manual and it describes a method to flush
> the cache using L2 hardware flushing feature. The cache flushing
> procedure consist of several steps and some of them are dictated by
> MPC7448 errata (www.freescale.com/files/32bit/doc/errata/MPC7448CE.pdf,
> Erratum no.3).
Are these errata 7448-only? If not, I wonder what is
done on PowerMacs?
> First, I'm looking for a help and advice why the current _set_L2CR()
> implementation may not work for MPC7450 (namely 7448 with 1Mb L2 cache
> installed). Is it a bug in _set_L2CR() or a hardware problem.
I think that if anyone here could answer this straight
away, the source code would have been fixed already ;-)
> I've
> mentioned above about MPC7450 hardware bug in L2 hardware flushing
> mechanism. May it be applicable to common cache flushing procedure
> based
> on sequence of lwz/dcbf instructions?
Dunno, too lazy to download that PDF, perhaps you can
quote the relevant part?
> Second, Is this patch acceptable?
Looks reasonable enough to me... if it works (on all
things considered "7450" by the kernel).
> /* 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.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-14 13:43 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <46713999.2080004@ru.mvista.com>
>> , and I don't see what
>> it buys us over the partitions/partition-names pair of properties.
>
> I was thinking of using a signle multipart prop but dtc had no
> support for it at that time...
The kernel (and probably most DTB parsers) cannot handle
unaligned integers in properties, even though it is a
perfectly fine thing to have.
Segher
^ permalink raw reply
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Li Yang @ 2007-06-14 13:42 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev Development, Liu Dave-r63238
In-Reply-To: <4671321E.9000204@ThePTRGroup.com>
Here is the patch to remove internal fragment when doing
aligned allocation.
The patch change to add the fragments back into the free list,
instead of allocate the whole trunk of space with internal
fragment.
---
arch/powerpc/lib/rheap.c | 45 +++++++++++++++++++++++++++------------------
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/lib/rheap.c b/arch/powerpc/lib/rheap.c
index 180ee29..f8b3f1a 100644
--- a/arch/powerpc/lib/rheap.c
+++ b/arch/powerpc/lib/rheap.c
@@ -437,16 +437,12 @@ unsigned long rh_alloc_align(rh_info_t * info, int size, int alignment, const ch
struct list_head *l;
rh_block_t *blk;
rh_block_t *newblk;
- unsigned long start;
+ unsigned long start, sp_size;
/* Validate size, and alignment must be power of two */
if (size <= 0 || (alignment & (alignment - 1)) != 0)
return (unsigned long) -EINVAL;
- /* given alignment larger that default rheap alignment */
- if (alignment > info->alignment)
- size += alignment - 1;
-
/* Align to configured alignment */
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
@@ -456,8 +452,11 @@ unsigned long rh_alloc_align(rh_info_t * info, int size, int alignment, const ch
blk = NULL;
list_for_each(l, &info->free_list) {
blk = list_entry(l, rh_block_t, list);
- if (size <= blk->size)
- break;
+ if (size <= blk->size) {
+ start = (blk->start + alignment - 1) & ~(alignment - 1);
+ if (start + size <= blk->start + blk->size)
+ break;
+ }
blk = NULL;
}
@@ -470,25 +469,35 @@ unsigned long rh_alloc_align(rh_info_t * info, int size, int alignment, const ch
list_del(&blk->list);
newblk = blk;
} else {
+ /* Fragment caused, split if needed */
+ /* Create block for fragment in the beginning, insert to free list */
+ sp_size = start - blk->start;
+ if (sp_size) {
+ rh_block_t *spblk;
+
+ spblk = get_slot(info);
+ spblk->start = blk->start;
+ spblk->size = sp_size;
+ list_add(&spblk->list, &blk->list);
+ }
newblk = get_slot(info);
- newblk->start = blk->start;
+ newblk->start = start;
newblk->size = size;
- /* blk still in free list, with updated start, size */
- blk->start += size;
- blk->size -= size;
+ /* blk still in free list, with updated start, size
+ * for fragment in the end */
+ blk->start = start + size;
+ blk->size -= sp_size + size;
+ /* No fragment in the end, remove blk */
+ if (blk->size == 0) {
+ list_del(&blk->list);
+ release_slot(info, blk);
+ }
}
newblk->owner = owner;
- start = newblk->start;
attach_taken_block(info, newblk);
- /* for larger alignment return fixed up pointer */
- /* this is no problem with the deallocator since */
- /* we scan for pointers that lie in the blocks */
- if (alignment > info->alignment)
- start = (start + alignment - 1) & ~(alignment - 1);
-
return start;
}
^ permalink raw reply related
* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Kumar Gala @ 2007-06-14 13:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, arnd, Stephen Rothwell
In-Reply-To: <18032.40447.579128.989284@cargo.ozlabs.ibm.com>
On Jun 13, 2007, at 8:46 PM, Paul Mackerras wrote:
> Most of this series of patches touch 8xxx or 5xxx stuff in one way or
> another, so I'll leave it to Kumar to make the decision about them.
> I'll put in 1/13.
Arnd,
I'm a little hesitant to move the embedded ppc's over to
multiplatform quite yet. One feature I wanted was in Kconfig a way
to enforce the selection of at least one choice, as well as being
able to optimize things since we only had one choice selected.
See the following thread for discussion I had with Sam & Roman on the
subject:
http://marc.info/?t=117156757000002&r=1&w=2
- k
^ permalink raw reply
* Re: [PATCH v4]: Fix e500 v2 core reboot bug
From: Kumar Gala @ 2007-06-14 13:26 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1181726022.13195.28.camel@localhost.localdomain>
On Jun 13, 2007, at 4:13 AM, Zang Roy-r61911 wrote:
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> Fix the reset bug on 8548CDS board.
> Begin from MPC8548 with e500 v2 core, a new reset
> control register is added.
> This register is used for the cpu reset.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> Pick up this one :-(
>
> arch/powerpc/boot/dts/mpc8548cds.dts | 6 ++++++
> arch/powerpc/platforms/85xx/misc.c | 32 +++++++++++++++++++++++
> +++++++++
> 2 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts b/arch/powerpc/
> boot/dts/mpc8548cds.dts
> index ad96381..0550a3c 100644
> --- a/arch/powerpc/boot/dts/mpc8548cds.dts
> +++ b/arch/powerpc/boot/dts/mpc8548cds.dts
> @@ -177,6 +177,12 @@
> interrupt-parent = <&mpic>;
> };
>
> + global-utilities@e0000 { //global utilities reg
> + compatible = "fsl,mpc8548-guts";
> + reg = <e0000 1000>;
> + fsl,has-rstcr;
> + };
> +
> pci1: pci@8000 {
> interrupt-map-mask = <1f800 0 0 7>;
> interrupt-map = <
Now that we resolved this can you work up a second patch to update
Documentation/powerpc/booting-without-of.txt for this node.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-14 13:20 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <46713711.5010709@ru.mvista.com>
>> I tought I saw some config option implying that there already existed
>> an on-device partition table format for flashes. Doesn't help us for
>
> You probably mean RedBoot table?
>
>> existing boards which don't expect such a setup, of course.
>
> Exactly. It's specific to RedBoot.
Sounds like we need to create a more generic format
then -- perhaps adopting most of the redboot thing.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-14 13:18 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <4671390D.1060606@ru.mvista.com>
>>> So, what you're suggesting is a subnode for each described partition?
>
>> I'm saying this is a reasonable way to describe the regions
>> of flash the firmware itself cares about.
>
>> This isn't anything new; it is done like this on some
>> Apple systems, for example.
>
> First you're saying that nodes should correspont to *real* devices,
> then it turns out that there have been precedents for the nodes
> corresponding to completely virtual entities? ;-)
Every physical device should have its own node (there
_can_ be exceptions, but if you can help it at all...)
There can be virtual devices as well, although you don't
often need or want them. There are a few pseudo-nodes
too, not representing _any_ device, physical or virtual.
>>> Seems an awfully verbose way of going about it,
>
>> Not verbose, but flexible, and in line with everything
>
> Yes, I'd agree about more flexibility...
Good to hear :-)
>> else about the device tree.
>
> How about your earlier arguments against the representation of
> flashes?
What arguments, exactly? Perhaps you're not understanding
exactly what I meant, or perhaps I changed my mind -- that
happens sometimes, after long discussions. That is what
those discussions are for, even -- only after looking at
every detail, and discussing all those details with other
people, including non-experts on OF who can bring in valuable
concerns about use cases etc.; only then can a good device
binding be defined. Sometimes also it should be concluded
there is not enough experience yet on how to do a certain
device binding; in such a case, the best course of action is
usually to _not_ define such a binding yet.
>>> and I don't see what
>>> it buys us over the partitions/partition-names pair of properties.
>
>> It is extensible. It makes parsing trivial. It
>
> Excellent -- previously my arguments about more simplicity for
> representing flash itself were sent to /dev/null.
Do you like my proposed CFI binding? I need a bit more
input on how to do a JEDEC flash binding still. After
I've written it all up properly, I plan to send this to
the OF working group to turn it into a standard binding.
>> represents a flash partition in a way similar to how
>> a "whole" flash device is represented.
>
> Except it's not a device. :-)
Yes, but in many aspects it can be treated as one. And
it cannot be mistaken for one, either.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-14 12:50 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070612044246.GC4198@localhost.localdomain>
Hello.
David Gibson wrote:
> So, what you're suggesting is a subnode for each described partition?
> Seems an awfully verbose way of going about it, and I don't see what
> it buys us over the partitions/partition-names pair of properties.
I was thinking of using a signle multipart prop but dtc had no support for
it at that time...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-14 12:48 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <9fbd7a7f5cdde58768569ab23c7aec7c@kernel.crashing.org>
Segher Boessenkool wrote:
>>So, what you're suggesting is a subnode for each described partition?
> I'm saying this is a reasonable way to describe the regions
> of flash the firmware itself cares about.
> This isn't anything new; it is done like this on some
> Apple systems, for example.
First you're saying that nodes should correspont to *real* devices, then
it turns out that there have been precedents for the nodes corresponding to
completely virtual entities? ;-)
>>Seems an awfully verbose way of going about it,
> Not verbose, but flexible, and in line with everything
Yes, I'd agree about more flexibility...
> else about the device tree.
How about your earlier arguments against the representation of flashes?
>>and I don't see what
>>it buys us over the partitions/partition-names pair of properties.
> It is extensible. It makes parsing trivial. It
Excellent -- previously my arguments about more simplicity for
representing flash itself were sent to /dev/null.
> represents a flash partition in a way similar to how
> a "whole" flash device is represented.
Except it's not a device. :-)
> Segher
WBR, Sergei
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Li Yang-r58472 @ 2007-06-14 12:48 UTC (permalink / raw)
To: Chuck Meade, joakim.tjernlund; +Cc: linuxppc-dev Development, Liu Dave-r63238
In-Reply-To: <4671321E.9000204@ThePTRGroup.com>
You are right. The proposed change is just an unwise suggestion.
I later overhauled and reworked the aligned allocation of rheap to
prevent it from generating internal fragment. Patch coming soon.
- Leo
> -----Original Message-----
> From: Chuck Meade [mailto:chuck@ThePTRGroup.com]
> Sent: Thursday, June 14, 2007 8:19 PM
> To: joakim.tjernlund@transmode.se
> Cc: Li Yang-r58472; linuxppc-dev Development; Liu Dave-r63238
> Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> This output looks buggy:
>=20
{snip}
>=20
> These buffer overlaps probably have a lot to do with your pings
stopping.
> I would say first order of business would be to investigate what could
> be generating all these overlapped allocations. Some of these make me
think
> the allocator code could be racy, like allocations are not aware of
other
> "recent" or ongoing allocations. But in any case the allocator is
broken.
>=20
> Chuck
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-14 12:39 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070614042906.GC11177@localhost.localdomain>
David Gibson wrote:
>>>>How do non-device-tree MTD users handle this?
>>>Invidual, board-specific map files with hardcoded partition tables.
>>That's what I was afraid of. Sigh.
>>>See drivers/mtd/maps/ebony.c for example.
>>[/me looks...] Oh horror.
>>>Hence my view of the device
>>>tree as a preferable option.
>>I think some binary partition table format that can be
>>used by _all_ MTD consumers should be defined. How
>>that table should be communicated to the kernel in the
>>device tree case we can discuss later, then. Maybe
>>something as simple as storing it in flash, and have a
>>"partition-table-offset" property or something like that.
>>This is something the MTD people will have to buy into
>>of course.
> I tought I saw some config option implying that there already existed
> an on-device partition table format for flashes. Doesn't help us for
You probably mean RedBoot table?
> existing boards which don't expect such a setup, of course.
Exactly. It's specific to RedBoot.
WBR, Sergei
^ permalink raw reply
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Chuck Meade @ 2007-06-14 12:18 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev Development, Liu Dave-r63238
In-Reply-To: <1181807671.30670.358.camel@gentoo-jocke.transmode.se>
This output looks buggy:
Joakim Tjernlund wrote:
> On Thu, 2007-06-14 at 15:37 +0800, Li Yang-r58472 wrote:
>> Try remove the following lines in rheap.c
>>
>> /* given alignment larger that default rheap alignment */
>> if (alignment > info->alignment)
>> size += alignment - 1;
>>
>> I don't know if this breaks other things, just have a try.
> I did and got this alloc:
> MURAM alloc, start:400, size:200(512), align:8(8)
> MURAM alloc, start:600, size:208(520), align:8(8)
> MURAM alloc, start:880, size:80(128), align:80(128)
Bogus -- note the overlap below
> MURAM alloc, start:900, size:1a0(416), align:100(256)
> MURAM alloc, start:a40, size:40(64), align:20(32)
> MURAM alloc, start:b00, size:100(256), align:100(256)
Another overlap(s) below-- all of these overlap
> MURAM alloc, start:c00, size:a0(160), align:100(256)
> MURAM alloc, start:c40, size:c(12), align:40(64)
> MURAM alloc, start:c18, size:30(48), align:8(8)
> MURAM alloc, start:c80, size:80(128), align:80(128)
> MURAM alloc, start:d00, size:80(128), align:80(128)
> MURAM alloc, start:d80, size:80(128), align:80(128)
> MURAM alloc, start:e00, size:80(128), align:80(128)
> MURAM alloc, start:e80, size:40(64), align:40(64)
> MURAM alloc, start:ec0, size:40(64), align:40(64)
> MURAM alloc, start:f00, size:40(64), align:40(64)
Another overlap--
> MURAM alloc, start:f40, size:40(64), align:40(64)
> MURAM alloc, start:f44, size:5d(93), align:4(4)
> MURAM alloc, start:f48, size:200(512), align:8(8)
> MURAM alloc, start:1148, size:208(520), align:8(8)
> MURAM alloc, start:1380, size:80(128), align:80(128)
And here-
> MURAM alloc, start:1400, size:1a0(416), align:100(256)
> MURAM alloc, start:1580, size:40(64), align:20(32)
> MURAM alloc, start:1600, size:100(256), align:100(256)
Here- note the start address moving backward. All overlap.
> MURAM alloc, start:1700, size:a0(160), align:100(256)
> MURAM alloc, start:1780, size:c(12), align:40(64)
> MURAM alloc, start:1758, size:30(48), align:8(8)
> MURAM alloc, start:1800, size:80(128), align:80(128)
> MURAM alloc, start:1880, size:80(128), align:80(128)
> MURAM alloc, start:1900, size:80(128), align:80(128)
And-
> MURAM alloc, start:1980, size:80(128), align:80(128)
> MURAM alloc, start:19c0, size:40(64), align:40(64)
> MURAM alloc, start:1a00, size:40(64), align:40(64)
> MURAM alloc, start:1a40, size:40(64), align:40(64)
And-
> MURAM alloc, start:1a80, size:40(64), align:40(64)
> MURAM alloc, start:1a88, size:5d(93), align:4(4)
> MURAM alloc, start:1a88, size:200(512), align:8(8)
> MURAM alloc, start:1c88, size:208(520), align:8(8)
> MURAM alloc, start:1f00, size:80(128), align:80(128)
And-
> MURAM alloc, start:2000, size:1a0(416), align:100(256)
> MURAM alloc, start:20c0, size:40(64), align:20(32)
> MURAM alloc, start:2100, size:100(256), align:100(256)
> MURAM alloc, start:2200, size:a0(160), align:100(256)
An overlap exists here too-
> MURAM alloc, start:22c0, size:c(12), align:40(64)
> MURAM alloc, start:22a0, size:30(48), align:8(8)
> MURAM alloc, start:2300, size:80(128), align:80(128)
> MURAM alloc, start:2380, size:80(128), align:80(128)
> MURAM alloc, start:2400, size:80(128), align:80(128)
> MURAM alloc, start:2480, size:80(128), align:80(128)
> MURAM alloc, start:2500, size:40(64), align:40(64)
> MURAM alloc, start:2540, size:40(64), align:40(64)
> MURAM alloc, start:2580, size:40(64), align:40(64)
And-
> MURAM alloc, start:25c0, size:40(64), align:40(64)
> MURAM alloc, start:25cc, size:5d(93), align:4(4)
>
> But I can't ping anymore
These buffer overlaps probably have a lot to do with your pings stopping.
I would say first order of business would be to investigate what could
be generating all these overlapped allocations. Some of these make me think
the allocator code could be racy, like allocations are not aware of other
"recent" or ongoing allocations. But in any case the allocator is broken.
Chuck
^ permalink raw reply
* Re: [PATCH] Add the support of ST M48T59 RTC chip in rtc-class driver subsystem
From: Gabriel Paubert @ 2007-06-14 10:32 UTC (permalink / raw)
To: Mark Zhan; +Cc: a.zummo, rtc-linux, linuxppc-dev@ozlabs.org
In-Reply-To: <1181656776.3975.16.camel@mark>
On Tue, Jun 12, 2007 at 09:59:36PM +0800, Mark Zhan wrote:
> Hi Gabriel,
>
> On Mon, 2007-06-11 at 14:11 +0200, Gabriel Paubert wrote:
> ....
> > There are other boards which have exactly the same chip, but use
> > a very different (uglier) access method: using ISA 2 I/O ports
> > (0x74 and 0x75) to write the address and another port (0x77) to
> > read/write the data.
> >
> > Besides that, these boards also use the NVRAM part which means that
> > a spinlock must be used to serialize between RTC and NVRAM access.
> >
> > I have no idea whether the drivers should be shared or two
> > different drivers should be written... But if there are two
> > different drivers, there should be a way to distinguish them
> > (different config name, different module names, and some
> > explanation in the config help text).
> >
>
> I will rework this driver to add a platform data structure which enables
> the platform to provide the platform specific access method.
I'm not even sure that this is a good idea: the direct mapped nvram/RTC
is much simpler, and adding another indirection layer transforms many
leaf functions into non leaf one, which makes the code significantly bigger.
>
> For the NVRAM issue, I have no idea how other boards access the NVRAM.
> So could you provide me more information?
That's the hardest problem. Since you use the same ISA (yuck) I/O
ports to access the NVRAM and the RTC (after all it is the same chip,
using the same address pins), the accesses need to be serialized
through a shared spinlock.
With a direct mapped like your machine, the drivers can be completely
independent: they will never step on each other's toes.
I've not yet made up my mind on which is the best way to handle
the problem and am leaving tomorrow for about 1 week. For
now I think that your patch is fine (using NO_IRQ as I suggested)
and I shall revisit it when time comes to port the kernel
to these boards (running 2.2 for 8 years, it's not a few
more months to switch to 2.6 that matters).
Regards,
Gabriel
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-14 10:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <1181815870.14818.401.camel@localhost.localdomain>
>> Please review the OF spec, sections 3.4 and the "/" entry
>> of 3.5.
>>
>> I'f the flat device tree doc and/or code says differently
>> here, that is a bug.
>
> Well, I wonder if that's been superceeded by some RFC or never
> validated
> addition ...
It has been that way since before the OF standard
existed, and never has been changed.
> None of the Apple trees for example has a /name property
Apple's trees have many many problems, you know that
as well as anybody.
> and the idea of having a node with a name that doesn't participate in
> the path resolution in just wrong.
Nonsense, a pathname starting with "/" is handled
specially. This is true on Unix systems as well.
> We should check but I don't think IBM
> trees have one either.
>
> So I stand by the way I defined the flat DT -> no name in the root. But
> you are welcome to use compatible
You can use "compatible" as an alternate name, sure.
Not allowing a "name" in the root node is simply an
oversight in the flat device tree, and should be fixed
in my opinion. There is no backwwards-compatibility
problem with that.
> and model.
> "model" is a completely separate thing, so yeah.
Segher
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Benjamin Herrenschmidt @ 2007-06-14 10:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <3fa8fff1a1c5b1b353aab4f1ef014804@kernel.crashing.org>
On Thu, 2007-06-14 at 09:31 +0200, Segher Boessenkool wrote:
> >> It should include "sony,", in the "name" property at least.
> >>
> >> "model" same as "name" cannot make sense either.
> >
> > Dunno what you are on about the model vs. name but this is the root of
> > the DT, it has no name.
>
> Please review the OF spec, sections 3.4 and the "/" entry
> of 3.5.
>
> I'f the flat device tree doc and/or code says differently
> here, that is a bug.
Well, I wonder if that's been superceeded by some RFC or never validated
addition ... None of the Apple trees for example has a /name property
and the idea of having a node with a name that doesn't participate in
the path resolution in just wrong. We should check but I don't think IBM
trees have one either.
So I stand by the way I defined the flat DT -> no name in the root. But
you are welcome to use compatible and model.
Ben.
^ permalink raw reply
* [PATCH] ehea: Whitespace cleanup
From: Jan-Bernd Themann @ 2007-06-14 7:40 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
This patch fixes several whitespace issues.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index c0f81b5..abaf3ac 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0064"
+#define DRV_VERSION "EHEA_0065"
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -136,10 +136,10 @@ void ehea_dump(void *adr, int len, char *msg);
(0xffffffffffffffffULL >> ((64 - (mask)) & 0xffff))
#define EHEA_BMASK_SET(mask, value) \
- ((EHEA_BMASK_MASK(mask) & ((u64)(value))) << EHEA_BMASK_SHIFTPOS(mask))
+ ((EHEA_BMASK_MASK(mask) & ((u64)(value))) << EHEA_BMASK_SHIFTPOS(mask))
#define EHEA_BMASK_GET(mask, value) \
- (EHEA_BMASK_MASK(mask) & (((u64)(value)) >> EHEA_BMASK_SHIFTPOS(mask)))
+ (EHEA_BMASK_MASK(mask) & (((u64)(value)) >> EHEA_BMASK_SHIFTPOS(mask)))
/*
* Generic ehea page
@@ -190,7 +190,7 @@ struct ehea_av;
* Queue attributes passed to ehea_create_qp()
*/
struct ehea_qp_init_attr {
- /* input parameter */
+ /* input parameter */
u32 qp_token; /* queue token */
u8 low_lat_rq1;
u8 signalingtype; /* cqe generation flag */
@@ -212,7 +212,7 @@ struct ehea_qp_init_attr {
u64 recv_cq_handle;
u64 aff_eq_handle;
- /* output parameter */
+ /* output parameter */
u32 qp_nr;
u16 act_nr_send_wqes;
u16 act_nr_rwqes_rq1;
@@ -279,12 +279,12 @@ struct ehea_qp {
* Completion Queue attributes
*/
struct ehea_cq_attr {
- /* input parameter */
+ /* input parameter */
u32 max_nr_of_cqes;
u32 cq_token;
u64 eq_handle;
- /* output parameter */
+ /* output parameter */
u32 act_nr_of_cqes;
u32 nr_pages;
};
diff --git a/drivers/net/ehea/ehea_hw.h b/drivers/net/ehea/ehea_hw.h
index 1246757..1af7ca4 100644
--- a/drivers/net/ehea/ehea_hw.h
+++ b/drivers/net/ehea/ehea_hw.h
@@ -211,34 +211,34 @@ static inline void epa_store_acc(struct h_epa epa, u32 offset, u64 value)
}
#define epa_store_eq(epa, offset, value)\
- epa_store(epa, EQTEMM_OFFSET(offset), value)
+ epa_store(epa, EQTEMM_OFFSET(offset), value)
#define epa_load_eq(epa, offset)\
- epa_load(epa, EQTEMM_OFFSET(offset))
+ epa_load(epa, EQTEMM_OFFSET(offset))
#define epa_store_cq(epa, offset, value)\
- epa_store(epa, CQTEMM_OFFSET(offset), value)
+ epa_store(epa, CQTEMM_OFFSET(offset), value)
#define epa_load_cq(epa, offset)\
- epa_load(epa, CQTEMM_OFFSET(offset))
+ epa_load(epa, CQTEMM_OFFSET(offset))
#define epa_store_qp(epa, offset, value)\
- epa_store(epa, QPTEMM_OFFSET(offset), value)
+ epa_store(epa, QPTEMM_OFFSET(offset), value)
#define epa_load_qp(epa, offset)\
- epa_load(epa, QPTEMM_OFFSET(offset))
+ epa_load(epa, QPTEMM_OFFSET(offset))
#define epa_store_qped(epa, offset, value)\
- epa_store(epa, QPEDMM_OFFSET(offset), value)
+ epa_store(epa, QPEDMM_OFFSET(offset), value)
#define epa_load_qped(epa, offset)\
- epa_load(epa, QPEDMM_OFFSET(offset))
+ epa_load(epa, QPEDMM_OFFSET(offset))
#define epa_store_mrmw(epa, offset, value)\
- epa_store(epa, MRMWMM_OFFSET(offset), value)
+ epa_store(epa, MRMWMM_OFFSET(offset), value)
#define epa_load_mrmw(epa, offset)\
- epa_load(epa, MRMWMM_OFFSET(offset))
+ epa_load(epa, MRMWMM_OFFSET(offset))
#define epa_store_base(epa, offset, value)\
- epa_store(epa, HCAGR_OFFSET(offset), value)
+ epa_store(epa, HCAGR_OFFSET(offset), value)
#define epa_load_base(epa, offset)\
- epa_load(epa, HCAGR_OFFSET(offset))
+ epa_load(epa, HCAGR_OFFSET(offset))
static inline void ehea_update_sqa(struct ehea_qp *qp, u16 nr_wqes)
{
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 9e13433..bdb5241 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -81,7 +81,7 @@ MODULE_PARM_DESC(use_mcs, " 0:NAPI, 1:Multiple receive queues, Default = 1 ");
static int port_name_cnt = 0;
static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
- const struct of_device_id *id);
+ const struct of_device_id *id);
static int __devexit ehea_remove(struct ibmebus_dev *dev);
@@ -236,7 +236,7 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
rwqe = ehea_get_next_rwqe(qp, rq_nr);
rwqe->wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE, wqe_type)
- | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
+ | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
rwqe->sg_list[0].l_key = pr->recv_mr.lkey;
rwqe->sg_list[0].vaddr = (u64)skb->data;
rwqe->sg_list[0].len = packet_size;
@@ -427,7 +427,7 @@ static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
break;
}
skb_copy_to_linear_data(skb, ((char*)cqe) + 64,
- cqe->num_bytes_transfered - 4);
+ cqe->num_bytes_transfered - 4);
ehea_fill_skb(port->netdev, skb, cqe);
} else if (rq == 2) { /* RQ2 */
skb = get_skb_by_index(skb_arr_rq2,
@@ -618,7 +618,7 @@ static struct ehea_port *ehea_get_port(struct ehea_adapter *adapter,
for (i = 0; i < EHEA_MAX_PORTS; i++)
if (adapter->port[i])
- if (adapter->port[i]->logical_port_id == logical_port)
+ if (adapter->port[i]->logical_port_id == logical_port)
return adapter->port[i];
return NULL;
}
@@ -1695,6 +1695,7 @@ static void ehea_xmit2(struct sk_buff *skb, struct net_device *dev,
{
if (skb->protocol == htons(ETH_P_IP)) {
const struct iphdr *iph = ip_hdr(skb);
+
/* IPv4 */
swqe->tx_control |= EHEA_SWQE_CRC
| EHEA_SWQE_IP_CHECKSUM
@@ -1705,13 +1706,12 @@ static void ehea_xmit2(struct sk_buff *skb, struct net_device *dev,
write_ip_start_end(swqe, skb);
if (iph->protocol == IPPROTO_UDP) {
- if ((iph->frag_off & IP_MF) ||
- (iph->frag_off & IP_OFFSET))
+ if ((iph->frag_off & IP_MF)
+ || (iph->frag_off & IP_OFFSET))
/* IP fragment, so don't change cs */
swqe->tx_control &= ~EHEA_SWQE_TCP_CHECKSUM;
else
write_udp_offset_end(swqe, skb);
-
} else if (iph->protocol == IPPROTO_TCP) {
write_tcp_offset_end(swqe, skb);
}
@@ -1739,6 +1739,7 @@ static void ehea_xmit3(struct sk_buff *skb, struct net_device *dev,
if (skb->protocol == htons(ETH_P_IP)) {
const struct iphdr *iph = ip_hdr(skb);
+
/* IPv4 */
write_ip_start_end(swqe, skb);
@@ -1751,8 +1752,8 @@ static void ehea_xmit3(struct sk_buff *skb, struct net_device *dev,
write_tcp_offset_end(swqe, skb);
} else if (iph->protocol == IPPROTO_UDP) {
- if ((iph->frag_off & IP_MF) ||
- (iph->frag_off & IP_OFFSET))
+ if ((iph->frag_off & IP_MF)
+ || (iph->frag_off & IP_OFFSET))
/* IP fragment, so don't change cs */
swqe->tx_control |= EHEA_SWQE_CRC
| EHEA_SWQE_IMM_DATA_PRESENT;
@@ -2407,7 +2408,7 @@ static void __devinit logical_port_release(struct device *dev)
}
static int ehea_driver_sysfs_add(struct device *dev,
- struct device_driver *driver)
+ struct device_driver *driver)
{
int ret;
@@ -2424,7 +2425,7 @@ static int ehea_driver_sysfs_add(struct device *dev,
}
static void ehea_driver_sysfs_remove(struct device *dev,
- struct device_driver *driver)
+ struct device_driver *driver)
{
struct device_driver *drv = driver;
@@ -2453,7 +2454,7 @@ static struct device *ehea_register_port(struct ehea_port *port,
}
ret = device_create_file(&port->ofdev.dev, &dev_attr_log_port_id);
- if (ret) {
+ if (ret) {
ehea_error("failed to register attributes, ret=%d", ret);
goto out_unreg_of_dev;
}
@@ -2601,6 +2602,7 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
{
struct device_node *lhea_dn;
struct device_node *eth_dn = NULL;
+
const u32 *dn_log_port_id;
int i = 0;
@@ -2608,7 +2610,7 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
while ((eth_dn = of_get_next_child(lhea_dn, eth_dn))) {
dn_log_port_id = of_get_property(eth_dn, "ibm,hea-port-no",
- NULL);
+ NULL);
if (!dn_log_port_id) {
ehea_error("bad device node: eth_dn name=%s",
eth_dn->full_name);
@@ -2648,7 +2650,7 @@ static struct device_node *ehea_get_eth_dn(struct ehea_adapter *adapter,
while ((eth_dn = of_get_next_child(lhea_dn, eth_dn))) {
dn_log_port_id = of_get_property(eth_dn, "ibm,hea-port-no",
- NULL);
+ NULL);
if (dn_log_port_id)
if (*dn_log_port_id == logical_port_id)
return eth_dn;
@@ -2789,7 +2791,7 @@ static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
adapter->ebus_dev = dev;
adapter_handle = of_get_property(dev->ofdev.node, "ibm,hea-handle",
- NULL);
+ NULL);
if (adapter_handle)
adapter->handle = *adapter_handle;
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index f24a886..29eaa46 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -211,7 +211,7 @@ u64 ehea_destroy_cq_res(struct ehea_cq *cq, u64 force)
u64 hret;
u64 adapter_handle = cq->adapter->handle;
- /* deregister all previous registered pages */
+ /* deregister all previous registered pages */
hret = ehea_h_free_resource(adapter_handle, cq->fw_handle, force);
if (hret != H_SUCCESS)
return hret;
@@ -362,7 +362,7 @@ int ehea_destroy_eq(struct ehea_eq *eq)
if (hret != H_SUCCESS) {
ehea_error("destroy EQ failed");
return -EIO;
- }
+ }
return 0;
}
@@ -507,44 +507,44 @@ out_freemem:
u64 ehea_destroy_qp_res(struct ehea_qp *qp, u64 force)
{
- u64 hret;
- struct ehea_qp_init_attr *qp_attr = &qp->init_attr;
+ u64 hret;
+ struct ehea_qp_init_attr *qp_attr = &qp->init_attr;
- ehea_h_disable_and_get_hea(qp->adapter->handle, qp->fw_handle);
- hret = ehea_h_free_resource(qp->adapter->handle, qp->fw_handle, force);
- if (hret != H_SUCCESS)
- return hret;
+ ehea_h_disable_and_get_hea(qp->adapter->handle, qp->fw_handle);
+ hret = ehea_h_free_resource(qp->adapter->handle, qp->fw_handle, force);
+ if (hret != H_SUCCESS)
+ return hret;
- hw_queue_dtor(&qp->hw_squeue);
- hw_queue_dtor(&qp->hw_rqueue1);
+ hw_queue_dtor(&qp->hw_squeue);
+ hw_queue_dtor(&qp->hw_rqueue1);
- if (qp_attr->rq_count > 1)
- hw_queue_dtor(&qp->hw_rqueue2);
- if (qp_attr->rq_count > 2)
- hw_queue_dtor(&qp->hw_rqueue3);
- kfree(qp);
+ if (qp_attr->rq_count > 1)
+ hw_queue_dtor(&qp->hw_rqueue2);
+ if (qp_attr->rq_count > 2)
+ hw_queue_dtor(&qp->hw_rqueue3);
+ kfree(qp);
- return hret;
+ return hret;
}
int ehea_destroy_qp(struct ehea_qp *qp)
{
- u64 hret;
- if (!qp)
- return 0;
+ u64 hret;
+ if (!qp)
+ return 0;
- if ((hret = ehea_destroy_qp_res(qp, NORMAL_FREE)) == H_R_STATE) {
- ehea_error_data(qp->adapter, qp->fw_handle);
- hret = ehea_destroy_qp_res(qp, FORCE_FREE);
- }
+ if ((hret = ehea_destroy_qp_res(qp, NORMAL_FREE)) == H_R_STATE) {
+ ehea_error_data(qp->adapter, qp->fw_handle);
+ hret = ehea_destroy_qp_res(qp, FORCE_FREE);
+ }
- if (hret != H_SUCCESS) {
- ehea_error("destroy QP failed");
- return -EIO;
- }
+ if (hret != H_SUCCESS) {
+ ehea_error("destroy QP failed");
+ return -EIO;
+ }
- return 0;
+ return 0;
}
int ehea_reg_kernel_mr(struct ehea_adapter *adapter, struct ehea_mr *mr)
^ permalink raw reply related
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-14 8:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070614042906.GC11177@localhost.localdomain>
>> I think some binary partition table format that can be
>> used by _all_ MTD consumers should be defined. How
>> that table should be communicated to the kernel in the
>> device tree case we can discuss later, then. Maybe
>> something as simple as storing it in flash, and have a
>> "partition-table-offset" property or something like that.
>>
>> This is something the MTD people will have to buy into
>> of course.
>
> I tought I saw some config option implying that there already existed
> an on-device partition table format for flashes.
Interesting.
> Doesn't help us for
> existing boards which don't expect such a setup, of course.
If they don't use a device tree yet, I don't see much
of a problem. If they do already, that can be fixed,
too -- gradually.
> Incidentally, with either the partitions-described-by-properties, or
> the revised more-flexible partitions-described-by-subnodes format, I'm
> not seeing it as required that the whole of the flash address space be
> described.
Indeed. It is fine to simply tell the OS "there is
some flash here, you figure out what to use it for".
> So it would certainly be possible to *only* describe the
> sections of the flash used by firmware. But I'm suggesting that we
> optionally allow other partitions to be described for boards / systems
> which have strong conventions about how the flash is divided and where
> we don't have any other way of recording the partition layout short of
> hardcoding.
As long as it's optional there should be no harm in
that, of course.
Segher
^ permalink raw reply
* Re: [patch 12/13] powerpc: fix building without PCI
From: Arnd Bergmann @ 2007-06-14 7:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <18032.40314.440212.19149@cargo.ozlabs.ibm.com>
On Thursday 14 June 2007, Paul Mackerras wrote:
> > Some code looks can be configured to be built without
> > PCI support, but does not work properly.
>=20
> I don't think it makes sense to build a chrp kernel without PCI. =A0I
> would rather just always select PCI for chrp rather than uglifying the
> code with all those ifdefs.
Ok, good. I had done that at first but then saw that the chrp code
already has a conditional on CONFIG_PCI in the Makefile and changed
it.
I have changed it back in my series now.
Arnd <><
^ permalink raw reply
* can you help me
From: volcano @ 2007-06-14 7:57 UTC (permalink / raw)
To: linuxppc-embedded
hi all :
I have been reading the U-BOOT code based on mpc8260 these days.Can you
show me where can I find the document which have the explaination of the whole
code . thanks.
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Joakim Tjernlund @ 2007-06-14 7:57 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development, Liu Dave-r63238
In-Reply-To: <989B956029373F45A0B8AF0297081890D2ADA9@zch01exm26.fsl.freescale.net>
On Thu, 2007-06-14 at 15:26 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] On Behalf
> Of
> > Joakim Tjernlund
> > Sent: Thursday, June 14, 2007 3:18 PM
> > To: Liu Dave-r63238
> > Cc: 'linuxppc-dev Development'
> > Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
> >
> > On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> > > On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > > > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > > > a Freescale 832x CPU gives me this:
> > > > > ifconfig eth2 up
> > > > > ucc_geth_startup: Can not allocate DPRAM memory for
> p_thread_data_tx.
> > > > > eth2: Cannot configure net device, aborting.
> > > > > SIOCSIFFLAGS: Cannot allocate memory
> > > > >
> > > > > This worked in 2.6.20
> > > >
> > > > Could you print the MURAM memory usage for debug?
> > > > eg. start address and size.
> > > >
> > > > -d
> > >
> > > Like this?
> >
> > redid with all hex, decimal within()
> > MURAM alloc, start:1400, size:200(512), align:8(8)
> > MURAM alloc, start:1608, size:208(520), align:8(8)
> > MURAM alloc, start:1880, size:80(128), align:80(128)
> > MURAM alloc, start:1a00, size:1a0(416), align:100(256)
> > MURAM alloc, start:1bc0, size:40(64), align:20(32)
> > MURAM alloc, start:1d00, size:100(256), align:100(256)
> > MURAM alloc, start:1f00, size:a0(160), align:100(256)
> > MURAM alloc, start:1fc0, size:c(12), align:40(64)
> > MURAM alloc, start:2000, size:30(48), align:8(8)
> > MURAM alloc, start:2080, size:80(128), align:80(128)
> > MURAM alloc, start:2180, size:80(128), align:80(128)
> > MURAM alloc, start:2280, size:80(128), align:80(128)
> > MURAM alloc, start:2380, size:80(128), align:80(128)
> > MURAM alloc, start:2440, size:40(64), align:40(64)
> > MURAM alloc, start:24c0, size:40(64), align:40(64)
> > MURAM alloc, start:2540, size:40(64), align:40(64)
> > MURAM alloc, start:25c0, size:40(64), align:40(64)
> > MURAM alloc, start:262c, size:5d(93), align:4(4)
>
> Looks like you are using virtual FIFO for 100Mbps.
>
> > some comments:
> >
> > With these aligments, won't you waste alot of MURAM?
> >
> > Looking at the 2 first allocs:
> > MURAM alloc, start:1400, size:200(512), align:8(8)
> > MURAM alloc, start:1608, size:208(520), align:8(8)
> > shouldn't the second alloc have 0x1600 as start address?
>
> This looks like a bug of rheap. The main problem is that at system
> startup phase, there is an allocation of size 0x400,align 0x1000.
> The rheap starts to allocate next buffer from 0x1400, instead of 0x400.
Strangely, that alloc(0x400,align 0x1000) never shows up
in the print out.
For reference I have added the same printout to
my 2.6.20 kernel, here is the initial allocs in that kernel:
MURAM alloc, start:728, size:200(512), align:8(8)
MURAM alloc, start:930, size:208(520), align:8(8)
MURAM alloc, start:b80, size:80(128), align:80(128)
MURAM alloc, start:d00, size:1a0(416), align:100(256)
MURAM alloc, start:ee0, size:40(64), align:20(32)
MURAM alloc, start:1000, size:100(256), align:100(256)
MURAM alloc, start:1200, size:a0(160), align:100(256)
MURAM alloc, start:12d8, size:8(8), align:4(4)
MURAM alloc, start:12e0, size:30(48), align:8(8)
MURAM alloc, start:1380, size:80(128), align:80(128)
MURAM alloc, start:1480, size:80(128), align:80(128)
MURAM alloc, start:1580, size:80(128), align:80(128)
MURAM alloc, start:1680, size:80(128), align:80(128)
MURAM alloc, start:1740, size:40(64), align:40(64)
MURAM alloc, start:17c0, size:40(64), align:40(64)
MURAM alloc, start:1840, size:40(64), align:40(64)
MURAM alloc, start:18c0, size:40(64), align:40(64)
MURAM alloc, start:1910, size:5d(93), align:4(4)
^ permalink raw reply
* Re: [patch 29/30 v2] PS3: Device tree source.
From: Geert Uytterhoeven @ 2007-06-14 7:55 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <46709A76.4000602@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 963 bytes --]
On Wed, 13 Jun 2007, Geoff Levand wrote:
> Subject: PS3: Device tree source.
>
> The PS3 device tree source.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
>
> ver2: Here's an updated version based on the discussions.
This one doesn't seem to work. The kernel hangs very early in the boot process.
I haven't digged into it yet to find out why.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1930 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Centre Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 413.825.160 · RPR Brussels
Fortis Bank Londerzeel IBAN BE39 0013 8235 8619 GEBA-BE-BB
^ 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