How complete should the DTS be?

How complete should the DTS be?

[Sean MacLennan]

Just a general question about DTS "completeness". Like all 440EP 
processors, the taco has two i2c buses. However, only one bus has 
anything connected to it.

Should I show both bus entries in the DTS, or only the one that is used? 
I have generally only been showing the devices that are present. i.e. 
Only one emac, only one serial port.

Is there a convention for this?

Cheers,
   Sean

Re: How complete should the DTS be?

[Kumar Gala]

On Jan 7, 2008, at 8:07 PM, Sean MacLennan wrote:

> Just a general question about DTS "completeness". Like all 440EP
> processors, the taco has two i2c buses. However, only one bus has
> anything connected to it.
>
> Should I show both bus entries in the DTS, or only the one that is  
> used?
> I have generally only been showing the devices that are present. i.e.
> Only one emac, only one serial port.
>
> Is there a convention for this?


The .dts should reflect the HW as its used.  On some reference boards  
we might put out more info because of the various configs these types  
of boards can be setup in.  However if something has a static config  
just describe that.  So in your example of two i2c buses with only one  
connected, just describe the one that is used.

- k

Re: How complete should the DTS be?

[David Gibson]

On Tue, Jan 08, 2008 at 12:04:36AM -0600, Kumar Gala wrote:
> 
> On Jan 7, 2008, at 8:07 PM, Sean MacLennan wrote:
> 
> > Just a general question about DTS "completeness". Like all 440EP
> > processors, the taco has two i2c buses. However, only one bus has
> > anything connected to it.
> >
> > Should I show both bus entries in the DTS, or only the one that is  
> > used?
> > I have generally only been showing the devices that are present. i.e.
> > Only one emac, only one serial port.
> >
> > Is there a convention for this?
> 
> The .dts should reflect the HW as its used.  On some reference boards  
> we might put out more info because of the various configs these types  
> of boards can be setup in.  However if something has a static config  
> just describe that.  So in your example of two i2c buses with only one  
> connected, just describe the one that is used.

Hrm... I'd say this is not something which has a firm convention yet.

It's going to become more of an issue once we get a macros system for
dtc, so the "440EP" macro would have all the devices, even if some are
not connected on a given board.

I'm contemplating suggesting that we adopt the "status" property from
IEEE1275 to cover this.

-- 
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

Re: How complete should the DTS be?

[Sean MacLennan]

David Gibson wrote:
> Hrm... I'd say this is not something which has a firm convention yet.
> It's going to become more of an issue once we get a macros system for
> dtc, so the "440EP" macro would have all the devices, even if some are
> not connected on a given board.
>
> I'm contemplating suggesting that we adopt the "status" property from
> IEEE1275 to cover this.
>
>   
When I am laying out the dts, leaving out what isn't used makes the dts 
file cleaner, at least in my view. It doesn't hurt to have the second 
i2c bus there, but it also doesn't help and leaving it out points out 
that it is not used.

When we get a macro system I assume the second i2c bus will be there but 
hidden by a macro. It will still be clean and shouldn't cause grief.

Cheers,
    Sean

Re: How complete should the DTS be?

[David Gibson]

On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote:
> David Gibson wrote:
> > Hrm... I'd say this is not something which has a firm convention yet.
> > It's going to become more of an issue once we get a macros system for
> > dtc, so the "440EP" macro would have all the devices, even if some are
> > not connected on a given board.
> >
> > I'm contemplating suggesting that we adopt the "status" property from
> > IEEE1275 to cover this.
> >
> >   
> When I am laying out the dts, leaving out what isn't used makes the dts 
> file cleaner, at least in my view. It doesn't hurt to have the second 
> i2c bus there, but it also doesn't help and leaving it out points out 
> that it is not used.
> 
> When we get a macro system I assume the second i2c bus will be there but 
> hidden by a macro. It will still be clean and shouldn't cause grief.

Right, but if it is there we'll want to mark it as unused in some way
so that the kernel doesn't waste resources attempting to drive it.

-- 
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

Re: How complete should the DTS be?

[Benjamin Herrenschmidt]

On Thu, 2008-01-10 at 17:02 +1100, David Gibson wrote:
> On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote:
> > David Gibson wrote:
> > > Hrm... I'd say this is not something which has a firm convention yet.
> > > It's going to become more of an issue once we get a macros system for
> > > dtc, so the "440EP" macro would have all the devices, even if some are
> > > not connected on a given board.
> > >
> > > I'm contemplating suggesting that we adopt the "status" property from
> > > IEEE1275 to cover this.
> > >
> > >   
> > When I am laying out the dts, leaving out what isn't used makes the dts 
> > file cleaner, at least in my view. It doesn't hurt to have the second 
> > i2c bus there, but it also doesn't help and leaving it out points out 
> > that it is not used.
> > 
> > When we get a macro system I assume the second i2c bus will be there but 
> > hidden by a macro. It will still be clean and shouldn't cause grief.
> 
> Right, but if it is there we'll want to mark it as unused in some way
> so that the kernel doesn't waste resources attempting to drive it.

Sure but I don't want to make it mandatory for people to put unused
devices in. If the macro system brings them in, then yes, it's good to
have a way to properly mark them unused. But people hand crafting DTS
shouldn't have to bloat them.

There is -one- case where you may want to put unused devices, is if you
do some kind of resource management on that specific bus (like need to
be able to dynamically allocate space on the bus). In this case, you
want to know everything that's there and potentially decodes addresses
to avoid collisions.

Cheers,
Ben.

Re: How complete should the DTS be?

[Josh Boyer]

On Thu, 10 Jan 2008 17:50:49 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> On Thu, 2008-01-10 at 17:02 +1100, David Gibson wrote:
> > On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote:
> > > David Gibson wrote:
> > > > Hrm... I'd say this is not something which has a firm convention yet.
> > > > It's going to become more of an issue once we get a macros system for
> > > > dtc, so the "440EP" macro would have all the devices, even if some are
> > > > not connected on a given board.
> > > >
> > > > I'm contemplating suggesting that we adopt the "status" property from
> > > > IEEE1275 to cover this.
> > > >
> > > >   
> > > When I am laying out the dts, leaving out what isn't used makes the dts 
> > > file cleaner, at least in my view. It doesn't hurt to have the second 
> > > i2c bus there, but it also doesn't help and leaving it out points out 
> > > that it is not used.
> > > 
> > > When we get a macro system I assume the second i2c bus will be there but 
> > > hidden by a macro. It will still be clean and shouldn't cause grief.
> > 
> > Right, but if it is there we'll want to mark it as unused in some way
> > so that the kernel doesn't waste resources attempting to drive it.
> 
> Sure but I don't want to make it mandatory for people to put unused
> devices in. If the macro system brings them in, then yes, it's good to
> have a way to properly mark them unused. But people hand crafting DTS
> shouldn't have to bloat them.
> 
> There is -one- case where you may want to put unused devices, is if you
> do some kind of resource management on that specific bus (like need to
> be able to dynamically allocate space on the bus). In this case, you
> want to know everything that's there and potentially decodes addresses
> to avoid collisions.

There are other uses too.  E.g. pin sharing between devices based on
DIP switch settings.  You'd want to enumerate all the devices, and then
add 'status = "failed-not-connected"' to the ones that don't have pins.

josh