How complete should the DTS be?
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
Quoted 9 lines · 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?
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
Quoted 12 lines · Kumar Gala
Quoted 9 lines · 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.
Quoted 7 lines
Quoted 1 line
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.
Signature · 4 lines
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
Quoted 9 lines · David Gibson
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
Quoted 10 lines · Sean MacLennan
Quoted 9 lines · David Gibson
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.
Quoted 7 lines
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.
Signature · 4 lines
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
Quoted 16 lines · David Gibson
Quoted 15 lines · Sean MacLennan
Quoted 9 lines · David Gibson
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 29 lines · On Thu, 10 Jan 2008 17:50:49 +1100 Benjamin Herrenschmidt…
Quoted 16 lines · David Gibson
Quoted 15 lines · Sean MacLennan
Quoted 9 lines · David Gibson
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 5 lines
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