RE: Add some documentation for the dts formta

[Yoder Stuart]

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 the dts formta
> 
> This patch adds a dts-format.txt in the Documentation directory, with
> an introduction to the dtc source format.  Note that this
> documentation is also going into the upcoming ePAPR specification.
> 
> Signed-off-by: David Gibson <[EMAIL PROTECTED]>
> 
> ---
>  Documentation/dts-format.txt |  110 
> +++
>  1 file changed, 110 insertions(+)
> 
> I wrote this documentation based on an earlier draft from Stuart
> Yoder.  Stuart, can you please reply with a Signed-off-by line?
> 
> Index: dtc/Documentation/dts-format.txt
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ dtc/Documentation/dts-format.txt  2008-03-11 
> 10:42:17.0 +1100
> @@ -0,0 +1,110 @@
> +Device Tree Source Format (version 1)
> +=
> +
> +The Device Tree Source (DTS) format is a textual representation of a
> +device tree in a form that can be processed by dtc into a binary
> +device tree in the form expected by the kernel.  The 
> description below
> +is not a formal syntax definition of DTS, but describes the basic
> +constructs used to represent device trees.
> +
> +Node and property definitions
> +-
> +
> +Device tree nodes are defined with a node name and unit address with
> +braces marking the start and end of the node definition.  They may be
> +preceded by a label.
> +
> + [label:] [EMAIL PROTECTED] {
> + [properties definitions]
> + [child nodes]
> + }
> +
> +Nodes may contain property definitions and/or child node
> +definitions. If both are present, properties must come before child
> +nodes.
> +
> +Property definitions are name value pairs in the form:
> + [label:] property-name = value;
> +except for properties with empty (zero length) value which have the
> +form:
> + [label:] property-name;
> +
> +Property values may be defined as an array of 32-bit integer 
> cells, as
> +NUL-terminated strings, as bytestrings or a combination of these.
> +
> +* Arrays of cells are represented by angle brackets surrounding a
> +  space separated list of C-style integers
> +
> + e.g. interrupts = <17 0xc>;
> +
> +* A 64-bit value is represented with two 32-bit cells.
> +
> + e.g. clock-frequency = <0x0001 0x>;
> +
> +* A NUL-terminated string value is represented using double quotes
> +  (the property value is considered to include the terminating NUL
> +  character).
> +
> + e.g. compatible = "simple-bus";
> +
> +* A bytestring is enclosed in square brackets [] with each byte
> +  represented by two hexadecimal digits.  Spaces between 
> each byte are
> +  optional.
> +
> + e.g. local-mac-address = [00 00 12 34 56 78]; or equivalently
> +  local-mac-address = [12345678];
> +
> +* Values may have several comma-separated components, which are
> +  concatenated together.
> + e.g. compatible = "ns16550", "ns8250";
> +  example = <0xf00f 19>, "a strange property format";
> +
> +* In a cell array a reference to another node will be 
> expanded to that
> +  node's phandle.  References may by '&' followed by a node's label:
> + e.g. interrupt-parent = < &mpic >;
> +  or they may be '&' followed by a node's full path in braces:
> + e.g. interrupt-parent = < &{/soc/[EMAIL PROTECTED] >;
> +
> +* Outside a cell array, a reference to another node will be expanded
> +  to that node's full path.
> + e.g. ethernet0 = &EMAC0;
> +
> +* Labels may also appear before or after any component of a property
> +  value, or between cells of a cell array, or between bytes of a
> +  bytestring.
> + e.g. reg = reglabel: <0 sizelabel: 0x100>;
> + e.g. prop = [ab cd ef byte4: 00 ff fe];
> + e.g. str = start: "string value" end: ;
> +
> +
> +File layout
> +---
> +
> +Version 1 DTS files have the overall layout:
> + /dts-v1/;
> +
> + [memory reservations]
> +
> + / {
> + [property definitions]
> + [child nodes]
> + };
> +
> +* The "/dts-v1/;" must be present to identify the file as a version 1
> +  

ePAPR 1.0 is published

[Yoder Stuart]

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
relevant parts of 1275 and misc bindings created by the OF working
group.

It also contains a specification for how multicore boot works in
an ePAPR-compliant system.

Stuart Yoder
Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart]

 

> -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() 
> utility function
> 
> On Wed, Aug 06, 2008 at 11:46:47AM -0500, Timur Tabi wrote:
> > On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely 
> <[EMAIL PROTECTED]> wrote:
> > > From: Grant Likely <[EMAIL PROTECTED]>
> > >
> > > of_lookup_stdout() is useful for figuring out what device 
> to use as output
> > > for early boot progress messages.  It returns the node 
> pointed to by the
> > > linux,stdout-path property in the chosen node.
> > 
> > I thought linux,stdout-path is deprecated are we're supposed to be
> > using the aliases node instead?
> 
> During the ePAPR process this idea came up - standardising a 'stdout'
> alias that would replace linux,stdout-path in chosen.  However that
> was done in ignorance of the history of the linux,stdout-path property
> and its connection to the stdout ihandle in chosen.  In any case, the
> proposed 'stdout' alias didn't make the final cut for ePAPR, so how to
> address this for flat-tree systems is still an open question.

In the ePAPR discussion I think we generally agreed that
an alias was better than a property under /chosen.  There
were 2 things that caused us to delete the /aliases/stdout.

One was discussions around whether we needed to support
multiple consoles somehow.

The second was the idea that we may need a /aliases/stdin as well.
You could conceptually have stdout be a monitor and a stdin
be a keyboard.

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart]

 

> -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 I2C support.
> 
> 
> 
> 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 Bradley  ([EMAIL PROTECTED])
>  
> >>> Hi Mitch,
> >>>
> >>> What is your suggestion.  Where should we be discussing new device
> >>> tree bindings?  Whether it be real Open Firmware, or 
> flattened device
> >>> tree, or something in between
> >>>   
> >> ...and along those lines: is there a place for documenting new
> >> bindings?  Lacking anything better, those of us in 
> PowerPC-Linux-land
> >> have been adding documentation to 
> Documentation/powerpc/dts-bindings/*
> >> in the Linux kernel tree.
> >> 
> >
> > In a discussion I am having with Greg Onufer, David K. and Tayfun
> > at Sun, Greg said the some of the newer binding documents are
> > being published on the opensolaris site, and he is trying to
> > get some of the older cases (like this I2C one) published there
> > too.
> >
> >   
> 
> This collection of mailing lists is as good a place as any to discuss 
> new bindings.  I don't know how many Sun people are on the 
> lists, but we 
> might be able to persuade various Sun people to lurk on one 
> or more of 
> them;  I lurk on devicetree-discuss.
> 
> The opensolaris site seems as good as anywhere for publishing the 
> bindings, especially if they can pull over the old ones from e.g. 
> playground.sun.com .
> 
> Another possible site might be openbios.org .

I agree that the linuxppc-dev and devicetree-discuss mailing
lists are probably the best place to discuss bindings.  (I'm
not aware of other good options).

Once there is consensus as to what a binding should be, and publishing
is needed-- for general, common bindings some single place is needed.
Something that is ideally authoritative, with a committed organization
behind it.  One suggestion would be the power.org and follow on
versions of the ePAPR.  ePAPR 1.0 is out now and currently is a base
document-- defines the flat device tree concept, and basically extracts
the relevant parts of 1275 for how this is used in the embedded space.

There are a few bindings specified in the ePAPR, based on the old
Open Firmware working group stuff:
   -cpu
   -interrupt controllers
   -PCI
   -network devices
   -DCR devices
   -serial devices

ePAPR doc is at:
http://www.power.org/resources/downloads/

It's obvious that more bindings are needed, and the expecation from
those who worked on the ePAPR (most or all of which are on this
mailing list) was that as bindings are codified they could be
added to the ePAPR.

The best way to publish bindings will be on the web.  I've been
looking into getting power.org to host a wiki-based site
that could be used as a repository for bindings.  We could have
both an area for general bindings and company specific ones.
I've made some progress here and actually have a sandbox wiki
that I'm playing with.

Stuart Yoder
Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

pci overmapping

[Yoder Stuart-B08248]

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, PCI_CAP_ID_EXP)) {

You are implying that PCIe can overmap and PCI can't.  Why is
that?   (I'm assuming that 'overmap' means that inbound window
can extend beyond the end of ram.)

We are facing an issue for a non-PCI express controller (i.e. without
PCI_CAP_ID_EXP) emulated by QEMU.  In our case we need the ATMU
window to extend beyond the end of ram, since the window size has
to be a power of 2.

Thanks,
Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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
> Subject: Re: [PATCH][v2] KVM: PPC: add paravirt idle loop for 64-bit book E
> 
> On 01/22/2013 05:54:43 PM, Stuart Yoder wrote:
> > +.macro BOOK3E_IDLE_LOOP
> > +1:
> > +   PPC_WAIT(0)
> > b   1b
> > +.endm
> > +
> > +.macro EPAPR_EV_IDLE_LOOP
> > +idle_loop:
> > +   LOAD_REG_IMMEDIATE(r11, EV_HCALL_TOKEN(EV_IDLE))
> > +
> > +.global epapr_ev_idle_start
> > +epapr_ev_idle_start:
> > +   li  r3, -1
> > +   nop
> > +   nop
> > +   nop
> > +   b   idle_loop
> > +.endm
> > +
> > +BOOK3E_IDLE epapr_ev_idle, EPAPR_EV_IDLE_LOOP
> > +
> > +BOOK3E_IDLE book3e_idle BOOK3E_IDLE_LOOP
> 
> Why the comma after epapr_ev_idle but not after book3e_idle?
> 
> Also you have spaces where there should be tabs.
> 
> Otherwise looks good.

Hmm...there shouldn't be a comma there.  I'll respin
and fix the whitespace too.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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 
> device tree
> 
> 
> On Jan 17, 2013, at 4:34 PM, Timur Tabi wrote:
> 
> > From: Timur Tabi 
> >
> > The PAMU caches use the LIODNs to determine which cache lines hold the
> > entries for the corresponding LIODs.  The LIODNs must therefore be
> > carefully assigned to avoid cache thrashing -- two active LIODs with
> > LIODNs that put them in the same cache line.
> >
> > Currently, LIODNs are statically assigned by U-Boot, but this has
> > limitations.  LIODNs are assigned even for devices that may be disabled
> > or unused by the kernel.  Static assignments also do not allow for device
> > drivers which may know which LIODs can be used simultaneously.  In
> > other words, we really should assign LIODNs dynamically in Linux.
> >
> > To do that, we need to describe the PAMU device and cache topologies in
> > the device trees.
> >
> > Signed-off-by: Timur Tabi 
> > ---
> > .../devicetree/bindings/powerpc/fsl/guts.txt   |   14 ++-
> > .../devicetree/bindings/powerpc/fsl/pamu.txt   |  142 
> > 
> > arch/powerpc/boot/dts/fsl/p2041si-post.dtsi|   87 +++--
> > arch/powerpc/boot/dts/fsl/p3041si-post.dtsi|   87 +++--
> > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi|   68 +-
> > arch/powerpc/boot/dts/fsl/p5020si-post.dtsi|   92 +++--
> > arch/powerpc/boot/dts/fsl/p5040si-post.dtsi|   92 +++--
> > 7 files changed, 533 insertions(+), 49 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
> 
> Scott, Stuart, does this have your guys Ack?

Ack

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -Original Message-
> From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
> Sent: Friday, March 01, 2013 4:07 AM
> To: Sethi Varun-B16395
> Cc: Kumar Gala; Benjamin Herrenschmidt; io...@lists.linux-foundation.org; 
> linuxppc-dev@lists.ozlabs.org
> list; linux-ker...@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 iommu_group, and the
> iommu_group struct itself has a pointer void *iommu_data which you could
> use for anything you want (iommu_group_get_iommudata(),
> iommu_group_set_iommudata()).
>
> By design you are expected to add iommu groups to a domain but not devices
> so I am not so sure that you really need a pointer to domain in the device
> struct.

Well, at the lowest level the IOMMU API does attach devices to domains-- i.e.
API attach_dev().  So, it seems to conceptually make sense to have a ptr
from the device to the associated domain.  When you implement attach_dev()
you need to be able to see whether the device is already attached to
a domain.   Adding a couple of levels of indirection...from device to
group to domain...doesn't seems to make things simpler or better IMHO.

x86 keeps a pointer to the domain in device archdata and since there is
a direct correlation between a device and domain I'd rather see it
where this patch has it.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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
> Subject: RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API 
> implementation.
> 
> 
> 
> > -Original Message-
> > From: Stuart Yoder [mailto:b08...@gmail.com]
> > Sent: Saturday, March 02, 2013 4:58 AM
> > To: Sethi Varun-B16395
> > Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
> > linux-ker...@vger.kernel.org; Wood Scott-B07421; Joerg Roedel; Yoder
> > Stuart-B08248
> > Subject: Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU
> > API implementation.
> >
> > On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi 
> > wrote:
> > [cut]
> > > +static phys_addr_t get_phys_addr(struct fsl_dma_domain *dma_domain,
> > > +unsigned long iova) {
> > > +   u32 win_cnt = dma_domain->win_cnt;
> > > +   struct dma_window *win_ptr =
> > > +   &dma_domain->win_arr[0];
> > > +   struct iommu_domain_geometry *geom;
> > > +
> > > +   geom = &dma_domain->iommu_domain->geometry;
> > > +
> > > +   if (!win_cnt || !dma_domain->geom_size) {
> > > +   pr_err("Number of windows/geometry not configured for
> > the domain\n");
> > > +   return 0;
> > > +   }
> > > +
> > > +   if (win_cnt > 1) {
> > > +   u64 subwin_size;
> > > +   unsigned long subwin_iova;
> > > +   u32 wnd;
> > > +
> > > +   subwin_size = dma_domain->geom_size >> ilog2(win_cnt);
> >
> > Could it be just geom_size / win_cnt ??
> [Sethi Varun-B16395] You would run in to linking issues with respect to u64 
> division on 32 bit kernels.
> 
> >
> > > +   subwin_iova = iova & ~(subwin_size - 1);
> > > +   wnd = (subwin_iova - geom->aperture_start) >>
> > ilog2(subwin_size);
> > > +   win_ptr = &dma_domain->win_arr[wnd];
> > > +   }
> > > +
> > > +   if (win_ptr->valid)
> > > +   return (win_ptr->paddr + (iova & (win_ptr->size -
> > > + 1)));
> > > +
> > > +   return 0;
> > > +}
> > > +
> > > +static int map_liodn_subwins(int liodn, struct fsl_dma_domain
> > > +*dma_domain)
> >
> > Just call it map_subwins().  They are just sub windows, not "liodn sub
> > windows".
> >
> [Sethi Varun-B16395] This would be called per liodn.
>
> > [cut]
> >
> > > +static int map_liodn_win(int liodn, struct fsl_dma_domain
> > > +*dma_domain)
> >
> > Call it map_win().
> [Sethi Varun-B16395] This would again be called per liodn.

On the function names-- function names are typically named
with a noun describing some object and a verb describing
the action...and sometimes a subsystem identifier:
kmem_cache + zalloc
spin + lock

I don't think inserting liodn in the function name to indicates that it 
operates per liodn makes it more clear and reads a little awkward to me:

map + liodn_win

...it's almost like there is a "liodn_win" object.

I think plain map_win() is more clear and the function prototype makes
it pretty clear that you are operating on an liodn.
 
> > [cut]
> > > +static  bool check_pci_ctl_endpt_part(struct pci_controller *pci_ctl)
> > > +{
> > > +   u32 version;
> > > +
> > > +   /* Check the PCI controller version number by readding BRR1
> > register */
> > > +   version = in_be32(pci_ctl->cfg_addr + (PCI_FSL_BRR1 >> 2));
> > > +   version &= PCI_FSL_BRR1_VER;
> > > +   /* If PCI controller version is >= 0x204 we can partition
> > endpoints*/
> > > +   if (version >= 0x204)
> > > +   return 1;
> > > +
> > > +   return 0;
> > > +}
> >
> > Can we just use the compatible string here to identify the different
> > kinds of PCI
> > controllers?   Reading the actual device registers is ugly right now
> > because
> > you are #defining the BRR1 stuff in a generic powerpc header.
> >
> [Sethi Varun-B16395] hmmm.., I would have to check for various different 
> compatible strings in that
> case. May be I can move the defines to a different file. What if I move them 
> to some other header?

Don't personally feel too strongly about version register or header...but it 
should be some fsl
PCI header that you define those regs.

You'll either need to check for a hardware version number or a compatible,
so a compatible check may be just as easy...look for "fsl,qoriq-pcie-v2.4"?

Stuart


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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 properties for e6500 
> cores
> 
> On 03/05/2013 02:16:42 PM, Stuart Yoder wrote:
> > From: Stuart Yoder 
> >
> > Signed-off-by: Stuart Yoder 
> > ---
> > -v2
> >-fix some typos
> >
> >  arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi |   65
> > 
> >  1 file changed, 65 insertions(+)
> >  create mode 100644 arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi
> >
> > diff --git a/arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi
> > b/arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi
> > new file mode 100644
> > index 000..6b4d16a
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi
> > @@ -0,0 +1,65 @@
> > +/*
> > + * e6500 Power ISA Device Tree Source (include)
> > + *
> > + * Copyright 2013 Freescale Semiconductor Inc.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following
> > conditions are met:
> > + * * Redistributions of source code must retain the above
> > copyright
> > + *   notice, this list of conditions and the following
> > disclaimer.
> > + * * Redistributions in binary form must reproduce the above
> > copyright
> > + *   notice, this list of conditions and the following
> > disclaimer in the
> > + *   documentation and/or other materials provided with the
> > distribution.
> > + * * Neither the name of Freescale Semiconductor nor the
> > + *   names of its contributors may be used to endorse or promote
> > products
> > + *   derived from this software without specific prior written
> > permission.
> > + *
> > + *
> > + * ALTERNATIVELY, this software may be distributed under the terms
> > of the
> > + * GNU General Public License ("GPL") as published by the Free
> > Software
> > + * Foundation, either version 2 of that License or (at your option)
> > any
> > + * later version.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND
> > ANY
> > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > IMPLIED
> > + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> > PURPOSE ARE
> > + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE
> > FOR ANY
> > + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > CONSEQUENTIAL DAMAGES
> > + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> > OR SERVICES;
> > + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> > CAUSED AND
> > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> > LIABILITY, OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> > USE OF THIS
> > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +/ {
> > +   cpus {
> > +   power-isa-version = "2.06";
> > +   power-isa-b;// Base
> > +   power-isa-e;// Embedded
> > +   power-isa-atb;  // Alternate Time Base
> > +   power-isa-cs;   // Cache Specification
> > +   power-isa-ds;   // Decorated Storage
> > +   power-isa-e.ed; // Embedded.Enhanced Debug
> > +   power-isa-e.pd; // Embedded.External PID
> > +   power-isa-e.hv; // Embedded.Hypervisor
> > +   power-isa-e.le; // Embedded.Little-Endian
> > +   power-isa-e.pm; // Embedded.Performance Monitor
> > +   power-isa-e.pc; // Embedded.Processor Control
> > +   power-isa-ecl;  // Embedded Cache Locking
> > +   power-isa-exp;  // External Proxy
> > +   power-isa-fp;   // Floating Point
> > +   power-isa-fp.r; // Floating Point.Record
> > +   power-isa-mmc;  // Memory Coherence
> > +   power-isa-scpm; // Store Conditional Page
> > Mobility
> > +   power-isa-wt;   // Wait
> > +   power-isa-64;   // 64-bit
> > +   power-isa-e.pt; // Embedded.Page Table
> > +   power

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

[Yoder Stuart-B08248]

> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Thursday, March 14, 2013 3:20 PM
> To: Sethi Varun-B16395
> Cc: j...@8bytes.org; io...@lists.linux-foundation.org; 
> linuxppc-dev@lists.ozlabs.org; linux-
> ker...@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 corresponding PORT_ID values.
> > + *
> > + * All future CoreNet-enabled SOCs will have this erratum fixed, so this 
> > table
> > + * should never need to be updated.  SVRs are guaranteed to be unique, so
> > + * there is no worry that a future SOC will inadvertently have one of these
> > + * values.
> > + */
> 
> Maybe add to the comment about what port_id represents

