> -Original Message-
> From: devicetree-discuss-bounces+stuart.yoder=freescale@lists.ozlabs.org
> [mailto:devicetree-discuss-bounces+stuart.yoder=freescale@lists.ozlabs.org]
> On Behalf Of
> David Gibson
> Sent: Monday, October 24, 2011 6:15 PM
> To: Kumar Gala
> Cc: devicetree-d
> -Original Message-
> From: Meador Inge [mailto:mead...@gmail.com]
> Sent: Thursday, February 10, 2011 9:26 PM
> To: Benjamin Herrenschmidt
> Cc: Yoder Stuart-B08248; devicetree-discuss@lists.ozlabs.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v3 0
> -Original Message-
> From: devicetree-discuss-
> bounces+stuart.yoder=freescale@lists.ozlabs.org [mailto:devicetree-
> discuss-bounces+stuart.yoder=freescale@lists.ozlabs.org] On Behalf Of
> Benjamin Herrenschmidt
> Sent: Monday, February 07, 2011 3:46 PM
> To: Meador Inge
> Cc:
> -Original Message-
> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
> Likely
> Sent: Monday, February 07, 2011 3:45 PM
> To: Benjamin Herrenschmidt
> Cc: pa...@power.org; devicetree-discuss; David Gibson; Yoder Stuart-B08248;
> McCl
> > + - no-reset
> > + Usage: optional
> > + Value type:
> > + Definition: The presence of this property indicates that the
> > + PIC
> > + should not be reset during runtime initialization. The
> > + presence of
> > + this property also mandates that any initia
> -Original Message-
> From: Meador Inge [mailto:meador_i...@mentor.com]
> Sent: Wednesday, January 19, 2011 6:08 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; devicetree-
> disc...@lists.ozlabs.org; Blanchard, Hollis
> Su
> +** Optional properties:
> +
> + - no-reset : The presence of this property indicates that the MPIC
> + should not be reset during runtime initialization.
> + - protected-sources : Specifies a list of interrupt sources that are
> + not
> + available for
> -Original Message-
> From: Meador Inge [mailto:meador_i...@mentor.com]
> Sent: Wednesday, January 19, 2011 2:25 PM
> To: Yoder Stuart-B08248
> Cc: linuxppc-...@lists.ozlabs.org; devicetree-discuss@lists.ozlabs.org;
> Blanchard, Hollis
> Subject: Re: [PATCH 1/2]
> From: Meador Inge
> Date: Mon, Jan 17, 2011 at 6:52 PM
> Subject: [PATCH 1/2] powerpc: document the MPIC device tree binding
> To: linuxppc-...@lists.ozlabs.org
> Cc: minge ,
> devicetree-discuss@lists.ozlabs.org, "Blanchard, Hollis"
>
>
>
> This binding documents several properties that have
> -Original Message-
> From: Meador Inge [mailto:meador_i...@mentor.com]
> Sent: Monday, January 17, 2011 7:21 PM
> To: Yoder Stuart-B08248
> Cc: linuxppc-...@lists.ozlabs.org; devicetree-discuss@lists.ozlabs.org;
> Blanchard, Hollis; Meador Inge
> Subject: Re: [PATC
> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, September 13, 2010 1:18 PM
> To: Yoder Stuart-B08248
> Cc: pa...@power.org; devicetree-discuss
> Subject: Re: [Power.org:parch] ePAPR 1.1 to do list
>
> On Mon, 30 Aug 2010 14:34:44 -0700
>
Mitch,
In the dma-ranges proposal:
http://playground.sun.com/1275/proposals/Closed/Accepted/410-it.txt
...there is the following special case described:
As a special case, a "dma-ranges" property may be present in the
root node of the device tree. In this case, the property value
desc
> -Original Message-
> From: David VomLehn [mailto:dvoml...@cisco.com]
> Sent: Monday, October 25, 2010 3:41 PM
> To: Yoder Stuart-B08248
> Cc: dev...@dvomlehn-lnx2.corp.sa.net; t...@dvomlehn-lnx2.corp.sa.net;
> mail...@dvomlehn-lnx2.corp.sa.net; l...@dvomleh
> -Original Message-
> From: devicetree-discuss-
> bounces+stuart.yoder=freescale@lists.ozlabs.org
[mailto:devicetree-
> discuss-bounces+stuart.yoder=freescale@lists.ozlabs.org] On Behalf
Of
> David VomLehn
> Sent: Friday, October 22, 2010 4:45 PM
> To: dev...@dvomlehn-lnx2.corp.s
-Scott Wood, Dan Hettena, and myself discussed IMAs and have
a proposal for ePAPR 1.1
-there are a number of issues/questions/inconsistencies around IMAs
(initial mapped areas) as described in ePAPR 1.0
-5.3 says IMAs are applicable to book III-E only, but
in 5.4.4 real mode CPUs have
I've consolidated what I am aware of with respect to errors found in
1.0,
clarifications needed, and new mechanisms to go into ePAPR 1.1 into
a single list.
Let me know if you are aware of anything else.
ePAPR 1.1 To Do
---
1. Fix typos, misc cleanup
-device_type="simple-bus" in
There is no standard binding for how hardware threads
(which in most cases share an MMU) for the Power
architecture are represented in device trees.
The IBM SPAPR uses the ibm,ppc-interrupt-server#s.
property, which is an array with 1 element per thread. The
number is used in addressing by the i
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Monday, August 16, 2010 11:02 AM
> To: devicetree-discuss
> Cc: Yoder Stuart-B08248
> Subject: standard property to convey device dma address width?
>
> Do we or should we hav
> MediaWiki does support XML exporting for off-line editing (one of the
> reasons I chose mediawiki), so we could have a canned xml export of
> approved bindings into a git repo somewhere. Being able to generate
> an off-line copy is something I think is important.
If there are ways to export th
> Device tree 'bindings' document how individual devices are described
> in the device tree. For any given device, the binding says what
> properties and nodes a device driver needs to use the device.
>
> This page documents the process for writing and reviewing new
> bindings. New bindings are
Some questions have come up recently regarding how
CPUs and hardware threads are represented in device
trees. This has come up in the context of the embedded
hypervisor committee in power.org working on some
interrupt controller APIs, but is really a general
issue. We had some side discussions w
> > That still leaves node and property deletion to cover. In keeping
> > with the above approach, I'd like to do that in the form of
> "negative
> > redefinitions" of properties or nodes. A neat syntax for
> that doesn't
> > immediately occur to be for that yet, though.
>
> hmmm. I'll think
> -Original Message-
> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On
> Behalf Of Grant Likely
> Sent: Wednesday, January 13, 2010 12:04 AM
> To: Wood Scott-B07421
> Cc: David Gibson; Yoder Stuart-B08248;
> devicetree-discuss@lists.ozlabs.org;
> -Original Message-
> From:
> devicetree-discuss-bounces+stuart.yoder=freescale@lists.oz
labs.org [mailto:devicetree-discuss->
bounces+stuart.yoder=freescale@lists.ozlabs.org] On
> Behalf Of Segher Boessenkool
> Sent: Tuesday, January 12, 2010 12:18 PM
> -Original Message-
> From:
> devicetree-discuss-bounces+stuart.yoder=freescale@lists.oz
labs.org [mailto:devicetree-discuss->
bounces+stuart.yoder=freescale@lists.ozlabs.org] On
> Behalf Of David Gibson
> Sent: Wednesday, January 06, 2010 10:55 PM
> To
> -Original Message-
> From:
> devicetree-discuss-bounces+stuart.yoder=freescale@lists.oz
labs.org [mailto:devicetree-discuss->
bounces+stuart.yoder=freescale@lists.ozlabs.org] On
> Behalf Of David Gibson
> Sent: Wednesday, January 06, 2010 6:51 PM
> To
The current open-pic binding defines that interrupt specifiers
have 2 cells-- an interrupt number and level/sense encoding.
With chips like the P4080 this is no longer sufficient to
represent the various types of interrupt sources handled by
the interrupt controller. A linear list of interrupt n
> -Original Message-
> From:
> devicetree-discuss-bounces+stuart.yoder=freescale@lists.oz
labs.org [mailto:devicetree-discuss->
bounces+stuart.yoder=freescale@lists.ozlabs.org] On
> Behalf Of John Schmoller
> Sent: Wednesday, December 30, 2009 10:58 AM
> To: devicetree-discuss@
On Mon, Nov 23, 2009 at 2:57 AM, Kumar Amarjit
wrote:
>
> Hi All,
> We are using PowerPc440 core on our Soc that consists of PCIe core,
SAS core and many other things.
> We are writing DTS for our board to be used during booting, we have
gone through various dts files available inside the Linux
29 matches
Mail list logo
