RE: Add some documentation for the dts formta

Signed-off-by: Stuart Yoder <[EMAIL PROTECTED]> > -Original Message- > From: David Gibson [mailto:[EMAIL PROTECTED] > Sent: Monday, March 10, 2008 6:47 PM > To: Loeliger Jon > Cc: Yoder Stuart; linuxppc-dev@ozlabs.org > Subject: dtc: Add some documentation for

ePAPR 1.0 is published

The ePAPR 1.0 spec is officially published and available on the power.org website. One purpose of the spec is to more formally specify in one place the flat device tree concept defined booting_without_of.txt plus the releva

RE: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of David Gibson > Sent: Thursday, August 07, 2008 1:13 AM > To: Tabi Timur > Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [RFC/PATCH 2/3] of: add of_lookup_stdout(

RE: [PATCH 0/3]: Sparc OF I2C support.

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Mitch Bradley > Sent: Friday, August 22, 2008 12:19 AM > To: David Miller > Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Wood Scott > Subject: Re: [PATCH 0/3]: Sparc OF I2

pci overmapping

Kumar, In fsl_pci.c there is a change you made a while back: "powerpc/fsl: Setup PCI inbound window based on actual amount of memory" ...and there is this comment in the code: /* PCIe can overmap inbound & outbound since RX & TX are separated */ if (early_find_capability(hose, 0, 0, PC

RE: [PATCH][v2] KVM: PPC: add paravirt idle loop for 64-bit book E

> -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, January 24, 2013 12:22 PM > To: Yoder Stuart-B08248 > Cc: ag...@suse.de; b...@kernel.crashing.org; linuxppc-...@ozlabs.org; > kvm-...@vger.kernel.org; > k...@vger.kernel.org; Yoder Stuart-B08248 >

RE: [PATCH 2/2] powerpc/85xx: describe the PAMU topology in the device tree

> -Original Message- > From: Gala Kumar-B11780 > Sent: Wednesday, January 23, 2013 11:27 AM > To: Wood Scott-B07421; Yoder Stuart-B08248 > Cc: linuxppc-...@ozlabs.org list; Timur Tabi > Subject: Re: [PATCH 2/2] powerpc/85xx: describe the PAMU topology in the > devic

RE: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.

@vger.kernel.org list; Wood Scott-B07421; Yoder > Stuart-B08248; Joerg Roedel; Paul > Mackerras; David Gibson; Alex Williamson > Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer > in archdata. > > btw the device struct already has a pointer to its io

RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.

> -Original Message- > From: Sethi Varun-B16395 > Sent: Monday, March 04, 2013 5:31 AM > To: Stuart Yoder > Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; > linux-ker...@vger.kernel.org; Wood > Scott-B07421; Joerg Roedel; Yoder Stuart-B08248 &g

RE: [PATCH][v2] powerpc/e6500: Add Power ISA properties for e6500 cores

> -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, March 05, 2013 2:29 PM > To: Yoder Stuart-B08248 > Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Yoder > Stuart-B08248 > Subject: Re: [PATCH][v2] powerpc/e6500: Add Power ISA properti

RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.

..@vger.kernel.org; b...@kernel.crashing.org; Wood Scott-B07421; Yoder > Stuart-B08248 > Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu > implementation. > > > On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote: > > > +/* > > + * Table of SVRs and the correspond

RE: [Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig

> -Original Message- > From: Michael Neuling [mailto:mi...@neuling.org] > Sent: Thursday, March 21, 2013 6:21 PM > To: Chen Gang F T; Yoder Stuart-B08248; Kumar Gala > Cc: Chen Gang; Benjamin Herrenschmidt; s...@canb.auug.org.au; > pau...@samba.org; m...@ozlabs.

RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.

> -Original Message- > From: Sethi Varun-B16395 > Sent: Thursday, March 28, 2013 2:54 PM > To: j...@8bytes.org; Yoder Stuart-B08248; Wood Scott-B07421; > io...@lists.linux-foundation.org; linuxppc- > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; > ga...@k

RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.

> -Original Message- > From: Sethi Varun-B16395 > Sent: Wednesday, April 03, 2013 12:12 AM > To: Wood Scott-B07421; Timur Tabi > Cc: Joerg Roedel; lkml; Kumar Gala; Yoder Stuart-B08248; > io...@lists.linux-foundation.org; Benjamin > Herrenschmidt; linuxppc-dev@lists

RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, April 04, 2013 10:22 AM > To: Sethi Varun-B16395 > Cc: Joerg Roedel; Yoder Stuart-B08248; Wood Scott-B07421; > io...@lists.linux-foundation.org; linuxppc- > d...@li

RE: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver.

ernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart-B08248; > Wood Scott-B07421 > Subject: Re: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes > required by the PAMU driver. > > On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote: > > Added the following domain attributes

RE: [PATCH] powerpc: set stack limit properly in crit_transfer_to_handler

> -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Monday, July 16, 2012 3:36 PM > To: Yoder Stuart-B08248 > Cc: b...@kernel.crashing.org; s...@canb.auug.org.au; pau...@samba.org; > linuxppc-dev@lists.ozlabs.org; > ag...@suse.de

RE: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding

> -Original Message- > From: linuxppc-release-boun...@linux.freescale.net [mailto:linuxppc-release- > boun...@linux.freescale.net] On Behalf Of Jia Hongtao-B38951 > Sent: Thursday, February 16, 2012 8:49 PM > To: linuxppc-dev@lists.ozlabs.org > Cc: meador_i...@mentor.com; Li Yang-R58472;

RE: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding

> -Original Message- > From: Wood Scott-B07421 > Sent: Friday, February 17, 2012 6:48 PM > To: Yoder Stuart-B08248 > Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; > meador_i...@mentor.com; Li Yang-R58472 > Subject: Re: [linuxppc-release] [PATCH 1/2] powe

pci node question

There was refactoring change a while back that moved the interrupt map down into the virtual pci bridge. example: 42 /* controller at 0x20 */ 43 &pci0 { 44 compatible = "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2"; 45 device_type = "pci"; 46 #size-cells = <2>; 47 #

RE: pci node question

> -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Friday, April 20, 2012 1:54 PM > To: Yoder Stuart-B08248 > Cc: linuxppc-dev@lists.ozlabs.org > Subject: Re: pci node question > > > On Apr 20, 2012, at 1:37 PM, Yoder Stuart

RE: pci node question

> -Original Message- > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] > Sent: Friday, April 20, 2012 4:11 PM > To: Kumar Gala > Cc: Yoder Stuart-B08248; linuxppc-dev@lists.ozlabs.org > Subject: Re: pci node question > > On Fri, 2012-04-20 at 13:53

RE: pci node question

> -Original Message- > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] > Sent: Monday, April 23, 2012 3:22 PM > To: Yoder Stuart-B08248 > Cc: Kumar Gala; linuxppc-dev@lists.ozlabs.org > Subject: RE: pci node question > > On Mon, 2012-04-23 at 1

RE: [PATCH][v2] PPC: use CURRENT_THREAD_INFO instead of open coded assembly

> -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Monday, July 02, 2012 4:16 PM > To: Yoder Stuart-B08248 > Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH][v2] PPC: use CURRENT_THREAD_INFO instead of open

RE: linux-next: build failure after merge of the kvm-ppc tree

> -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Thursday, July 05, 2012 1:03 AM > To: Stephen Rothwell > Cc: linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; Yoder > Stuart-B08248; ppc-dev > Subject: Re: linux-next: build failu

RE: [PATCH] define binding for fsl mpic interrupt controllers

> -Original Message- > From: Meador Inge [mailto:meador_i...@mentor.com] > Sent: Monday, January 17, 2011 7:21 PM > To: Yoder Stuart-B08248 > Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org; > Blanchard, Hollis; Meador Inge > Subject: Re: [PATC

RE: [PATCH 1/2] powerpc: document the MPIC device tree binding

> 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-dev@lists.ozlabs.org > Cc: minge , > devicetree-disc...@lists.ozlabs.org, "Blanchard, Hollis" > > > > This binding documents several properties that have

RE: [PATCH 1/2] powerpc: document the MPIC device tree binding

> -Original Message- > From: Meador Inge [mailto:meador_i...@mentor.com] > Sent: Wednesday, January 19, 2011 2:25 PM > To: Yoder Stuart-B08248 > Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org; > Blanchard, Hollis > Subject: Re: [PATCH 1/2]

RE: [PATCH 1/2] powerpc: document the MPIC device tree binding

> +** 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

RE: [PATCH 1/2] powerpc: document the MPIC device tree binding

> -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-dev@lists.ozlabs.org; devicetree- > disc...@lists.ozlabs.org; Blanchard, Hollis > Su

RE: [PATCH v2 2/3] powerpc: document the Open PIC device tree binding

> > +  - 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

RE: [PATCH v3 1/4] powerpc: Removing support for 'protected-sources'

> -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:

RE: [PATCH v3 0/4] powerpc: Open PIC binding and "pic-no-reset"

> -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-disc...@lists.ozlabs.org; linuxppc- > d...@lists.ozlabs.org > Subject: Re: [PATCH v3 0

RFC: top level compatibles for virtual platforms

With KVM on Freescale booke parts we have currently two general types of virtual platforms-- 1) an 85xx-like platform with e500v2 cpus, etc, and 2) a P4080-like platform with a corenet based bus. Today QEMU passes through to the guest a device tree with a top level compatible of either "MPC8544DS"

RE: RFC: top level compatibles for virtual platforms

> -Original Message- > From: Tabi Timur-B04825 > Sent: Friday, July 08, 2011 8:39 PM > To: Yoder Stuart-B08248 > Cc: Grant Likely; Benjamin Herrenschmidt; Gala Kumar-B11780; Wood > Scott-B07421; Alexander > Graf; linuxppc-...@ozlabs.org > Subject: Re: RFC: t

RE: RFC: top level compatibles for virtual platforms

> -Original Message- > From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant > Likely > Sent: Friday, July 08, 2011 9:42 PM > To: Tabi Timur-B04825 > Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala > Kumar-B11780;

RE: RFC: top level compatibles for virtual platforms

> -Original Message- > From: Wood Scott-B07421 > Sent: Monday, July 11, 2011 11:24 AM > To: Tabi Timur-B04825 > Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala > Kumar-B11780; Wood Scott- > B07421; Alexander Graf; linuxppc-...@ozlabs.org > Sub

RE: RFC: top level compatibles for virtual platforms

> -Original Message- > From: Wood Scott-B07421 > Sent: Monday, July 11, 2011 1:05 PM > To: Yoder Stuart-B08248 > Cc: Wood Scott-B07421; Tabi Timur-B04825; Grant Likely; Benjamin > Herrenschmidt; Gala Kumar- > B11780; Alexander Graf; linuxppc-...@ozlabs.org > Sub

RE: RFC: top level compatibles for virtual platforms

> -Original Message- > From: Wood Scott-B07421 > Sent: Monday, July 11, 2011 4:07 PM > To: Yoder Stuart-B08248 > Cc: Wood Scott-B07421; Tabi Timur-B04825; Grant Likely; Benjamin > Herrenschmidt; Gala Kumar- > B11780; Alexander Graf; linuxppc-...@ozlabs.org > Sub

RFC: replace device_type with new "class" property?

We've had some discussions internally here at Freescale among various PPC Linux developers about the device_type property and how 'classes' of devices should be represented in the device tree. Taking a long term view, the question I'd like to pose is how should classes of device should be identi

RE: RFC: replace device_type with new "class" property?

Here's an example of what I'm trying to get at-- take a node from a FSL device tree. The ideas I've heard for expressing the class are like this-- #1 don't express any class at all: [EMAIL PROTECTED] { compatible = "fsl,ucc_geth"; model = "UCC"; device-id = <3>;

RE: RFC: replace device_type with new "class" property?

> -Original Message- > From: Wood Scott-B07421 > Sent: Monday, October 29, 2007 2:44 PM > To: Yoder Stuart-B08248 > Cc: Matt Sealey; Dale Farnsworth; Linuxppc-dev@ozlabs.org > Subject: Re: RFC: replace device_type with new "class" property? > > Yoder

RE: RFC: replace device_type with new "class" property?

> -Original Message- > From: David Gibson [mailto:[EMAIL PROTECTED] > Sent: Monday, October 29, 2007 7:52 PM > To: Olof Johansson > Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org > Subject: Re: RFC: replace device_type with new "class" property? >

RE: RFC: replace device_type with new "class" property?

> Explicitly specifying what device class bindings / conventions the > node complies with is cute, but not actually all that useful in > practice. If it looks like a "duck" class device node, and it > quacks^Whas the properties of a "duck" class device node, it's "duck" > class compliant. Don't

RE: RFC: replace device_type with new "class" property?

> -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, October 30, 2007 11:34 AM > To: Yoder Stuart-B08248 > Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org > Subject: Re: RFC: replace device_type with new "class" property? > >

RE: RFC: replace device_type with new "class" property?

> > 1. There are types of nodes that don't have a programming > > inteface per se and thus no compatible. > > "cpu", "memory", "cache" are 3 that come to mind. > > Well, yes, this is why I suggested treating these "fundamental" nodes > as a special case in an earlier mail. Given your st

RE: RFC: replace device_type with new "class" property?

> > I think what we should do is keep device_type, including > > permitting new uses of it in a limited way-- only permitting > > the use of device_type when there is an official binding > > (like in the power.org ePAPR) defined. > > That's what I was thinking when we first started defining

RE: Refactor booting-without-of.txt

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Grant Likely > Sent: Monday, October 15, 2007 11:09 AM > To: linuxppc-dev; [EMAIL PROTECTED] > Subject: Refactor booting-without-of.txt > > Adding the Linux expected device tree bindings to > boo

RE: RFC: replace device_type with new "class" property?

> -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, October 31, 2007 12:06 PM > To: Yoder Stuart-B08248 > Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org > Subject: Re: RFC: replace device_type with new "class" property? > >

RE: [PATCH 3/3] First cut at PReP support for arch/powerpc

> > > > + MPIC: [EMAIL PROTECTED] { > > > > + device_type = "open-pic"; > > > > > > > > device_type = "interrupt-controller". > > > > Not according to the binding in booting-without-of.txt > > My understanding here, though possibly flawed, is that the current

RE: [PATCH v2][POWERPC] document ipic level/sense info

> -Original Message- > From: Segher Boessenkool [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 10, 2007 8:21 AM > To: Grant Likely > Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] > Subject: Re: [PATCH v2][POWERPC] document ipic level/sense info

RE: [RFC][PATCH 6/8] Walnut DTS

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Segher Boessenkool > Sent: Wednesday, July 11, 2007 12:50 PM > To: Josh Boyer > Cc: linuxppc-dev@ozlabs.org > Subject: Re: [RFC][PATCH 6/8] Walnut DTS > > > + UIC0: interrupt-controller0 { > >

RE: [PATCH 1/2] Kernel: Move all technical descriptons of the DeviceTree Complier

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Paul Mackerras > Sent: Wednesday, July 11, 2007 10:42 PM > To: Loeliger Jon-LOELIGER > Cc: linuxppc-dev@ozlabs.org; Jon Loeliger > Subject: Re: [PATCH 1/2] Kernel: Move all technical > descripton

RE: [RFC][PATCH 6/8] Walnut DTS

[snip] > There is no child device node, but there are child interrupt > nodes, and > since the interrupt-tree uses #address/size-cells, it does make some > sense to specify them. > > Yes, there is a default value when absent, but the simple > fact that the > default is different depending if yo