When you update the comment, I would also suggest identifying the specific
errata here (A-004510) so that it's easy to reference back to the specific
issue this code is fixing.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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.org;
> imun...@au1.ibm.com; linuxppc-dev@lists.ozlabs.org; 
> linux-ker...@vger.kernel.org
> Subject: Re: [Suggestion] PowerPC: kernel: cross compiling issue with 
> allmodconfig
> 
> Chen Gang F T  wrote:
> 
> >
> >   it seems:
> > only move slb_miss_realmode to the end, can fix this issue without 
> > negative effect.
> 
> So this works but uncovers a new bug.
> 
> Stuart: if you apply this patch allmodconfig now gets this build error
> on linux-next.
> 
> arch/powerpc/kernel/built-in.o: In function `restore_pblist_ptr':
> ftrace.c:(.toc+0xd78): undefined reference to `epapr_ev_idle_start'
> ftrace.c:(.toc+0xd88): undefined reference to `epapr_ev_idle'
> make[1]: *** [vmlinux] Error 1
> 
> Reverting your patch below fixes this:
> 
>   commit f070986a07e514e3b4fc4aef6551b8dffcb19287
>   Author: Stuart Yoder 
>   Date:   Fri Feb 8 13:22:56 2013 -0600
> 
>   powerpc: Add paravirt idle loop for 64-bit Book-E
> 
>   Signed-off-by: Stuart Yoder 
>   Signed-off-by: Kumar Gala 
> 
> Should we revert your patch or can you send a fix?  This is currently
> broken in linux-next (at least next-20130321).

Sent a patch that resolves this.  Not completely happy with it
because of the added #ifdefs, but not sure how else to resolve
this.   allmodconfig is creating config combinations that don't
happen in a normal build (at least currently)-- 64-bit build
that enables EPAPR_PARAVIRT but not PPC_BOOK3E_64.

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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...@kernel.crashing.org; b...@kernel.crashing.org
> Cc: Sethi Varun-B16395
> Subject: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu 
> implementation.
> 
> Following is a brief description of the PAMU hardware:
> PAMU determines what action to take and whether to authorize the action on
> the basis of the memory address, a Logical IO Device Number (LIODN), and
> PAACT table (logically) indexed by LIODN and address. Hardware devices which
> need to access memory must provide an LIODN in addition to the memory address.
> 
> Peripheral Access Authorization and Control Tables (PAACTs) are the primary
> data structures used by PAMU. A PAACT is a table of peripheral access
> authorization and control entries (PAACE).Each PAACE defines the range of
> I/O bus address space that is accessible by the LIOD and the associated access
> capabilities.
> 
> There are two types of PAACTs: primary PAACT (PPAACT) and secondary PAACT
> (SPAACT).A given physical I/O device may be able to act as one or more
> independent logical I/O devices (LIODs). Each such logical I/O device is
> assigned an identifier called logical I/O device number (LIODN). A LIODN is
> allocated a contiguous portion of the I/O bus address space called the DSA 
> window
> for performing DSA operations. The DSA window may optionally be divided into
> multiple sub-windows, each of which may be used to map to a region in system
> storage space. The first sub-window is referred to as the primary sub-window
> and the remaining are called secondary sub-windows.
> 
> This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU
> API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c)
> has been derived from the work done by Ashish Kalra and Timur Tabi.
> 
> Signed-off-by: Timur Tabi <
> Signed-off-by: Varun Sethi 
> ---
> changes in v11:
> - changed iova to dma_addr_t in iova_to_phys API.
> changes in v10:
> - Support for new guts compatibe string for T4 & B4 devices.
> - Modified comment about port ID and mentioned the errata number.
> - Fixed the issue where data pointer was not freed in case of a an error.
> - Pass data pointer while freeing irq.
> - Whle initializing the SPAACE entry clear the valid bit.
> changes in v9:
> - Merged and createad a single function to delete
> a device from domain list.
> - Refactored the add_device API code.
> - Renamed the paace and spaace init fucntions.
> - Renamed functions for mapping windows and subwindows.
> - Changed the MAX LIODN value to MAX value u-boot can
> program.
> - Hard coded maximum number of subwindows.
> changes in v8:
> - implemented the new API for window based IOMMUs.
> changes in v7:
> - Set max_subwidows in the geometry attribute.
> - Add checking for maximum supported LIODN value.
> - Use upper_32_bits and lower_32_bits macros while
>   intializing PAMU data structures.
> changes in v6:
> - Simplified complex conditional statements.
> - Fixed indentation issues.
> - Added comments for IOMMU API implementation.
> changes in v5:
> - Addressed comments from Timur.
> changes in v4:
> - Addressed comments from Timur and Scott.
> changes in v3:
> - Addressed comments by Kumar Gala
> - dynamic fspi allocation
> - fixed alignment check in map and unmap
>  arch/powerpc/sysdev/fsl_pci.h   |5 +
>  drivers/iommu/Kconfig   |8 +
>  drivers/iommu/Makefile  |1 +
>  drivers/iommu/fsl_pamu.c| 1269 
> +++
>  drivers/iommu/fsl_pamu.h|  405 +
>  drivers/iommu/fsl_pamu_domain.c | 1137 +++
>  drivers/iommu/fsl_pamu_domain.h |   85 +++
>  7 files changed, 2910 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/iommu/fsl_pamu.c
>  create mode 100644 drivers/iommu/fsl_pamu.h
>  create mode 100644 drivers/iommu/fsl_pamu_domain.c
>  create mode 100644 drivers/iommu/fsl_pamu_domain.h

Ack.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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.ozlabs.org
> Subject: RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu 
> implementation.
> 
> 
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, April 03, 2013 7:23 AM
> > To: Timur Tabi
> > Cc: Joerg Roedel; Sethi Varun-B16395; lkml; Kumar Gala; Yoder Stuart-
> > B08248; io...@lists.linux-foundation.org; Benjamin Herrenschmidt;
> > linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu
> > implementation.
> >
> > On 04/02/2013 08:35:54 PM, Timur Tabi wrote:
> > > On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel  wrote:
> > >
> > > > > + panic("\n");
> > > >
> > > > A kernel panic seems like an over-reaction to an access violation.
> > >
> > > We have no way to determining what code caused the violation, so we
> > > can't just kill the process.  I agree it seems like overkill, but what
> > > else should we do?  Does the IOMMU layer have a way for the IOMMU
> > > driver to stop the device that caused the problem?
> >
> > At a minimum, log a message and continue.  Probably turn off the LIODN,
> > at least if it continues to be noisy (otherwise we could get stuck in an
> > interrupt storm as you note).  Possibly let the user know somehow,
> > especially if it's a VFIO domain.
> [Sethi Varun-B16395] Can definitely log the message and disable the LIODN (to 
> avoid an interrupt storm),
> but
> we definitely need a mechanism to inform vfio subsystem about the error. 
> Also, disabling LIODN may not
> be a viable
> option with the new LIODN allocation scheme (where LIODN would be associated 
> with a domain).

I think for phase 1 of this, just log the error, shut down DMA as you described.
We can implement more full featured error management, like notifying vfio
or the VM somehow in the future.

Stuart


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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...@lists.ozlabs.org; linux-ker...@vger.kernel.org; 
> ga...@kernel.crashing.org; b...@kernel.crashing.org
> Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu 
> implementation.
> 
> On Thu, 2013-04-04 at 13:00 +, Sethi Varun-B16395 wrote:
> >
> > > -Original Message-
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday, April 03, 2013 11:32 PM
> > > To: Joerg Roedel
> > > Cc: Sethi Varun-B16395; Yoder Stuart-B08248; Wood Scott-B07421;
> > > io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> > > ker...@vger.kernel.org; ga...@kernel.crashing.org;
> > > b...@kernel.crashing.org
> > > Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu
> > > implementation.
> > >
> > > On Tue, 2013-04-02 at 18:18 +0200, Joerg Roedel wrote:
> > > > Cc'ing Alex Williamson
> > > >
> > > > Alex, can you please review the iommu-group part of this patch?
> > >
> > > Sure, it looks pretty reasonable.  AIUI, all PCI devices are below some
> > > kind of host bridge that is either new and supports partitioning or old
> > > and doesn't.  I don't know if that's a visibility or isolation
> > > requirement, perhaps PCI ACS-ish.  In the new host bridge case, each
> > > device gets a group.  This seems not to have any quirks for multifunction
> > > devices though.  On AMD and Intel IOMMUs we test multifunction device ACS
> > > support to determine whether all the functions should be in the same
> > > group.  Is there any reason to trust multifunction devices on PAMU?
> > >
> > [Sethi Varun-B16395] In the case where we can partition endpoints we
> > can distinguish transactions based on the bus,device,function number
> > combination. This support is available in the PCIe controller (host
> > bridge).
> 
> So can x86 IOMMUs, that's the visibility aspect of IOMMU groups.
> Visibility alone doesn't necessarily imply that a device is isolated
> though.  A multifunction PCI device that doesn't expose ACS support may
> not isolate functions from each other.  For example a peer-to-peer DMA
> between functions may not be translated by the upstream IOMMU.  IOMMU
> groups should encompass both visibility and isolation.
> 
> > > I also find it curious what happens to the iommu group of the host
> > > bridge.  In the partitionable case the host bridge group is removed, in
> > > the non-partitionable case the host bridge group becomes the group for
> > > the children, removing the host bridge.  It's unique to PAMU so far that
> > > these host bridges are even in an iommu group (x86 only adds pci
> > > devices), but I don't see it as necessarily wrong leaving it in either
> > > scenario.  Does it solve some problem to remove them from the groups?
> > > Thanks,
> > [Sethi Varun-B16395] The PCIe controller isn't a partitionable entity,
> > it would always be owned by the host.
> 
> Ownership of a device shouldn't play into the group context.  An IOMMU
> group should be defined by it's visibility and isolation from other
> devices.  Whether the PCIe controller is allowed to be handed to
> userspace is a question for VFIO.  Thanks,

Right now the add_device() callback gets called for all platform
devices (including PCI controller) and PCI devices.  PCI controllers
are a kind of special case in that their device tree node has a
property indicating that it is DMA capable...but in fact the
PCI controller itself does not DMA, but it's the PCI endpoints
under it.

So, as you noted the bridge/controller shouldn't be in an IOMMU
group and so since the platform 'add device' code didn't special
case PCI controllers, this patch removes their group if it's there.

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Tuesday, April 23, 2013 8:39 AM
> To: Sethi Varun-B16395
> Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; 
> linux-ker...@vger.kernel.org;
> ga...@kernel.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 for the FSL PAMU driver:
> > 1. Added new iommu stash attribute, which allows setting of the
> >LIODN specific stash id parameter through IOMMU API.
> > 2. Added an attribute for enabling/disabling DMA to a particular
> >memory window.
> > 3. Added domain attribute to check for PAMUV1 specific constraints.
> >
> > Signed-off-by: Varun Sethi 
> > ---
> > v14 changes:
> > - Add FSL prefix to PAMU attributes.
> > v13 changes:
> > - created a new file include/linux/fsl_pamu_stash.h for stash
> > attributes.
> > v12 changes:
> > - Moved PAMU specifc stash ids and structures to PAMU header file.
> > - no change in v11.
> > - no change in v10.
> >  include/linux/fsl_pamu_stash.h |   39 
> > +++
> 
> Isn't asm/ for your architecture a better place for that header?

The PAMU isn't strictly tied to Power architecture, although
that is where it is implemented now.  It could be implemented
on ARM for example.

Stuart


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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
> Subject: Re: [PATCH] powerpc: set stack limit properly in 
> crit_transfer_to_handler
> 
> 
> On Jul 16, 2012, at 2:06 PM, Stuart Yoder wrote:
> 
> > From: Stuart Yoder 
> >
> > without setting the stack limit like this there is the possibility
> > of stack overflow which corrupts the thread info but
> > is not detected by stack overflow detection
> >
> > Signed-off-by: Stuart Yoder 
> > ---
> > arch/powerpc/kernel/entry_32.S |   12 ++--
> > 1 files changed, 10 insertions(+), 2 deletions(-)
> 
> Do we need this for debug & mcheck ?

Maybe... I don't know the history of this code
and why this is only done in the critical exception
handlers.

But, this particular patch is to undo/fix something I
introduced in:
powerpc: Use CURRENT_THREAD_INFO instead of open coded assembly

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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; Jia Hongtao-B38951
> Subject: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC 
> message register
> binding
> 
> This binding documents how the message register blocks found in some FSL MPIC 
> implementations
> shall be represented in a device tree.
> 
> Signed-off-by: Meador Inge 
> Signed-off-by: Jia Hongtao 
> Signed-off-by: Li Yang 
> ---
>  .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt  |   62 
> 
>  1 files changed, 62 insertions(+), 0 deletions(-)  create mode 100644
> Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> new file mode 100644
> index 000..b4ae70e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> @@ -0,0 +1,62 @@
> +* FSL MPIC Message Registers
> +
> +This binding specifies what properties must be available in the device
> +tree representation of the message register blocks found in some FSL
> +MPIC implementations.
> +
> +Required properties:
> +
> +- compatible: Specifies the compatibility list for the message register
> +  block.  The type shall be  and the value shall be of the form
> +  "fsl,mpic-v-msgr", where  is the version number of
> +  the MPIC containing the message registers.

The type for compatibles is a .

> +- reg: Specifies the base physical address(s) and size(s) of the
> +  message register block's addressable register space.  The type shall be
> +  .
> +
> +- interrupts: Specifies a list of interrupt source and level-sense pairs.
> +  The type shall be .  The length shall be equal to
> +  the number of registers that are available for receiving interrupts.

How many interrupts are there?   If more than 1,  this is where
you need to specify what each interrupt is for.

> +Optional properties:
> +
> +- mpic-msgr-receive-mask: Specifies what registers in the containing 
> block
> +  are allowed to receive interrupts.  The value is a bit mask where a set
> +  bit at bit 'n' indicates that message register 'n' can receive 
> interrupts.
> +  The type shall be .  If not present, then all of
> +  the message registers in the block are available.

Your example implies that this is 1 32-bit cell.  If that is the case then
this really should be of type ''.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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] powerpc: document the FSL MPIC 
> message register
> binding
> 
> On 02/17/2012 09:50 AM, Yoder Stuart-B08248 wrote:
> >
> >
> >> -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; Jia Hongtao-B38951
> >> Subject: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL
> >> MPIC message register binding
> >>
> >> This binding documents how the message register blocks found in some
> >> FSL MPIC implementations shall be represented in a device tree.
> >>
> >> Signed-off-by: Meador Inge 
> >> Signed-off-by: Jia Hongtao 
> >> Signed-off-by: Li Yang 
> >> ---
> >>  .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt  |   62 
> >> 
> >>  1 files changed, 62 insertions(+), 0 deletions(-)  create mode
> >> 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> >> b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> >> new file mode 100644
> >> index 000..b4ae70e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> >> @@ -0,0 +1,62 @@
> >> +* FSL MPIC Message Registers
> >> +
> >> +This binding specifies what properties must be available in the
> >> +device tree representation of the message register blocks found in
> >> +some FSL MPIC implementations.
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: Specifies the compatibility list for the message 
> >> register
> >> +  block.  The type shall be  and the value shall be of the 
> >> form
> >> +  "fsl,mpic-v-msgr", where  is the version number of
> >> +  the MPIC containing the message registers.
> >
> > The type for compatibles is a .
> >
> >> +- reg: Specifies the base physical address(s) and size(s) of the
> >> +  message register block's addressable register space.  The type 
> >> shall be
> >> +  .
> >> +
> >> +- interrupts: Specifies a list of interrupt source and level-sense 
> >> pairs.
> >> +  The type shall be .  The length shall be equal 
> >> to
> >> +  the number of registers that are available for receiving interrupts.
> >
> > How many interrupts are there?   If more than 1,  this is where
> > you need to specify what each interrupt is for.
> 
> They aren't "for" anything in particular -- each interrupt is associated with 
> a message
> register.  The binding does say that the number of interrupts corresponds to 
> the bits set in
> the receive mask.

Then make that clear, it also should use the term 'interrupt-specifier'
not 'interrupt source and level-sense pairs', which implies a particular
parent interrupt controller configuration.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

pci node question

[Yoder Stuart-B08248]

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 #address-cells = <3>;
48 bus-range = <0x0 0xff>;
49 clock-frequency = <>;
50 interrupts = <16 2 1 15>;
51 pcie@0 {
52 reg = <0 0 0 0 0>;
53 #interrupt-cells = <1>;
54 #size-cells = <2>;
55 #address-cells = <3>;
56 device_type = "pci";
57 interrupts = <16 2 1 15>;
58 interrupt-map-mask = <0xf800 0 0 7>;
59 interrupt-map = <
60 /* IDSEL 0x0 */
61  0 0 1 &mpic 40 1 0 0
62  0 0 2 &mpic 1 1 0 0
63  0 0 3 &mpic 2 1 0 0
64  0 0 4 &mpic 3 1 0 0
65 >;
66 };
67 };

Why was the interrupt-map moved here?

Do we really need the error interrupt specified twice?

Why is there a zeroed out reg property: reg = <0 0 0 0 0> ??

Thanks,
Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: pci node question

[Yoder Stuart-B08248]

> -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-B08248 wrote:
> 
> > 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 #address-cells = <3>;
> > 48 bus-range = <0x0 0xff>;
> > 49 clock-frequency = <>;
> > 50 interrupts = <16 2 1 15>;
> > 51 pcie@0 {
> > 52 reg = <0 0 0 0 0>;
> > 53 #interrupt-cells = <1>;
> > 54 #size-cells = <2>;
> > 55 #address-cells = <3>;
> > 56 device_type = "pci";
> > 57 interrupts = <16 2 1 15>;
> > 58 interrupt-map-mask = <0xf800 0 0 7>;
> > 59 interrupt-map = <
> > 60 /* IDSEL 0x0 */
> > 61  0 0 1 &mpic 40 1 0 0
> > 62  0 0 2 &mpic 1 1 0 0
> > 63  0 0 3 &mpic 2 1 0 0
> > 64  0 0 4 &mpic 3 1 0 0
> > 65 >;
> > 66 };
> > 67 };
> >
> > Why was the interrupt-map moved here?
> 
> Its been a while, but I think i moved it down because of which node is used 
> for interrupt handling in
> linux.
> 
> > Do we really need the error interrupt specified twice?
> 
> I put it twice because it has multiple purposes, one has to do with 
> interrupts defined by the PCI spec
> vs ones defined via FSL controller.
> 
> > Why is there a zeroed out reg property: reg = <0 0 0 0 0> ??
> 
> scratching my head, what happens if you remove it?

Tried removing the zeroed reg, and get this error when bringing
up an e1000 interface:

[root@kvmtst1 root]# ifconfig eth0 192.168.1.20
e1000e :01:00.0: eth0: Unable to allocate interrupt, Error: -22
SIOCSIFFLAGS: Invalid argument

Stuart


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: pci node question

[Yoder Stuart-B08248]

> -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 -0500, Kumar Gala wrote:
> > On Apr 20, 2012, at 1:37 PM, Yoder Stuart-B08248 wrote:
> >
> > > 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 #address-cells = <3>;
> > > 48 bus-range = <0x0 0xff>;
> > > 49 clock-frequency = <>;
> > > 50 interrupts = <16 2 1 15>;
> > > 51 pcie@0 {
> > > 52 reg = <0 0 0 0 0>;
> > > 53 #interrupt-cells = <1>;
> > > 54 #size-cells = <2>;
> > > 55 #address-cells = <3>;
> > > 56 device_type = "pci";
> > > 57 interrupts = <16 2 1 15>;
> > > 58 interrupt-map-mask = <0xf800 0 0 7>;
> > > 59 interrupt-map = <
> > > 60 /* IDSEL 0x0 */
> > > 61  0 0 1 &mpic 40 1 0 0
> > > 62  0 0 2 &mpic 1 1 0 0
> > > 63  0 0 3 &mpic 2 1 0 0
> > > 64  0 0 4 &mpic 3 1 0 0
> > > 65 >;
> > > 66 };
> > > 67 };
> > >
> > > Why was the interrupt-map moved here?
> >
> > Its been a while, but I think i moved it down because of which node is used 
> > for interrupt handling in
> linux.
> 
> Yeah, it would swizzle if going accross the virtual P2P bridge. On the
> other hand, if it's PCIe, the children of the vP2P should always be at
> device 0 and thus the swizzling should be a NOP no ? So we -could- leave
> it in the PHB unless I'm mistaken...
> 
> On the other hand, we probably want to fix the mapping code to handle
> things like SR-IOV PFs with different device numbers... do those get
> swizzled ? In that case we might want to keep things down the virtual
> bridge.
> 
> > > Do we really need the error interrupt specified twice?
> >
> > I put it twice because it has multiple purposes, one has to do with 
> > interrupts defined by the PCI spec
> vs ones defined via FSL controller.
> >
> > > Why is there a zeroed out reg property: reg = <0 0 0 0 0> ??
> >
> > scratching my head, what happens if you remove it?
> 
> If you remove it, the kernel will fail to match the vP2P with the
> corresponding struct pci_dev It's not "zeroed out". It contains a
> valid bus/dev/fn ... of 0,0,0 :-)

Hmmm... I vaguely understand what you are saying.   But why is the
length zero, that is what doesn't make sense on the surface?

We really should put a comment on that reg property-- can you suggest
a short comment that would capture what the reg with all zeros 
is for?  ...I'll submit a patch.

Thanks,
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: pci node question

[Yoder Stuart-B08248]

> -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 15:48 +, Yoder Stuart-B08248 wrote:
> > Hmmm... I vaguely understand what you are saying.   But why is the
> > length zero, that is what doesn't make sense on the surface?
> 
> Ah indeed, on would think that we could represent the real size of the
> config space there... but I've always seen this as 0 in real OF
> implementations as well, at least the G5 device-tree I'm looking at now
> has it that way.
> 
> > We really should put a comment on that reg property-- can you suggest
> > a short comment that would capture what the reg with all zeros
> > is for?  ...I'll submit a patch.
> 
> Hrm.. "config address of the device: 0,0,0" ?

How about:

  /* config space address of the device 0,0,0. OF convention is that
 the size of config space is 0. */

...is that accurate?

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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 coded 
> assembly
> 
> 
> On 02.07.2012, at 23:14, Stuart Yoder wrote:
> 
> > From: Stuart Yoder 
> >
> > Signed-off-by: Stuart Yoder 
> > ---
> >
> > -this patch is a pre-requisite for the idle hcall which I
> > am trying to get into Alex's KVM tree, so ideally would like
> > Ben's ack and get this applied to Alex's tree
> >
> > -built/tested with a 32-bit booke kernel, built a 64-bit
> > booke kernel
> >
> > -v2
> >   -moved CURRENT_THREAD_INFO under assembly only
> >#ifdef
> >
> > arch/powerpc/include/asm/exception-64s.h |4 ++--
> > arch/powerpc/include/asm/thread_info.h   |8 
> > arch/powerpc/kernel/entry_32.S   |   24 
> > arch/powerpc/kernel/entry_64.S   |   14 +++---
> > arch/powerpc/kernel/exceptions-64e.S |2 +-
> > arch/powerpc/kernel/exceptions-64s.S |2 +-
> > arch/powerpc/kernel/head_fsl_booke.S |2 +-
> > arch/powerpc/kernel/idle_6xx.S   |4 ++--
> > arch/powerpc/kernel/idle_book3e.S|2 +-
> > arch/powerpc/kernel/idle_e500.S  |4 ++--
> > arch/powerpc/kernel/idle_power4.S|2 +-
> > arch/powerpc/kernel/misc_32.S|4 ++--
> > arch/powerpc/kvm/bookehv_interrupts.S|6 +-
> > arch/powerpc/mm/hash_low_32.S|8 
> > arch/powerpc/sysdev/6xx-suspend.S|2 +-
> > 15 files changed, 46 insertions(+), 42 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/exception-64s.h 
> > b/arch/powerpc/include/asm/exception-64s.h
> > index d58fc4e..5dbd00d 100644
> > --- a/arch/powerpc/include/asm/exception-64s.h
> > +++ b/arch/powerpc/include/asm/exception-64s.h
> > @@ -293,7 +293,7 @@ label##_hv: 
> > \
> >
> > #define RUNLATCH_ON \
> > BEGIN_FTR_SECTION   \
> > -   clrrdi  r3,r1,THREAD_SHIFT; \
> > +   CURRENT_THREAD_INFO(r3, r1) \
> > ld  r4,TI_LOCAL_FLAGS(r3);  \
> > andi.   r0,r4,_TLF_RUNLATCH;\
> > beqlppc64_runlatch_on_trampoline;   \
> > @@ -332,7 +332,7 @@ label##_common: 
> > \
> > #ifdef CONFIG_PPC_970_NAP
> > #define FINISH_NAP  \
> > BEGIN_FTR_SECTION   \
> > -   clrrdi  r11,r1,THREAD_SHIFT;\
> > +   CURRENT_THREAD_INFO(r11, r1)\
> > ld  r9,TI_LOCAL_FLAGS(r11); \
> > andi.   r10,r9,_TLF_NAPPING;\
> > bnelpower4_fixup_nap;   \
> > diff --git a/arch/powerpc/include/asm/thread_info.h 
> > b/arch/powerpc/include/asm/thread_info.h
> > index 68831e9..3760620 100644
> > --- a/arch/powerpc/include/asm/thread_info.h
> > +++ b/arch/powerpc/include/asm/thread_info.h
> > @@ -74,6 +74,14 @@ static inline struct thread_info 
> > *current_thread_info(void)
> > return (struct thread_info *)(sp & ~(THREAD_SIZE-1));
> > }
> >
> > +#else
> > +
> > +#ifndef CONFIG_PPC64
> 
> Oh no! The logic is still backwards :(

Doh...somehow I missed that comment in your previous reply.  Will fix 
that.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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 failure after merge of the kvm-ppc tree
> 
> 
> On 05.07.2012, at 07:49, Stephen Rothwell wrote:
> 
> > Hi Alexander,
> >
> > After merging the kvm-ppc tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> > arch/powerpc/kernel/exceptions-64s.S:479: Error: wrong number of operands
> > arch/powerpc/kernel/exceptions-64s.S:486: Error: wrong number of operands
> > arch/powerpc/kernel/exceptions-64s.S:486: Error: wrong number of operands
> > arch/powerpc/kernel/exceptions-64s.S:487: Error: wrong number of operands
> > arch/powerpc/kernel/exceptions-64s.S:487: Error: wrong number of operands
> > arch/powerpc/kernel/exceptions-64s.S:494: Error: wrong number of operands
> > arch/powerpc/kernel/exceptions-64s.S:494: Error: wrong number of operands
> >
> > Caused by commit bc8cc4993e19 ("PPC: use CURRENT_THREAD_INFO instead of
> > open coded assembly").  The fact that this patch has problems was already
> > pointed out on the linuxppc-dev mailing list and it clearly hasn't been
> > build tested.
> >
> > I have used the version of the kvm-ppc tree from next-20120703 for today.
> 
> Ah, yes, thanks. I kept the old, broken version in my tree to make sure I 
> have the dependencies for (and
> don't forget) the (hopefully good) patches that follow on top, but was 
> planning to replace it once we
> have a new version of the CURRENT_THREAD_INFO one.
> 
> Stuart, could you please send a new version of the CURRENT_THREAD_INFO patch?

Yes, will send that shortly.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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: [PATCH] define binding for fsl mpic interrupt controllers
> 
> Hi Stuart,
> 
> > From: Stuart Yoder
> >
> > define the binding for compatible = "fsl,mpic", including the
> > definition of 4-cell interrupt specifiers.  The 3rd and 4th cells are
> > needed to define additional types of interrupt source outside the
> > "normal"
> > external and internal interrupts in FSL SoCs.  Define error interrupt,
> > IPIs, and PIC timer sources.
> 
> Recently I posted an RFC concerning a binding for the MPIC [1].  I also
> submitted a patch based on that feedback today (patch subject '[PATCH 1/2]
> powerpc: document the MPIC device tree binding').  You provide much more
> information concerning the interrupt sources and how interrupt specifiers
> are encoded.  I had a few more properties listed: 'name', 'device_type',
> 'protected-sources', and 'no-reset'.  The 'no-reset'
> property is a proposed addition to the binding, the others are already in
> use.
> 

I'm not sure a complete merge into one binding makes sense.  The thing that
motivated creating this new binding with 4 cells was a thread from
last year.  See:

http://lists.ozlabs.org/pipermail/devicetree-discuss/2010-January/001489.html

Since Freescale had the need to represent additional information
in interrupt specifiers (error ints, timers, ipis), the suggestion
at the end was to add additional cells in a FSL-specific binding.
So this really is a Freescale specific thing and does belong in the
Freescale binding directory.

That being said, if there is consensus on the AMP related properties,
I should probably incorporate those as well-- protected-sources
and no-reset.

I'll separately comment on your mpic binding patch.

Stuart 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> 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 been in use for quite
> some time, and adds one new property 'no-reset', which controls whether the
> MPIC should be reset during runtime initialization.
> 
> Signed-off-by: Meador Inge 
> CC: Hollis Blanchard 
> ---
>  Documentation/powerpc/dts-bindings/mpic.txt |   78

This is really the binding for an open-pic interrupt controller
and I think the name should reflect that-- open-pic.txt.

> +++
>  1 files changed, 78 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/powerpc/dts-bindings/mpic.txt
> 
> diff --git a/Documentation/powerpc/dts-bindings/mpic.txt
> b/Documentation/powerpc/dts-bindings/mpic.txt
> new file mode 100644
> index 000..3a67919
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/mpic.txt
> @@ -0,0 +1,78 @@
> +* MPIC Binding
> +
> +This binding specifies what properties and child nodes must be
> +available on the device tree representation of the "MPIC" interrupt
> +controller.  This binding is based on the binding defined for Open PIC
> +in [1] and is a superset of that binding.

I think it would be better to base this on the ePAPR binding which
was based on the original chrp binding.  Properties like "name"
and "device_type" are deprecated not being used in flat device trees.



The proposed new properties really should go back into the ePAPR. 

> +
> +** Required properties:
> +
> +   NOTE: Many of these descriptions were paraphrased from [1] to aid
> +         readability.
> +
> +   - name : Specifies the name of the MPIC.

Drop this.  No DTS files use it.

> +   - device_type : Specifies the device type of this MPIC.  The value
> + of this
> +                   property shall be "open-pic".

device_type is deprecated, since this is not real open-firmware.  In
practice the kernel is matching on device_type, but we want to move
away from that to match on "compatible", just hasn't been implemented
yet.

> +   - reg : Specifies the base physical address(s) and size(s) of this
> + MPIC's
> +           addressable register space.
> +   - compatible : Specifies the compatibility list for the MPIC.  The
> + property
> +                  value shall include "chrp,open-pic".

In the ePAPR we modified this to just "open-pic", because this has
nothing to do with chrp anymore.   I think just "open-pic" is
what we want.

> +   - interrupt-controller : The presence of this property identifies
> + the node
> +                            as a MPIC.  No property value should be
> defined.
> +   - #address-cells : Specifies the number of cells needed to encode an
> +                      address.  The value of this property shall always
> + be 0
> +                      so that 'interrupt-map' nodes do not have to
> + specify a
> +                      parent unit address.
> +   - #interrupt-cells : Specifies the number of cells needed to encode
> + an
> +                        interrupt source.

Should be 2, correct?

> +** 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 use and whose corresponding
> + vectors
> +                         should not be initialized.  A typical use case
> + for
> +                         this property is in AMP systems where multiple
> +                         independent operating systems need to share
> + the MPIC
> +                         without clobbering each other.

I do think you need to include the definition of interrupt
specifiers here.   Feel free to cut/paste text from my
Freescale mpic binding.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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] powerpc: document the MPIC device tree binding
> 
> On 01/18/2011 02:21 PM, Yoder Stuart-B08248 wrote:
> >>   Documentation/powerpc/dts-bindings/mpic.txt |   78
> >
> > This is really the binding for an open-pic interrupt controller and I
> > think the name should reflect that-- open-pic.txt.
> 
> Yup, agreed.
> 
> >> +This binding specifies what properties and child nodes must be
> >> +available on the device tree representation of the "MPIC" interrupt
> >> +controller.  This binding is based on the binding defined for Open
> >> +PIC in [1] and is a superset of that binding.
> >
> > I think it would be better to base this on the ePAPR binding which was
> > based on the original chrp binding.  Properties like "name"
> > and "device_type" are deprecated not being used in flat device trees.
> >
> > <http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pd
> > f>
> >
> > The proposed new properties really should go back into the ePAPR.
> 
> I read portions of ePAPR while writing this binding and considered that.
>   My only worry was that ePAPR is focused on embedded systems and this
> binding will have to cover non-embedded systems that exist in the kernel.
> However, perhaps that is not a legitimate concern?

The ePAPR tried to codify what was previously implemented in
Linux, so I don't think lack of things like "name" and
"device_type" in the binding are an issue.

> >> +
> >> +** Required properties:
> >> +
> >> +   NOTE: Many of these descriptions were paraphrased from [1] to aid
> >> + readability.
> >> +
> >> +   - name : Specifies the name of the MPIC.
> >
> > Drop this.  No DTS files use it.
> 
> Done.
> 
> >> +   - device_type : Specifies the device type of this MPIC.  The
> >> + value of this
> >> +   property shall be "open-pic".
> >
> > device_type is deprecated, since this is not real open-firmware.  In
> > practice the kernel is matching on device_type, but we want to move
> > away from that to match on "compatible", just hasn't been implemented
> > yet.
> 
> I will drop this property with the expectation that the kernel will be
> fixed.  From a quick grep of '.../arch/powerpc' it looks like most uses are
> of the form:
> 
>  np = of_find_node_by_type(NULL, "open-pic");
>  if (np == NULL)
> return;
> 
> In most of these cases I suppose the 'of_find_node_by_type' calls could
> just be replaced with calls to 'of_find_compatible_node(NULL, "open-pic")'.

For backwards compatibility, we should continue to accept
the old/deprecated device_type="open-pic", but in addition
we should accept the compatible="open-pic".

> >> +   - reg : Specifies the base physical address(s) and size(s) of this
> >> + MPIC's
> >> +   addressable register space.
> >> +   - compatible : Specifies the compatibility list for the MPIC.  The
> >> + property
> >> +  value shall include "chrp,open-pic".
> >
> > In the ePAPR we modified this to just "open-pic", because this has
> > nothing to do with chrp anymore.   I think just "open-pic" is
> > what we want.
> 
> OK, but as a migration path we should allow the kernel to accept both
> (Scott mentioned this in another reply), but "open-pic" is the
> documented correct way.

Right.

> >> +   - interrupt-controller : The presence of this property identifies
> >> + the node
> >> +as a MPIC.  No property value should be
> >> defined.
> >> +   - #address-cells : Specifies the number of cells needed to encode an
> >> +  address.  The value of this property shall always
> >> + be 0
> >> +  so that 'interrupt-map' nodes do not have to
> >> + specify a
> >> +  parent unit address.
> >> +   - #interrupt-cells : Specifies the number of cells needed to encode
> >> + an
> >> +interrupt source.
> >
> > Should be 2, correct?
> 
> Yup.
> 
> >> +** Optional 

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

[Yoder Stuart-B08248]

> +** 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 use and whose corresponding
> + vectors
> +                         should not be initialized.  A typical use case
> + for
> +                         this property is in AMP systems where multiple
> +                         independent operating systems need to share
> + the MPIC
> +                         without clobbering each other.

Is "protected-sources" really needed for AMP systems to
tell the OSes not to clobber each other?  Won't each
OS be given a device tree with only its interrupt
sources?  ...so you know what you are allowed to touch.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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
> Subject: Re: [PATCH 1/2] powerpc: document the MPIC device tree binding
> 
> On 01/19/2011 04:14 PM, Yoder Stuart-B08248 wrote:
> >
> >> +** 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 use and whose corresponding
> >> + vectors
> >> + should not be initialized.  A typical use
> >> + case for
> >> + this property is in AMP systems where multiple
> >> + independent operating systems need to share
> >> + the MPIC
> >> + without clobbering each other.
> >
> > Is "protected-sources" really needed for AMP systems to tell the OSes
> > not to clobber each other?  Won't each OS be given a device tree with
> > only its interrupt sources?  ...so you know what you are allowed to
> > touch.
> 
> This was discussed a little bit already [1, 2].  The MPIC driver currently
> initializes the VECPRI register for all interrupt sources, which can lead
> to the aforementioned clobbering.

For sources that are protected and not to be touched, it seems
that the other need is for the OS to know (be guaranteed?) that
those sources have been put in state where the source is masked
or directed to other cores.   You can't have interrupts occurring
on sources that you are not allowed to initialize.

So the "no-reset" property could potentially cover this as well-- if it was
defined to mean "don't reset the mpic" and boot firmware has put all sources
in a sane initial state.   And we wouldn't need the "protected-sources"
property any longer.

Stuart


Right...so it would seem that the no-reset property if prop

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> > +  - 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 initialization related
> > + to
> > +          interrupt sources shall be limited to sources explicitly
> > + referenced
> > +          in the device tree.
> 
> Please follow the lead set by the other binding documentation which is more
> concise and tends to be of the form:
> 
> Required properties:
> - reg : 
> - interrupt-controller : 
> 
> Optional Properties:
> - no-reset : blah
> 
> I'm considering formalizing the binding format so that fully specified and
> cross-referenced documentation can be generated from the bindings
> directory.

Regarding the format-- The definition should also to specify the value
type.  I don't see this being consistently done in existing bindings.  
They are not completely unclear, but using consistent terms might help.

The ePAPR uses this convention:

  # no value, a Boolean
# A 32-bit integer in big-endian format
# A 64-bit integer in big-endian format
 # null terminated
 # format specific to the property
   # A  value, referecnes another node
  # A list of  values concatenated together.

The identifier prop-encoded-array came from precedence in other
of binding and ieee1275.   prop-encoded-arrays should be
be specifically defined in terms of # of cells and the 
meaning of each cell.

If you use the above types identifiers, there is no ambiguity.

Also, there are properties that don't necessarily fall in 'required'
and 'optional', but may be required depending on the context.  Thus
the 'Usage' identifier which Meador derived from my mpic binding
posted.   Usage could be:
   Required
   Optional
   See Definition

Stuart


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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: Hollis Blanchard; devicetree-disc...@lists.ozlabs.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v3 1/4] powerpc: Removing support for 'protected-
> sources'
> 
> 
> > In my previous reply I said that "it is not so much as a need as it is
> > a potential simplification."  After further reflection, I don't think
> > that is completely true.  As we get into AMP systems with higher core
> > counts, then implementing this functionality using the existing
> > "protected-sources" implementation versus the new "pic-no-reset" work
> > is going to be harder to maintain.
> 
> I'm not arguing that your approach isn't more suitable for AMP systems, I
> just want to leave the existing protected-sources mechanism alone. I'm not
> opposing adding a new, better, mechanism for newer platforms.
> 
> However, I'd name it differently. "pic-no-reset" doesn't carry enough
> meaning in that case. What we want to point out here is that the PIC has
> been pre-initialized.
> 
> Another option, which may be cleaner, is to stick to "no-reset" (no need
> for pic- prefix) and make it do just that (prevent the reset), and then use
> a positive variant of "protected-sources", call it "allowed-sources". Maybe
> even make it a series of ranges. Then have the MPIC only access these.
> 
> I think this is more robust as it would also prevent "accidental" use of
> the wrong sources (bad device-tree, drivers that let you muck around with
> irq numbers, etc...).

What is the use case for "allowed-sources"?   For AMP the only device
nodes in your device tree should be your AMP partition's devices,
thus any interrupt specifiers in your dev tree are "allowed".

The MPIC is a shared device and thus the need for no-reset.

So, all newer platforms should need is "no-reset".

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> -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/4] powerpc: Open PIC binding and "pic-no-reset"
> 
> Apologies for the bad post.  Bad day for email ...  Please ignore the top
> reply in my previous reply.  The full reply is the below the quote.
> 
> On Thu, Feb 10, 2011 at 8:01 PM, Meador Inge 
> wrote:
> >
> > On 02/10/2011 02:42 PM, Meador Inge wrote:
> >>
> >> -- Forwarded message --
> >> From: Meador Inge
> >> Date: Fri, Feb 4, 2011 at 5:25 PM
> >> Subject: [PATCH v3 0/4] powerpc: Open PIC binding and "pic-no-reset"
> >> To: linuxppc-dev@lists.ozlabs.org
> >> Cc: devicetree-disc...@lists.ozlabs.org, Hollis Blanchard<
> >> hollis_blanch...@mentor.com>
> >>
> >>
> >> This patch set provides a binding for Open PIC and implements support
> >> for a new property, specified by that binding, called "pic-no-reset".
> >> With "pic-no-reset" in place the "protected-sources" property is no
> >> longer needed and its full implementation was removed.
> >> "protected-sources" is still checked for, however, for legacy
> >> purposes.
> >>
> >> For v3 of this patch the Open PIC binding was changed to be more
> >> consistent with existing bindings, several DTS files were cleaned up,
> >> "no-reset" was changed to "pic-no-reset", and a check to treat
> >> "protected-sources" as a synonym for "pic-no-reset" was added.
> >>
> 
> From the feedback I have received so far, the fundamental ideas in this
> patch set are sane.  However, the following issues still need agreement:
> 
>     1. What should be the name of the no reset property?
>        "pic-no-reset" or "no-reset"?
>     2. Should we just keep the existing protected sources implementation
>        in place?
> 
> For (1), I prefer "no-reset".

I also prefer plain "no-reset".  The property is on a pic node so
"pic" on the property seems redundant.

> For (2), I still think that we can make "no-
> reset" a synonym for "protected-sources" and that things will work out.
> 
> Ben, you said that you would really like to leave the protected sources
> implementation alone.  Is the mechanism implemented in "PATCH
> v3 3/4" [1] of having "protected-sources" as a synonym for "pic-no-reset"
> not suitable?

I thought what Ben was getting at was that there is existing
firmware that may provide a device tree with protected-sources,
and thus we should continue supporting it for backwards
compatibility.

So, I would say add "no-reset" as the preferred mechanism
going forward, but keep "protected-sources" for backwards
compatibility.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

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", or "fsl,P4080DS".
These work but neither is quite accurate this is used on all targets
regardless of the underlying physical hardware.  Also, the guest
device tree represents virtual devices as well as a subset of the
cpus, memory, and devices on the hardware platform.

So continuing to use "MPC8544DS" or "fsl,P4080DS" compatible for all QEMU/KVM
created virtual machines is misleading and seems hackish.  They are
compatible to a degree, but the virtual platform would typically
be quite different.

What do you all think about creating some new somewhat generic 
machine types in Linux to represent these 2 types of virtual
platforms.  Perhaps:

   "MPC85xxDS" - for a virtual machine for the e500v2 type platforms
 and would support 85xx targets, plus P2020, P1022,etc

   "corenet-32-ds" - for a virtual machine similar to the 32-bit P4080
 platforms

   "corenet-64-ds" - for a virtual machine based on a 64-bit corenet
 platform


Thoughts?

Thanks,
Stuart Yoder

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -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: top level compatibles for virtual platforms
> 
> On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248  
> wrote:
> 
> >   "MPC85xxDS" - for a virtual machine for the e500v2 type platforms
> >                 and would support 85xx targets, plus P2020, P1022,etc
> >
> >   "corenet-32-ds" - for a virtual machine similar to the 32-bit P4080
> >                     platforms
> >
> >   "corenet-64-ds" - for a virtual machine based on a 64-bit corenet
> >                     platform
> 
> I think we should drop the "DS" because that's a name applied to certain 
> Freescale reference
> boards.
> 
> Is being a CoreNet board really something meaningful with respect to KVM?  I 
> don't see the
> connection.

We're talking about what would be meaningful to Linux as a guest on
this platform here--  Corenet-based SoCs are similar 
in various ways, like using msgsnd for IPIs, having external proxy
support, etc.

A corenet platform created by a QEMU/KVM looks similar
to other corenet SoCs.   So, I'm trying to find some generic
compatible string that describes this platform.

> Also, if these are KVM creations, shouldn't there be a "kvm" in the 
> compatible string
> somewhere?

There is nothing KVM specific about these platforms.  Any hypervisor
could create a similar virtual machine.

A guest OS can determine specific info about the hypervisor it is
running on by looking at the /hypervisor node on the device
tree.

We could put a generic -hv extension to indicate that this is
a virtual platform.

 "mpc85xx-hv"
 "corenet-32-hv"
 "corenet-64-hv"

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -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; Wood Scott-
> B07421; Alexander Graf; linuxppc-...@ozlabs.org
> Subject: Re: RFC: top level compatibles for virtual platforms
> 
> On Friday, July 8, 2011, Tabi Timur-B04825  wrote:
> > On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248
> >  wrote:
> >
> >>   "MPC85xxDS" - for a virtual machine for the e500v2 type platforms
> >>                 and would support 85xx targets, plus P2020, P1022,etc
> >>
> >>   "corenet-32-ds" - for a virtual machine similar to the 32-bit P4080
> >>                     platforms
> >>
> >>   "corenet-64-ds" - for a virtual machine based on a 64-bit corenet
> >>                     platform
> >
> > I think we should drop the "DS" because that's a name applied to
> > certain Freescale reference boards.
> >
> > Is being a CoreNet board really something meaningful with respect to
> > KVM?  I don't see the connection.
> >
> > Also, if these are KVM creations, shouldn't there be a "kvm" in the
> > compatible string somewhere?
> 
> I would say so. That would accurately describe the execution environment.

As I mentioned to Timur, there is nothing KVM specific about
the execution environment.   The /hypervisor node (as per 
ePAPR 1.1) describes hypervisor specific info.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -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
> Subject: Re: RFC: top level compatibles for virtual platforms
> 
> On Mon, 11 Jul 2011 10:45:47 -0500
> Timur Tabi  wrote:
> 
> > >> Also, if these are KVM creations, shouldn't there be a "kvm" in the
> > >> compatible string somewhere?
> > >
> > > There is nothing KVM specific about these platforms.  Any hypervisor
> > > could create a similar virtual machine.
> >
> > True, but I think we're on a slippery slope, here.  Virtualization
> > allows us to create "virtual platforms" that are not well defined.
> > Linux requires a unique compatible string for each platform.
> 
> The device tree is supposed to describe the hardware (virtual or otherwise), 
> not just supply
> what Linux wants.  Perhaps there simply shouldn't be a toplevel compatible if 
> there's nothing
> appropriate to describe there -- and fix whatever issues Linux has with that.

But there is a concept in Linux of a platform 'machine':

define_machine(p4080_ds) {
.name   = "P4080 DS",
.probe  = p4080_ds_probe,
.setup_arch = corenet_ds_setup_arch,
.init_IRQ   = corenet_ds_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
#endif
.get_irq= mpic_get_coreint_irq,
.restart= fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
.progress   = udbg_progress,
};

Right now p4080_ds_probe needs something to match on to determine
whether this is the machine type.   How would it work if 
there was no top level compatible to match on?   Some 
platforms (e.g. e500v2-type) need mpc85xx_ds_pic_init(),
others need corenet_ds_pic_init().  We need a way to
select the machine.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -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
> Subject: Re: RFC: top level compatibles for virtual platforms
> 
> On Mon, 11 Jul 2011 12:41:20 -0500
> Yoder Stuart-B08248  wrote:
> 
> >
> >
> > > -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
> > > Subject: Re: RFC: top level compatibles for virtual platforms
> > >
> > > On Mon, 11 Jul 2011 10:45:47 -0500
> > > Timur Tabi  wrote:
> > >
> > > > >> Also, if these are KVM creations, shouldn't there be a "kvm" in
> > > > >> the compatible string somewhere?
> > > > >
> > > > > There is nothing KVM specific about these platforms.  Any
> > > > > hypervisor could create a similar virtual machine.
> > > >
> > > > True, but I think we're on a slippery slope, here.  Virtualization
> > > > allows us to create "virtual platforms" that are not well defined.
> > > > Linux requires a unique compatible string for each platform.
> > >
> > > The device tree is supposed to describe the hardware (virtual or
> > > otherwise), not just supply what Linux wants.  Perhaps there simply
> > > shouldn't be a toplevel compatible if there's nothing appropriate to 
> > > describe there -- and
> fix whatever issues Linux has with that.
> >
> > But there is a concept in Linux of a platform 'machine':
> 
> So have a Linux "machine" that is used when no other one matches.  That 
> doesn't justify making
> something up in the device tree.
> 
> > define_machine(p4080_ds) {
> > .name   = "P4080 DS",
> > .probe  = p4080_ds_probe,
> > .setup_arch = corenet_ds_setup_arch,
> > .init_IRQ   = corenet_ds_pic_init,
> > #ifdef CONFIG_PCI
> > .pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
> > #endif
> > .get_irq= mpic_get_coreint_irq,
> > .restart= fsl_rstcr_restart,
> > .calibrate_decr = generic_calibrate_decr,
> > .progress   = udbg_progress,
> > };
> >
> > Right now p4080_ds_probe needs something to match on to determine
> > whether this is the machine type.   How would it work if
> > there was no top level compatible to match on?   Some
> > platforms (e.g. e500v2-type) need mpc85xx_ds_pic_init(), others need
> > corenet_ds_pic_init().
> 
> Just because Linux does it that way now doesn't mean it needs to.  The 
> interrupt controller
> has a compatible property.  Match on it like any other device.  You can find 
> which one is the
> root interrupt controller by looking for nodes with the interrupt-controller 
> property that
> doesn't have an explicit interrupt-parent (or an interrupts property?  seems 
> to be a conflict
> between ePAPR and the original interrupt mapping document).

This may be the right long term thing to do, but restructuring
how Linux powerpc platforms work is a bigger effort.  I was looking
for an incremental improvement over what we do now, which is pass
a compatible of MPC8544DS and P4080DS for these virtual platforms.

However, they _are_ compatible with MPC8544DS and P4080DS so maybe
leaving the compatible string alone is ok for now.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -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
> Subject: Re: RFC: top level compatibles for virtual platforms
> 
> On Mon, 11 Jul 2011 15:41:35 -0500
> Yoder Stuart-B08248  wrote:
> 
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Monday, July 11, 2011 1:05 PM
> > >
> > > Just because Linux does it that way now doesn't mean it needs to.
> > > The interrupt controller has a compatible property.  Match on it
> > > like any other device.  You can find which one is the root interrupt
> > > controller by looking for nodes with the interrupt-controller
> > > property that doesn't have an explicit interrupt-parent (or an interrupts 
> > > property?  seems
> to be a conflict between ePAPR and the original interrupt mapping document).
> >
> > This may be the right long term thing to do, but restructuring how
> > Linux powerpc platforms work is a bigger effort.  I was looking for an
> > incremental improvement over what we do now, which is pass a
> > compatible of MPC8544DS and P4080DS for these virtual platforms.
> 
> A hack is usually easier than doing it right. :-)
> 
> Though often the effort required for the latter is overstated, and the "right 
> long term thing"
> never makes the jump to "short term plan".
> 
> There are a few things that need to be driven off the device tree that 
> currently aren't --
> using some mechanism other than the standard device model, if necessary (or 
> as a first step) -
> - and then we need a does-nothing default platform as the match of last 
> resort.
> 
> > However, they _are_ compatible with MPC8544DS and P4080DS so maybe
> > leaving the compatible string alone is ok for now.
> 
> The virtual platforms are not compatible with MPC8544DS or P4080DS.  Only a 
> subset of what is
> on those boards is provided.  And in the case of direct device assignment, 
> often the things
> that are present are incompatible (e.g.
> different type of eTSEC).

Hmm.  Perhaps what we need is a real binding that defines specifically
what those compatibles mean.   While not identical, a KVM
virtual machine is compatible in certain areas with those
boards.

The ePAPR defines the top level compatible as:

Specifies a list of platform architectures with which this
platform is compatible. This property can be used by
operating systems in selecting platform specific code.

1275 doesn't mention compatible on the root from what I can
see.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RFC: replace device_type with new "class" property?

[Yoder Stuart-B08248]

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 identified in the
flat device tree model?   A device class, as I'm using it,
refers basically to general categories of devices-- devices
that share common properties.   Examples in current device
would be "cpu", "memory", "pci", "network", "serial".

Today the device_type property serves this purpose to some
degree.  However, the original meaning of device_type in
Open Firmware is related to the method interface of a node
it has a recent history of abuse in the Linux kernel DTS
files, with a plethora of types made up in an ad hoc way.
In addition, an OS can match on "compatible" and in the
absence of method interfaces really doesn't need
device_type anyway.

However, one good thing about device_type (if properly used)
is that it could identify which device nodes follow an official
binding, vs proprietary devices or one-off device node definitions.
Without something like device_type the _human_ reader of a DTS
file has to infer from the name or compatible what the device
type is.  So, device class identifiers like "memory", "cpu",
"serial", "pci", "network" provide that clarity.

So, what should the long term approach be?  Here are a couple
of options:

1.  Keep device_type, with it's use specifically defined to
mean that the node with that property implements an
'official' binding.   In the flat device tree model a
binding is just a defined set of required (and optional
properties.

2.  Get rid of device_type and create a _new_ property like
"class".  The only nodes permitted to have this property
are those with 'official' bindings.  These nodes would
have a set of required (and optional) properties.

The benefit of a new property is cutting all baggage
associated with the old device_type property.

One other point-- the intent of a device class is not
necessarily to specify a sufficient set of properties
to implement drivers.  The "network" class would have
a base set of required properties (e.g. mac-address,etc),
but most likely would need additional properties
to implement a driver for a specific device.  The value
in the class is when a developer needs to represent
a new device that fits into an existing class he has a base
set of properties to start with that has had some good
thinking put into defining it.  A device class would
facilitate and encourage consistent use of properties
names, which would be a good thing.

The initial list of official classes would be small--
"cpu","memory", "cache", "pci", "serial", "network",
"open-pic"(?).  As other types get codified in actual use
and have official bindings specified (perhaps through
power.org) new types would be supported--e.g. "i2c",
"jdec-flash".

Thoughts?

Stuart Yoder
Freescale Semiconductor, Inc.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

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>;
reg = <2200 200>;
interrupts = <22>;
interrupt-parent = < &qeic >;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <19>;
tx-clock = <1a>;
phy-handle = < &phy3 >;
pio-handle = < &pio3 >;
  

  > This is bad IMHO because the human reader has to
  > infer the class of device.  Can the human reader
  > tell if it implements a standardized binding or
  > not??

#2 use device_type

  [EMAIL PROTECTED] {
device_type = "network";
compatible = "fsl,ucc_geth";
model = "UCC";
device-id = <3>;
reg = <2200 200>;
interrupts = <22>;
interrupt-parent = < &qeic >;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <19>;
tx-clock = <1a>;
phy-handle = < &phy3 >;
pio-handle = < &pio3 >;
  };

  > This is better...I can tell it implments the network
  > binding.   The problem is the past abuse and OF
  > connotations.

#3 use a new "class" property

  [EMAIL PROTECTED] {
class = "network";
compatible = "fsl,ucc_geth";
model = "UCC";
device-id = <3>;
reg = <2200 200>;
interrupts = <22>;
interrupt-parent = < &qeic >;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <19>;
tx-clock = <1a>;
phy-handle = < &phy3 >;
pio-handle = < &pio3 >;
  };

  > This is good...I can tell it implments the "network"
  > binding.   There is no association with the abused
  > OF device_type.

#4 use "compatible"

  [EMAIL PROTECTED] {
compatible = "fsl,ucc_geth","[official spec],network";
model = "UCC";
device-id = <3>;
reg = <2200 200>;
interrupts = <22>;
interrupt-parent = < &qeic >;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <19>;
tx-clock = <1a>;
phy-handle = < &phy3 >;
pio-handle = < &pio3 >;
  };

  > I don't like this...we are overloading "compatible" with
  > stuff that is not specifying a programming interface.  compatible
  > is supposed to be specifying a programming interface which
  > the device complies to.


Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

 

> -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 Stuart-B08248 wrote:
> > 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>;
> > reg = <2200 200>;
> > interrupts = <22>;
> > interrupt-parent = < &qeic >;
> > mac-address = [ 00 00 00 00 00 00 ];
> > local-mac-address = [ 00 00 00 00 00 00 ];
> > rx-clock = <19>;
> > tx-clock = <1a>;
> > phy-handle = < &phy3 >;
> > pio-handle = < &pio3 >;
> 
> Of course, this should properly be something like
> 
> [EMAIL PROTECTED] {
>   compatible = "fsl,mpc8360-qe-enet", "fsl,qe-enet";
>   local-mac-address = [ 00 00 00 00 00 00 ];
>   ...
> };
> 
> With no "mac-address", and a more useful "model" if any at all.

That's fine, but as a human reader there is nothing
that would tell me this node implemented a defined
binding that specified required properties.

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

 

> -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?
> 
> On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote:
> [snip]
> > I don't see how switching the property name from "device_type" to
> > "class" is going to stop people from misunderstanding it's intended
> > use. There's nothing inherently more understandable in calling it
> > "class" -- it also invites people to make up their own class names
> > as they go along, just as what happened to "device_type".
> > 
> > I also don't understand the people wanting to use "compatible"
> > for _everything_. It's just mashing together two separate pieces of
> > information into one property, and I seriously don't see 
> how that helps
> > anything or anyone. It's absolutely useless for a driver to 
> be able to
> > bind to a compatible field of "standard,network" or 
> whatever it might be,
> > since there's no way that "standard," will imply that the 
> register layout
> > and programming model is somehow the same as all other 
> standard-labelled
> > devices.
> > 
> > So yes, there is a problem with the device trees and how 
> people build
> > them, and it requires education on how to properly craft 
> one. I don't
> > think changing the layout to either be flatter (only using 
> compatible),
> > or changing names of a property (device_type->class) will 
> help anything
> > at all.
> > 
> > I actually prefer keeping device_type myself, since it 
> means existing
> > OF-based device trees will already have some of the labels.
> 
> Yeah.. what he said.
> 
> The *only* substantive change with the "class" proposal is the fact
> that multiple classes can be specified.  That's nice, but I don't
> think it's worth the trouble of attempting to define a whole new chunk
> of standard for.

I tend to agree, but I think device_type serves a useful
purpose.   I don't think we should deprecate it.

> Stuart, I think you overestimate the value of this class property to a
> human reader.  The generic names convention (not followed as much as
> it should be) means the name should give the reader some idea of what
> the device is, in most cases.  For trickier cases, if we really want
> something for humans reading the tree, we could add an optional
> "comment" or "description" property with purely human readable
> information.
> 
> I think we should leave existing IEEE1275 defined uses of device_type,
> in order not to make flat trees gratuitously different from real-OF
> trees, but we should avoid any new use of device_type.

I'm fine with keeping device_type, but there are a few
of things I don't like about the 'no new use'.

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.

What if there is a _new_ class of nodes of this type?
What is wrong with a new use of device_type for something
say like "i2c"?

Conceptually and ideally, what _is_ the right way to
represent these types of devices.

2.  'Existing IEEE1275 defined uses' of device_type is 
actually very vague.  There are a conglomeration of
old bindings, recommended practices, proposals and
it is not clear at all which are useful or not.  What
are the existing IEEE1275 uses???   I actually went
through all the OF documents and there are dozens
of device types that have no practical use.

Also, many 'real-OF' trees seem to follow no published
binding at all.

Conceptually, I'd like to a crisp list of 'official'
bindings and hope that the current ePAPR work in
power.org will establish this list.

3.  You're advocating deprecating device_class, but still
requiring it for certain node types.  So a "network"
node is _required_ to have the deprecated
device_type="network".   But a "i2c" node is required
_not_ to have device_type.  Long term, I'd like to see
any inconsitency be removed.  If device_type is 
deprecated, it's use should be optional in flat 
device trees.   That goes for "cpu", "memory", etc.

I think what we should do is keep device_type, including
permitting new uses of it in a limited way-- only permitting
the us

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

[Yoder Stuart-B08248]

> 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 know how cute it is, but I think it is practically 
helpful.   Take another example:

Say you-- a human reader-- see this in a device
tree:

...
interrupts = ;
interrupt-parent = < &mpic >;
...

What does the 'b' and '8' mean?  You look
at the interrupt controller node--

  mpic: [EMAIL PROTECTED] {
 clock-frequency = <0>;
 interrupt-controller;
 #address-cells = <0>;
 #interrupt-cells = <2>;
 reg = <4 4>;
 compatible = "fsl,xyz";
 big-endian;
}

Note-- I removed the device_type property and changed
compatible somewhat.  How are you going to find where
the meaning interrupt controller's interrupt cells are
defined?   What spec will you look at?

device_type = "open-pic"; makes it perfectly clear.
It's an open-pic type controller and follows that
binding.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

 

> -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?
> 
> On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> >   mpic: [EMAIL PROTECTED] {
> >  clock-frequency = <0>;
> >  interrupt-controller;
> >  #address-cells = <0>;
> >  #interrupt-cells = <2>;
> >  reg = <4 4>;
> >  compatible = "fsl,xyz";
> >  big-endian;
> > }
> > 
> > Note-- I removed the device_type property and changed
> > compatible somewhat.  How are you going to find where
> > the meaning interrupt controller's interrupt cells are
> > defined?   What spec will you look at?
> 
> The binding for fsl,xyz.

Not every string listed in compatible has a spec 
backing it (or should be required to).  You would
have to go look at the source code and cross your
fingers that the comments were sufficient.

Another good reason for device_type-- it helps 
distinguish between two similar classes of devices.
Both "open-pic" and "isa-pic" look very similar but
have different encodings of their interrupt cells.
Without a device_type it may be difficult or impossible
to distinguish them unless the "name" and
"compatible" are luckily clear enough.

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> > 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 statement below, I'm wondering how you think
"fundamental" nodes should be represented ideally?
 
> The *only* reason I'm suggesting leaving device_type values for
> IEEE1275 defined classes is so that flat trees written as flat trees
> look more similar to OF derived trees.

So, ideally (without respect to 1275) how should a "cpu"
node be represented and identified as a cpu node?

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

 
> > 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 flat tree
> bindings.  But the more time I've spent thinking about it, and the
> more time I've spent reviewing people's proposed bindings, the less
> useful I think it is.
> 
> The *only* reason I'm suggesting leaving device_type values for
> IEEE1275 defined classes is so that flat trees written as flat trees
> look more similar to OF derived trees.
> 
> > > 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.
> > > 
> > > Or to look at it another way, "class bindings" aren't 
> really bindings,
> > > but rather a set of conventions that device bindings for specific
> > > devices in that class ought to follow.
> > 
> > I tend to think of a 'binding' as a 'set of conventions'.
> 
> Well, whatever.  My point is that conventions are most flexible if you
> don't have to explicitly announce that you're following them - you
> just go ahead and follow as many conventions as make sense for your
> device.

Let me repeat what I think you are advocating--  we should
treat the collection of properties for 'established' device
classes like like "network", "serial", etc as a set of useful 
conventions.  That is, there are no set of _required_ properties
per se, but the device tree creator picks from the established
properties plus supplementing with "company,xyz" properties
in whatever way they think makes sense for them.

This works...but certainly is weaker with respect to
standardization.  My previous argument had the assumption
that something like "mac-address" in a network node was
_required_, and thus needed a class id of some sort to tie
the standardized node to.

If we relax things so there are no required properties for
device nodes, then I agree that a device class property
has limited or no value.

However, maybe we do want to keep device_type in 
a very limited way to define requirements for what you
call 'fundamental' types of nodes.  It may be that certain
properties in a "cpu" node (like cache-size?) should be
_required_ so that an OS that consumes the device tree
can really count on certain properties being there.  Or,
I guess we could use "compatible" for that...?

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Refactor booting-without-of.txt

[Yoder Stuart-B08248]

 

> -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
> booting-without-of.txt seems to be getting a little unwieldy.  Plus
> with more than one arch using the device tree (powerpc, sparc &
> microblaze) the device tree bindings aren't necessarily powerpc only
> (the Xilinx devices certainly fall in this category).
> 
> Anyone have comments about splitting the expected device tree bindings
> out of booting-without-of.txt into a separate directory?
> 
> Perhaps something like this; each file contains common bindings for
> the type of device and device specific properties:
> 
> Documentation/of/
> Documentation/of/README - Description of the purpose and layout of
> this directory
> Documentation/of/net.txt - network device bindings (eth, 
> MDIO, phy, etc)
> Documentation/of/serial.txt - serial device bindings
> Documentation/of/misc.txt - anything that doesn't fit 
> anywhere else yet.
> Documentation/of/soc/* - System on chip stuff that doesn't fit will
> into established device types; possibly a separate file for each chip.
> Documentation/of/usb.txt - usb blah blah blah
> Documentation/of/whatever - you get the picture.
> 

I agree in principle with what your are proposing.

One other thing to consider-- as has been publicly 
announced in several forums, a committee in power.org
(including several folks on this thread) is working
on a standard called the ePAPR which in general is
attempting to standardize the base set of requirements
and boot conventions that apply to the flat device tree.
There will not be much device specific stuff to 
start with.

The ePAPR document is actually quite far a long
and is well beyond the 'idea' stage.

The one point is that we hope that the device tree
with be useful for other embedded OSes beyond Linux.
So long term, I think this documentation should
be pulled out of the kernel source and put
on a public wiki that is not tied directly to Linux.
What you are proposing is a good start...

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

 

> -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?
> 
> On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote:
> > This works...but certainly is weaker with respect to
> > standardization.  My previous argument had the assumption
> > that something like "mac-address" in a network node was
> > _required_, and thus needed a class id of some sort to tie
> > the standardized node to.
> 
> It is certainly not required -- the device could have an 
> eeprom, or it might
> not be ethernet at all.

Fine, I picked a bad example. My point was that if a
property was _required_ that it should have a class id
of some sort that ties it back to the standard that
required it.

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

> > > > +   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
> implementation has "open-pic" but _should_ have "interrupt-controller"
> as that is the officially correct name.
> 
> I _think_ this means we need a transitional period where we update
> the code to look for "interrupt-controller", and obsoletedly, looks
> for the "open-pic", while we transition to the new, correct name.

"open-pic" is the correct value for the device_type property.
See the binding at:
http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps
That is the definition for open pic interrupt controllers (AFAIK).

I am not aware of any official binding with "interrupt-controller" 
as the device_type.

However, the interrupt mapping spec says that all interrupt
controller (regardless of device_type) must have a 
property named "interrupt-controller" to identify
the device node as an interrupt controller and root of
a interrupt tree.
See: http://playground.sun.com/1275/practice/imap/imap0_9d.html

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

 

> -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
> 
> >> +Sense and level information follows the Linux convention
> >> +(specified in include/linux/interrupt.h) and should be encoded
> >> +as follows:
> >> +
> >> +   2 =  high to low edge sensitive type enabled
> >> +   8 =  active low level sensitive type enabled
> 
> > ... but it is probably worthwhile commentting that sense types 1 & 4
> > are not supported; just to fill in the obvious gaps.  :-)
> 
> Same for sense types 0, 3, 5, 6, ...
> 
> Just name the sense types 0 and 1, similar to what all other
> OF interrupt controller bindings do.

Actually, all I am trying to do with this patch is document the
current state of things.  The 2/8 sense type usage has been that
way for a long time, and I'll defer to the 83xx maintainers
if they see any value in changing it.

Right now there are many DTS files with level/sense set to values
like 8 and no indication anywhere where those values came from.

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

 

> -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 {
> 
> Why not just "interrupt-controller"?
> 
> > +   #address-cells = <0>;
> > +   #size-cells = <0>;
> 
> No need for these.

Isn't a good practice to put #address-cells in interrupt controller
nodes?

If the device tree has an interrupt map defined the interrupt
parent 'unit interrupt specifier' has to be interpreted according
to the #address-cells of the interrupt parent.  It seems like 
typical practice in the current DTS files to explicitly define this
in the interrupt controller.

Of course this particular device tree doesn't have an interrupt
map...

#size-cells is not needed.

Stuart

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

 

> -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 
> descriptons of the DeviceTree Complier
> 
> Jon Loeliger writes:
> 
> > and its formats, command lines, descriptions, etc,
> > over to the Device Tree Compiler repositories now.
> 
> Hrm, section II (DT block format) is a description of a kernel
> interface, and I think it should stay.  After all, there's nothing
> that says that you have to use dtc to generate the device tree blob,
> so there is no reason for the dtc source to be the only place where
> the format is specified.
> 
> I have no problem with that section being copied over to the dtc
> source.

I think creating copies is going to cause problems as now there will
be two document to be kept in sync.

What's wrong with simply putting a pointer/link in b-w-o.txt to the
DTC source repository and stating the the Linux kernel implements 
version x.y of the DTC binary blob standard.

After all, many standards may be used by the kernel (e.g. ELF) without
the
standard document itself being kept/mainatined in the kernel source
tree.

The DTB format down the road may be used by hypervisors (e.g. Xen) and
OSes other than Linux, and thus it makes to keep it independent of the
kernel.

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Yoder Stuart-B08248]

[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 you are doing a device walk or an
> interrupt tree walk is very confusing. As I said above, the default
> values are a source of more problem than anything else and I tend to
> think they should be banned.
> 
> I would personally be inclined to define that whatever spec we come up
> with always require #address-cells/#size-cells for any node that can
> have either device children or interrupt children, and ban default
> values alltogether.

Did you really mean #size-cells here?  Shouldn't it be #interrupt-cells?

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev