From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace•com>
To: Scott Wood <scottwood@freescale•com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs•org>,
Timur Tabi <timur@freescale•com>,
Zhang Wei-r63237 <Wei.Zhang@freescale•com>
Subject: Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
Date: Fri, 18 May 2007 13:30:59 -0400 [thread overview]
Message-ID: <464DE2D3.3090805@smiths-aerospace.com> (raw)
In-Reply-To: <20070518164628.GA16825@ld0162-tx32.am.freescale.net>
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
next prev parent reply other threads:[~2007-05-18 17:31 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-15 16:17 [PATCH 0/5] MPC8641 HPCN fixes Wade Farnsworth
2007-05-15 16:23 ` [PATCH 1/5] Add MTD support to mpc8641_hpcn.dts Wade Farnsworth
2007-05-15 16:27 ` [PATCH 2/5] Add legacy devices " Wade Farnsworth
2007-05-16 16:37 ` Jon Loeliger
2007-05-16 17:59 ` Wade Farnsworth
2007-05-16 19:59 ` Segher Boessenkool
2007-05-16 19:55 ` Segher Boessenkool
2007-05-16 20:03 ` Sergei Shtylyov
2007-05-16 20:17 ` Wade Farnsworth
2007-05-16 23:40 ` Segher Boessenkool
2007-05-16 23:47 ` Segher Boessenkool
2007-05-17 0:11 ` Wade Farnsworth
2007-05-17 0:09 ` Wade Farnsworth
2007-05-18 16:44 ` Jon Loeliger
2007-05-21 16:04 ` Wade Farnsworth
2007-05-21 16:10 ` Jon Loeliger
2007-05-21 16:51 ` Wade Farnsworth
2007-05-16 20:29 ` Wade Farnsworth
2007-07-07 18:29 ` Sergei Shtylyov
2007-07-07 18:39 ` Arnd Bergmann
2007-07-08 13:13 ` Segher Boessenkool
2007-07-08 20:36 ` Arnd Bergmann
2007-07-08 23:42 ` Segher Boessenkool
2007-07-09 12:43 ` Sergei Shtylyov
2007-07-09 14:43 ` Segher Boessenkool
2007-07-07 18:59 ` Sergei Shtylyov
2007-07-07 19:23 ` Arnd Bergmann
2007-05-15 16:32 ` [PATCH 3/5] Support for the LPC47M192 SuperIO on the MPC8641 HPCN Wade Farnsworth
2007-05-15 16:36 ` [PATCH 4/5] Add RTC CMOS support for " Wade Farnsworth
2007-05-15 16:50 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02 hardware Wade Farnsworth
2007-05-16 16:44 ` Jon Loeliger
2007-05-16 18:06 ` Wade Farnsworth
2007-05-18 6:52 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev1.02 hardware Jin Zhengxiong-R64188
2007-05-21 15:59 ` Wade Farnsworth
2007-05-17 2:50 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware Zhang Wei-r63237
2007-05-17 16:03 ` Wade Farnsworth
2007-05-17 16:14 ` Kumar Gala
2007-05-17 16:58 ` Wade Farnsworth
2007-05-17 18:46 ` Timur Tabi
2007-05-17 18:48 ` Timur Tabi
2007-05-17 18:53 ` Scott Wood
2007-05-17 18:59 ` Timur Tabi
2007-05-17 19:16 ` Jerry Van Baren
2007-05-18 13:48 ` Matt Sealey
2007-05-17 22:34 ` Wade Farnsworth
2007-05-18 0:56 ` David Gibson
2007-05-18 3:49 ` Jerry Van Baren
2007-05-18 14:34 ` Timur Tabi
2007-05-18 15:22 ` Jerry Van Baren
2007-05-18 16:46 ` Scott Wood
2007-05-18 17:30 ` Jerry Van Baren [this message]
2007-05-18 17:39 ` Timur Tabi
2007-05-18 17:43 ` Scott Wood
2007-05-18 17:47 ` Timur Tabi
2007-05-18 17:52 ` Scott Wood
2007-05-18 17:56 ` Timur Tabi
2007-05-18 18:02 ` Scott Wood
2007-05-18 18:03 ` Jerry Van Baren
2007-05-18 18:19 ` Jon Loeliger
2007-05-18 18:23 ` Scott Wood
2007-05-18 19:05 ` Jon Loeliger
2007-05-18 19:09 ` Scott Wood
2007-05-18 18:30 ` Timur Tabi
2007-05-18 17:59 ` Jerry Van Baren
2007-05-18 10:20 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev1.02hardware Zhang Wei-r63237
2007-05-21 16:01 ` Wade Farnsworth
2007-05-22 2:53 ` [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon andRev1.02hardware Zhang Wei-r63237
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=464DE2D3.3090805@smiths-aerospace.com \
--to=gerald.vanbaren@smiths-aerospace$(echo .)com \
--cc=Wei.Zhang@freescale$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=scottwood@freescale$(echo .)com \
--cc=timur@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox