Re: [XenPPC] XenPPC IEEE1275 binding?

[Segher Boessenkool]

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@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel