On 12/10/2012 12:38 PM, Benjamin Herrenschmidt wrote:
On Mon, 2012-12-10 at 21:43 +, Grant Likely wrote:
Sorry for my pci ignorance (have never got hw for mb/zynq)
I just want to get better overview how we should we our drivers to
be compatible.
Does it mean that pci is supposed be
On 11/7/2011 10:09 AM, Robert Sciuk wrote:
In my continuing saga of dev/tree driver development, I have a problem which
might be obvious to those who have more experience in such matters.
I'm a bit perplexed on the tree nodes for the localbus/simplebus nodes for my
FPGA. CS0 is reserved for
On 11/25/2010 5:15 PM, Michael Ellerman wrote:
On Thu, 2010-11-25 at 09:17 -0700, Grant Likely wrote:
On Thu, Nov 25, 2010 at 6:34 AM, Michael Ellerman
mich...@ellerman.id.au wrote:
On Thu, 2010-11-25 at 01:03 +1100, Michael Ellerman wrote:
Hi all,
There were some murmurings on IRC last
One Laptop Per Child ships real Open Firmware on its x86 Linux systems,
of which approximately 2 million have been shipped or ordered. An ARM
version, also with OFW, is in the works.
OK. I don't see any code under arch/x86 or arch/arm that uses of_()
routines though? Or is it under drivers
In general I think it's better to report parameter values directly,
instead of inferring them from manufacturer and part numbers. That way
you at least have a fighting chance of avoiding a kernel upgrade when a
part changes.
Of course, that only works when the device tree is exported from
Grant Likely wrote:
On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock m...@freescale.com wrote:
On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock m...@freescale.com wrote:
Yes. Where would we get a list of memreserve
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good arguments to support
that opposition. Furthermore, the economic
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good arguments to support
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That
will not happen for several reasons. The opposition to the idea
is widespread and deeply held
Benjamin Herrenschmidt wrote:
On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote:
We use that to suck the device-tree, which we flatten, and then
re-enter
the kernel with the common entry interface.
I don't think I want to do the same on ARM. I'd rather have the
Russell King - ARM Linux wrote:
On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
Or perhaps the MMU and caches can be turned off for the duration of the
callback.
I don't have the details of ARM MMUs and caches reloaded into my head
yet. Maybe next week...
We've had
I shall try to clarify this discussion.
There are actually two different things being discussed. The first is,
I hope, not too controversial. The second is so controversial as to be
a hopeless cause.
First, the primary use case for keeping OFW alive is for debugging
purposes. OFW remains
Nicolas Pitre wrote:
On Mon, 14 Jun 2010, Mitch Bradley wrote:
First, the primary use case for keeping OFW alive is for debugging purposes.
OFW remains resident in memory so that, if the OS is set to allow it (not the
default), a hot-key freezes the OS and enters OFW, where a human can
Benjamin Herrenschmidt wrote:
On Sat, 2010-06-12 at 19:39 -1000, Mitch Bradley wrote:
Minimally, OFW needs to own some memory that the kernel won't steal.
OFW on ARM is position-independent, so it can be tucked up at the top of memory
fairly easily.
Amen :-)
To call back
Grant Likely wrote:
I also changed the property in the cpu nodes from model to compatible
so that the exact CPU version can be specified. This isn't actually
in any spec anywhere, but I need something to properly identify the
different ARM cores.
Mitch, I know you were working on a draft ARM
Benjamin Herrenschmidt wrote:
On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote:
On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote:
It seems that many of the differences at the CPU level can be determined
by looking at coprocessor registers. For what purpose(s) do
Grant Likely wrote:
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote:
I'm certainly going to try keeping OFW alive. On the x86 OLPC machines,
the ability to
dive into OFW via a SysRq key
Benjamin Herrenschmidt wrote:
On Fri, 2010-06-11 at 16:47 -0700, Dan Malek wrote:
Hi Grant.
On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
I've been doing a bit of work on some introductory level documentation
of the flattened device tree.
Wow, I feel empowered to create
Wow, there is some serious bikeshedding going on with this argument
about structures and arrays .
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Grant Likely wrote:
On Tue, May 25, 2010 at 2:09 AM, Martyn Welch martyn.we...@ge.com wrote:
Currently the irqs for the i8042, which historically provides keyboard and
mouse (aux) support, is hardwired in the driver rather than parsing the
dts. This patch modifies the powerpc legacy IO code
Timur Tabi wrote:
Grant Likely wrote:
Without the compatible property, the only way I'd know that the child node
contains a firmware is to look at the actual name of the child node, which (as
Scott and I believe) is not better than a compatible property.
If it is always a child of
Timur Tabi wrote:
Grant Likely wrote:
Nah. That looks totally fine. Not having the firmware under a qe
node would look bad to me.
You don't think it weird to have one QE node reference data from another QE
node, or that the DTS implies that the firmware belongs to one QE more than
It seems to me that there are plausible use cases for both
direct-inclusion and indirection. I don't see any real problems with
either, so I would vote for specifying both alternatives.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Most firmware is 8-12KB, so this will make for one ugly DTS. Plus, there's
the issue of distributing non-GPL firmware data inside a DTS, which is GPL.
You've got the distribution problem that needs to be solved regardless
because it cannot be part of U-Boot either. How do you plan to
Hi Anatolij,
[added cc: to devicetree-disc...@lists.ozlabs.org]
On Sat, Feb 27, 2010 at 2:58 PM, Anatolij Gustschin ag...@denx.de wrote:
Framebuffer drivers may want to get panel timing info
from the device tree. This patch adds appropriate support.
Subsequent patch for FSL DIU frame
Right, that's the only sane way to do it, I just didn't remember off
hand what was said in the OF spec :-)
3.2.2.1.2 Property values
The property-encoding format is independent of hardware byte order and
alignment characteristics. The encoded byte order is well-defined (in
particular,
Sun3 doesn't have OF
When I was first developing Open Boot for the SPARCstation-1, I was also
simultaneously trying to do it for a Sun-3 system that was being built
at the same time.
It proved to be too much to do both jobs at the same time, especially in
light of all the hardware
On Tue, 2009-08-18 at 14:21 +1000, Benjamin Herrenschmidt wrote:
So here's a followup to my discussion about the clock API.
Really nobody has a comment here ? :-) Not even Mitch ?
I refrained from commenting as I didn't want to get involved in an
endless argument about
Open Firmware often avoids indexed structures. Cases in point include
the use of named properties instead of fixed structures and named
methods instead of function pointer arrays. Open Firmware's use of
arrays for reg properties seems like the right choice for that
particular case,
One advantage of indices is that they avoid endless arguments about the
exact name (and spelling) of things.
Right, though in that case, nobody gets to have to decide on the name,
it comes from the chip manufacturer pin naming or data sheet.
I agree in general. It has long been
The idea of a wiki as a registration authority is a good one, but I'm
not volunteering to maintain it :-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, 2009-08-12 at 17:57 +1000, Benjamin Herrenschmidt wrote:
- Device-tree: The idea on top of my mind would be to define a
clock-map property that has the following format:
A list of:
- zero terminated string clock ID, padded with zeros
to a cell boundary
I'm running into a dilemma choosing between two approaches of defining device
tree binding. Let's say if we have several chips with a similar SoC block, but
each of them have different quirks. If I define different compatibles for each
of the chips, the driver will have a longer match table
n Mon, 08 Dec 2008 21:57:12 -1000
Mitch Bradley [EMAIL PROTECTED] wrote:
One address/size cell isn't enough for the next generation of NAND
FLASH chips.
I am no dts expert, but I thought I could put:
nand {
#address-cells = 1;
#size-cells
One address/size cell isn't enough for the next generation of NAND FLASH
chips.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Right. I had a similar discussion about this the other day with Anton (I
think he forwarded it here but I wasn't subscribed at that point..). The
current ideology for device trees is to get rid of device_type for new
trees that aren't OF-based. I think it's relevant to give nodes fancy
names
the convention that preassigned GPIOs must be
represented by subordinate nodes, and any GPIO that is not covered by a
subordinate node's reg property is implicitly available. That's the
way it works for other address spaces.
Mitch Bradley
Hi guys,
I'm a little perplexed as to how I would define a GPIO
Mitch Bradley wrote:
[snip]
You could adopt the convention that preassigned GPIOs must be
represented by subordinate nodes, and any GPIO that is not covered by
a subordinate node's reg property is implicitly available. That's
the way it works for other address spaces.
I like that idea
No, no, no, no, no. Making complex multi-level representations of
nested things for gpios is just insanity.
You know, I don't find this argument particularly compelling. But it
certainly is strongly worded.
Just use the same encoded
format as we already use for gpio descriptors in
Hi, I wrote most of 1275.
Mitch Bradley ([EMAIL PROTECTED])
David Miller wrote:
From: Grant Likely [EMAIL PROTECTED]
Date: Thu, 21 Aug 2008 22:18:56 -0600
On Thu, Aug 21, 2008 at 9:53 PM, David Miller [EMAIL PROTECTED] wrote:
Have patience with the embedded people that are both new
David Miller wrote:
From: Grant Likely [EMAIL PROTECTED]
Date: Thu, 21 Aug 2008 22:34:31 -0600
On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
[EMAIL PROTECTED] wrote:
On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley [EMAIL PROTECTED] wrote:
Hi, I wrote most of 1275.
Mitch
David Gibson wrote:
On Thu, Aug 14, 2008 at 12:43:48PM -0500, Scott Wood wrote:
On Thu, Aug 14, 2008 at 08:28:19AM -0500, Kumar Gala wrote:
- if (*path != '/')
- return -FDT_ERR_BADPATH;
+ /* see if we have an alias */
+ if (*path != '/') {
+
Segher Boessenkool wrote:
It's not what we do with flattened device trees blobs though. In the
flattened tree we're not using a /chosen/stdout property, just the
linux,stdout-path one.
The question that remains is; should there be? Should the dt blobs
use /chosen/stdout also? (I'm not
Signed-off-by: Mitch Bradley [EMAIL PROTECTED]
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index f86e069..b83b26c 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -7,6 +7,10 @@
* Revised to handle newer style flash binding by:
* Copyright (C) 2007 David Gibson, IBM
A revised version of the patch, addressing some points that Segher
identified, will be issued soon.
So if you want to review the patch as submitted, please be aware that
some stylistic things have already been fixed (u64 instead of u_int64_t
etc, use of of_read_number(), removal of fallback code
David Gibson wrote:
On Thu, Jun 26, 2008 at 01:50:40PM -1000, Mitch Bradley wrote:
This patch modifes ofpart.c so the total size of NAND FLASH
and the size of an individual partition can exceed 4GiB. It does so
by decoding the reg property based on the values of #address-cells
and #size
David Gibson wrote:
On Thu, Jun 26, 2008 at 05:28:42PM -1000, Mitch Bradley wrote:
David Gibson wrote:
On Thu, Jun 26, 2008 at 01:50:40PM -1000, Mitch Bradley wrote:
[snip]
+ const u_int32_t *propval;
+ u_int32_t addrcells = 0, sizecells = 0
47 matches
Mail list logo
