Re: [XenPPC] XenPPC IEEE1275 binding?

[Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>]

> > I remember seeing some mention of it, but I don't think we currently
> > have an IEEE1275 binding describing the contents of the /xen node.
As you're currently both the only producer and the only consumer of
this node, you don't need a real binding yet.  But, the standard
properties you have should be correct; and you should make your
specific properties as sane as possible as soon as possible.

> > start-info is going away, which means we'll need to add more  
> > properties
> > to replace it... something like this:
> >         xen {
> >                 name = "xen";
> >                 version = "Xen-3.0-unstable";
Call this property "xen-version" instead?

> Should we have a "compatible" that domain can compare against?
Yes, but you also should have a "device_type".

> >                 reg = <0 @DOMAIN_ID@ 0 0>;
> This could certainly be "domain-id" and be one cell.
If it's a 32-bit number always -- if not, make it two cells.

> I used "reg" because I mistakenly thought is was a mandatory  
> property and we needed a "unit-id" which makes no sense as you  
> point out below.
If you only ever have one "xen" node, you don't need the "reg".

> It is 2x2 cells because:
>   /#address-cells: 2
>   /#size-cells: 2
>
> and they dictate the size of the unit-address.
Only #address-cells actually; but "reg" contains a size as well.

> >                 domain-name = "@DOMAIN_NAME@";
> >                 shared = <@SHARED_INFO@>;
> This, console and store, and all addresses should be expressed in  
> bytes and are domain-physical not MFNs so we should label them  
> correctly.  They also need to match /#address-cells and should  
> prolly have a size.
> >                 privileged;
> >                 init-domain;
I have no idea what these last three props describe; please
explain?  (And perhaps make the names more specific).

> >                 console {
> >                         name = "console";
> >                         interrupts = <@CONSOLE_EVTCHN@ 0>;
> FYI, the second zero here denotes a sense code of 0 indicating  
> positive edge triggered interrupt
Well no.  A node's "interrupts" property's semantics depends
on the interrupt-controller it points to.  You don't point to
anything yet.

Are those interrupts "virtual" interrupts?  In that case, you
want to have a "xen-interrupt-controller" node; or you could
even just put an "interrupt-controller" in the main "xen" node.

All virtual irqs will have the same sense/value, so you can do
without that second cell in the interrupt specifiers completely.

> >                         frameno = <@CONSOLE_MFN@>;
> Perhaps this should be a "unit address" and be a reg property, that  
> actually makes sense.
Can't comment; what is this?

> >                 };
> >                 store {
> >                         name = "store";
> >                         interrupts = <@STORE_EVTCHN@ 0>;
> >                         frameno = <@STORE_MFN@>;
> this could be a "reg"/"unit address" as well.
You need #address-cells and #size-cells in the parent node for
that, btw.


Segher


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel