* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-18 17:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <6F8D3143-423D-45FA-9F40-00BF770831F2@kernel.crashing.org>
Kumar Gala wrote:
>
> On May 18, 2007, at 11:35 AM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>
>>> I guess my gripe is about proposing a solution and not willing to
>>> extend it in light of people providing issues with it.
>>
>>
>> I'm perfectly willing to extend it if you let me know what you think
>> is needed, rather than just saying "switches and muxes". What
>> *specifically* would they need beyond what I proposed?
>
>
> I provided you an example device and asked you to explain how it would
> be described in what you are proposing.
And I did. What did you find lacking in the device tree fragment I
suggested?
> I never said don't bother because you didn't cover the switch/mux
> case. I said don't bother because I don't see what the value is
> creating a namespace that no one is going to manage and thus will end
> up most likely being linux specific, and linux already provides a
> solution for the problem.
Given that power.org is attempting to do further standardization of the
device tree for embedded applications, I'd be surprised if there weren't
a way we could have them act as a registry.
> For I2C specifically we already have both a dynamic way (kernel cmd
> line) and static (i2c_board_info) to specify the i2c devices, why do we
> need yet another?
This uses i2c_board_info; it doesn't replace it.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Jerry Van Baren @ 2007-05-18 17:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi, Zhang Wei-r63237
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
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Kumar Gala @ 2007-05-18 17:33 UTC (permalink / raw)
To: Scott Wood; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <464DDFA5.6050106@freescale.com>
On May 18, 2007, at 12:17 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On May 18, 2007, at 11:35 AM, Scott Wood wrote:
>>> Kumar Gala wrote:
>>>
>>>> I guess my gripe is about proposing a solution and not willing
>>>> to extend it in light of people providing issues with it.
>>>
>>>
>>> I'm perfectly willing to extend it if you let me know what you
>>> think is needed, rather than just saying "switches and muxes".
>>> What *specifically* would they need beyond what I proposed?
>> I provided you an example device and asked you to explain how it
>> would be described in what you are proposing.
>
> And I did. What did you find lacking in the device tree fragment I
> suggested?
Once you expand the beyond just a root node for the controller I'd
like to see how you suggest we handle the case where a particular
child ends up having children as well. You example, is sufficient
the majority of devices, but I'd like to know that we'll be able to
handle the case where a node is both a device and controller.
>> I never said don't bother because you didn't cover the switch/mux
>> case. I said don't bother because I don't see what the value is
>> creating a namespace that no one is going to manage and thus will
>> end up most likely being linux specific, and linux already
>> provides a solution for the problem.
>
> Given that power.org is attempting to do further standardization of
> the device tree for embedded applications, I'd be surprised if
> there weren't a way we could have them act as a registry.
If/when they sign up for this I'd be more inclined to have kernel
support for it.
>> For I2C specifically we already have both a dynamic way (kernel
>> cmd line) and static (i2c_board_info) to specify the i2c devices,
>> why do we need yet another?
>
> This uses i2c_board_info; it doesn't replace it.
Ok, but what functionality does it give us that we dont already have
today?
- k
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Timur Tabi @ 2007-05-18 17:39 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DE2D3.3090805@smiths-aerospace.com>
Jerry Van Baren wrote:
>> I'd like to point out that what I originally proposed was much simpler
>> than this;
Actually, we're talking about the same thing, but I guess my over-simplification back-fired.
> 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 idea stemmed from a desire to have a single DTS file for a given board, even in
situations where jumpers changed what hardware was enabled.
> * 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.
Just being able to delete a given node/property would be enough. By default, the nodes
with conditionals would be present in the device tree. The boot loader would then also
strip out all conditionals from the device tree before passing it to the kernel. The
kernel would then receive a standard device tree like it does today.
> * 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
It's not a u-boot-specific concept. The idea of representing jumpers (and other hardware
options) in the device tree is not something that's unique to u-boot or any boot loader.
The conditionals, however, are a bootloader-specific concept. We don't want Linux to see
them.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Scott Wood @ 2007-05-18 17:43 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DE4C7.7030906@freescale.com>
Timur Tabi wrote:
> Just being able to delete a given node/property would be enough.
I'd rather have an additive model than a subtractive one. And it would
not be enough, as you would not be able to have two different versions
of a property with the same name.
>> 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
>
>
> It's not a u-boot-specific concept. The idea of representing jumpers
> (and other hardware options) in the device tree is not something that's
> unique to u-boot or any boot loader. The conditionals, however, are a
> bootloader-specific concept. We don't want Linux to see them.
I put the u-boot namespace qualifier on there because the implementation
is being suggested in the context of u-boot, and it's not a general OF
binding. However, as long as it gets nuked before passing it on to the
kernel, OF/ePAPR/whatever compliance isn't quite as relevant, so plain
old "hwoptions" should be OK.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Timur Tabi @ 2007-05-18 17:47 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DE5D2.5000301@freescale.com>
Scott Wood wrote:
> Timur Tabi wrote:
>> Just being able to delete a given node/property would be enough.
>
> I'd rather have an additive model than a subtractive one. And it would
> not be enough, as you would not be able to have two different versions
> of a property with the same name.
The model would be additive, but the DTB would be subtractive. After all, the nodes have
to *exist* in the DTB that's given to U-Boot. After U-Boot scans the device tree and
evaluates the conditions, it has to remove the nodes that fail.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Scott Wood @ 2007-05-18 17:52 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DE6C1.2010108@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>
>> Timur Tabi wrote:
>>
>>> Just being able to delete a given node/property would be enough.
>>
>>
>> I'd rather have an additive model than a subtractive one. And it
>> would not be enough, as you would not be able to have two different
>> versions of a property with the same name.
>
>
> The model would be additive, but the DTB would be subtractive.
I meant additive at the DTB level.
> After
> all, the nodes have to *exist* in the DTB that's given to U-Boot.
Yes, they exist under the /hwoptions node.
> After
> U-Boot scans the device tree and evaluates the conditions, it has to
> remove the nodes that fail.
That's your model. Mine involves merging a fragment that corresponds to
an active hwoption, with no complex conditional evaluation or deletion
of anything from the main tree.
How would you express the alternate setting of phy_type in a subtractive
model? You can't have two nodes with the same name and different
phy_types, and you can't have two phy_type properties in one node.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Timur Tabi @ 2007-05-18 17:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DE7F7.3030302@freescale.com>
Scott Wood wrote:
> That's your model. Mine involves merging a fragment that corresponds to
> an active hwoption, with no complex conditional evaluation or deletion
> of anything from the main tree.
I think my model (which is also Jon's, I think) is easier to read and implement.
> How would you express the alternate setting of phy_type in a subtractive
> model? You can't have two nodes with the same name and different
> phy_types, and you can't have two phy_type properties in one node.
The conditionals would have to be correct:
phy-node [ if j22 = on ]
{
phy-type = 1
}
phy-node [ if j22 = off ]
{
phy-type = 2
}
Obviously, j22 can be either on or off, but never both. If the DTS is coded incorrectly,
then it will have problems, but I think that's a fair trade-off for the easier implementation.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Jerry Van Baren @ 2007-05-18 17:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DE4C7.7030906@freescale.com>
Timur Tabi wrote:
> Jerry Van Baren wrote:
[snip]
>> * 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.
>
> Just being able to delete a given node/property would be enough. By
> default, the nodes with conditionals would be present in the device
> tree. The boot loader would then also strip out all conditionals from
> the device tree before passing it to the kernel. The kernel would then
> receive a standard device tree like it does today.
Deleting isn't really enough because you would want to copy/move the
configuration from a subnode of the hwoptions node to the final resting
place in the standard tree (assuming there is a final resting place in
the standard tree - I'm picturing SOC configuration choices here).
Simple deletion isn't adequate in general because
* It would be silly to change linux to look in a new location for things
that already exist in standard locations (e.g. SOC stuff)
* Deleting a node inherently deletes all of the subnodes. In order to
do only delete operations, you would end up with an ugly path like:
/u-boot,hwoptions/J1/on/tree/&usb/phy_type (set to "ulpi")
where I suspect the &usb/phy_type portion should be glued into a SOC
(or other) pre-existing subnode.
* It is possible some choices can be used multiple times - the above
example specifies a PHY. There are very often multiple instances of
only type of PHY and copying one "prototype" selection into multiple
final destination nodes could save space and effort.
>> * 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
>
> It's not a u-boot-specific concept. The idea of representing jumpers
> (and other hardware options) in the device tree is not something that's
> unique to u-boot or any boot loader. The conditionals, however, are a
> bootloader-specific concept. We don't want Linux to see them.
Well, then we shouldn't name it u-boot,hwoptions. Ahh, nevermind, Scott
beat me to that point.
Best regards,
gvb
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Scott Wood @ 2007-05-18 18:02 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DE8BB.5040601@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>
>> That's your model.
Yes. That was the whole point of my post, to point out my alternative.
You were the one that said, "Actually, we're talking about the same
thing."
>> Mine involves merging a fragment that corresponds
>> to an active hwoption, with no complex conditional evaluation or
>> deletion of anything from the main tree.
>
>
> I think my model (which is also Jon's, I think) is easier to read
What does the dtb-level implementation have to do with ease of reading?
I said that I didn't mind conditionals at the source level that get
turned to hwoptions at the dtb level.
> and implement.
I disagree.
> phy-node [ if j22 = on ]
> {
> phy-type = 1
> }
>
> phy-node [ if j22 = off ]
> {
> phy-type = 2
> }
Ah.
So I take it you'll need a new dtb version to implement this? No such
revision would be needed for my model.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Jerry Van Baren @ 2007-05-18 18:03 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DE8BB.5040601@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>
>> That's your model. Mine involves merging a fragment that corresponds
>> to an active hwoption, with no complex conditional evaluation or
>> deletion of anything from the main tree.
>
> I think my model (which is also Jon's, I think) is easier to read and
> implement.
>
>> How would you express the alternate setting of phy_type in a
>> subtractive model? You can't have two nodes with the same name and
>> different phy_types, and you can't have two phy_type properties in one
>> node.
>
> The conditionals would have to be correct:
>
>
> phy-node [ if j22 = on ]
> {
> phy-type = 1
> }
>
> phy-node [ if j22 = off ]
> {
> phy-type = 2
> }
>
> Obviously, j22 can be either on or off, but never both. If the DTS is
> coded incorrectly, then it will have problems, but I think that's a fair
> trade-off for the easier implementation.
OK, your syntax implies fairly significant changes to the dtc/dtb/u-boot
(and possibly linux, depending on what detritus is left after u-boot
does the selections). Scott's syntax fits into the current fdt
definition, tools, and blob-users with the exception that u-boot would
have board specific selection code added, but that needs to be added
regardless.
Best regards,
gvb
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-18 17:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <79CACFC8-DD5B-4284-AC2E-C92FE2A85330@kernel.crashing.org>
Kumar Gala wrote:
> Once you expand the beyond just a root node for the controller I'd like
> to see how you suggest we handle the case where a particular child ends
> up having children as well. You example, is sufficient the majority of
> devices, but I'd like to know that we'll be able to handle the case
> where a node is both a device and controller.
The example I gave *was* a controller and an i2c device at the same time
(note the i2c-style reg = <70>). Just take the fragment and stick it in
an existing i2c controller node; I omitted the latter for brevity, as a
result of making the mistake of typing it in Mozilla rather than mutt,
and thus having no autoindent.
>> Given that power.org is attempting to do further standardization of
>> the device tree for embedded applications, I'd be surprised if there
>> weren't a way we could have them act as a registry.
>
> If/when they sign up for this I'd be more inclined to have kernel
> support for it.
Fair enough. I'm still interested in what you think would need to be
done to support switches and muxes, from the context of standardizing it
in ePAPR. The bus numbering shouldn't be an issue as long as you keep
the bus numbers local to the switch/mux, and don't pretend that they
have anything to do with any global i2c bus number that the OS may or
may not have.
>>> For I2C specifically we already have both a dynamic way (kernel cmd
>>> line) and static (i2c_board_info) to specify the i2c devices, why
>>> do we need yet another?
>>
>>
>> This uses i2c_board_info; it doesn't replace it.
>
>
> Ok, but what functionality does it give us that we dont already have
> today?
The convenience of putting the data in a dts rather than in
board-specific code/structs. It's not a huge deal, but I find the
former to be a more pleasant way of doing things, and others have
similarly expressed interest in it.
It would be significantly more useful as an ePAPR standard that can be
used by multiple OSes, but they seem to be in
standardize-what-Linux-does mode, hence why I proposed it here first.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Jon Loeliger @ 2007-05-18 18:19 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Wei Zhang
In-Reply-To: <464DE8BB.5040601@freescale.com>
On Fri, 2007-05-18 at 12:56, Timur Tabi wrote:
> Scott Wood wrote:
>
> > That's your model. Mine involves merging a fragment that corresponds to
> > an active hwoption, with no complex conditional evaluation or deletion
> > of anything from the main tree.
>
> I think my model (which is also Jon's, I think) is easier to read and implement.
Harumph.
>
> phy-node [ if j22 = on ]
> {
> phy-type = 1
> }
>
> phy-node [ if j22 = off ]
> {
> phy-type = 2
> }
>
> Obviously, j22 can be either on or off, but never both. If the DTS is coded incorrectly,
> then it will have problems, but I think that's a fair trade-off for the easier implementation.
First of all, I wanted to get away from the notion of calling
anything a "jumper". What I said to you was to predicate the
clause based on some arbitrary conditional, not just some "jumper
setting."
Second, I never came anywhere near the syntax above.
Third, I am pretty sure we've always really been talking
about a DTC enhancement to selectively add regions to the
DTB in much the same way as if one had said:
#if <compile-time-conditional>
{
<use this node or property snippet>
}
#else
{
<use this other snippet>
}
#endif
So embedding a full runtime evaluation of conditionals
expressions wasn't really in my suggestion at this time
at all. I had essentially proposed (to you, Timur) that
we have a predicate clause in the DTS that guarded a the
presence/absence of a node.
And finally, I wasn't sure I was happy with it all yet
in any event, so I hadn't acted on it yet. I was still
pondering "the right approach here".
Ah well,
jdl
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Scott Wood @ 2007-05-18 18:23 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Timur Tabi, Wei Zhang
In-Reply-To: <1179512385.19664.8.camel@ld0161-tx32>
Jon Loeliger wrote:
> First of all, I wanted to get away from the notion of calling
> anything a "jumper". What I said to you was to predicate the
> clause based on some arbitrary conditional, not just some "jumper
> setting."
Yes, I like the "hwoption" name better.
> Second, I never came anywhere near the syntax above.
>
> Third, I am pretty sure we've always really been talking
> about a DTC enhancement to selectively add regions to the
> DTB in much the same way as if one had said:
>
> #if <compile-time-conditional>
> {
> <use this node or property snippet>
> }
> #else
> {
> <use this other snippet>
>
> }
> #endif
No, we were pretty much always talking about a run-time thing.
Compile-time would just give you a more convenient way of generating
multiple dtbs; it wouldn't address the root problem of combinatorial
explosion with several independent options. Even when the number of
alternatives isn't high, it's much nicer to the user to be able to just
type a command into u-boot (or better yet, have it be autodetected) when
an option changes than to have to rebuild and install a new dtb.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Timur Tabi @ 2007-05-18 18:30 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Wei Zhang
In-Reply-To: <1179512385.19664.8.camel@ld0161-tx32>
Jon Loeliger wrote:
>> I think my model (which is also Jon's, I think) is easier to read and implement.
>
> Harumph.
Hey, I got the idea from you!
> First of all, I wanted to get away from the notion of calling
> anything a "jumper". What I said to you was to predicate the
> clause based on some arbitrary conditional, not just some "jumper
> setting."
True, but the arbitrary condition would, in practice, be the value of some
jum^H^H^Hhardware setting.
> Second, I never came anywhere near the syntax above.
That's just a rough version because I don't have the DTS layout memorized.
> Third, I am pretty sure we've always really been talking
> about a DTC enhancement to selectively add regions to the
> DTB in much the same way as if one had said:
The problem is that the conditions that I'm talking about are not known until U-Boot runs.
If your idea was only compile-time conditional, then I'm just extending it to a runtime
conditional.
> So embedding a full runtime evaluation of conditionals
> expressions wasn't really in my suggestion at this time
> at all. I had essentially proposed (to you, Timur) that
> we have a predicate clause in the DTS that guarded a the
> presence/absence of a node.
predicate clause == conditional.
> And finally, I wasn't sure I was happy with it all yet
> in any event, so I hadn't acted on it yet. I was still
> pondering "the right approach here".
I was trying to avoid a premature discussion on this idea, but apparently everyone else
wants to talk about it!
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: David Brownell @ 2007-05-18 19:00 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c
In-Reply-To: <20070518183140.4644ffc6@hyperion.delvare>
On Friday 18 May 2007, Jean Delvare wrote:
> On Fri, 18 May 2007 10:58:06 -0500, Scott Wood wrote:
> > Jean Delvare wrote:
> > > On Thu, 17 May 2007 14:32:11 -0500, Scott Wood wrote:
> > >
> > >>(and the
> > >>i2c code in Linux should be fixed to allow drivers to specify multiple
> > >>match names).
> > >
> > >
> > > Back when David proposed his new-style i2c code, I had the same
> > > objection. But we addressed the need differently. If you look at struct
> > > i2c_board_info, you'll see two string fields, driver_name and type. The
> > > former specifies the driver name, the second specifies the exact device
> > > variant. For drivers which support several device variants, the
> > > platform code should fill both fields.
> >
> > But that still requires the platform to know the driver name, rather
> > than matching any driver which knows about the type.
Given that the platform (== board/system) may care about the upper layer
of the driver (APIs exposed) not just the lower one (talking-to-hardware),
that seems like a reasonable tradeoff. It wouldn't want to use the driver
which provides the wrong programming interface!
Plus, to repeat, there is no notion of "type" in I2C. So in order to
talk about a "type based matching" algorithm you'd have to define one...
> > This prevents the
> > use of OS-independent device trees (such as in Open Firmware), which
> > cannot know specific Linux driver names, without something hacky like a
> > type-to-driver table in the device tree code.
>
> Oh well, this was also the reason why I objected to David's approach in
> the first place. If you dig back in the i2c list archive, you'll find
> that I was asking for exactly the same thing you do now: that each i2c
> driver would export a list of supported devices, and the i2c-core would
> match a device name against that list (independent of the driver name.)
> It felt more flexible, but I wondered how useful it would be in
> practice, and finally gave up and David had the last word. If you had
> shown up back then rather than now...
With concrete suggestions and patches. I'd have to dig back in the
list archives to see the details of what was said at that time, but
I don't recall any suggestions being rejected unless they dropped
essential functionality. (There was one notion to key driver binding
purely on device address, for example...)
- Dave
^ permalink raw reply
* Re: BDI2000 configuration file for MPC8313E-RDB
From: Stefan Roese @ 2007-05-18 19:04 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Leonid, Frank Prepelica
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C017BA668@ehost011-3.exch011.intermedia.net>
On Friday 18 May 2007, Leonid wrote:
> See, it's not a question that BDI2000 can be used with board which has
> NAND flash on it, just it's not capable of NAND direct programming as it
> does in the case of NOR flash.
Yes, "direct" NAND programming via BDI2000 is not possible. At least not at
the moment with the current firmware versions.
> I also have AMCC Sequoia board with both NOR and NAND flash. On this
> board you can boot u-boot from NOR first and use it to program NAND.
Correct.
Just a side note: You can also boot the Sequoia from NAND directly if you have
programmed the NAND U-Boot version for the Sequoia, as the 440EP(x) supports
direct NAND booting.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Jon Loeliger @ 2007-05-18 19:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi, Wei Zhang
In-Reply-To: <464DEF3C.7070202@freescale.com>
On Fri, 2007-05-18 at 13:23, Scott Wood wrote:
> Jon Loeliger wrote:
> > First of all, I wanted to get away from the notion of calling
> > anything a "jumper". What I said to you was to predicate the
> > clause based on some arbitrary conditional, not just some "jumper
> > setting."
>
> Yes, I like the "hwoption" name better.
I think my point was missed. It could be more general
than "a hardware thing". Sure, HW contributes.
> No, we were pretty much always talking about a run-time thing.
On he contrary, here are copies of two pieces of mail from
roughly May 2006 and Feb 2007 in which CPP and M4 as _compiled_time_
processing are being discussed. In the latter, you discuss it more:.
From: Kumar Gala <galak@kernel.crashing.org>
To: Jon Loeliger <jdl@freescale.com>
Cc: Jon Loeliger <jdl@jdl.com>, Benjamin Herrenschmidt
<benh@kernel.crashing.org>, linuxppc-dev@ozlabs.org list
<linuxppc-dev@ozlabs.org>
Subject: Re: DTC/dts modifications
Date: Mon, 1 May 2006 14:52:23 -0500
[snip]
>> If these used some other symbol instead of '#' cpp
>> will be happy and we can use it to create macros for us.
>
> Yeah, we're not going to be able to change those; they
> are "By The Book".
By what book? It would seem to me that BNF for dtc is
completely under our control and if we want to change it we can.
I understand that there is some correspondence to Open Firmware,
but it seems that if its people are ok with the dts format
changing that's a lot easier than implementing tons of support
in dtc for features that cpp gives us.
[I'm also guessing no one's really got time to go and implement
these features in dtc]
> Instead, we'll have to make the lexical analysis conscious
> of something like a <newline> context sensitive token or so.
> Or throw some flag to cpp to not emit location markers.
- kumar
From: Jon Loeliger <jdl@jdl.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org,
Roland Dreier <rdreier@cisco.com>,
Stefan Roese <sr@denx.de>, linuxppc-embedded@ozlabs.org
Subject:Re: [PATCH] ppc: Add support for AMCC Taishan 440GX eval board
Date: Mon, 12 Feb 2007 14:16:21 -0600
So, like, the other day Benjamin Herrenschmidt mumbled:
> Note that there are still things that we might want to
> change. For example, I think we really should look into adding
> a macro mecanism and/or an include mecanism to dtc so that we
> can do things like #include <ibm440gp.dtc> to get the base
> processor/SoC definition and then "overlay" some properties on
> top of it (like emac phy mode etc...)
What do people prefer here? Straight CPP pre-run?
Direct support built into dtc to do file-inclusion, macros?
Thoughts, opinions, suggestions, pre-NACKs, Cabernet Franc bribes?
jdl
And you reply:
Simple textual macros would make it difficult to define 123A and
123B SoCs whose device tree nodes are mostly a generic 123, but
require a few changes in various parts. I'd rather see dtc
support overlaying trees, with the "newer" tree able to add,
modify, and remove nodes and properties from the "older", more
generic tree.
Parametric macros (or "template" nodes) might be nice for a few
things on top of that, though (preferably with better syntax
than CPP).
Clearly, we have in fact historically discussed compile-time
conditional DTC behavior.
> Compile-time would just give you a more convenient way of generating
> multiple dtbs; it wouldn't address the root problem of combinatorial
> explosion with several independent options. Even when the number of
> alternatives isn't high, it's much nicer to the user to be able to just
> type a command into u-boot (or better yet, have it be autodetected) when
> an option changes than to have to rebuild and install a new dtb.
Yes, I understand. But I think, say, the Linux build handles
the compile time combinatorial explosion of compile time options
reasonably well so far... :-)
jdl
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Scott Wood @ 2007-05-18 19:09 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Timur Tabi, Wei Zhang
In-Reply-To: <1179515137.19664.19.camel@ld0161-tx32>
Jon Loeliger wrote:
> On Fri, 2007-05-18 at 13:23, Scott Wood wrote:
>
>>Jon Loeliger wrote:
>>
>>>First of all, I wanted to get away from the notion of calling
>>>anything a "jumper". What I said to you was to predicate the
>>>clause based on some arbitrary conditional, not just some "jumper
>>>setting."
>>
>>Yes, I like the "hwoption" name better.
>
>
> I think my point was missed. It could be more general
> than "a hardware thing". Sure, HW contributes.
What, other than hardware differences, would one conditionalize on?
>>No, we were pretty much always talking about a run-time thing.
>
>
> On he contrary, here are copies of two pieces of mail from
> roughly May 2006 and Feb 2007 in which CPP and M4 as _compiled_time_
> processing are being discussed. In the latter, you discuss it more:.
That was a separate discussion for a separate purpose (reducing
redundancy and duplication among dts files). I was talking about the
discussions I had with Timur about a month ago, to which you responded
with the conditional suggestion.
-Scott
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Segher Boessenkool @ 2007-05-18 20:07 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c
In-Reply-To: <20070518171555.543f9bdc@hyperion.delvare>
>> The only support we have for i2c controllers is to support one
>> specific i2c controller from Freescale.
>>
>> If you aren't going to provide a complete solution why are you
>> prosing one? I'm tired of this put stuff in the device tree but only
>> as much as I need to do my particular thing.
>
> This is exactly how free software development works. If people were
> only proposing complete solutions, Linux would not even exist. Things
> happen exactly because people write what they need and contribute what
> they wrote. If you think it's not enough for your own needs (present or
> future), then _you_ get to do the extra work.
You propose a generic device tree binding. This is
a public API/ABI so it is important that it is future-
proofed as far as possible/sane/whatever. If you're
asked how a not at all uncommon situation should be
expressed using that binding, and you cannot / will
not give an answer, that is basically equivalent to
withdrawing your proposed binding.
If you cannot get yourself to think about the general
situation, please don't try to draft generic bindings,
but restrict yourself to something board specific or
with that scope at least. And hope no one else takes
interest in that board or they'll happily NAK your
patches.
Segher
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: David Miller @ 2007-05-18 20:27 UTC (permalink / raw)
To: galak; +Cc: linux-kernel, linuxppc-dev, tglx, mingo
In-Reply-To: <32E780BE-58B7-4303-AA49-1852C4C7EB50@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Fri, 18 May 2007 11:31:19 -0500
> I asked this earlier, but figured you might have a better insight.
> Is their value in having 'drivers' for more than one clock source?
> I'd say most (of not all) the PPC SoCs have timers on the system side
> that we could provide drivers for, I'm just not sure if that does
> anything for anyone.
I'm in a similar situation on sparc64, so I'm interested in
this as well :-)
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Benjamin Herrenschmidt @ 2007-05-18 23:27 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, Dave Liu, mingo, linux-kernel
In-Reply-To: <464DAD06.2060504@ru.mvista.com>
On Fri, 2007-05-18 at 17:41 +0400, Sergei Shtylyov wrote:
> From the "PowerPC Operating Environment Architecture" that I've
> already
> quoated t follows that POWER4-compatible decremented exception *must*
> be edge
> triggered.
>
> > says that an exception is generated when the MSB transitions from 0
> to
> > 1. It's not clear wether the exception sticks while that bit is 1 or
> is
>
> Freescale MPC 7450 manual says the same, for example.
I find it extremely silly to implement it as edge anyway. The EE line is
level triggered, and having a mix of edge and level on the same
exception without a clean way to retrigger the DEC one other than
waiting one tick is just causing trouble.
Ben.
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Segher Boessenkool @ 2007-05-18 23:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-kernel, linuxppc-dev, Dave Liu, mingo, tglx
In-Reply-To: <1179530872.32247.423.camel@localhost.localdomain>
> I find it extremely silly to implement it as edge anyway. The EE line
> is
> level triggered, and having a mix of edge and level on the same
> exception without a clean way to retrigger the DEC one other than
> waiting one tick is just causing trouble.
It isn't edge triggered, it just automatically clears the
decrementer exception condition at its source when taken
(on certain implementations -- others leave it to software
to clear it).
Segher
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Matt Sealey @ 2007-05-19 0:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jean Delvare, i2c, linuxppc-dev
In-Reply-To: <6F8D3143-423D-45FA-9F40-00BF770831F2@kernel.crashing.org>
Kumar Gala wrote:
> On May 18, 2007, at 11:35 AM, Scott Wood wrote:
>
>> device tree isn't worthwhile for i2c devices, why is it worthwhile
>> for soc devices? It seems to me that non-probable chips like i2c
>> devices are precisely the kind of thing that the device tree is
>> useful for.
>
> I dont believe anyone has ever said that platform devices have to be
> in the device tree. We've been putting them their because we are
> going to act as the registry for the devices. The number of devices
> on all the various Freescale/AMCC/IBM PPC SoCs is likely a very small
> number compared to all I2C devices.
>
> For I2C specifically we already have both a dynamic way (kernel cmd
> line) and static (i2c_board_info) to specify the i2c devices, why do
> we need yet another?
Linux doesn't but it might be nice to specify this kind of thing in a
way that other operating systems might or may support.
Essentially I think since there are a lot of ways to support I2C
(including bitbanging a GPIO pair), the only real way to support it
is to do something like;
i2c@blah {
name = "i2c"
compatible = "mpc52xx-i2c,someother-i2c"
regs = "address:range"
}
The PURPOSE of this node is not to describe how the i2c controller
works, but to advertise it's presence and AUTHORIZE it's use. If a
node is not in the device tree, a driver author should probably
think twice about using it, especially on chips where pin muxing
is the modus operandii.
If it's in the device tree, then the chances of it being a wildly
crazy type of device external to the board design is probably very
low. If you have an SPI controller on - for example - an MPC52xx
chip, there are only 2 or 3 ways to have it implemented. Either
the inbuilt SPI, a PSC-based SPI, or perhaps using a bunch of GPIOs
to mimic an SPI interface very closely. The same applies to i2c.
You're not ever going to be able to specify in the device tree
exactly how to handle a driver, encompassing both implementation,
bugs in revisions, quirks of board design, but you can specify
for a driver a very accurate, very educated guess on it (any
quirks, bugs or implementation differences would be board/chip
specific, and are easily derived from the other device nodes
like the cpu node, soc node, and so on)
To carry on from the previous paragraph, with that in mind, if
it is an external device (perhaps bridged through another
chip or bus) it will be a child of the external bus. This also
gives a big clue about it's operation. If it is USB, or PCI,
or i2c based device, it will be marked with vendor/device/subsystem
ids or even an i2c slave address. Also very, very big clues.
(the only way you can accurately do all of the above and take
out all of the guesswork, is provide the driver in the firmware.
U-Boot and FDT's, you can forget it!)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Benjamin Herrenschmidt @ 2007-05-19 0:13 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-kernel, linuxppc-dev, Dave Liu, mingo, tglx
In-Reply-To: <51b3a75638604c9dd7ed60a10f0ed934@kernel.crashing.org>
On Sat, 2007-05-19 at 01:49 +0200, Segher Boessenkool wrote:
> > I find it extremely silly to implement it as edge anyway. The EE line
> > is
> > level triggered, and having a mix of edge and level on the same
> > exception without a clean way to retrigger the DEC one other than
> > waiting one tick is just causing trouble.
>
> It isn't edge triggered, it just automatically clears the
> decrementer exception condition at its source when taken
Which is exactly the same thing software-wise as edge triggered...
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox