>> However, the interrupt mapping spec says that all interrupt
>> controller (regardless of device_type) must have a
>> property named "interrupt-controller" to identify
>> the device node as an interrupt controller and root of
>> a interrupt tree.
>> See: http://playground.sun.com/1275/practice/im
>> It seems to me a flat device tree could leave out all those
>> properties that can be derived from the PVR (except for the
>> few that are really useful for bootloaders and such -- cache
>> line size, 64-bit-or-not, what kind of MMU). Linux doesn't
>> use it anyway. Existing DTSs already leave
+ MPIC: [EMAIL PROTECTED] {
+ device_type = "open-pic";
device_type = "interrupt-controller".
>>
>> Not according to the binding in booting-without-of.txt
>
> My understanding here, though possibly flawed, is that the current
> implementation has "open-
>>> + PIC8259: interrupt-controller {
>>> + device_type = "i8259";
>>>
>>> device_type = "interrupt-controller".
>
> Is that really right? The MPIC binding, at least, has device_type =
> "open-pic" rather than "interrupt-controller".
I got confused. "o
On Fri, Aug 03, 2007 at 02:55:16PM -0700, Yoder Stuart-B08248 wrote:
>
> > > > > + MPIC: [EMAIL PROTECTED] {
> > > > > + device_type = "open-pic";
> > > > >
> > > > > device_type = "interrupt-controller".
> > >
> > > Not according to the binding in booting-without
> > > > + MPIC: [EMAIL PROTECTED] {
> > > > + device_type = "open-pic";
> > > >
> > > > device_type = "interrupt-controller".
> >
> > Not according to the binding in booting-without-of.txt
>
> My understanding here, though possibly flawed, is that the current
On Fri, 2007-08-03 at 01:35, David Gibson wrote:
> > > + PIC8259: interrupt-controller {
> > > + device_type = "i8259";
> > >
> > > device_type = "interrupt-controller".
>
> Is that really right? The MPIC binding, at least, has device_type =
> "open-pic"
On Wed, Jul 18, 2007 at 05:55:16PM +0200, Segher Boessenkool wrote:
> >>> Too big for the list, the patch is at:
> >>> http://ozlabs.org/~dgibson/home/prep-support
> >>
> >> Too lazy to split the patch into bite-size chunks, you mean ;-)
> >
> > Well... much as I like small patches, I don't reall
On Thu, Jun 28, 2007 at 12:00:20PM +0200, Gabriel Paubert wrote:
> On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > > Here is an implementation to allow PReP systems to boot under the
> > > arch/powerpc codebase, one of the few remaining platforms supported in
> > > arch/ppc
>>> Too big for the list, the patch is at:
>>> http://ozlabs.org/~dgibson/home/prep-support
>>
>> Too lazy to split the patch into bite-size chunks, you mean ;-)
>
> Well... much as I like small patches, I don't really like having a big
> string of patches, each of which does basically nothing
On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > Here is an implementation to allow PReP systems to boot under the
> > arch/powerpc codebase, one of the few remaining platforms supported in
> > arch/ppc but not so far in arch/powerpc.
>
> > Too big for the list, the patch is
+ external-control;
Really?
>>>
>>> Well, is anybody actually using eciwx/ecowx?
>>
>> That's not the point -- the device tree should only
>> say "external-control" if the CPU actually supports
>> it; AFAIK, that's 601 only.
>
> I wonder whether you are mixing up ext
On Mon, Jul 02, 2007 at 01:51:42PM +0200, Segher Boessenkool wrote:
> >>+ external-control;
> >>
> >>Really?
> >
> >Well, is anybody actually using eciwx/ecowx?
>
> That's not the point -- the device tree should only
> say "external-control" if the CPU actually supports
> it; AFA
Hi,
>> On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
>>
>> > Do all (supported) PReP boards have one CPU only?
>>
>> Not sure, but I don't have any. I believe that there were
>> dual processors MTX boards, and dual 604 MVME boards were
>> offered (but probably not very popul
On 6/28/07, Gabriel Paubert <[EMAIL PROTECTED]> wrote:
On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> Do all (supported) PReP boards have one CPU only?
Not sure, but I don't have any. I believe that there were
dual processors MTX boards, and dual 604 MVME boards were
off
>> +external-control;
>>
>> Really?
>
> Well, is anybody actually using eciwx/ecowx?
That's not the point -- the device tree should only
say "external-control" if the CPU actually supports
it; AFAIK, that's 601 only.
>> +[EMAIL PROTECTED] {
>> +device_type = "p
On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > Here is an implementation to allow PReP systems to boot under the
> > arch/powerpc codebase, one of the few remaining platforms supported in
> > arch/ppc but not so far in arch/powerpc.
>
> > Too big for the list, the patch is
> Here is an implementation to allow PReP systems to boot under the
> arch/powerpc codebase, one of the few remaining platforms supported in
> arch/ppc but not so far in arch/powerpc.
> Too big for the list, the patch is at:
> http://ozlabs.org/~dgibson/home/prep-support
Too lazy to split t
On Wed, Jun 27, 2007 at 06:22:27AM -0500, Milton Miller wrote:
> On Wed Jun 27 17:10:08 EST 2007, David Gibson wrote:
> > Here is an implementation to allow PReP systems to boot under the
> > arch/powerpc codebase, one of the few remaining platforms supported in
> > arch/ppc but not so far in arch/
19 matches
Mail list logo
