[PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware

[Jerry Van Baren]

Scott Wood wrote:
> On Fri, May 18, 2007 at 09:34:46AM -0500, Timur Tabi wrote:
>> We'll propose a spec once we have everything figured out.  Our current
>> idea is to allow any node or property to have a conditional attached to
>> it.  U-Boot will then scan the device tree, evaluate the conditional,
>> and if it's false, delete the particular node/property.
>>
>> U-Boot will be also be expanded to include the concept of "hardware
>> options", whether the user and/or board-specific code can tell U-Boot
>> that hardware option X is set to value Y. The conditions in the device
>>   tree will be of the form "X == Y" (or X != Y, X > Y, etc).
>>
>> For instance, on some board, if jumper 22 is on, then it means that the
>> USB port is enabled.  If it's possible for software to scan the status
>> of J22, then the board-specific code will do that, and it will create
>> an environment variable "J22=ON".  The USB node in the device tree will
>> have the conditional "J22 = ON".
> 
> I'd like to point out that what I originally proposed was much simpler
> than this; it simply allowed a special section of the device tree to list
> jumpers and other hw options, and associate a device tree fragment with
> each possibility.  Something like this:
> 
> u-boot,hwoptions {
> 	J1 {
> 		description = "USB PHY selector";
> 		
> 		off {
> 			description = "USB internal PHY";
> 			
> 			tree {
> 				&usb {
> 					phy_type = "utmi_wide";
> 				};
> 			};
> 		};
> 
> 		on {
> 			description = "USB external PHY";
> 			
> 			tree {
> 				&usb {
> 					phy_type = "ulpi";
> 				};
> 			};
> 		};
> 	};
> };
> 
> The fragment that corresponds to the option that is either detected
> automatically or specified by the user on the command line gets merged
> into the main dts.  The u-boot,hwoptions tree gets removed before passing
> to the kernel, to avoid confusion.  The descriptions can be used to
> provide interactive help text, as an alternative to having to fetch the
> manual to find jumper information.
> 
> I agreed with using conditionals at the dtc level, and having dtc
> transform it into the above at the dtb level.  I'm not quite comfortable
> with having general conditional expressions at the binary level.
> 
> -Scott

Aye, that looks useful and reasonable to me.  In one of my previous 
spiels I talked about merging fragments of fdt blobs.  That was a 
half-baked thought, the above dts (blob) would have all the fragments in 
it and the u-boot board-specific logic would be copying/moving the 
selected nodes.  That has a lot of benefits...
* The above should result in reasonable board-specific code.
   * We may want to invent a libfdt move/copy subtree function (I don't
       recall one being in there).  Board specific code would want to
       move selected subtrees out of /u-boot,hwoptions into the
       appropriate final node.  All the pieces are in libfdt, just would
       need to be hooked together in a utility subroutine.
* With the above, nothing in the infrastructure (dtc, libfdt) needs to
     change.

On a related note, would it be better to name the node 
"/u-boot/hwoptions" (two levels deep)?  It seems very desirable to me to 
avoid cluttering the root node.  I would like to see, for instance, 
"/u-boot-env" be moved to "/u-boot/env" and probably "/bd_t" moved to 
"/u-boot/bd_t" (if it survives - the fdt should make bd_t obsolete).

Best regards,
gvb