From: Segher Boessenkool <segher@kernel.crashing.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
Date: Fri, 14 Sep 2007 00:30:28 +0200 [thread overview]
Message-ID: <bad36d212328a6fcdf273411609e842d@kernel.crashing.org> (raw)
In-Reply-To: <96A13129-D16E-440D-B317-29BED85852D9@kernel.crashing.org>
>>>>> + 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.
>>
>> Since the CPU cores on all these SoCs are identical (well, there
>> might be a few revisions, or different cache sizes or such -- minor
>> differences that can be probed for separately), it probably is a
>> good idea to name them in the tree instead of having each client
>> have its own table.
>>
>> Or is there anything about the CPU that can be derived from "8572"
>> but not from "e500"?
>
> Only in so much that we need something that states what the actual
> processor is.
You mean, something needs to say "8572"? I think the "soc" node
would be best for that.
It's all not terribly important, just something to think about.
>>>> 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.
>>
>> Okay, fair enough. Are you looking at resolving those kernel issues?
>
> No. I've had enough of this device tree foo for a while :)
Heh okay :-)
> [I'm happy to test any patches related to this, if someone else comes
> up with them]
Well I don't know what the problem is ("it doesn't work" doesn't
say much), and don't have your hardware to test. Maybe we can do
it on IRC again ;-)
Segher
prev parent reply other threads:[~2007-09-13 22:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 19:37 [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port Kumar Gala
2007-09-12 3:11 ` David Gibson
2007-09-12 3:33 ` Kumar Gala
2007-09-12 3:53 ` David Gibson
2007-09-12 14:00 ` Segher Boessenkool
2007-09-12 15:08 ` MDIO & phy device tree bindings (was Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port) Kumar Gala
2007-09-12 15:13 ` [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port Kumar Gala
2007-09-12 14:10 ` Segher Boessenkool
2007-09-13 3:27 ` Kumar Gala
2007-09-12 13:36 ` Segher Boessenkool
2007-09-13 3:28 ` Kumar Gala
2007-09-13 4:21 ` David Gibson
2007-09-13 17:06 ` Segher Boessenkool
2007-09-13 18:24 ` Kumar Gala
2007-09-13 22:30 ` Segher Boessenkool [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bad36d212328a6fcdf273411609e842d@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.