Re: [PATCH v2 0/3] powerpc: Open PIC binding and 'no-reset' implementation

[Kumar Gala]

On Feb 2, 2011, at 7:51 PM, Meador Inge wrote:

> This patch set provides a binding for Open PIC and implements support for
> a new property, specified by that binding, called 'no-reset'.  With 'no-reset'
> in place the 'protected-sources' property is no longer needed and was removed.
> 
> Signed-off-by: Meador Inge 
> CC: Hollis Blanchard 
> 
> Meador Inge (3):
>  powerpc: Removing support for 'protected-sources'
>  powerpc: document the Open PIC device tree binding
>  powerpc: make MPIC honor the 'no-reset' device tree property
> 
> Documentation/powerpc/dts-bindings/open-pic.txt |  115 +++
> arch/powerpc/include/asm/mpic.h |7 +-
> arch/powerpc/sysdev/mpic.c  |   92 --
> 3 files changed, 160 insertions(+), 54 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt
> 

Please cleanup all the .dts that are impacted by this.

- k
___
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

[Grant Likely]

On Wed, Feb 2, 2011 at 6:51 PM, Meador Inge  wrote:
> 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
> Open PIC should be reset during runtime initialization.
>
> The general formatting and interrupt specifier definition is based off of
> Stuart Yoder's FSL MPIC binding.
>
> Signed-off-by: Meador Inge 
> CC: Hollis Blanchard 
> CC: Stuart Yoder 
> ---
>  Documentation/powerpc/dts-bindings/open-pic.txt |  115 
> +++
>  1 files changed, 115 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt
>
> diff --git a/Documentation/powerpc/dts-bindings/open-pic.txt 
> b/Documentation/powerpc/dts-bindings/open-pic.txt
> new file mode 100644
> index 000..447ef65
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/open-pic.txt
> @@ -0,0 +1,115 @@
> +* Open PIC Binding
> +
> +This binding specifies what properties must be available in the device tree
> +representation of an Open PIC compliant interrupt controller.  This binding 
> is
> +based on the binding defined for Open PIC in [1] and is a superset of that
> +binding.
> +
> +PROPERTIES
> +
> +  NOTE: Many of these descriptions were paraphrased here from [1] to aid
> +        readability.
> +
> +  - compatible
> +      Usage: required
> +      Value type: 
> +      Definition: Specifies the compatibility list for the PIC.  The
> +          property value shall include "open-pic".
> +
> +  - reg
> +      Usage: required
> +      Value type: 
> +      Definition: Specifies the base physical address(s) and size(s) of this
> +          PIC's addressable register space.
> +
> +  - interrupt-controller
> +      Usage: required
> +      Value type: 
> +      Definition: The presence of this property identifies the node
> +          as an Open PIC.  No property value should be defined.
> +
> +  - #interrupt-cells
> +      Usage: required
> +      Value type: 
> +      Definition: Specifies the number of cells needed to encode an
> +          interrupt source.  Shall be 2.
> +
> +  - #address-cells
> +      Usage: required
> +      Value type: 
> +      Definition: Specifies the number of cells needed to encode an
> +          address.  The value of this property shall always be 0.
> +          As such, 'interrupt-map' nodes do not have to specify a
> +          parent unit address.
> +
> +  - 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.

Also, to avoid the potential of a future namespace collision, it would
not be a bad idea to name this openpic-no-reset or something that
makes it clear that this is a binding specific property.  "no-reset"
sounds generic enough to give me pause.

> +
> +INTERRUPT SPECIFIER DEFINITION
> +
> +  Interrupt specifiers consists of 2 cells encoded as
> +  follows:
> +
> +   <1st-cell>   interrupt-number
> +
> +                Identifies the interrupt source.
> +
> +   <2nd-cell>   level-sense information, encoded as follows:
> +                    0 = low-to-high edge triggered
> +                    1 = active low level-sensitive
> +                    2 = active high level-sensitive
> +                    3 = high-to-low edge triggered
> +
> +EXAMPLE 1
> +
> +    /*
> +     * An Open PIC interrupt controller
> +     */
> +       mpic: pic@4 {
> +        // This is an interrupt controller node.
> +               interrupt-controller;
> +
> +        // No address cells so that 'interrupt-map' nodes which reference
> +        // this Open PIC node do not need a parent address specifier.
> +               #address-cells = <0>;
> +
> +        // Two cells to encode interrupt sources.
> +               #interrupt-cells = <2>;
> +
> +        // Offset address of 0x4 and size of 0x4.
> +               reg = <0x4 0x4>;
> +
> +        // Compatible with Open PIC.
> +               compatible = "open-pic";
> +
> +        // The PIC should not be reset.
> +               no-reset;
> +       };
> +
> +EXAMPLE 2
> +
> +    /*
> +     * An interrupt generating device that is wired to an Open PIC.
> +     */
> +    serial0: serial@4500 {
> +        // Interrupt source '42' that is active high level-sensitive.
> +        // Not

Re: [PATCH v2 1/3] powerpc: Removing support for 'protected-sources'

[Arnd Bergmann]

On Thursday 03 February 2011, Meador Inge wrote:
> In a recent discussion [1, 2] concerning device trees for AMP systems, the
> question of whether we really need 'protected-sources' arose.  The general
> consensus was that if you don't want a source to be used, then it should *not*
> be mentioned in an 'interrupts' property.  If a source really needs to be
> mentioned, then it should be put in a property other than 'interrupts' with
> a specific binding for that use case.
> 
> [1] 
> http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/004038.html
> [2] 
> http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/003991.html

That doesn't work in the case that this code was written for:

http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg01394.html

The problem is that you don't want the mpic to initialize the interrupt
line to the default, but instead leave it at whatever the boot firmware
has set up. Note that interrupt is not listed in any "interrupts"
property of any of the devices on the CPU interpreting the device
tree, but it may be mentioned in the device tree that another CPU
uses to access the same MPIC.

Arnd
___
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

[Meador Inge]

On 02/03/2011 09:56 AM, Grant Likely wrote:

On Wed, Feb 2, 2011 at 6:51 PM, Meador Inge  wrote:

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
Open PIC should be reset during runtime initialization.

The general formatting and interrupt specifier definition is based off of
Stuart Yoder's FSL MPIC binding.

Signed-off-by: Meador Inge
CC: Hollis Blanchard
CC: Stuart Yoder
---
  Documentation/powerpc/dts-bindings/open-pic.txt |  115 +++
  1 files changed, 115 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt

diff --git a/Documentation/powerpc/dts-bindings/open-pic.txt 
b/Documentation/powerpc/dts-bindings/open-pic.txt
new file mode 100644
index 000..447ef65
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/open-pic.txt
@@ -0,0 +1,115 @@
+* Open PIC Binding
+
+This binding specifies what properties must be available in the device tree
+representation of an Open PIC compliant interrupt controller.  This binding is
+based on the binding defined for Open PIC in [1] and is a superset of that
+binding.
+
+PROPERTIES
+
+  NOTE: Many of these descriptions were paraphrased here from [1] to aid
+readability.
+
+  - compatible
+  Usage: required
+  Value type:
+  Definition: Specifies the compatibility list for the PIC.  The
+  property value shall include "open-pic".
+
+  - reg
+  Usage: required
+  Value type:
+  Definition: Specifies the base physical address(s) and size(s) of this
+  PIC's addressable register space.
+
+  - interrupt-controller
+  Usage: required
+  Value type:
+  Definition: The presence of this property identifies the node
+  as an Open PIC.  No property value should be defined.
+
+  - #interrupt-cells
+  Usage: required
+  Value type:
+  Definition: Specifies the number of cells needed to encode an
+  interrupt source.  Shall be 2.
+
+  - #address-cells
+  Usage: required
+  Value type:
+  Definition: Specifies the number of cells needed to encode an
+  address.  The value of this property shall always be 0.
+  As such, 'interrupt-map' nodes do not have to specify a
+  parent unit address.
+
+  - 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


OK, will do.  The one thing that I like about the other format, though, 
is that it specifies the value type.  That is a useful addition.



I'm considering formalizing the binding format so that fully specified
and cross-referenced documentation can be generated from the bindings
directory.


Formalizing the binding format would be great.  Perhaps we should add a 
HOWTO write a new binding document to the "Documentation" directory? 
The would be a great place to capture some of the common pitfalls that 
have been coming up on the list lately (versioned compatibility tags, 
for example).



Also, to avoid the potential of a future namespace collision, it would
not be a bad idea to name this openpic-no-reset or something that
makes it clear that this is a binding specific property.  "no-reset"
sounds generic enough to give me pause.


Isn't that a little redundant, though (e.g. 
"/soc/pic/openpic-no-reset")?  It is already scoped to the PIC node:


   mpic: pic@4 {
  compatible = "open-pic";
  no-reset;
   };

Or are you worried that someone will find the wrong "no-reset" property 
when searching from a location higher in the tree than the PIC node?


I don't have a serious objection to the idea, but it seems slightly odd 
to partially flatten the hierarchy back into the property names.  On the 
other hand, I do see the practical consideration of having a more unique 
property which might prevent programming confusion/errors.


--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
___
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

[Grant Likely]

On Thu, Feb 3, 2011 at 9:29 AM, Meador Inge  wrote:
> On 02/03/2011 09:56 AM, Grant Likely wrote:
>>
>> On Wed, Feb 2, 2011 at 6:51 PM, Meador Inge
>>  wrote:
>>>
>>> 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
>>> Open PIC should be reset during runtime initialization.
>>>
>>> The general formatting and interrupt specifier definition is based off of
>>> Stuart Yoder's FSL MPIC binding.
>>>
>>> Signed-off-by: Meador Inge
>>> CC: Hollis Blanchard
>>> CC: Stuart Yoder
>>> ---
>>>  Documentation/powerpc/dts-bindings/open-pic.txt |  115
>>> +++
>>>  1 files changed, 115 insertions(+), 0 deletions(-)
>>>  create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt
>>>
>>> diff --git a/Documentation/powerpc/dts-bindings/open-pic.txt
>>> b/Documentation/powerpc/dts-bindings/open-pic.txt
>>> new file mode 100644
>>> index 000..447ef65
>>> --- /dev/null
>>> +++ b/Documentation/powerpc/dts-bindings/open-pic.txt
>>> @@ -0,0 +1,115 @@
>>> +* Open PIC Binding
>>> +
>>> +This binding specifies what properties must be available in the device
>>> tree
>>> +representation of an Open PIC compliant interrupt controller.  This
>>> binding is
>>> +based on the binding defined for Open PIC in [1] and is a superset of
>>> that
>>> +binding.
>>> +
>>> +PROPERTIES
>>> +
>>> +  NOTE: Many of these descriptions were paraphrased here from [1] to aid
>>> +        readability.
>>> +
>>> +  - compatible
>>> +      Usage: required
>>> +      Value type:
>>> +      Definition: Specifies the compatibility list for the PIC.  The
>>> +          property value shall include "open-pic".
>>> +
>>> +  - reg
>>> +      Usage: required
>>> +      Value type:
>>> +      Definition: Specifies the base physical address(s) and size(s) of
>>> this
>>> +          PIC's addressable register space.
>>> +
>>> +  - interrupt-controller
>>> +      Usage: required
>>> +      Value type:
>>> +      Definition: The presence of this property identifies the node
>>> +          as an Open PIC.  No property value should be defined.
>>> +
>>> +  - #interrupt-cells
>>> +      Usage: required
>>> +      Value type:
>>> +      Definition: Specifies the number of cells needed to encode an
>>> +          interrupt source.  Shall be 2.
>>> +
>>> +  - #address-cells
>>> +      Usage: required
>>> +      Value type:
>>> +      Definition: Specifies the number of cells needed to encode an
>>> +          address.  The value of this property shall always be 0.
>>> +          As such, 'interrupt-map' nodes do not have to specify a
>>> +          parent unit address.
>>> +
>>> +  - 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
>
> OK, will do.  The one thing that I like about the other format, though, is
> that it specifies the value type.  That is a useful addition.
>
>> I'm considering formalizing the binding format so that fully specified
>> and cross-referenced documentation can be generated from the bindings
>> directory.
>
> Formalizing the binding format would be great.  Perhaps we should add a
> HOWTO write a new binding document to the "Documentation" directory? The
> would be a great place to capture some of the common pitfalls that have been
> coming up on the list lately (versioned compatibility tags, for example).
>
>> Also, to avoid the potential of a future namespace collision, it would
>> not be a bad idea to name this openpic-no-reset or something that
>> makes it clear that this is a binding specific property.  "no-reset"
>> sounds generic enough to give me pause.
>
> Isn't that a little redundant, though (e.g. "/soc/pic/openpic-no-reset")?
>  It is already scoped to the PIC node:
>
>   mpic: pic@4 {
>      compatible = "open-pic";
>      no-reset;
>   };
>
> Or are you worried that someone will find the wrong "no-reset" property when
> searching from a location higher in the tree than the PIC node?
>
> I don't have a serious objection to the idea, but it seems slightly odd to
> partially flatten the hierarchy back into the property names.  On the other
> hand, I do see the practical consideration of having a more unique property
> which might prevent programming confusion/errors.

It's the sort of thing where properties with really generic names,
like no-reset, I could potentially s

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

[PATCH] powerpc/85xx: fix compatible properties of the P1022DS DMA nodes used for audio

[Timur Tabi]

In order to prevent the fsl_dma driver from claiming the DMA channels that the
P1022DS audio driver needs, the compatible properties for those nodes must say
"fsl,ssi-dma-channel" instead of "fsl,eloplus-dma-channel".

Commit b2e0861e51f2961954330dcafe6d148ee3ab5cff upstream.

Signed-off-by: Timur Tabi 
Cc: sta...@kernel.org
---
 arch/powerpc/boot/dts/p1022ds.dts |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1022ds.dts 
b/arch/powerpc/boot/dts/p1022ds.dts
index 2bbecbb..69422eb 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -291,13 +291,13 @@
ranges = <0x0 0xc100 0x200>;
cell-index = <1>;
dma00: dma-channel@0 {
-   compatible = "fsl,eloplus-dma-channel";
+   compatible = "fsl,ssi-dma-channel";
reg = <0x0 0x80>;
cell-index = <0>;
interrupts = <76 2>;
};
dma01: dma-channel@80 {
-   compatible = "fsl,eloplus-dma-channel";
+   compatible = "fsl,ssi-dma-channel";
reg = <0x80 0x80>;
cell-index = <1>;
interrupts = <77 2>;
-- 
1.7.3.4


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

[OT - MPC5200B] strange framing, break problems with uart

[Albrecht Dreß]

Hi all,

sorry for a slightly off-topic question, but I hope someone here on the list 
may be able to help me...

I have a strange problem with the psc uart of the mpc5200b, running 2.6.32.26 
(still), with my baud rate divisor selection patch [1].

The uart runs at 115.2 kBaud with rtc/cts handshake to send bigger chunks of data to the '5200.  I 
noticed "missing" data in the input stream, and inspected the uart status using the 
TIOCGICOUNT ioctl which tells me that a bunch of framing and break errors occurred.  I 
"tapped" the RxD line and connected it via a level shifter to a standard 16450-style uart 
in a (much faster) Linux PC, and *that* one receives the *complete* stream *without any* break or 
framing errors!

I also looked at the waveforms with an oscilloscope, and they look pretty fine. 
 The port configuration should also be ok, re-checked with a bdi3000 jtag 
debugger - it's PSC3, set to '1100', with PSC3_0 .. PSC3_3 being used here.

This leads me to the assumption that either the hardware handshake or the Linux 
driver or both are broken...  any insight would be highly appreciated!

Cheers,
Albrecht.


[1] ; included in 2.6.37


pgpiuP4ghbD7P.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: MMC on MPC8379

[Gary Thomas]

On 01/31/2011 01:12 PM, Gary Thomas wrote:

I'm running 2.6.32 on MPC8379, trying to use the SDHCI interface.
It seems to work, reads are fine, but when I write to the device
(I've tried both eMMC soldered-on and pluggable MMC/SD cards),
I get intermittent failures. Specifically, some blocks will be
written while others fail. I haven't yet found a pattern.

Is there anything special about this interface? I notice that
it's not really used by any FSL platforms although the driver
claims support.


On the surface, it looks like it should work and I'm perplexed
by the failures.

Does anyone have any ideas or experience with this device?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems

[Dave Kleikamp]

On Thu, 2011-02-03 at 16:03 +1100, David Gibson wrote:
> On Wed, Feb 02, 2011 at 05:53:59PM -0600, Dave Kleikamp wrote:
> > On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
> > > On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> > > > Since other OS's may be running on the other cores don't use tlbivax
> > > 
> > > [snip]
> > > > +#ifdef CONFIG_44x
> > > > +void __init early_init_mmu_44x(void)
> > > > +{
> > > > +   unsigned long root = of_get_flat_dt_root();
> > > > +   if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))
> > > > +   amp = 1;
> > > > +}
> > > > +#endif /* CONFIG_44x */
> > > 
> > > A test against a hardcoded compatible string seems a nasty way to do
> > > this.  Maybe we should define a new boolean property for the root
> > > node.
> > 
> > I'm not crazy about this string, but I needed something in the device
> > tree to key off of.  Freescale has something similar (i.e.
> > MPC8572DS-CAMP), so I chose to follow their example.  I'd be happy to
> > replace it with a boolean property.  Any objection to just using
> > "amp"?
> 
> Bit too short, I think.  I'd suggest either spelling out
> 'asymmetric-multiprocessor' or 'cooperative-partition' (a more
> accurate term, IMO).

I could be wrong, but I thought the A stands for Asynchronous, not
Asymmetric.  I thought Asymmetric means that different types of tasks
run on the secondary processors, as on the Cell.  Anyway, going with
'cooperative-partition' would avoid that confusion.

Shaggy
-- 
Dave Kleikamp
IBM Linux Technology Center

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

Re: [PATCH v2 1/3] powerpc: Removing support for 'protected-sources'

[Meador Inge]

On 02/03/2011 09:56 AM, Arnd Bergmann wrote:

On Thursday 03 February 2011, Meador Inge wrote:

In a recent discussion [1, 2] concerning device trees for AMP systems, the
question of whether we really need 'protected-sources' arose.  The general
consensus was that if you don't want a source to be used, then it should *not*
be mentioned in an 'interrupts' property.  If a source really needs to be
mentioned, then it should be put in a property other than 'interrupts' with
a specific binding for that use case.

[1] 
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/004038.html
[2] 
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/003991.html


That doesn't work in the case that this code was written for:

http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg01394.html

The problem is that you don't want the mpic to initialize the interrupt
line to the default, but instead leave it at whatever the boot firmware
has set up. Note that interrupt is not listed in any "interrupts"
property of any of the devices on the CPU interpreting the device
tree, but it may be mentioned in the device tree that another CPU
uses to access the same MPIC.

Arnd


We touched on that use case before on list.  However, I did a really bad 
job of explaining things in the above patch description.  I understand 
that the sources that are being protected are mentioned in a device tree 
other than the one that actually interprets the 'protected-sources' 
property.


The idea is to try and expand the meaning of the 'no-reset' property to 
cover what 'protected-sources' was taking care of, but without 
explicitly naming the sources.


In the protected sources version of the code, the relevant MPIC 
initialization went something like (in 'mpic_init'):


for (i = 0; i < mpic->num_sources; i++) {
/* start with vector = source number, and masked */
u32 vecpri = MPIC_VECPRI_MASK | i |
(8 << MPIC_VECPRI_PRIORITY_SHIFT);

/* check if protected */
if (mpic->protected && test_bit(i, mpic->protected))
continue;
/* init hw */
mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), 1 << cpu);
}

So unless a particular source was marked as protected, it would get the 
VECPRI and CPU binding initialization.  This is the exact behavior that 
you describe above, Arnd.


In the 'no-reset' model, the initialization looks more like (see PATCH 3 
in the set for the full implementation):


if (mpic->flags & MPIC_WANTS_RESET) {
for (i = 0; i < mpic->num_sources; i++) {
mpic_init_vector(mpic, hw);
}
}

So in 'mpic_init' we don't initialize anything and then in 
'mpic_host_map' we lazily do the VECPRI and CPU binding initialization with:


if (!(mpic->flags & MPIC_WANTS_RESET))
if (!(mpic_is_ipi(mpic, hw)
|| mpic_is_timer_interrupt(mpic, hw)))
mpic_init_vector(mpic, hw);

Thus when 'no-reset' is thrown it ensures that only the sources which 
are mentioned in the device tree are actually initialized.  The net 
effect should be the same as what 'protected-sources' was accomplishing, 
but without having to maintain the list of sources in the property cell.



--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems

[Timur Tabi]

On Thu, Feb 3, 2011 at 5:15 PM, Dave Kleikamp  wrote:

>> Bit too short, I think.  I'd suggest either spelling out
>> 'asymmetric-multiprocessor' or 'cooperative-partition' (a more
>> accurate term, IMO).
>
> I could be wrong, but I thought the A stands for Asynchronous, not
> Asymmetric.  I thought Asymmetric means that different types of tasks
> run on the secondary processors, as on the Cell.  Anyway, going with
> 'cooperative-partition' would avoid that confusion.

Well, if we pretend that everyone already knows what the "A" stands
for, that's not going to avoid confusion.  Some people still are going
to be wrong.  It would be great if we could settle the matter once and
for all.

I've always thought the A stood for asymmetric, since you're running
multiple cores, but each OS is not aware of the others.  It doesn't
necessarily have to be two copies of Linux.  In fact, it usually
isn't.

As for "MPC8572DS-CAMP", I've always hated that.  A specific property
that defines an AMP environment is a much better idea.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev