of tree1 tests.
The fact that you can only apply a single label by this method is a
bit of a wart, but it's something we can fix later. I had a look at
it and (as I suspect you already discovered) it's surprisingly
complicated to do so.
--
David Gibson| I'll have my music baroque
On Thu, Jan 29, 2015 at 09:07:31PM +1100, David Gibson wrote:
On Wed, Jan 28, 2015 at 08:20:11PM +0530, Nikhil Devshatwar wrote:
This patch changes the dtc grammar to allow following syntax
i2cexp: i2c2 {
...
};
Current device tree compiler allows to define multiple labels
, and the implementation looks fine.
Only 2 things before I'm ready to merge:
1) It wants a testcase
2) I need to stare at the syntax for a while and convince myself
it's as good as we can reasonably do.
--
David Gibson| I'll have my music baroque, and my code
david
ahead!
Benoit,
Sorry, I meant to ask earlier but forgot.
Shouldn't this development be based on the
upstream DTC repository and not the in-kernel
copy of the DTC?
Absolutely. Please work against upstream dtc.
--
David Gibson| I'll have my music baroque, and my
between a binding document and a formal schema
is that a binding defines both the syntax required of a node, and its
semantics, whereas a schema defines only syntax - the semantics still
need to be defined somewhere.
--
David Gibson| I'll have my music baroque, and my code
david
the schema
language needs to be substantially more flexible than the draft
presented here.
While I think a schema syntax which mirrors dts syntax makes a lot of
sense, actually defining schemas as device trees doesn't seem quite
right to me.
--
David Gibson| I'll have my music
;
+
+ free_node_list(bi-dt);
+ free(bi);
+}
--
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
pgpIqVVeRdOcK.pgp
-parent or interrupt-map
--
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
pgpODmqrjd5GL.pgp
Description: PGP
On Wed, Oct 02, 2013 at 07:08:41PM +0100, Mark Brown wrote:
On Wed, Oct 02, 2013 at 11:54:50PM +1000, David Gibson wrote:
On Tue, Oct 01, 2013 at 03:54:20PM -0500, Rob Herring wrote:
I would expect the schema to replace
Documentation/devicetree/bindings/* over time. I think the thing
On Wed, Jan 23, 2013 at 01:01:58PM +0200, Pantelis Antoniou wrote:
On Jan 23, 2013, at 7:12 AM, David Gibson wrote:
On Tue, Jan 22, 2013 at 01:08:04PM +0200, Pantelis Antoniou wrote:
Hi
On Jan 22, 2013, at 5:50 AM, David Gibson wrote:
On Fri, Jan 04, 2013 at 09:31:10PM +0200
On Tue, Jan 22, 2013 at 01:06:09PM +0200, Pantelis Antoniou wrote:
Hi
On Jan 22, 2013, at 6:05 AM, David Gibson wrote:
On Mon, Jan 21, 2013 at 12:59:15PM +0200, Pantelis Antoniou wrote:
Hi David
On Jan 21, 2013, at 6:48 AM, David Gibson wrote:
On Fri, Jan 04, 2013 at 09:31:09PM
On Tue, Jan 22, 2013 at 01:08:04PM +0200, Pantelis Antoniou wrote:
Hi
On Jan 22, 2013, at 5:50 AM, David Gibson wrote:
On Fri, Jan 04, 2013 at 09:31:10PM +0200, Pantelis Antoniou wrote:
Introduce DT overlay support.
Using this functionality it is possible to dynamically overlay a part
is in the live tree format, but it still needs a bunch of extra
mangling. Would it simplify things to just go straight from the
overlay in flat tree form to modifications to the system-wide live
tree.
--
David Gibson| I'll have my music baroque, and my code
david
On Mon, Jan 21, 2013 at 12:59:15PM +0200, Pantelis Antoniou wrote:
Hi David
On Jan 21, 2013, at 6:48 AM, David Gibson wrote:
On Fri, Jan 04, 2013 at 09:31:09PM +0200, Pantelis Antoniou wrote:
Introduce support for dynamic device tree resolution.
Using it, it is possible to prepare
*resolve);
+
+#else
+
+static inline int of_resolve(struct device_node *resolve)
+{
+ return -ENOTSUPP;
+}
+
+#endif
+
#endif /* _LINUX_OF_H */
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you
like interrupt-map
where possible, rather than having a very general, but very low-level
interface to make arbitrary changes to the DT.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
On Tue, Nov 13, 2012 at 10:09:28AM +0200, Pantelis Antoniou wrote:
Hi David,
On Nov 13, 2012, at 9:25 AM, David Gibson wrote:
On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote:
On 11/12/2012 05:10 AM, Pantelis Antoniou wrote:
[snip]
Oh yes. In fact if one was to use
identify all the types that will need special handling.
For example for our cape use, we already have references that do not
follow this example.
A generic way to resolve references is what we need.
Hrm... *mutters dubiously*.
--
David Gibson| I'll have my music baroque
On Fri, Nov 09, 2012 at 09:08:14PM +, Grant Likely wrote:
On Fri, Nov 9, 2012 at 2:26 AM, David Gibson
da...@gibson.dropbear.id.au wrote:
Summary points:
- Create an FDT overlay data format and usage model
- SHALL reliable resolve or validate of phandles between base
On Fri, Nov 09, 2012 at 09:42:37PM +, Grant Likely wrote:
On Fri, Nov 9, 2012 at 2:26 AM, David Gibson
da...@gibson.dropbear.id.au wrote:
(3) Resolving phandle references from the subtree to the main tree.
So, I think this can actually be avoided, at least in cases where what
not too long to store, but changing to paths would break years
of existing OF practice.
--
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
On Mon, Nov 12, 2012 at 10:22:07PM -0700, Stephen Warren wrote:
On 11/12/2012 06:05 PM, David Gibson wrote:
On Fri, Nov 09, 2012 at 09:42:37PM +, Grant Likely wrote:
...
2) graft bundle
The base tree has something like this:
...
i2c@XXX
dependencies except libc, so that really shouldn't be too
bad. In return we entirely avoid inventing a new phandle resolution
protocol.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
the index of all other nodes in the string block as well.. Hmm.
--
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
to distinguish them, we can just use
socket local mmio addresses within the subtree and the ranges property
here will sort that out.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
On Sat, Jul 14, 2012 at 07:07:17AM -1000, Mitch Bradley wrote:
On 7/14/2012 6:37 AM, David Gibson wrote:
On Fri, Jul 13, 2012 at 07:30:42PM -1000, Mitch Bradley wrote:
I'm not sure this is really a good use of aliases. UARTs use aliases
because it is important that the UART number to tty
.
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap
On Tue, Aug 30, 2011 at 12:27:24PM +0300, Felipe Balbi wrote:
Hi,
On Tue, Aug 30, 2011 at 12:29:12PM +1000, David Gibson wrote:
So, I actually agree that in the long term getting resource names in
the DT would be a generally good thing.
But doing so is a *huge* change in one
On Fri, Aug 26, 2011 at 04:13:15PM +0200, Cousson, Benoit wrote:
On 8/26/2011 12:58 PM, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
Seriously, how many times do I have to say it?
[...]
Insisting that the names come from the DT is to mistakenly think of
the DT
On Sat, Aug 27, 2011 at 08:13:59PM +0200, Arnd Bergmann wrote:
On Sunday 28 August 2011 00:37:36 David Gibson wrote:
On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
On Friday 26 August 2011, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
If you
On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
On Friday 26 August 2011, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
If you open code it this way then yes, it's silly. But what about
something like this:
static struct of_device_id
On Fri, Aug 26, 2011 at 12:58:32PM +0200, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
Seriously, how many times do I have to say it?
Using _byname in drivers DOES NOT require adding names to the DT.
All it needs is some glue logic to attach names
.
Insisting that the names come from the DT is to mistakenly think of
the DT as an extension of the kernel's internal interfaces, instead of
as the external and OS neutral data structure it actually is.
--
David Gibson| I'll have my music baroque, and my code
david
On Thu, Aug 11, 2011 at 02:28:55PM +0200, Cousson, Benoit wrote:
On 8/10/2011 9:22 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:49 PM, Grant Likely wrote
translates the
DT reg entries into the Linux resource structures.
The difficulty with adding th enames to the DT itself is that it
exposes the essentially Linux-specific names in what's supposed to be
an OS neutral data structure.
--
David Gibson| I'll have my music baroque, and my
to just have a static place to
name mapping in the Linux driver.
In short, yes, named reg elements in the DT would be nice in theory,
but I'm not convinced it's worth a DT flag day to accomplish it.
--
David Gibson| I'll have my music baroque, and my code
david
36 matches
Mail list logo
