[RFC PATCH v3] drivers: bus: add ARM CCI support

2013-05-09 Thread Lorenzo Pieralisi
On ARM multi-cluster systems coherency between cores running on
different clusters is managed by the cache-coherent interconnect (CCI).
It allows broadcasting of TLB invalidates and memory barriers and it
guarantees cache coherency at system level through snooping of slave
interfaces connected to it.

This patch enables the basic infrastructure required in Linux to handle and
programme the CCI component.

Non-local variables used by the CCI management functions called by power
down function calls after disabling the cache must be flushed out to main
memory in advance, otherwise incoherency of those values may occur if they
are sitting in the cache of some other CPU when power down functions
execute. Driver code ensures that relevant data structures are flushed
from inner and outer caches after the driver probe is completed.

CCI slave port resources are linked to set of CPUs through bus masters
phandle properties that link the interface resources to masters node in
the device tree.

Documentation describing the CCI DT bindings is provided with the patch.

Signed-off-by: Lorenzo Pieralisi 
---
 Documentation/devicetree/bindings/arm/cci.txt | 161 ++
 drivers/bus/Kconfig   |   7 +
 drivers/bus/Makefile  |   2 +
 drivers/bus/arm-cci.c | 420 ++
 include/linux/arm-cci.h   |  61 
 5 files changed, 651 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cci.txt
 create mode 100644 drivers/bus/arm-cci.c
 create mode 100644 include/linux/arm-cci.h

diff --git a/Documentation/devicetree/bindings/arm/cci.txt 
b/Documentation/devicetree/bindings/arm/cci.txt
new file mode 100644
index 000..384b460
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -0,0 +1,161 @@
+===
+ARM CCI cache coherent interconnect binding description
+===
+
+ARM multi-cluster systems maintain intra-cluster coherency through a
+cache coherent interconnect (CCI) that is capable of monitoring bus
+transactions and manage coherency, TLB invalidations and memory barriers.
+
+It allows snooping and distributed virtual memory message broadcast across
+clusters, through memory mapped interface, with a global control register
+space and multiple sets of interface control registers, one per slave
+interface.
+
+Bindings for the CCI node follow the ePAPR standard, available from:
+
+www.power.org/documentation/epapr-version-1-1/
+
+with the addition of the bindings described in this document which are
+specific to ARM.
+
+* CCI interconnect node
+
+   Description: Describes a CCI cache coherent Interconnect component
+
+   Node name must be "cci".
+   Node's parent must be the root node /, and the address space visible
+   through the CCI interconnect is the same as the one seen from the
+   root node (ie from CPUs perspective as per DT standard).
+   Every CCI node has to define the following properties:
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be set to
+   "arm,cci-400"
+
+   - reg
+   Usage: required
+   Value type: 
+   Definition: A standard property. Specifies base physical
+   address of CCI control registers common to all
+   interfaces.
+
+   - ranges:
+   Usage: required
+   Value type: 
+   Definition: A standard property. Follow rules in the ePAPR for
+   hierarchical bus addressing. CCI interfaces
+   addresses refer to the parent node addressing
+   scheme to declare their register bases.
+
+   CCI interconnect node can define the following child nodes:
+
+   - CCI control interface nodes
+
+   Node name must be "slave-if".
+   Parent node must be CCI interconnect node.
+
+   A CCI interface node must contain the following properties:
+   - interface-type:
+   Usage: required
+   Value type: 
+   Definition: must be set to one of {"ace", "ace-lite"}
+   depending on the interface type the node
+   represents.
+
+   - reg:
+   Usage: required
+   Value type: 
+   Definition: the base address and size of the
+   corresponding interface programming
+   registers.
+
+* CCI interconnect bus masters
+
+   Description: masters in the device tree connected to a CCI port
+(inclusive of CPUs and their cpu nodes).
+
+   A CCI intercon

Re: [RFC PATCH v3] drivers: bus: add ARM CCI support

2013-05-14 Thread Nicolas Pitre
On Tue, 14 May 2013, Javi Merino wrote:

> On Thu, May 09, 2013 at 11:34:00AM +0100, Lorenzo Pieralisi wrote:
> 
> > +static inline void init_cpu_port(struct cpu_port *port, u32 index, u32 
> > mpidr)
> 
> The mpidr should be u64.

Why?


Nicolas
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC PATCH v3] drivers: bus: add ARM CCI support

2013-05-15 Thread Lorenzo Pieralisi
On Tue, May 14, 2013 at 11:21:32PM +0100, Nicolas Pitre wrote:
> On Tue, 14 May 2013, Javi Merino wrote:
> 
> > On Thu, May 09, 2013 at 11:34:00AM +0100, Lorenzo Pieralisi wrote:
> > 
> > > +static inline void init_cpu_port(struct cpu_port *port, u32 index, u32 
> > > mpidr)
> > 
> > The mpidr should be u64.
> 
> Why?

Since on arm64 MPIDR_EL1 size is 64 bits, we need the driver to work on
both arm and arm64.

Lorenzo

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC PATCH v3] drivers: bus: add ARM CCI support

2013-05-15 Thread Nicolas Pitre
On Wed, 15 May 2013, Lorenzo Pieralisi wrote:

> On Tue, May 14, 2013 at 11:21:32PM +0100, Nicolas Pitre wrote:
> > On Tue, 14 May 2013, Javi Merino wrote:
> > 
> > > On Thu, May 09, 2013 at 11:34:00AM +0100, Lorenzo Pieralisi wrote:
> > > 
> > > > +static inline void init_cpu_port(struct cpu_port *port, u32 index, u32 
> > > > mpidr)
> > > 
> > > The mpidr should be u64.
> > 
> > Why?
> 
> Since on arm64 MPIDR_EL1 size is 64 bits, we need the driver to work on
> both arm and arm64.

OK.

Are you OK for me to carry this patch in the series for MCPM support 
on RTSM?  I would like to send it to arm-soc ASAP.


Nicolas
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC PATCH v3] drivers: bus: add ARM CCI support

2013-05-15 Thread Lorenzo Pieralisi
On Wed, May 15, 2013 at 03:51:43PM +0100, Nicolas Pitre wrote:
> On Wed, 15 May 2013, Lorenzo Pieralisi wrote:
> 
> > On Tue, May 14, 2013 at 11:21:32PM +0100, Nicolas Pitre wrote:
> > > On Tue, 14 May 2013, Javi Merino wrote:
> > > 
> > > > On Thu, May 09, 2013 at 11:34:00AM +0100, Lorenzo Pieralisi wrote:
> > > > 
> > > > > +static inline void init_cpu_port(struct cpu_port *port, u32 index, 
> > > > > u32 mpidr)
> > > > 
> > > > The mpidr should be u64.
> > > 
> > > Why?
> > 
> > Since on arm64 MPIDR_EL1 size is 64 bits, we need the driver to work on
> > both arm and arm64.
> 
> OK.
> 
> Are you OK for me to carry this patch in the series for MCPM support 
> on RTSM?  I would like to send it to arm-soc ASAP.

Absolutely, I will apply the latest fixes and send the updated version
to you for arm-soc inclusion today.

Lorenzo

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC PATCH v3] drivers: bus: add ARM CCI support

2013-05-20 Thread Jon Medhurst (Tixy)
On Thu, 2013-05-09 at 11:34 +0100, Lorenzo Pieralisi wrote:
[...]
> +static int __init cci_probe(void)
> +{
> + struct cci_nb_ports const *cci_config;
> + int ret, i, nb_ace = 0, nb_ace_lite = 0;
> + struct device_node *np, *cp;
> + const char *match_str;
> + bool is_ace;
> +
> + np = of_find_matching_node(NULL, arm_cci_matches);
> + if (!np)
> + return -ENODEV;
> +
> + cci_config = of_match_node(arm_cci_matches, np)->data;
> + if (!cci_config)
> + return -ENODEV;
> +
> + nb_cci_ports = cci_config->nb_ace + cci_config->nb_ace_lite;
> +
> + ports = kcalloc(sizeof(*ports), nb_cci_ports, GFP_KERNEL);
> + if (!ports)
> + return -ENOMEM;
> +
> + cci_ctrl_base = of_iomap(np, 0);
> +
> + if (!cci_ctrl_base) {
> + WARN(1, "unable to ioremap CCI ctrl\n");
> + ret = -ENXIO;
> + goto memalloc_err;
> + }
> +
> + for_each_child_of_node(np, cp) {
> + i = nb_ace + nb_ace_lite;
> +
> + if (i >= nb_cci_ports)
> + break;

I know this is a bit late, but...

Would it not be best to check here that the node type is in fact
"slave-if", that way if we add support in later versions for other node
types (e.g. for the PMU) then we don't cause backward compatibility
issues. I'm thinking here of the same concerns that Rob raised with
"ARM: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes"


> + if (of_property_read_string(cp, "interface-type",
> + &match_str)) {
> + WARN(1, "node %s missing interface-type property\n",
> +   cp->full_name);
> + continue;
> + }
> +
[..]

-- 
Tixy

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC PATCH v3] drivers: bus: add ARM CCI support

2013-05-21 Thread Lorenzo Pieralisi
On Mon, May 20, 2013 at 01:11:21PM +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2013-05-09 at 11:34 +0100, Lorenzo Pieralisi wrote:
> [...]
> > +static int __init cci_probe(void)
> > +{
> > +   struct cci_nb_ports const *cci_config;
> > +   int ret, i, nb_ace = 0, nb_ace_lite = 0;
> > +   struct device_node *np, *cp;
> > +   const char *match_str;
> > +   bool is_ace;
> > +
> > +   np = of_find_matching_node(NULL, arm_cci_matches);
> > +   if (!np)
> > +   return -ENODEV;
> > +
> > +   cci_config = of_match_node(arm_cci_matches, np)->data;
> > +   if (!cci_config)
> > +   return -ENODEV;
> > +
> > +   nb_cci_ports = cci_config->nb_ace + cci_config->nb_ace_lite;
> > +
> > +   ports = kcalloc(sizeof(*ports), nb_cci_ports, GFP_KERNEL);
> > +   if (!ports)
> > +   return -ENOMEM;
> > +
> > +   cci_ctrl_base = of_iomap(np, 0);
> > +
> > +   if (!cci_ctrl_base) {
> > +   WARN(1, "unable to ioremap CCI ctrl\n");
> > +   ret = -ENXIO;
> > +   goto memalloc_err;
> > +   }
> > +
> > +   for_each_child_of_node(np, cp) {
> > +   i = nb_ace + nb_ace_lite;
> > +
> > +   if (i >= nb_cci_ports)
> > +   break;
> 
> I know this is a bit late, but...
> 
> Would it not be best to check here that the node type is in fact
> "slave-if", that way if we add support in later versions for other node
> types (e.g. for the PMU) then we don't cause backward compatibility
> issues. I'm thinking here of the same concerns that Rob raised with
> "ARM: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes"

The node name, not type, but point is taken. I prefer to add a
compatible property to slave-if nodes (eg "arm,cci-400-control-if"),
I do not think that checking the node name is the standard way of doing
things in DT world.

Thoughts ?

Thanks,
Lorenzo

> > +   if (of_property_read_string(cp, "interface-type",
> > +   &match_str)) {
> > +   WARN(1, "node %s missing interface-type property\n",
> > + cp->full_name);
> > +   continue;
> > +   }
> > +
> [..]
> 
> -- 
> Tixy
> 
> 

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC PATCH v3] drivers: bus: add ARM CCI support

2013-05-21 Thread Benjamin Herrenschmidt
On Tue, 2013-05-21 at 10:21 +0100, Lorenzo Pieralisi wrote:
> The node name, not type, but point is taken. I prefer to add a
> compatible property to slave-if nodes (eg "arm,cci-400-control-if"),
> I do not think that checking the node name is the standard way of
> doing
> things in DT world.
> 
> Thoughts ?

Agreed.

Cheers,
Ben.


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss