* RE: 2.6.23-rc3 boot hang on MPC8641D
From: Zhang Wei-r63237 @ 2007-09-13 5:19 UTC (permalink / raw)
To: Kumar Gala, sivaji; +Cc: linuxppc-dev
In-Reply-To: <5850B6F4-61FD-4866-B50E-8F7FEA3FA9AD@kernel.crashing.org>
Yes, It's too old. Maybe not fully supports FDT. You can try the version
of Kumar said or in the BSP of Freescale released.
- zw
> -----Original Message-----
> From: linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.or
> g] On Behalf Of Kumar Gala
> Sent: Thursday, September 13, 2007 1:11 PM
> To: sivaji
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: 2.6.23-rc3 boot hang on MPC8641D
>=20
>=20
> On Sep 12, 2007, at 11:52 PM, sivaji wrote:
>=20
> >
> >
> > Hi,
> > I tired to move the dtb to 0x2000000, but the result was =20
> > same.
> > uboot version is 1.1.6
>=20
> seems like a pretty old u-boot. Willing to try a 1.3.0-rc1?
>=20
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: David Gibson @ 2007-09-13 5:11 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <20070912200706.449fe450@localhost.localdomain>
On Wed, Sep 12, 2007 at 08:07:06PM +0400, Vitaly Bordug wrote:
> On Wed, 12 Sep 2007 10:13:50 +0200
> Arnd Bergmann wrote:
>
> > On Wednesday 12 September 2007, Vitaly Bordug wrote:
> >
> > >
> > > Well, it's more a rewrite than a move, based on 64-bit
> > > implementation.
> >
> > ok.
> >
> > > > Could you perhaps split the patch into two separate changesets,
> > > > one that makes both functions identical in place, and one that
> > > > merges them to live in a common location?
> > > >
> > > I'm not sure I'm following what you are requesting. What is a
> > > benefit of code duplication? I was thinking about, if it will look
> > > good enough, to provide this function at generic level but changing
> > > its name a little, while leaving old stuff in place, and
> > > encouraging people to use it in favour of 32 or 64-bit-specific
> > > approaches. That way we won't kill many boards at once(in case, for
> > > example,odd dts with missed ranges for pci subnode).
> >
> > I wasn't suggesting to leave the duplicated code in, but rather to
> > make the review easier by first modifying the code in place.
> >
> > If you're taking the 64 bit code as a base, you can for instance make
> > the first patch leave pci_32 alone, and modify the 64 bit
> > pci_process_bridge_OF_ranges to look exactly like the merged version.
> > That allows us to see what changed in the 64 bit case.
> >
> > The second patch would then move the functions over, but leave the
> > code identical to the result of the first patch.
>
> ok, makes sense, will do it that way.
>
> > > > > diff --git a/include/asm-powerpc/ppc-pci.h
> > > > > b/include/asm-powerpc/ppc-pci.h index b847aa1..882b8bc 100644
> > > > > --- a/include/asm-powerpc/ppc-pci.h
> > > > > +++ b/include/asm-powerpc/ppc-pci.h
> > > > > @@ -15,6 +15,13 @@
> > > > > #include <linux/pci.h>
> > > > > #include <asm/pci-bridge.h>
> > > > >
> > > > > +struct ranges_pci {
> > > > > + unsigned int pci_space;
> > > > > + u64 pci_addr;
> > > > > + phys_addr_t phys_addr;
> > > > > + u64 size;
> > > > > +} __attribute__((packed));
> > > > > +
> > > >
> > > > This structure definition uses unaligned members because of the
> > > > 'packed' attribute. Is that really what you intended?
> > > >
> > > yes, exactly, because I'm mapping this struct on ranges extracted
> > > from the dts instead of juggling with ranges[foo] offsets.
> >
> > I see. It does however look wrong to me, because you are using a
> > hardcoded phys_addr_t type. This breaks when phys_addr has a
> > different size from what you expect, e.g. when booting a pure 32 bit
> > kernel on a machine that has a 64 bit physical address space.
> >
> I wondered around with "32 bit phys" and "64 bit phys" struct
> definitions first, but, well, it does not look good. In fact it
> already verified with alike case (on 4xx), and I thought it would be
> fair tradeoff to have 64 bit ranges definition.
>
> otoh, there might be cases when phys_addr_t is u64 and pci stuff
> resides on some 32-bit SoC bus. I will try to address that next
> iteration.
Yes, I was going to point out this sort of case. I don't think
including the parent-address in the structure is going to work.
Oh, also, since this structure is only used in this function, it
should go in the .c file, not a .h file.
--
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: 2.6.23-rc3 boot hang on MPC8641D
From: Kumar Gala @ 2007-09-13 5:13 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12648671.post@talk.nabble.com>
On Sep 12, 2007, at 11:47 PM, sivaji wrote:
>
>
> Hi,
> I have JTAG Debugger connected to the board. I was given the
> following commands in the root path of the kernel source
If you can dump memory w/o connecting GDB, I suggest the following.
Look in your kernel build for System.map and grep for log_buf you
should get something like:
c040b04c d log_buf
c043b1a4 b __log_buf
then dump the memory @ these addresses. I can't remember which one
is the correct one. You'll want to subtract c000_0000 from the
address to get a physical address that you can dump. This should
help provide some possible insight into what's going on.
- k
^ permalink raw reply
* Re: 2.6.23-rc3 boot hang on MPC8641D
From: Kumar Gala @ 2007-09-13 5:11 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12648696.post@talk.nabble.com>
On Sep 12, 2007, at 11:52 PM, sivaji wrote:
>
>
> Hi,
> I tired to move the dtb to 0x2000000, but the result was
> same.
> uboot version is 1.1.6
seems like a pretty old u-boot. Willing to try a 1.3.0-rc1?
- k
^ permalink raw reply
* RE: 2.6.23-rc3 boot hang on MPC8641D
From: sivaji @ 2007-09-13 4:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C85D7FB@zch01exm26.fsl.freescale.net>
Hi,
I tired to move the dtb to 0x2000000, but the result was same.
uboot version is 1.1.6
by
Sivaji
Zhang Wei-r63237 wrote:
>
> Hi,
>
> Your flat device tree address seems too low. Try to move the dtb to
> higher address such as 0x2000000.
>
> And which version of your u-boot?
>
> Cheers!
> - zw
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.org
>> [mailto:linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.or
>> g] On Behalf Of sivaji
>> Sent: Thursday, September 13, 2007 12:18 PM
>> To: linuxppc-dev@ozlabs.org
>> Subject: 2.6.23-rc3 boot hang on MPC8641D
>>
>>
>> Hi,
>> I am try to boot the 2.6.23-rc3 kernel to my custom
>> board based on
>> 8641D Processor. After uncompressing the kernel it was hang. I got the
>> following messages.
>>
>> Uncompressing Kernel Image ... OK
>> Booting using flat device tree at 0x600000.
>>
>> Then i tried to debug with GDB. In my source path i
>> given the command
>> ${CROSS_COMPILE}gdb vmlinux, I got GDB Prompt after i tried to set the
>> breakpoint at start_kernel. I got follwing messages
>>
>> gdb) b start_kernel
>> Cannot access memory at address 0xc02b44ec
>>
>> Processor Information:
>> 8641D processor and the silicon revision is 2.0.
>> Part : MPC8641D
>> Revision: 2.0
>> e600 Core Revision: 2.2
>> DeviceMarking: B
>> Processor Version Register Value: 0x8004_0202
>> System Version Register Value: 0x8090_0120
>>
>> I don't know how to proceed. Please tell the way how to
>> start kernel
>> debug in this situation.
>>
>> By
>> Sivaji
>> --
>> View this message in context:
>> http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf44335
>> 08.html#a12648489
>> Sent from the linuxppc-dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
View this message in context: http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf4433508.html#a12648696
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: 2.6.23-rc3 boot hang on MPC8641D
From: sivaji @ 2007-09-13 4:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <85940BCC-C5A7-4461-B49C-A5C1879708C3@kernel.crashing.org>
Hi,
I have JTAG Debugger connected to the board. I was given the
following commands in the root path of the kernel source
1. ${CROSS_COMPILE}gdb vmlinux
2. I got th GDB prompt after that i give
target remote 172.29.38.213:2001 i got following results
(gdb) target remote 172.29.38.213:2001
Remote debugging using 172.29.38.213:2001
Remote packet too long:
deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbe
0000000000605200000000000060520000000000006052000000000000605200000000000060520000000000006052000000000000605200000000000060520000000000006052000000000000605200000000000060520000000000006052000000000000605200000000000060520000000000006052000000000000605200000000000060520000000000006052000000000000605200000000000060520000000000006052000000000000605200000000000060520000000000006052000000000000605200000000000060520000000000006052000000000000605200000000000060520000000000006052000000000000605200000000fff00100deadbee
Ignoring packet error, continuing...
0xdeadbeef in ?? ()
3.(gdb) b start_kernel
Cannot access memory at address 0xc02b44ec
by
sivaji
Kumar Gala-3 wrote:
>
>
> On Sep 12, 2007, at 11:18 PM, sivaji wrote:
>
>>
>> Hi,
>> I am try to boot the 2.6.23-rc3 kernel to my custom board
>> based on
>> 8641D Processor. After uncompressing the kernel it was hang. I got the
>> following messages.
>>
>> Uncompressing Kernel Image ... OK
>> Booting using flat device tree at 0x600000.
>>
>> Then i tried to debug with GDB. In my source path i given
>> the command
>> ${CROSS_COMPILE}gdb vmlinux, I got GDB Prompt after i tried to set the
>> breakpoint at start_kernel. I got follwing messages
>>
>> gdb) b start_kernel
>> Cannot access memory at address 0xc02b44ec
>
> how are you connecting gdb to the board?
>
> do you have a JTAG debugger connected to the board?
>
> - k
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
View this message in context: http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf4433508.html#a12648671
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Linuxppc-dev Digest, Vol 37, Issue 84
From: Olof Johansson @ 2007-09-13 4:40 UTC (permalink / raw)
To: lakshminarayana babu; +Cc: linuxppc-dev
In-Reply-To: <a38e30640709122131g14642e9pa599681551ed9c23@mail.gmail.com>
On Thu, Sep 13, 2007 at 10:01:36AM +0530, lakshminarayana babu wrote:
> i am new to the linux.....can you tell me how to access the pci
> configuration space using ioremap function...but it is implicit function
> declaration...
That is architecture and platform dependent. Some platforms don't even
have a memory-mappable interface to configuration space.
Instead, please use the abstracted config access functions that the
kernel provides. (pci_read_config_word and friends).
-Olof
^ permalink raw reply
* RE: 2.6.23-rc3 boot hang on MPC8641D
From: Zhang Wei-r63237 @ 2007-09-13 4:38 UTC (permalink / raw)
To: sivaji, linuxppc-dev
In-Reply-To: <12648489.post@talk.nabble.com>
Hi,=20
Your flat device tree address seems too low. Try to move the dtb to
higher address such as 0x2000000.
And which version of your u-boot?
Cheers!
- zw
> -----Original Message-----
> From: linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.or
> g] On Behalf Of sivaji
> Sent: Thursday, September 13, 2007 12:18 PM
> To: linuxppc-dev@ozlabs.org
> Subject: 2.6.23-rc3 boot hang on MPC8641D
>=20
>=20
> Hi,
> I am try to boot the 2.6.23-rc3 kernel to my custom=20
> board based on
> 8641D Processor. After uncompressing the kernel it was hang. I got the
> following messages.
>=20
> Uncompressing Kernel Image ... OK
> Booting using flat device tree at 0x600000.=20
>=20
> Then i tried to debug with GDB. In my source path i=20
> given the command
> ${CROSS_COMPILE}gdb vmlinux, I got GDB Prompt after i tried to set the
> breakpoint at start_kernel. I got follwing messages
>=20
> gdb) b start_kernel
> Cannot access memory at address 0xc02b44ec
>=20
> Processor Information:
> 8641D processor and the silicon revision is 2.0.
> Part : MPC8641D
> Revision: 2.0
> e600 Core Revision: 2.2
> DeviceMarking: B
> Processor Version Register Value: 0x8004_0202
> System Version Register Value: 0x8090_0120
>=20
> I don't know how to proceed. Please tell the way how to=20
> start kernel
> debug in this situation.
>=20
> By
> Sivaji
> --=20
> View this message in context:=20
> http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf44335
> 08.html#a12648489
> Sent from the linuxppc-dev mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: [PATCH] IB/ehca: Make sure user pages are from hugetlb before using MR large pages
From: Roland Dreier @ 2007-09-13 4:33 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <200709121439.32641.fenkes@de.ibm.com>
> -#define HCA_CAP_MR_PGSIZE_4K 1
> -#define HCA_CAP_MR_PGSIZE_64K 2
> -#define HCA_CAP_MR_PGSIZE_1M 4
> -#define HCA_CAP_MR_PGSIZE_16M 8
> +#define HCA_CAP_MR_PGSIZE_4K 0x80000000
> +#define HCA_CAP_MR_PGSIZE_64K 0x40000000
> +#define HCA_CAP_MR_PGSIZE_1M 0x20000000
> +#define HCA_CAP_MR_PGSIZE_16M 0x10000000
Not sure I understand what this has to do with things... is this an
unrelated fix?
> +static int ehca_is_mem_hugetlb(unsigned long addr, unsigned long size)
This is rather awful -- another call to get_user_pages() to iterate
over all the vmas...
I would suggest extending ib_umem_get() to check the vmas and adding a
member to struct ib_umem to say whether the memory is entirely covered
by hugetlb pages or not.
> + ret = ehca_is_mem_hugetlb(virt, length);
> + switch (ret) {
> + case 0: /* mem is not from hugetlb */
> + hwpage_size = PAGE_SIZE;
> + break;
> + case 1:
> + if (length <= EHCA_MR_PGSIZE4K
> + && PAGE_SIZE == EHCA_MR_PGSIZE4K)
> + hwpage_size = EHCA_MR_PGSIZE4K;
> + else if (length <= EHCA_MR_PGSIZE64K)
> + hwpage_size = EHCA_MR_PGSIZE64K;
> + else if (length <= EHCA_MR_PGSIZE1M)
> + hwpage_size = EHCA_MR_PGSIZE1M;
> + else
> + hwpage_size = EHCA_MR_PGSIZE16M;
> + break;
> + default: /* out of mem */
> + ib_mr = ERR_PTR(-ENOMEM);
> + goto reg_user_mr_exit1;
It seems like it would be better to just assume the memory is not from
a hugetlb is ehca_is_mem_hugetlb() fails its memory allocation and
fall back to the PAGE_SIZE case rather than failing entirely.
Also if someone runs a kernel with 64K pages on a machine where they
end up being simulated from 4K pages, do you have the same issue with
the hypervisor ganging together non-contiguous pages?
- R.
^ permalink raw reply
* Re: Linuxppc-dev Digest, Vol 37, Issue 84
From: lakshminarayana babu @ 2007-09-13 4:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <mailman.2011.1189652741.2970.linuxppc-dev@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 20183 bytes --]
i am new to the linux.....can you tell me how to access the pci
configuration space using ioremap function...but it is implicit function
declaration...
On 9/13/07, linuxppc-dev-request@ozlabs.org <linuxppc-dev-request@ozlabs.org>
wrote:
>
> Send Linuxppc-dev mailing list submissions to
> linuxppc-dev@ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> or, via email, send a message with subject or body 'help' to
> linuxppc-dev-request@ozlabs.org
>
> You can reach the person managing the list at
> linuxppc-dev-owner@ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE() (Michael Ellerman)
> 2. Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port (Segher Boessenkool)
> 3. Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port (Segher Boessenkool)
> 4. Re: [PATCH 1/5] Add Freescale DMA and DMA channel to
> Documentation/powerpc/booting-without-of.txt file.
> (Segher Boessenkool)
> 5. Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port (Segher Boessenkool)
> 6. Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port (Segher Boessenkool)
> 7. Re: [PATCH] [POWERPC] DTS cleanup (Segher Boessenkool)
> 8. Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS
> port (Segher Boessenkool)
> 9. Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit
> pci_process_bridge_OF_ranges() instances (Segher Boessenkool)
> 10. Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS
> port (Segher Boessenkool)
> 11. Re: [PATCH] [POWERPC] DTS cleanup (Kumar Gala)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Sep 2007 12:05:41 +1000
> From: Michael Ellerman <michael@ellerman.id.au>
> Subject: Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE()
> To: Arnd Bergmann <arnd@arndb.de>
> Cc: linuxppc-dev@ozlabs.org, Jeremy Kerr <jk@ozlabs.org>,
> linux-kernel@vger.kernel.org
> Message-ID: <1189649141.19087.13.camel@concordia.ozlabs.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> On Wed, 2007-09-12 at 10:47 +0200, Arnd Bergmann wrote:
> > On Wednesday 12 September 2007, Michael Ellerman wrote:
> > > On Wed, 2007-09-12 at 17:43 +1000, Michael Ellerman wrote:
> > > > This patch adds DEFINE_SPUFS_ATTRIBUTE(), a wraper around
> > > > DEFINE_SIMPLE_ATTRIBUTE which does the specified locking for the get
> > > > routine for us.
> > > >
> > > > Unfortunately we need two get routines (a locked and unlocked
> version) to
> > > > support the coredump code. This patch hides one of those (the locked
> version)
> > > > inside the macro foo.
> >
> > >
> > > jk said:
> > > > "Good god man!"
> > >
> > > Yeah, I'm a bit lukewarm on this one. But the diffstat is nice, 50%
> code
> > > reduction ain't bad :)
> >
> > Have you looked at the change in object code size? I would expect the
> > object code to actually become bigger. I also think that it hurts
> > readability rather than help it.
>
> Yeah I did, it's smaller actually:
>
> text data bss dec hex filename
> 44898 17804 120 62822 f566 spufs-before.o
> 44886 17804 120 62810 f55a spufs-after.o
>
> > Maybe a better solution is to change the core dump code to not
> > require the mutex to be held in the first place. By the time
> > we get to call the get functions, it should already be in
> > saved state and no longer be able to get scheduled, so we might
> > not actually need all the extra tricks with avoiding the
> > mutex to be taken again.
>
> Well that'd be nice, but I don't see anywhere that that happens. AFAICT
> the acquire we do in the first coredump callback is the first the SPU
> contexts know about their PPE process dying. And spufs is still live, so
> I think we definitely need to grab the mutex, or we might race with
> userspace accessing spufs files.
>
> 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
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: This is a digitally signed message part
> Url :
> http://ozlabs.org/pipermail/linuxppc-dev/attachments/20070913/d7914b17/attachment-0001.pgp
>
> ------------------------------
>
> Message: 2
> Date: Wed, 12 Sep 2007 15:36:55 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <a58bb9a05680c3befc4d3588992caed0@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Looks a lot better, thanks!
>
> Some minor nits and suggestions...
>
> > +/ {
> > + model = "fsl,MPC8572DS";
> > + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
>
> We don't want "xx" compatible entries; especially here it makes
> no sense at all. If the board is compatible to some other (older)
> board, just name that board explicitly.
>
> > + PowerPC,8572@0 {
>
> Maybe it would be good to use "PowerPC,e500" instead -- it would
> make it easier to probe for the actual CPU type, that way. Not
> that Linux uses the name/compatible here at all ;-)
>
> > + soc8572@ffe00000 {
>
> You should put an interrupt-parent in here, so you can get rid of
> it in all the children.
>
>
> And then there's the pci_bridge thing we're discussing on IRC, of
> course -- basically, get rid of the pci_bridge pseudo-node, and
> move the interrupt-map for the south-bridge devices into the
> south-bridge node.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 12 Sep 2007 16:00:38 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port
> To: David Gibson <david@gibson.dropbear.id.au>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <44b4b3a133980aeb6c596aad71612e6c@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>>> + uli1575@0 {
> >>>> + reg = <0 0 0 0 0>;
> >>>
> >>> This looks kind of bogus...
> >>
> >> Its a PCIe to PCI bridge that is transparent.
> >
> > Right.... if it has no control registers, I think it should just lack
> > 'reg', not define a zero-length register block.
>
> "reg" for PCI config registers has length 0 always, it's defined that
> way in the PCI binding.
>
> But if this thing is transparent, it doesn't have PCI config regs.
>
> >>>> + #size-cells = <2>;
> >>>> + #address-cells = <3>;
> >>>> + ranges = <02000000 0 80000000
> >>>> + 02000000 0 80000000
> >>>> + 0 20000000
> >>>> + 01000000 0 00000000
> >>>> + 01000000 0 00000000
> >>>> + 0 00100000>;
> >
> > And if truly transparent, it should perhaps have just ranges;
> > indicating that child addresses are identity mapped to parent
> > addresses.
>
> If truly transparent, the node should just not be there at all!
>
> >>>> + pci_bridge@0 {
> >>>
> >>> Ok.. why is pci_bridge nested within uli1575 - with the matching reg
> >>> and ranges, it looks like they ought to be one device. Also if this
> >>> is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
> >>
> >> We've been using this as it stands for a while. If there are some
> >> changes here that make sense I'm willing to make them.
> >
> > Right, at present I don't see why you couldn't just ditch the
> > pci_bridge node, and drop its contents straight into the uli1575 node.
>
> Yeah. The preferred name for PCI-to-PCI bridge nodes is simply "pci",
> btw.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 13 Sep 2007 04:09:29 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH 1/5] Add Freescale DMA and DMA channel to
> Documentation/powerpc/booting-without-of.txt file.
> To: Scott Wood <scottwood@freescale.com>
> Cc: linuxppc-dev@ozlabs.org, Zhang Wei-r63237
> <Wei.Zhang@freescale.com>, paulus@samba.org, David Gibson
> <david@gibson.dropbear.id.au>
> Message-ID: <fd81b53021e39a13ea65c0a0319aab77@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >> I have a strange issue here. If I rename 'fsl,dma' to
> >> 'fsl,mpc8540-dma',
> >> the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not
> >> DMA channel.
> >
> > What tree are you using? Commit
> > 804ace8881d211ac448082e871dd312132393049
> > in Paul's git tree should have fixed that.
>
> Strange, I don't see that commit -- maybe gitweb is broken, or
> maybe the patch was superseded, or maybe it just disappeared?
> It's still shown in patchworks with this commit id fwiw.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 12 Sep 2007 16:10:09 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org, David Gibson
> <david@gibson.dropbear.id.au>
> Message-ID: <cbff3b332b53f61721a8e14472347b98@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>> + i8259: interrupt-controller@20 {
> >>> + reg = <1 20 2
> >>> + 1 a0 2
> >>> + 1 4d0 2>;
> >>> + clock-frequency = <0>;
> >>
> >> Hrm.. what is clock-frequency for on an i8259? I see that other 8259
> >> descriptions have this as well, so it's not a problem with this patch
> >> specifically.
> >
> > Its a copy-paste thing so I don't know.
>
> If your bootwrapper doesn't fill in this value, you should get rid
> of this property -- better to have no value than to have the wrong
> value, esp. since it's probably unused anyway.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 13 Sep 2007 00:22:58 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <13038b1ac10f19f2e1fdbd0c1323c1e7@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> > + soc8572@ffe00000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + device_type = "soc";
> > + ranges = <00000000 ffe00000 00100000>;
> > + reg = <ffe00000 00001000>; // CCSRBAR & soc regs,
> remove once parse
> > code for immrbase fixed
>
> Hrm, if you remove it here, where else are you going to describe
> the SoC control register block (whatever it is called -- is that
> IMMR?)
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 13 Sep 2007 00:10:38 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH] [POWERPC] DTS cleanup
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <919c9b76c3e6e45af6e3fb887611a681@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> > * 32-bit in cpu node -- doesn't exist in any spec and not used by
> > kernel
>
> Yeah.
>
> > * built-in for non-standard buses (ISA, PCI)
>
> "built-in" is some weird CHRP property, so yes we don't need it
> or want it.
>
> > * Removed #interrupt-cells in places they don't need to be set
>
> Great :-)
>
> > * Fixed ranges on lite5200*
>
> This has a problem still:
>
> > model = "fsl,mpc5200";
> > compatible = "mpc5200";
> > revision = ""; // from bootloader
> > - #interrupt-cells = <3>;
> > device_type = "soc";
> > - ranges = <0 f0000000 f0010000>;
> > - reg = <f0000000 00010000>;
> > + ranges = <0 f0000000 0000c000>;
> > + reg = <f0000000 0000c000>;
>
> That makes "reg" and "ranges" identify an identical address range,
> which means no subnode can claim any address in that range, so the
> "ranges" property should go. Alternatively, the "reg" might be
> claiming too big a space.
>
> Which is it?
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 12 Sep 2007 15:20:14 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS
> port
> To: Scott Wood <scottwood@freescale.com>
> Cc: Olof Johansson <olof@lixom.net>, linuxppc-dev@ozlabs.org
> Message-ID: <41e2e527c0f0dfceedf2ffe6cdf34816@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>> well the ifdefs are orthogonal. We don't have a way of knowing
> >>> primary from the device tree today.
> >>
> >> How about something like "fsl,primary-phb" in the bus device node? I
> >> don't
> >> know, maybe it's already been discussed and turned down for some
> >> reason.
> >
> > It's more of a Linux issue than anything to do with the hardware.
>
> Yeah, many machines actually have multiple "primary PHBs", and
> Linux cannot really deal with that. It's probably best to handle
> this from platform code.
>
> >> Or would it be sufficient to check children of that device node to see
> >> if the ULi is on that bus?
> >
> > Or more generally, see if an isa node is somewhere in that subtree.
>
> And if there is no ISA node, find any other legacy device (non-native
> ATA controllers, ...), etc.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 12 Sep 2007 16:51:25 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit
> pci_process_bridge_OF_ranges() instances
> To: Arnd Bergmann <arnd@arndb.de>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <4cd6407b936b2ce65c11092883e7b8d5@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>>> +struct ranges_pci {
> >>>> + unsigned int pci_space;
> >>>> + u64 pci_addr;
> >>>> + phys_addr_t phys_addr;
> >>>> + u64 size;
> >>>> +} __attribute__((packed));
> >>>> +
> >>>
> >>> This structure definition uses unaligned members because of the
> >>> 'packed' attribute. Is that really what you intended?
> >>>
> >> yes, exactly, because I'm mapping this struct on ranges extracted from
> >> the dts instead of juggling with ranges[foo] offsets.
> >
> > I see. It does however look wrong to me, because you are using a
> > hardcoded
> > phys_addr_t type. This breaks when phys_addr has a different size from
> > what
> > you expect, e.g. when booting a pure 32 bit kernel on a machine that
> > has
> > a 64 bit physical address space.
>
> More generally, you can even have a different size for the "phys_addr"
> for different nodes in the same device tree.
>
> You really should look at the #address-cells in this node's parent,
> and translate that all the way up to the root node to get a CPU
> address.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 12 Sep 2007 15:20:25 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS
> port
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <6b92503d73565f8add983e64ad5d5d39@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>> + l2-cache-controller@20000 {
> >>> + compatible = "fsl,8572-l2-cache-controller";
> >>> + reg = <20000 1000>;
> >>> + cache-line-size = <20>; // 32 bytes
> >>> + cache-size = <80000>; // L2, 512K
> >>> + interrupt-parent = <&mpic>;
> >>> + interrupts = <10 2>;
> >>> + };
> >>
> >> Should this node be referenced by an l2-cache property in the cpu
> >> node?
> >
> > No, its a front side cache.
>
> What is a "front side cache"? What exactly does it cache? If it's
> a cache for one CPU only, that fact should be shown in the device
> tree somehow.
>
> >>> + device_type = "pci";
> >>> + #interrupt-cells = <1>;
> >>> + #size-cells = <2>;
> >>> + #address-cells = <3>;
> >>> + reg = <8000 1000>;
> >>> + bus-range = <0 ff>;
> >>> + ranges = <02000000 0 80000000 80000000 0 20000000
> >>> + 01000000 0 00000000 ffc00000 0
> 00010000>;
> >>
> >> No prefetchable mem space?
> >
> > we haven't normally provided prefetch on 85xx/86xx.. will deal with
> > this later.
>
> If you don't set up prefetchable memory regions on the PCI from
> the firmware, this code is fine, sure. It would be a good plan
> to do map all BARs that say they are prefetchable in some
> prefetchable PCI window, it gives a nice speed boost, even when
> the kernel accesses it as simple non-cacheable space: the PCI
> bridges in between can streamline loads from these areas.
>
> In any case, the device tree should be in synch with how the
> firmware set up the PCI hardware, and it seems that's what you
> have now, so all is fine.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 12 Sep 2007 22:08:33 -0500
> From: Kumar Gala <galak@kernel.crashing.org>
> Subject: Re: [PATCH] [POWERPC] DTS cleanup
> To: Segher Boessenkool <segher@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <8FFFBF2E-8255-40FB-836D-AB5B19222DD9@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> On Sep 12, 2007, at 5:10 PM, Segher Boessenkool wrote:
>
> >> * 32-bit in cpu node -- doesn't exist in any spec and not used by
> >> kernel
> >
> > Yeah.
> >
> >> * built-in for non-standard buses (ISA, PCI)
> >
> > "built-in" is some weird CHRP property, so yes we don't need it
> > or want it.
>
> Do you suggest we get ride of it from ISA nodes as well?
>
> >
> >> * Removed #interrupt-cells in places they don't need to be set
> >
> > Great :-)
> >
> >> * Fixed ranges on lite5200*
> >
> > This has a problem still:
> >
> >> model = "fsl,mpc5200";
> >> compatible = "mpc5200";
> >> revision = ""; // from bootloader
> >> - #interrupt-cells = <3>;
> >> device_type = "soc";
> >> - ranges = <0 f0000000 f0010000>;
> >> - reg = <f0000000 00010000>;
> >> + ranges = <0 f0000000 0000c000>;
> >> + reg = <f0000000 0000c000>;
> >
> > That makes "reg" and "ranges" identify an identical address range,
> > which means no subnode can claim any address in that range, so the
> > "ranges" property should go. Alternatively, the "reg" might be
> > claiming too big a space.
> >
> > Which is it?
>
> Yeah, I think it should be 0x100 for the 'soc' regs on 52xx so I'll
> set regs to that.
>
> - k
>
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
> End of Linuxppc-dev Digest, Vol 37, Issue 84
> ********************************************
>
[-- Attachment #2: Type: text/html, Size: 33549 bytes --]
^ permalink raw reply
* [PATCH] Allow sysfs_remove_group() to be called on non-added groups
From: Michael Ellerman @ 2007-09-13 4:25 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, linux-kernel
It would be nice to be able to do:
for_each_thing(thing) {
error = sysfs_create_group(&thing->kobj, attrs);
if (error) {
for_each_thing(thing)
sysfs_remove_group(&thing->kobj, attrs);
return error;
}
}
But there's a BUG_ON() in sysfs_remove_group() which hits if the attributes
were never added.
As discussed here ...
http://ozlabs.org/pipermail/cbe-oss-dev/2007-July/002774.html
.. we should just return in that case instead of BUG'ing.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
fs/sysfs/group.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index f318b73..a256775 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -73,7 +73,8 @@ void sysfs_remove_group(struct kobject * kobj,
if (grp->name) {
sd = sysfs_get_dirent(dir_sd, grp->name);
- BUG_ON(!sd);
+ if (!sd)
+ return;
} else
sd = sysfs_get(dir_sd);
--
1.5.1.3.g7a33b
^ permalink raw reply related
* Re: 2.6.23-rc3 boot hang on MPC8641D
From: Kumar Gala @ 2007-09-13 4:25 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12648489.post@talk.nabble.com>
On Sep 12, 2007, at 11:18 PM, sivaji wrote:
>
> Hi,
> I am try to boot the 2.6.23-rc3 kernel to my custom board
> based on
> 8641D Processor. After uncompressing the kernel it was hang. I got the
> following messages.
>
> Uncompressing Kernel Image ... OK
> Booting using flat device tree at 0x600000.
>
> Then i tried to debug with GDB. In my source path i given
> the command
> ${CROSS_COMPILE}gdb vmlinux, I got GDB Prompt after i tried to set the
> breakpoint at start_kernel. I got follwing messages
>
> gdb) b start_kernel
> Cannot access memory at address 0xc02b44ec
how are you connecting gdb to the board?
do you have a JTAG debugger connected to the board?
- k
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: David Gibson @ 2007-09-13 4:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <39A1A44F-CD73-4CC1-89DE-608A1041AAF7@kernel.crashing.org>
On Wed, Sep 12, 2007 at 10:28:24PM -0500, Kumar Gala wrote:
[snip]
> >> + soc8572@ffe00000 {
> >
> > You should put an interrupt-parent in here, so you can get rid of
> > it in all the children.
>
> Are interrupt-parent's inherited by child nodes?
Strictly speaking, a node's default interrupt-parent is its physical
parent. And a node without interrupt-map identity maps all interrupts
to *its* parent. So the interrupt is notionally wired from the child
to its parent and so forth up the bus tree until it reaches a node
with a specified interrupt-parent or interrupt-map.
--
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
* 2.6.23-rc3 boot hang on MPC8641D
From: sivaji @ 2007-09-13 4:18 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am try to boot the 2.6.23-rc3 kernel to my custom board based on
8641D Processor. After uncompressing the kernel it was hang. I got the
following messages.
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x600000.
Then i tried to debug with GDB. In my source path i given the command
${CROSS_COMPILE}gdb vmlinux, I got GDB Prompt after i tried to set the
breakpoint at start_kernel. I got follwing messages
gdb) b start_kernel
Cannot access memory at address 0xc02b44ec
Processor Information:
8641D processor and the silicon revision is 2.0.
Part : MPC8641D
Revision: 2.0
e600 Core Revision: 2.2
DeviceMarking: B
Processor Version Register Value: 0x8004_0202
System Version Register Value: 0x8090_0120
I don't know how to proceed. Please tell the way how to start kernel
debug in this situation.
By
Sivaji
--
View this message in context: http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf4433508.html#a12648489
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/2][RESEND] ehea: propagate physical port state
From: Jeff Garzik @ 2007-09-13 4:14 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200709071230.18395.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> Introduces a module parameter to decide whether the physical
> port link state is propagated to the network stack or not.
> It makes sense not to take the physical port state into account
> on machines with more logical partitions that communicate
> with each other. This is always possible no matter what the physical
> port state is. Thus eHEA can be considered as a switch there.
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
applied 1-2
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-13 3:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <cbff3b332b53f61721a8e14472347b98@kernel.crashing.org>
On Sep 12, 2007, at 9:10 AM, Segher Boessenkool wrote:
>>>> + i8259: interrupt-controller@20 {
>>>> + reg = <1 20 2
>>>> + 1 a0 2
>>>> + 1 4d0 2>;
>>>> + clock-frequency = <0>;
>>>
>>> Hrm.. what is clock-frequency for on an i8259? I see that other
>>> 8259
>>> descriptions have this as well, so it's not a problem with this
>>> patch
>>> specifically.
>>
>> Its a copy-paste thing so I don't know.
>
> If your bootwrapper doesn't fill in this value, you should get rid
> of this property -- better to have no value than to have the wrong
> value, esp. since it's probably unused anyway.
I'm going to kill this since I can't find it spec'd anywhere.
- k
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-13 3:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <a58bb9a05680c3befc4d3588992caed0@kernel.crashing.org>
On Sep 12, 2007, at 8:36 AM, Segher Boessenkool wrote:
> Looks a lot better, thanks!
>
> Some minor nits and suggestions...
>
>> +/ {
>> + model = "fsl,MPC8572DS";
>> + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
>
> We don't want "xx" compatible entries; especially here it makes
> no sense at all. If the board is compatible to some other (older)
> board, just name that board explicitly.
removed.
>
>> + PowerPC,8572@0 {
>
> Maybe it would be good to use "PowerPC,e500" instead -- it would
> make it easier to probe for the actual CPU type, that way. Not
> that Linux uses the name/compatible here at all ;-)
I thought about this, not sure what the best solution is.
>> + soc8572@ffe00000 {
>
> You should put an interrupt-parent in here, so you can get rid of
> it in all the children.
Are interrupt-parent's inherited by child nodes?
> And then there's the pci_bridge thing we're discussing on IRC, of
> course -- basically, get rid of the pci_bridge pseudo-node, and
> move the interrupt-map for the south-bridge devices into the
> south-bridge node.
Leaving the interrupt-map in the PHB because that works and moving it
down has issues.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-13 3:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <6b92503d73565f8add983e64ad5d5d39@kernel.crashing.org>
On Sep 12, 2007, at 8:20 AM, Segher Boessenkool wrote:
>>>> + l2-cache-controller@20000 {
>>>> + compatible = "fsl,8572-l2-cache-controller";
>>>> + reg = <20000 1000>;
>>>> + cache-line-size = <20>; // 32 bytes
>>>> + cache-size = <80000>; // L2, 512K
>>>> + interrupt-parent = <&mpic>;
>>>> + interrupts = <10 2>;
>>>> + };
>>>
>>> Should this node be referenced by an l2-cache property in the cpu
>>> node?
>>
>> No, its a front side cache.
>
> What is a "front side cache"? What exactly does it cache? If it's
> a cache for one CPU only, that fact should be shown in the device
> tree somehow.
Its in front of the memory controllers. Its not specific to a given
CPU.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] DTS cleanup
From: Kumar Gala @ 2007-09-13 3:08 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <919c9b76c3e6e45af6e3fb887611a681@kernel.crashing.org>
On Sep 12, 2007, at 5:10 PM, Segher Boessenkool wrote:
>> * 32-bit in cpu node -- doesn't exist in any spec and not used by
>> kernel
>
> Yeah.
>
>> * built-in for non-standard buses (ISA, PCI)
>
> "built-in" is some weird CHRP property, so yes we don't need it
> or want it.
Do you suggest we get ride of it from ISA nodes as well?
>
>> * Removed #interrupt-cells in places they don't need to be set
>
> Great :-)
>
>> * Fixed ranges on lite5200*
>
> This has a problem still:
>
>> model = "fsl,mpc5200";
>> compatible = "mpc5200";
>> revision = ""; // from bootloader
>> - #interrupt-cells = <3>;
>> device_type = "soc";
>> - ranges = <0 f0000000 f0010000>;
>> - reg = <f0000000 00010000>;
>> + ranges = <0 f0000000 0000c000>;
>> + reg = <f0000000 0000c000>;
>
> That makes "reg" and "ranges" identify an identical address range,
> which means no subnode can claim any address in that range, so the
> "ranges" property should go. Alternatively, the "reg" might be
> claiming too big a space.
>
> Which is it?
Yeah, I think it should be 0x100 for the 'soc' regs on 52xx so I'll
set regs to that.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 13:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1DE5CB62-9EF1-42BA-93F3-CE15DD94F5DD@kernel.crashing.org>
>>> + l2-cache-controller@20000 {
>>> + compatible = "fsl,8572-l2-cache-controller";
>>> + reg = <20000 1000>;
>>> + cache-line-size = <20>; // 32 bytes
>>> + cache-size = <80000>; // L2, 512K
>>> + interrupt-parent = <&mpic>;
>>> + interrupts = <10 2>;
>>> + };
>>
>> Should this node be referenced by an l2-cache property in the cpu
>> node?
>
> No, its a front side cache.
What is a "front side cache"? What exactly does it cache? If it's
a cache for one CPU only, that fact should be shown in the device
tree somehow.
>>> + device_type = "pci";
>>> + #interrupt-cells = <1>;
>>> + #size-cells = <2>;
>>> + #address-cells = <3>;
>>> + reg = <8000 1000>;
>>> + bus-range = <0 ff>;
>>> + ranges = <02000000 0 80000000 80000000 0 20000000
>>> + 01000000 0 00000000 ffc00000 0 00010000>;
>>
>> No prefetchable mem space?
>
> we haven't normally provided prefetch on 85xx/86xx.. will deal with
> this later.
If you don't set up prefetchable memory regions on the PCI from
the firmware, this code is fine, sure. It would be a good plan
to do map all BARs that say they are prefetchable in some
prefetchable PCI window, it gives a nice speed boost, even when
the kernel accesses it as simple non-cacheable space: the PCI
bridges in between can streamline loads from these areas.
In any case, the device tree should be in synch with how the
firmware set up the PCI hardware, and it seems that's what you
have now, so all is fine.
Segher
^ permalink raw reply
* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Segher Boessenkool @ 2007-09-12 14:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200709121013.51500.arnd@arndb.de>
>>>> +struct ranges_pci {
>>>> + unsigned int pci_space;
>>>> + u64 pci_addr;
>>>> + phys_addr_t phys_addr;
>>>> + u64 size;
>>>> +} __attribute__((packed));
>>>> +
>>>
>>> This structure definition uses unaligned members because of the
>>> 'packed' attribute. Is that really what you intended?
>>>
>> yes, exactly, because I'm mapping this struct on ranges extracted from
>> the dts instead of juggling with ranges[foo] offsets.
>
> I see. It does however look wrong to me, because you are using a
> hardcoded
> phys_addr_t type. This breaks when phys_addr has a different size from
> what
> you expect, e.g. when booting a pure 32 bit kernel on a machine that
> has
> a 64 bit physical address space.
More generally, you can even have a different size for the "phys_addr"
for different nodes in the same device tree.
You really should look at the #address-cells in this node's parent,
and translate that all the way up to the root node to get a CPU
address.
Segher
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 13:20 UTC (permalink / raw)
To: Scott Wood; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <46E6CE9A.8080402@freescale.com>
>>> well the ifdefs are orthogonal. We don't have a way of knowing
>>> primary from the device tree today.
>>
>> How about something like "fsl,primary-phb" in the bus device node? I
>> don't
>> know, maybe it's already been discussed and turned down for some
>> reason.
>
> It's more of a Linux issue than anything to do with the hardware.
Yeah, many machines actually have multiple "primary PHBs", and
Linux cannot really deal with that. It's probably best to handle
this from platform code.
>> Or would it be sufficient to check children of that device node to see
>> if the ULi is on that bus?
>
> Or more generally, see if an isa node is somewhere in that subtree.
And if there is no ISA node, find any other legacy device (non-native
ATA controllers, ...), etc.
Segher
^ permalink raw reply
* Re: [PATCH] [POWERPC] DTS cleanup
From: Segher Boessenkool @ 2007-09-12 22:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0709121154120.19816@blarg.am.freescale.net>
> * 32-bit in cpu node -- doesn't exist in any spec and not used by
> kernel
Yeah.
> * built-in for non-standard buses (ISA, PCI)
"built-in" is some weird CHRP property, so yes we don't need it
or want it.
> * Removed #interrupt-cells in places they don't need to be set
Great :-)
> * Fixed ranges on lite5200*
This has a problem still:
> model = "fsl,mpc5200";
> compatible = "mpc5200";
> revision = ""; // from bootloader
> - #interrupt-cells = <3>;
> device_type = "soc";
> - ranges = <0 f0000000 f0010000>;
> - reg = <f0000000 00010000>;
> + ranges = <0 f0000000 0000c000>;
> + reg = <f0000000 0000c000>;
That makes "reg" and "ranges" identify an identical address range,
which means no subnode can claim any address in that range, so the
"ranges" property should go. Alternatively, the "reg" might be
claiming too big a space.
Which is it?
Segher
^ permalink raw reply
* Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 22:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0709121119160.19430@blarg.am.freescale.net>
> + soc8572@ffe00000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <00000000 ffe00000 00100000>;
> + reg = <ffe00000 00001000>; // CCSRBAR & soc regs, remove once parse
> code for immrbase fixed
Hrm, if you remove it here, where else are you going to describe
the SoC control register block (whatever it is called -- is that
IMMR?)
Segher
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 13:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0709111436290.14121@blarg.am.freescale.net>
Looks a lot better, thanks!
Some minor nits and suggestions...
> +/ {
> + model = "fsl,MPC8572DS";
> + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
We don't want "xx" compatible entries; especially here it makes
no sense at all. If the board is compatible to some other (older)
board, just name that board explicitly.
> + PowerPC,8572@0 {
Maybe it would be good to use "PowerPC,e500" instead -- it would
make it easier to probe for the actual CPU type, that way. Not
that Linux uses the name/compatible here at all ;-)
> + soc8572@ffe00000 {
You should put an interrupt-parent in here, so you can get rid of
it in all the children.
And then there's the pci_bridge thing we're discussing on IRC, of
course -- basically, get rid of the pci_bridge pseudo-node, and
move the interrupt-map for the south-bridge devices into the
south-bridge node.
Segher
^ 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