[RFC 0/5] ARM: Add Cross Trigger Interface driver

[RFC 0/5] ARM: Add Cross Trigger Interface driver

[Jon Hunter]

Adds AMBA driver for ARM Coresight Cross Trigger Interface (CTI) driver
and device-tree binding for CTI module.

I have tested the driver on an OMAP4430 device and include the relevant
patches needed to enable CTI on OMAP4 devices for reference.

I would like to get some feedback on the binding, CTI APIs and usage of
the APB clock for OMAP4. I have seen that there has been some recent
discussion around adding other coresight drivers for ARM devices [1]
and so it would be also good to align on the appropriate location for
coresight drivers in general.

This series is based on the ARM-SOC for-next branch and Will Deacon's
patch for the CTI lock registers [2].

[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/204591/match=coresight+bus
[2] http://article.gmane.org/gmane.linux.ports.arm.kernel/200199/match=fix+manipulation+debug+lock+register

Jon Hunter (5):
  ARM: CORESIGHT: Add generic lock/unlock helpers
  ARM: dts: Add Cross Trigger Interface binding
  ARM: CTI: Convert CTI helpers to AMBA bus driver
  ARM: dts: OMAP4: Add CTI nodes
  ARM: OMAP4: Add AMBA APB Clock

 Documentation/devicetree/bindings/arm/cti.txt |   32 +++
 arch/arm/boot/dts/omap4.dtsi                  |   23 ++
 arch/arm/include/asm/cti.h                    |  163 --------------
 arch/arm/include/asm/hardware/coresight.h     |   16 +-
 arch/arm/mach-omap2/cclock44xx_data.c         |    1 +
 drivers/Kconfig                               |    2 +
 drivers/amba/Kconfig                          |   20 ++
 drivers/amba/Makefile                         |    1 +
 drivers/amba/cti.c                            |  284 +++++++++++++++++++++++++
 include/linux/amba/cti.h                      |   82 +++++++
 10 files changed, 453 insertions(+), 171 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/cti.txt
 delete mode 100644 arch/arm/include/asm/cti.h
 create mode 100644 drivers/amba/Kconfig
 create mode 100644 drivers/amba/cti.c
 create mode 100644 include/linux/amba/cti.h

-- 
1.7.10.4

[RFC 1/5] ARM: CORESIGHT: Add generic lock/unlock helpers

[Jon Hunter]

The Cross Trigger Interface (CTI) helpers in cti.h include definitions
for the Coresight Lock Access Register (LAR) and Lock Status Register
(LSR). These registers are already defined in coresight.h and so rather
than having multiple definitions, just use the definitions from
coresight.h.

Add the following coresight macros ...
- coresight_unlock() --> Unlocks coresight module
- coresight_lock()   --> Locks coresight module

Use the above macros for ETB, ETM and CTI. The do-while(0) statement
has been removed from the macro as it is not a multi-line macro.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/include/asm/cti.h                |   16 +++-------------
 arch/arm/include/asm/hardware/coresight.h |   16 ++++++++--------
 2 files changed, 11 insertions(+), 21 deletions(-)

diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
index f2e5cad..00add00 100644
--- a/arch/arm/include/asm/cti.h
+++ b/arch/arm/include/asm/cti.h
@@ -2,6 +2,7 @@
 #define __ASMARM_CTI_H
 
 #include	<asm/io.h>
+#include	<asm/hardware/coresight.h>
 
 /* The registers' definition is from section 3.2 of
  * Embedded Cross Trigger Revision: r0p0
@@ -29,17 +30,6 @@
 #define		CTIPCELLID2		0xFF8
 #define		CTIPCELLID3		0xFFC
 
-/* The below are from section 3.6.4 of
- * CoreSight v1.0 Architecture Specification
- */
-#define		LOCKACCESS		0xFB0
-#define		LOCKSTATUS		0xFB4
-
-/* write this value to LOCKACCESS will unlock the module, and
- * other value will lock the module
- */
-#define		LOCKCODE		0xC5ACCE55
-
 /**
  * struct cti - cross trigger interface struct
  * @base: mapped virtual address for the cti base
@@ -146,7 +136,7 @@ static inline void cti_irq_ack(struct cti *cti)
  */
 static inline void cti_unlock(struct cti *cti)
 {
-	__raw_writel(LOCKCODE, cti->base + LOCKACCESS);
+	coresight_unlock(cti->base);
 }
 
 /**
@@ -158,6 +148,6 @@ static inline void cti_unlock(struct cti *cti)
  */
 static inline void cti_lock(struct cti *cti)
 {
-	__raw_writel(~LOCKCODE, cti->base + LOCKACCESS);
+	coresight_lock(cti->base);
 }
 #endif
diff --git a/arch/arm/include/asm/hardware/coresight.h b/arch/arm/include/asm/hardware/coresight.h
index 7ecd793..dcd0e66 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -141,17 +141,17 @@
 #define ETBFF_TRIGEVT		BIT(9)
 #define ETBFF_TRIGFL		BIT(10)
 
-#define etb_writel(t, v, x) \
-	(__raw_writel((v), (t)->etb_regs + (x)))
+#define etb_writel(t, v, x) (__raw_writel((v), (t)->etb_regs + (x)))
 #define etb_readl(t, x) (__raw_readl((t)->etb_regs + (x)))
 
-#define etm_lock(t) do { etm_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etm_unlock(t) \
-	do { etm_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define etb_lock(t) coresight_lock((t)->etb_regs)
+#define etb_unlock(t) coresight_unlock((t)->etb_regs)
+#define etm_lock(t) coresight_lock((t)->etm_regs)
+#define etm_unlock(t) coresight_unlock((t)->etm_regs)
 
-#define etb_lock(t) do { etb_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etb_unlock(t) \
-	do { etb_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define coresight_lock(base) (__raw_writel(0, base + CSMR_LOCKACCESS))
+#define coresight_unlock(base) \
+	(__raw_writel(UNLOCK_MAGIC, base + CSMR_LOCKACCESS))
 
 #endif /* __ASM_HARDWARE_CORESIGHT_H */
 
-- 
1.7.10.4

[RFC 1/5] ARM: CORESIGHT: Add generic lock/unlock helpers

[Will Deacon]

Hi Jon,

On Wed, Dec 12, 2012 at 09:43:04PM +0000, Jon Hunter wrote:
> The Cross Trigger Interface (CTI) helpers in cti.h include definitions
> for the Coresight Lock Access Register (LAR) and Lock Status Register
> (LSR). These registers are already defined in coresight.h and so rather
> than having multiple definitions, just use the definitions from
> coresight.h.
> 
> Add the following coresight macros ...
> - coresight_unlock() --> Unlocks coresight module
> - coresight_lock()   --> Locks coresight module
> 
> Use the above macros for ETB, ETM and CTI. The do-while(0) statement
> has been removed from the macro as it is not a multi-line macro.
> 
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
>  arch/arm/include/asm/cti.h                |   16 +++-------------
>  arch/arm/include/asm/hardware/coresight.h |   16 ++++++++--------
>  2 files changed, 11 insertions(+), 21 deletions(-)

[...]

> diff --git a/arch/arm/include/asm/hardware/coresight.h b/arch/arm/include/asm/hardware/coresight.h
> index 7ecd793..dcd0e66 100644
> --- a/arch/arm/include/asm/hardware/coresight.h
> +++ b/arch/arm/include/asm/hardware/coresight.h
> @@ -141,17 +141,17 @@
>  #define ETBFF_TRIGEVT		BIT(9)
>  #define ETBFF_TRIGFL		BIT(10)
>  
> -#define etb_writel(t, v, x) \
> -	(__raw_writel((v), (t)->etb_regs + (x)))
> +#define etb_writel(t, v, x) (__raw_writel((v), (t)->etb_regs + (x)))
>  #define etb_readl(t, x) (__raw_readl((t)->etb_regs + (x)))
>  
> -#define etm_lock(t) do { etm_writel((t), 0, CSMR_LOCKACCESS); } while (0)
> -#define etm_unlock(t) \
> -	do { etm_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
> +#define etb_lock(t) coresight_lock((t)->etb_regs)
> +#define etb_unlock(t) coresight_unlock((t)->etb_regs)
> +#define etm_lock(t) coresight_lock((t)->etm_regs)
> +#define etm_unlock(t) coresight_unlock((t)->etm_regs)
>  
> -#define etb_lock(t) do { etb_writel((t), 0, CSMR_LOCKACCESS); } while (0)
> -#define etb_unlock(t) \
> -	do { etb_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
> +#define coresight_lock(base) (__raw_writel(0, base + CSMR_LOCKACCESS))
> +#define coresight_unlock(base) \
> +	(__raw_writel(UNLOCK_MAGIC, base + CSMR_LOCKACCESS))
>  
>  #endif /* __ASM_HARDWARE_CORESIGHT_H */

How about we take this opportunity to divorce the more general coresight
bits from the etb specific parts, like you've done for the cti. We could
move the ETB stuff out into asm/etb.h (although it might be nice to keep all
the coresight device headers in one place... answers on a postcard) and just
have the architected coresight functionality in this header.

Will

> -- 
> 1.7.10.4
> 
> 

[RFC 1/5] ARM: CORESIGHT: Add generic lock/unlock helpers

[Jon Hunter]

On 12/13/2012 08:58 AM, Will Deacon wrote:
> Hi Jon,
> 
> On Wed, Dec 12, 2012 at 09:43:04PM +0000, Jon Hunter wrote:
>> The Cross Trigger Interface (CTI) helpers in cti.h include definitions
>> for the Coresight Lock Access Register (LAR) and Lock Status Register
>> (LSR). These registers are already defined in coresight.h and so rather
>> than having multiple definitions, just use the definitions from
>> coresight.h.
>>
>> Add the following coresight macros ...
>> - coresight_unlock() --> Unlocks coresight module
>> - coresight_lock()   --> Locks coresight module
>>
>> Use the above macros for ETB, ETM and CTI. The do-while(0) statement
>> has been removed from the macro as it is not a multi-line macro.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> ---
>>  arch/arm/include/asm/cti.h                |   16 +++-------------
>>  arch/arm/include/asm/hardware/coresight.h |   16 ++++++++--------
>>  2 files changed, 11 insertions(+), 21 deletions(-)
> 
> [...]
> 
>> diff --git a/arch/arm/include/asm/hardware/coresight.h b/arch/arm/include/asm/hardware/coresight.h
>> index 7ecd793..dcd0e66 100644
>> --- a/arch/arm/include/asm/hardware/coresight.h
>> +++ b/arch/arm/include/asm/hardware/coresight.h
>> @@ -141,17 +141,17 @@
>>  #define ETBFF_TRIGEVT		BIT(9)
>>  #define ETBFF_TRIGFL		BIT(10)
>>  
>> -#define etb_writel(t, v, x) \
>> -	(__raw_writel((v), (t)->etb_regs + (x)))
>> +#define etb_writel(t, v, x) (__raw_writel((v), (t)->etb_regs + (x)))
>>  #define etb_readl(t, x) (__raw_readl((t)->etb_regs + (x)))
>>  
>> -#define etm_lock(t) do { etm_writel((t), 0, CSMR_LOCKACCESS); } while (0)
>> -#define etm_unlock(t) \
>> -	do { etm_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
>> +#define etb_lock(t) coresight_lock((t)->etb_regs)
>> +#define etb_unlock(t) coresight_unlock((t)->etb_regs)
>> +#define etm_lock(t) coresight_lock((t)->etm_regs)
>> +#define etm_unlock(t) coresight_unlock((t)->etm_regs)
>>  
>> -#define etb_lock(t) do { etb_writel((t), 0, CSMR_LOCKACCESS); } while (0)
>> -#define etb_unlock(t) \
>> -	do { etb_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
>> +#define coresight_lock(base) (__raw_writel(0, base + CSMR_LOCKACCESS))
>> +#define coresight_unlock(base) \
>> +	(__raw_writel(UNLOCK_MAGIC, base + CSMR_LOCKACCESS))
>>  
>>  #endif /* __ASM_HARDWARE_CORESIGHT_H */
> 
> How about we take this opportunity to divorce the more general coresight
> bits from the etb specific parts, like you've done for the cti. We could
> move the ETB stuff out into asm/etb.h (although it might be nice to keep all
> the coresight device headers in one place... answers on a postcard) and just
> have the architected coresight functionality in this header.

Yes I have been wondering about that too. Long term it would be good to
find a home in the drivers directory for all these coresight devices
too. For now, we could extract the etb/etm parts from coresight.h into
etb.h and etm.h, respectively.

Cheers
Jon

[RFC 1/5] ARM: CORESIGHT: Add generic lock/unlock helpers

[Jean Pihet]

Hi Jon, Will,

On Thu, Dec 13, 2012 at 8:18 PM, Jon Hunter <jon-hunter@ti.com> wrote:
>
> On 12/13/2012 08:58 AM, Will Deacon wrote:
>> Hi Jon,
>>
>> On Wed, Dec 12, 2012 at 09:43:04PM +0000, Jon Hunter wrote:
>>> The Cross Trigger Interface (CTI) helpers in cti.h include definitions
>>> for the Coresight Lock Access Register (LAR) and Lock Status Register
>>> (LSR). These registers are already defined in coresight.h and so rather
>>> than having multiple definitions, just use the definitions from
>>> coresight.h.
>>>
>>> Add the following coresight macros ...
>>> - coresight_unlock() --> Unlocks coresight module
>>> - coresight_lock()   --> Locks coresight module
>>>
>>> Use the above macros for ETB, ETM and CTI. The do-while(0) statement
>>> has been removed from the macro as it is not a multi-line macro.
>>>
>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>>> ---
>>>  arch/arm/include/asm/cti.h                |   16 +++-------------
>>>  arch/arm/include/asm/hardware/coresight.h |   16 ++++++++--------
>>>  2 files changed, 11 insertions(+), 21 deletions(-)
>>
>> [...]
>>
>>> diff --git a/arch/arm/include/asm/hardware/coresight.h b/arch/arm/include/asm/hardware/coresight.h
>>> index 7ecd793..dcd0e66 100644
>>> --- a/arch/arm/include/asm/hardware/coresight.h
>>> +++ b/arch/arm/include/asm/hardware/coresight.h
>>> @@ -141,17 +141,17 @@
>>>  #define ETBFF_TRIGEVT               BIT(9)
>>>  #define ETBFF_TRIGFL                BIT(10)
>>>
>>> -#define etb_writel(t, v, x) \
>>> -    (__raw_writel((v), (t)->etb_regs + (x)))
>>> +#define etb_writel(t, v, x) (__raw_writel((v), (t)->etb_regs + (x)))
>>>  #define etb_readl(t, x) (__raw_readl((t)->etb_regs + (x)))
>>>
>>> -#define etm_lock(t) do { etm_writel((t), 0, CSMR_LOCKACCESS); } while (0)
>>> -#define etm_unlock(t) \
>>> -    do { etm_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
>>> +#define etb_lock(t) coresight_lock((t)->etb_regs)
>>> +#define etb_unlock(t) coresight_unlock((t)->etb_regs)
>>> +#define etm_lock(t) coresight_lock((t)->etm_regs)
>>> +#define etm_unlock(t) coresight_unlock((t)->etm_regs)
>>>
>>> -#define etb_lock(t) do { etb_writel((t), 0, CSMR_LOCKACCESS); } while (0)
>>> -#define etb_unlock(t) \
>>> -    do { etb_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
>>> +#define coresight_lock(base) (__raw_writel(0, base + CSMR_LOCKACCESS))
>>> +#define coresight_unlock(base) \
>>> +    (__raw_writel(UNLOCK_MAGIC, base + CSMR_LOCKACCESS))
>>>
>>>  #endif /* __ASM_HARDWARE_CORESIGHT_H */
>>
>> How about we take this opportunity to divorce the more general coresight
>> bits from the etb specific parts, like you've done for the cti. We could
>> move the ETB stuff out into asm/etb.h (although it might be nice to keep all
>> the coresight device headers in one place... answers on a postcard) and just
>> have the architected coresight functionality in this header.
>
> Yes I have been wondering about that too. Long term it would be good to
> find a home in the drivers directory for all these coresight devices
> too. For now, we could extract the etb/etm parts from coresight.h into
> etb.h and etm.h, respectively.

I am now writing a HW trace driver that extracts traces from the CMI
and PMI IP blocks (and later L2CC). It is still in early development
status.

The idea I have in mind is to have the implementation in
drivers/power/hw_trace. Eventually this directory would contain the
drivers for ETM/ETB, CMI, PMI and also the coresight support. It would
be architected so that the lower level drivers export the necessary
functions for the higher level code to use the resource. Example: the
PMI driver would use the ETB and coresight drivers.

What do you think?

Regards,
Jean

>
> Cheers
> Jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

[Jon Hunter]

Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
The ARM Cross Trigger Interface provides a way to route events between
processor modules. For example, on OMAP4430 we use the CTI module to
route PMU events to the GIC interrupt module.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 Documentation/devicetree/bindings/arm/cti.txt |   32 +++++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cti.txt

diff --git a/Documentation/devicetree/bindings/arm/cti.txt b/Documentation/devicetree/bindings/arm/cti.txt
new file mode 100644
index 0000000..4a0e2d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cti.txt
@@ -0,0 +1,32 @@
+* ARM Cross Trigger Interface (CTI)
+
+The ARM Cross Trigger Interface provides a way to route events between
+processor modules. For example, debug events from one processor can be
+broadcasted to other processors. The events that can be routed between
+processors are specific to the device.
+
+Required properties:
+
+- compatible:			Should be "arm,primecell".
+- interrupts:			Interrupt associated with CTI module.
+- reg:				Contains timer register address range (base
+				address and length).
+- arm,cti-name:			A unique name for the CTI module, that will be
+				used when requesting the CTI module instance.
+
+
+Optional properties:
+
+- arm-primecell-periphid:	Primecell peripheral ID associated with CTI
+				module.
+
+
+Example:
+
+cti0: cti at 0x54148000 {
+	compatible = "arm,primecell";
+	interrupts = <0 1 0x4>;
+	reg = <0x54148000 0x1000>;
+	arm,cti-name = "cti0";
+	arm,primecell-periphid = <0x003bb906>;
+};
-- 
1.7.10.4

[RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

[Rob Herring]

On 12/12/2012 03:43 PM, Jon Hunter wrote:
> Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
> The ARM Cross Trigger Interface provides a way to route events between
> processor modules. For example, on OMAP4430 we use the CTI module to
> route PMU events to the GIC interrupt module.

Do you need to describe the PMU-CTI-GIC connection in DT?

Rob

> 
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
>  Documentation/devicetree/bindings/arm/cti.txt |   32 +++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/cti.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/cti.txt b/Documentation/devicetree/bindings/arm/cti.txt
> new file mode 100644
> index 0000000..4a0e2d3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cti.txt
> @@ -0,0 +1,32 @@
> +* ARM Cross Trigger Interface (CTI)
> +
> +The ARM Cross Trigger Interface provides a way to route events between
> +processor modules. For example, debug events from one processor can be
> +broadcasted to other processors. The events that can be routed between
> +processors are specific to the device.
> +
> +Required properties:
> +
> +- compatible:			Should be "arm,primecell".
> +- interrupts:			Interrupt associated with CTI module.
> +- reg:				Contains timer register address range (base
> +				address and length).
> +- arm,cti-name:			A unique name for the CTI module, that will be
> +				used when requesting the CTI module instance.
> +
> +
> +Optional properties:
> +
> +- arm-primecell-periphid:	Primecell peripheral ID associated with CTI
> +				module.
> +
> +
> +Example:
> +
> +cti0: cti at 0x54148000 {
> +	compatible = "arm,primecell";
> +	interrupts = <0 1 0x4>;
> +	reg = <0x54148000 0x1000>;
> +	arm,cti-name = "cti0";
> +	arm,primecell-periphid = <0x003bb906>;
> +};
> 

[RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

[Jon Hunter]

On 12/12/2012 04:12 PM, Rob Herring wrote:
> On 12/12/2012 03:43 PM, Jon Hunter wrote:
>> Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
>> The ARM Cross Trigger Interface provides a way to route events between
>> processor modules. For example, on OMAP4430 we use the CTI module to
>> route PMU events to the GIC interrupt module.
> 
> Do you need to describe the PMU-CTI-GIC connection in DT?

We definitely could. This is achieved by mapping a trigger-input to a
trigger-output. So we could list the trigger outputs and inputs in the
binding. For omap4430 we would have ...

arm,cti-trigin = <0 1 2 3 4 5 6>;
arm,cti-trigin-names =  "dbgack", "pmuirq", "ptmextout0",
			"ptmextout1", "commtx", "commrx",
			"ptmtrigger";
arm,cti-trigout = <0 1 2 3 4 6 7>;
arm,cti-trigout-names = "edbgreq", "ptmextin0", "ptmextin1",
			"ptmextin2", "ptmextin3","mpuirq",
			"dbgrestart";

So to map the PMU to GIC, we would map the "pmuirq" trigger input to the
"mpuirq" trigger output. Then we could setup the mapping by name instead
of index.

Let me know what you think about that.

Cheers
Jon

[RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

[Rob Herring]

On 12/12/2012 05:23 PM, Jon Hunter wrote:
> 
> On 12/12/2012 04:12 PM, Rob Herring wrote:
>> On 12/12/2012 03:43 PM, Jon Hunter wrote:
>>> Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
>>> The ARM Cross Trigger Interface provides a way to route events between
>>> processor modules. For example, on OMAP4430 we use the CTI module to
>>> route PMU events to the GIC interrupt module.
>>
>> Do you need to describe the PMU-CTI-GIC connection in DT?
> 
> We definitely could. This is achieved by mapping a trigger-input to a
> trigger-output. So we could list the trigger outputs and inputs in the
> binding. For omap4430 we would have ...
> 
> arm,cti-trigin = <0 1 2 3 4 5 6>;

I'd prefer to just spell it out: arm,cti-trigger-in

> arm,cti-trigin-names =  "dbgack", "pmuirq", "ptmextout0",
> 			"ptmextout1", "commtx", "commrx",
> 			"ptmtrigger";
> arm,cti-trigout = <0 1 2 3 4 6 7>;
> arm,cti-trigout-names = "edbgreq", "ptmextin0", "ptmextin1",
> 			"ptmextin2", "ptmextin3","mpuirq",
> 			"dbgrestart";
> 
> So to map the PMU to GIC, we would map the "pmuirq" trigger input to the
> "mpuirq" trigger output. Then we could setup the mapping by name instead
> of index.

I'm not crazy about the name strings and would prefer something with
phandles. The above binding doesn't really describe the connection of
the CTI to the GIC. The GIC node would need to define some inputs and
then you show the connection to the CTI outputs. This may be similar to
an interrupt nexus node.

Rob

[RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

[Will Deacon]

On Wed, Dec 12, 2012 at 09:43:05PM +0000, Jon Hunter wrote:
> Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
> The ARM Cross Trigger Interface provides a way to route events between
> processor modules. For example, on OMAP4430 we use the CTI module to
> route PMU events to the GIC interrupt module.
> 
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
>  Documentation/devicetree/bindings/arm/cti.txt |   32 +++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/cti.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/cti.txt b/Documentation/devicetree/bindings/arm/cti.txt
> new file mode 100644
> index 0000000..4a0e2d3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cti.txt
> @@ -0,0 +1,32 @@
> +* ARM Cross Trigger Interface (CTI)
> +
> +The ARM Cross Trigger Interface provides a way to route events between
> +processor modules. For example, debug events from one processor can be
> +broadcasted to other processors. The events that can be routed between
> +processors are specific to the device.
> +
> +Required properties:
> +
> +- compatible:			Should be "arm,primecell".
> +- interrupts:			Interrupt associated with CTI module.
> +- reg:				Contains timer register address range (base
> +				address and length).
> +- arm,cti-name:			A unique name for the CTI module, that will be
> +				used when requesting the CTI module instance.
> +
> +
> +Optional properties:
> +
> +- arm-primecell-periphid:	Primecell peripheral ID associated with CTI
> +				module.

For multi-cluster systems, I wouldn't be surprised to see multiple CTI
instances, each with different CPU affinities. Can we include an affinity
property following Mark's proposed binding?

  http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html

Will

[RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

[Jon Hunter]

On 12/13/2012 11:41 AM, Will Deacon wrote:
> On Wed, Dec 12, 2012 at 09:43:05PM +0000, Jon Hunter wrote:
>> Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
>> The ARM Cross Trigger Interface provides a way to route events between
>> processor modules. For example, on OMAP4430 we use the CTI module to
>> route PMU events to the GIC interrupt module.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> ---
>>  Documentation/devicetree/bindings/arm/cti.txt |   32 +++++++++++++++++++++++++
>>  1 file changed, 32 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/cti.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/cti.txt b/Documentation/devicetree/bindings/arm/cti.txt
>> new file mode 100644
>> index 0000000..4a0e2d3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/cti.txt
>> @@ -0,0 +1,32 @@
>> +* ARM Cross Trigger Interface (CTI)
>> +
>> +The ARM Cross Trigger Interface provides a way to route events between
>> +processor modules. For example, debug events from one processor can be
>> +broadcasted to other processors. The events that can be routed between
>> +processors are specific to the device.
>> +
>> +Required properties:
>> +
>> +- compatible:			Should be "arm,primecell".
>> +- interrupts:			Interrupt associated with CTI module.
>> +- reg:				Contains timer register address range (base
>> +				address and length).
>> +- arm,cti-name:			A unique name for the CTI module, that will be
>> +				used when requesting the CTI module instance.
>> +
>> +
>> +Optional properties:
>> +
>> +- arm-primecell-periphid:	Primecell peripheral ID associated with CTI
>> +				module.
> 
> For multi-cluster systems, I wouldn't be surprised to see multiple CTI
> instances, each with different CPU affinities. Can we include an affinity
> property following Mark's proposed binding?
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html

Yes I can take a look. Would something like that be applicable to pmu as
well or is that unlikely to have different affinities? I am just
wondering if there is something that we should implement in general for
the various primecell components.

Cheers
Jon

[RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

[Mark Rutland]

On Thu, Dec 13, 2012 at 07:21:30PM +0000, Jon Hunter wrote:
> 
> On 12/13/2012 11:41 AM, Will Deacon wrote:
> > On Wed, Dec 12, 2012 at 09:43:05PM +0000, Jon Hunter wrote:
> >> Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
> >> The ARM Cross Trigger Interface provides a way to route events between
> >> processor modules. For example, on OMAP4430 we use the CTI module to
> >> route PMU events to the GIC interrupt module.
> >>
> >> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> >> ---
> >>  Documentation/devicetree/bindings/arm/cti.txt |   32 +++++++++++++++++++++++++
> >>  1 file changed, 32 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/cti.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/cti.txt b/Documentation/devicetree/bindings/arm/cti.txt
> >> new file mode 100644
> >> index 0000000..4a0e2d3
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/arm/cti.txt
> >> @@ -0,0 +1,32 @@
> >> +* ARM Cross Trigger Interface (CTI)
> >> +
> >> +The ARM Cross Trigger Interface provides a way to route events between
> >> +processor modules. For example, debug events from one processor can be
> >> +broadcasted to other processors. The events that can be routed between
> >> +processors are specific to the device.
> >> +
> >> +Required properties:
> >> +
> >> +- compatible:			Should be "arm,primecell".
> >> +- interrupts:			Interrupt associated with CTI module.
> >> +- reg:				Contains timer register address range (base
> >> +				address and length).
> >> +- arm,cti-name:			A unique name for the CTI module, that will be
> >> +				used when requesting the CTI module instance.
> >> +
> >> +
> >> +Optional properties:
> >> +
> >> +- arm-primecell-periphid:	Primecell peripheral ID associated with CTI
> >> +				module.
> > 
> > For multi-cluster systems, I wouldn't be surprised to see multiple CTI
> > instances, each with different CPU affinities. Can we include an affinity
> > property following Mark's proposed binding?
> > 
> >   http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html
> 
> Yes I can take a look. Would something like that be applicable to pmu as
> well or is that unlikely to have different affinities? I am just
> wondering if there is something that we should implement in general for
> the various primecell components.

Do you mean for describing the PMU's affinity to the perf subsystem or its
wiring to the CTI?

It's certainly applicable for the former; I've been working on a series to
enable support for the PMUs in both clusters in a A15x2 A7x3 coretile using the
binding, and I intend to post a series shortly. I'm not sure about the latter,
as I don't have much of an understanding about the CTI.

I'm not sure how many other components have affinity concerns, but the
intention is for the binding to be reusable.

> 
> Cheers
> Jon
> 

Thanks,
Mark.

[RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

[Jon Hunter]

On 12/17/2012 10:20 AM, Mark Rutland wrote:
> On Thu, Dec 13, 2012 at 07:21:30PM +0000, Jon Hunter wrote:
>>
>> On 12/13/2012 11:41 AM, Will Deacon wrote:
>>> On Wed, Dec 12, 2012 at 09:43:05PM +0000, Jon Hunter wrote:
>>>> Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
>>>> The ARM Cross Trigger Interface provides a way to route events between
>>>> processor modules. For example, on OMAP4430 we use the CTI module to
>>>> route PMU events to the GIC interrupt module.
>>>>
>>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/cti.txt |   32 +++++++++++++++++++++++++
>>>>  1 file changed, 32 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/cti.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/cti.txt b/Documentation/devicetree/bindings/arm/cti.txt
>>>> new file mode 100644
>>>> index 0000000..4a0e2d3
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/cti.txt
>>>> @@ -0,0 +1,32 @@
>>>> +* ARM Cross Trigger Interface (CTI)
>>>> +
>>>> +The ARM Cross Trigger Interface provides a way to route events between
>>>> +processor modules. For example, debug events from one processor can be
>>>> +broadcasted to other processors. The events that can be routed between
>>>> +processors are specific to the device.
>>>> +
>>>> +Required properties:
>>>> +
>>>> +- compatible:			Should be "arm,primecell".
>>>> +- interrupts:			Interrupt associated with CTI module.
>>>> +- reg:				Contains timer register address range (base
>>>> +				address and length).
>>>> +- arm,cti-name:			A unique name for the CTI module, that will be
>>>> +				used when requesting the CTI module instance.
>>>> +
>>>> +
>>>> +Optional properties:
>>>> +
>>>> +- arm-primecell-periphid:	Primecell peripheral ID associated with CTI
>>>> +				module.
>>>
>>> For multi-cluster systems, I wouldn't be surprised to see multiple CTI
>>> instances, each with different CPU affinities. Can we include an affinity
>>> property following Mark's proposed binding?
>>>
>>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html
>>
>> Yes I can take a look. Would something like that be applicable to pmu as
>> well or is that unlikely to have different affinities? I am just
>> wondering if there is something that we should implement in general for
>> the various primecell components.
> 
> Do you mean for describing the PMU's affinity to the perf subsystem or its
> wiring to the CTI?

Yes the PMU's affinity in general, ignoring CTI for now.

> It's certainly applicable for the former; I've been working on a series to
> enable support for the PMUs in both clusters in a A15x2 A7x3 coretile using the
> binding, and I intend to post a series shortly. I'm not sure about the latter,
> as I don't have much of an understanding about the CTI.

Ok great. I think that this use-case of PMU+CTI is a special case for
OMAP. CTI could be used for many things and for some reason TI hooked up
the PMU interrupt via the CTI on OMAP4430 (which has been giving me
grief ;-)

So if there is a general way to describe the affinity of a module, such
as PMU, I could re-use this and add to the CTI binding as Will suggested.

> I'm not sure how many other components have affinity concerns, but the
> intention is for the binding to be reusable.

Great.

Thanks
Jon

[RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver

[Jon Hunter]

Convert the Cross Trigger Interface (CTI) helpers in cti.h into a
AMBA bus driver so that we can use device-tree to look-up the hardware
specific information such as base address and interrupt number during
the device probe. This also add APIs to request, cti_get() and release,
cti_put(), a CTI module so that drivers can allocate a module at
runtime.

Currently, the driver only supports looking-up the CTI hardware
information via device-tree, however, the driver could be extended to
support non-device-tree configurations if needed for a particular
architecture.

The CTI driver only currently supports CTI modules that have a single
CPU interrupt, however, could be extended in the future to support more
interrupts if a device requires this.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/include/asm/cti.h |  153 ------------------------
 drivers/Kconfig            |    2 +
 drivers/amba/Kconfig       |   20 ++++
 drivers/amba/Makefile      |    1 +
 drivers/amba/cti.c         |  284 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/amba/cti.h   |   82 +++++++++++++
 6 files changed, 389 insertions(+), 153 deletions(-)
 delete mode 100644 arch/arm/include/asm/cti.h
 create mode 100644 drivers/amba/Kconfig
 create mode 100644 drivers/amba/cti.c
 create mode 100644 include/linux/amba/cti.h

diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
deleted file mode 100644
index 00add00..0000000
--- a/arch/arm/include/asm/cti.h
+++ /dev/null
@@ -1,153 +0,0 @@
-#ifndef __ASMARM_CTI_H
-#define __ASMARM_CTI_H
-
-#include	<asm/io.h>
-#include	<asm/hardware/coresight.h>
-
-/* The registers' definition is from section 3.2 of
- * Embedded Cross Trigger Revision: r0p0
- */
-#define		CTICONTROL		0x000
-#define		CTISTATUS		0x004
-#define		CTILOCK			0x008
-#define		CTIPROTECTION		0x00C
-#define		CTIINTACK		0x010
-#define		CTIAPPSET		0x014
-#define		CTIAPPCLEAR		0x018
-#define		CTIAPPPULSE		0x01c
-#define		CTIINEN			0x020
-#define		CTIOUTEN		0x0A0
-#define		CTITRIGINSTATUS		0x130
-#define		CTITRIGOUTSTATUS	0x134
-#define		CTICHINSTATUS		0x138
-#define		CTICHOUTSTATUS		0x13c
-#define		CTIPERIPHID0		0xFE0
-#define		CTIPERIPHID1		0xFE4
-#define		CTIPERIPHID2		0xFE8
-#define		CTIPERIPHID3		0xFEC
-#define		CTIPCELLID0		0xFF0
-#define		CTIPCELLID1		0xFF4
-#define		CTIPCELLID2		0xFF8
-#define		CTIPCELLID3		0xFFC
-
-/**
- * struct cti - cross trigger interface struct
- * @base: mapped virtual address for the cti base
- * @irq: irq number for the cti
- * @trig_out_for_irq: triger out number which will cause
- *	the @irq happen
- *
- * cti struct used to operate cti registers.
- */
-struct cti {
-	void __iomem *base;
-	int irq;
-	int trig_out_for_irq;
-};
-
-/**
- * cti_init - initialize the cti instance
- * @cti: cti instance
- * @base: mapped virtual address for the cti base
- * @irq: irq number for the cti
- * @trig_out: triger out number which will cause
- *	the @irq happen
- *
- * called by machine code to pass the board dependent
- * @base, @irq and @trig_out to cti.
- */
-static inline void cti_init(struct cti *cti,
-	void __iomem *base, int irq, int trig_out)
-{
-	cti->base = base;
-	cti->irq  = irq;
-	cti->trig_out_for_irq = trig_out;
-}
-
-/**
- * cti_map_trigger - use the @chan to map @trig_in to @trig_out
- * @cti: cti instance
- * @trig_in: trigger in number
- * @trig_out: trigger out number
- * @channel: channel number
- *
- * This function maps one trigger in of @trig_in to one trigger
- * out of @trig_out using the channel @chan.
- */
-static inline void cti_map_trigger(struct cti *cti,
-	int trig_in, int trig_out, int chan)
-{
-	void __iomem *base = cti->base;
-	unsigned long val;
-
-	val = __raw_readl(base + CTIINEN + trig_in * 4);
-	val |= BIT(chan);
-	__raw_writel(val, base + CTIINEN + trig_in * 4);
-
-	val = __raw_readl(base + CTIOUTEN + trig_out * 4);
-	val |= BIT(chan);
-	__raw_writel(val, base + CTIOUTEN + trig_out * 4);
-}
-
-/**
- * cti_enable - enable the cti module
- * @cti: cti instance
- *
- * enable the cti module
- */
-static inline void cti_enable(struct cti *cti)
-{
-	__raw_writel(0x1, cti->base + CTICONTROL);
-}
-
-/**
- * cti_disable - disable the cti module
- * @cti: cti instance
- *
- * enable the cti module
- */
-static inline void cti_disable(struct cti *cti)
-{
-	__raw_writel(0, cti->base + CTICONTROL);
-}
-
-/**
- * cti_irq_ack - clear the cti irq
- * @cti: cti instance
- *
- * clear the cti irq
- */
-static inline void cti_irq_ack(struct cti *cti)
-{
-	void __iomem *base = cti->base;
-	unsigned long val;
-
-	val = __raw_readl(base + CTIINTACK);
-	val |= BIT(cti->trig_out_for_irq);
-	__raw_writel(val, base + CTIINTACK);
-}
-
-/**
- * cti_unlock - unlock cti module
- * @cti: cti instance
- *
- * unlock the cti module, or else any writes to the cti
- * module is not allowed.
- */
-static inline void cti_unlock(struct cti *cti)
-{
-	coresight_unlock(cti->base);
-}
-
-/**
- * cti_lock - lock cti module
- * @cti: cti instance
- *
- * lock the cti module, so any writes to the cti
- * module will be not allowed.
- */
-static inline void cti_lock(struct cti *cti)
-{
-	coresight_lock(cti->base);
-}
-#endif
diff --git a/drivers/Kconfig b/drivers/Kconfig
index dbdefa3..e857075 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -2,6 +2,8 @@ menu "Device Drivers"
 
 source "drivers/base/Kconfig"
 
+source "drivers/amba/Kconfig"
+
 source "drivers/bus/Kconfig"
 
 source "drivers/connector/Kconfig"
diff --git a/drivers/amba/Kconfig b/drivers/amba/Kconfig
new file mode 100644
index 0000000..b97ea23
--- /dev/null
+++ b/drivers/amba/Kconfig
@@ -0,0 +1,20 @@
+#
+# AMBA Devices
+#
+
+menu "AMBA devices"
+
+config ARM_AMBA_CTI
+	bool "Cross-Trigger Interface"
+	depends on ARM && OF
+	select ARM_AMBA
+	help
+	  The ARM Cross Trigger Interface provides a way to route events
+	  between processor modules. For example, debug events from one
+	  processor can be broadcasted to other processors. The events that
+	  can be routed between processors are specific to the device.
+	  Currently, the driver only supports looking-up the CTI hardware
+	  information (base address and interrupts) from device-tree (and
+	  hence, is dependent upon CONFIG_OF).
+
+endmenu
diff --git a/drivers/amba/Makefile b/drivers/amba/Makefile
index 66e81c2..f74abe9 100644
--- a/drivers/amba/Makefile
+++ b/drivers/amba/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_ARM_AMBA)		+= bus.o
+obj-$(CONFIG_ARM_AMBA_CTI)	+= cti.o
 obj-$(CONFIG_TEGRA_AHB)		+= tegra-ahb.o
diff --git a/drivers/amba/cti.c b/drivers/amba/cti.c
new file mode 100644
index 0000000..04debe7
--- /dev/null
+++ b/drivers/amba/cti.c
@@ -0,0 +1,284 @@
+/*
+ * ARM Cross Trigger Interface (CTI) Driver
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *  Jon Hunter <jon-hunter@ti.com>
+ *
+ * Based upon CTI Helpers by Ming Lei <ming.lei@canonical.com>.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <asm/hardware/coresight.h>
+
+#include <linux/amba/bus.h>
+#include <linux/amba/cti.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/slab.h>
+
+/* The registers' definition is from section 3.2 of
+ * Embedded Cross Trigger Revision: r0p0
+ */
+#define		CTICONTROL		0x000
+#define		CTISTATUS		0x004
+#define		CTILOCK			0x008
+#define		CTIPROTECTION		0x00C
+#define		CTIINTACK		0x010
+#define		CTIAPPSET		0x014
+#define		CTIAPPCLEAR		0x018
+#define		CTIAPPPULSE		0x01c
+#define		CTIINEN			0x020
+#define		CTIOUTEN		0x0A0
+#define		CTITRIGINSTATUS		0x130
+#define		CTITRIGOUTSTATUS	0x134
+#define		CTICHINSTATUS		0x138
+#define		CTICHOUTSTATUS		0x13c
+#define		CTIPERIPHID0		0xFE0
+#define		CTIPERIPHID1		0xFE4
+#define		CTIPERIPHID2		0xFE8
+#define		CTIPERIPHID3		0xFEC
+#define		CTIPCELLID0		0xFF0
+#define		CTIPCELLID1		0xFF4
+#define		CTIPCELLID2		0xFF8
+#define		CTIPCELLID3		0xFFC
+#define		CTI_MAX_CHANNELS	15
+#define		CTI_MAX_TRIGGERS	7
+
+#define cti_writel(v, c, x) (__raw_writel((v), (c)->base + (x)))
+#define cti_readl(c, x) (__raw_readl((c)->base + (x)))
+
+static DEFINE_SPINLOCK(cti_lock);
+static LIST_HEAD(cti_list);
+
+/**
+ * cti_map_trigger - use the @chan to map @trig_in to @trig_out
+ * @cti:	CTI instance
+ * @trig_in:	trigger in number
+ * @trig_out:	trigger out number
+ * @chan:	channel number
+ *
+ * Maps one trigger in of @trig_in to one trigger out of @trig_out
+ * using the channel @chan. The CTI module must not be enabled when
+ * calling this function.
+ */
+int cti_map_trigger(struct cti *cti, int trig_in, int trig_out, int chan)
+{
+	u32 v;
+
+	if (!cti)
+		return -EINVAL;
+
+	if (cti->enabled)
+		return -EBUSY;
+
+	if (chan > CTI_MAX_CHANNELS)
+		return -EINVAL;
+
+	if ((trig_in > CTI_MAX_TRIGGERS) || (trig_out > CTI_MAX_TRIGGERS))
+		return -EINVAL;
+
+	coresight_unlock(cti->base);
+
+	v = cti_readl(cti, CTIINEN + trig_in * 4);
+	v |= BIT(chan);
+	cti_writel(v, cti, CTIINEN + trig_in * 4);
+	v = cti_readl(cti, CTIOUTEN + trig_out * 4);
+	v |= BIT(chan);
+	cti_writel(v, cti, CTIOUTEN + trig_out * 4);
+	cti->trig_out = trig_out;
+
+	coresight_lock(cti->base);
+
+	return 0;
+}
+
+/**
+ * cti_enable - enable the CTI module
+ * @cti: CTI instance
+ *
+ * Unlocks and enables the CTI module. The CTI module cannot be
+ * programmed again until it has been disabled.
+ */
+int cti_enable(struct cti *cti)
+{
+	if (!cti || cti->enabled)
+			return -EINVAL;
+
+	coresight_unlock(cti->base);
+	cti_writel(1, cti, CTICONTROL);
+	cti->enabled = true;
+
+	return 0;
+}
+
+/**
+ * cti_disable - disable the CTI module
+ * @cti: CTI instance
+ *
+ * Disables and locks the CTI module.
+ */
+int cti_disable(struct cti *cti)
+{
+	if (!cti || !cti->enabled)
+		return -EINVAL;
+
+	cti_writel(0, cti, CTICONTROL);
+	cti->enabled = false;
+	coresight_lock(cti->base);
+
+	return 0;
+}
+
+/**
+ * cti_irq_ack - acknowledges the CTI trigger output
+ * @cti: CTI instance
+ *
+ * Acknowledges the CTI trigger output by writting to the appropriate
+ * bit in the CTI interrupt acknowledge register.
+ */
+int cti_irq_ack(struct cti *cti)
+{
+	u32 v;
+
+	if (!cti || !cti->enabled)
+		return -EINVAL;
+
+	v = cti_readl(cti, CTIINTACK);
+	v |= BIT(cti->trig_out);
+	cti_writel(v, cti, CTIINTACK);
+
+	return 0;
+}
+
+/**
+ * cti_get - acquire a CTI module
+ * @name: name of CTI instance
+ *
+ * Acquires a CTI module from a list of CTI modules by name. If the CTI
+ * module is already in use then return NULL, otherwise return a valid
+ * handle to the CTI module.
+ */
+struct cti *cti_get(const char *name)
+{
+	struct cti *cti = NULL;
+	unsigned long flags;
+
+	if (!name)
+		return NULL;
+
+	spin_lock_irqsave(&cti_lock, flags);
+
+	if (list_empty(&cti_list))
+		goto out;
+
+	list_for_each_entry(cti, &cti_list, node) {
+		if (!strcmp(cti->name, name) && (!cti->reserved)) {
+			cti->reserved = true;
+			goto out;
+		}
+	}
+
+out:
+	spin_unlock_irqrestore(&cti_lock, flags);
+
+	if (cti)
+		pm_runtime_get_sync(cti->dev);
+
+	return cti;
+}
+
+/**
+ * cti_put - release handle to CTI module
+ * @cti: CTI instance
+ *
+ * Releases a handle to CTI module that was previously acquired.
+ */
+void cti_put(struct cti *cti)
+{
+	if (!cti || !cti->reserved)
+		return;
+
+	cti->reserved = false;
+
+	pm_runtime_put(cti->dev);
+}
+
+static int cti_probe(struct amba_device *dev, const struct amba_id *id)
+{
+	struct cti *cti;
+	struct device_node *np = dev->dev.of_node;
+	int rc;
+
+	if (!np) {
+		dev_err(&dev->dev, "device-tree not found!\n");
+		return -ENODEV;
+	}
+
+	cti = devm_kzalloc(&dev->dev, sizeof(struct cti), GFP_KERNEL);
+	if (!cti) {
+		dev_err(&dev->dev, "memory allocation failed!\n");
+		return -ENOMEM;
+	}
+
+	rc = of_property_read_string_index(np, "arm,cti-name", 0, &cti->name);
+	if (rc) {
+		dev_err(&dev->dev, "no name found for CTI!\n");
+		return rc;
+	}
+
+	if (!dev->irq[0]) {
+		dev_err(&dev->dev, "no CTI interrupt found!\n");
+		return -ENODEV;
+	}
+
+	cti->irq = dev->irq[0];
+	cti->base = of_iomap(np, 0);
+	if (!cti->base) {
+		dev_err(&dev->dev, "unable to map CTI registers!\n");
+		return -ENOMEM;
+	}
+
+	cti->dev = &dev->dev;
+	amba_set_drvdata(dev, cti);
+	list_add_tail(&cti->node, &cti_list);
+
+	/*
+	 * AMBA bus driver has already enabled RPM and incremented
+	 * use-count, so now we can safely decrement the use-count
+	 * and allow the CTI driver to manage RPM for the device.
+	 */
+	pm_runtime_put(&dev->dev);
+
+	dev_info(&dev->dev, "ARM CTI driver");
+
+	return 0;
+}
+
+static const struct amba_id cti_ids[] = {
+	{
+		.id	= 0x003bb906,
+		.mask	= 0x00ffffff,
+	},
+	{ 0, 0 },
+};
+
+static struct amba_driver cti_driver = {
+	.drv		= {
+		.name	= "cti",
+	},
+	.id_table	= cti_ids,
+	.probe		= cti_probe,
+};
+
+static int __init cti_init(void)
+{
+	return amba_driver_register(&cti_driver);
+}
+subsys_initcall(cti_init);
diff --git a/include/linux/amba/cti.h b/include/linux/amba/cti.h
new file mode 100644
index 0000000..a82ae76
--- /dev/null
+++ b/include/linux/amba/cti.h
@@ -0,0 +1,82 @@
+/*
+ * ARM Cross Trigger Interface Platform Driver
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *  Jon Hunter <jon-hunter@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef AMBA_CTI_H
+#define AMBA_CTI_H
+
+#include <linux/io.h>
+
+/**
+ * struct cti - Cross Trigger Interface (CTI) struct
+ *
+ * @node:	Connects CTI instance to list of CTI instances
+ * @dev:	Pointer to device structure
+ * @base:	Mapped virtual address of the CTI module
+ * @name:	Name associated with CTI instance
+ * @irq:	Interrupt associated with CTI instance
+ * @trig_out:	Trigger output associated with interrupt (@irq)
+ * @reserved:	Used to indicate if CTI instance has been allocated
+ * @enabled:	Used to indicate if CTI instance has been enabled
+ */
+struct cti {
+	struct list_head node;
+	struct device *dev;
+	void __iomem *base;
+	const char *name;
+	int irq;
+	int trig_out;
+	bool reserved;
+	bool enabled;
+};
+
+#ifdef CONFIG_ARM_AMBA_CTI
+
+int cti_map_trigger(struct cti *cti, int trig_in, int trig_out, int chan);
+int cti_enable(struct cti *cti);
+int cti_disable(struct cti *cti);
+int cti_irq_ack(struct cti *cti);
+struct cti *cti_get(const char *name);
+void cti_put(struct cti *cti);
+
+#else
+
+static inline int cti_map_trigger(struct cti *cti, int trig_in, int trig_out,
+				  int chan)
+{
+	return 0;
+}
+
+static inline int cti_enable(struct cti *cti)
+{
+	return 0;
+}
+
+static inline int cti_disable(struct cti *cti)
+{
+	return 0;
+}
+
+static inline int cti_irq_ack(struct cti *cti)
+{
+	return 0;
+}
+
+static inline struct cti *cti_get(const char *name)
+{
+	return NULL;
+}
+
+static inline void cti_put(struct cti *cti) {}
+
+#endif /* ARM_AMBA_CTI */
+
+#endif /* AMBA_CTI_H */
-- 
1.7.10.4

[RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver

[Will Deacon]

On Wed, Dec 12, 2012 at 09:43:06PM +0000, Jon Hunter wrote:
> Convert the Cross Trigger Interface (CTI) helpers in cti.h into a
> AMBA bus driver so that we can use device-tree to look-up the hardware
> specific information such as base address and interrupt number during
> the device probe. This also add APIs to request, cti_get() and release,
> cti_put(), a CTI module so that drivers can allocate a module at
> runtime.
> 
> Currently, the driver only supports looking-up the CTI hardware
> information via device-tree, however, the driver could be extended to
> support non-device-tree configurations if needed for a particular
> architecture.
> 
> The CTI driver only currently supports CTI modules that have a single
> CPU interrupt, however, could be extended in the future to support more
> interrupts if a device requires this.

Aha, so elaborating on my earlier comments, we basically want to do the same
thing for ETB I reckon. This does raise the question about namespaces
though...

> +/**
> + * struct cti - Cross Trigger Interface (CTI) struct
> + *
> + * @node:      Connects CTI instance to list of CTI instances
> + * @dev:       Pointer to device structure
> + * @base:      Mapped virtual address of the CTI module
> + * @name:      Name associated with CTI instance
> + * @irq:       Interrupt associated with CTI instance
> + * @trig_out:  Trigger output associated with interrupt (@irq)
> + * @reserved:  Used to indicate if CTI instance has been allocated
> + * @enabled:   Used to indicate if CTI instance has been enabled
> + */
> +struct cti {
> +       struct list_head node;
> +       struct device *dev;
> +       void __iomem *base;
> +       const char *name;
> +       int irq;
> +       int trig_out;
> +       bool reserved;
> +       bool enabled;
> +};
> +
> +#ifdef CONFIG_ARM_AMBA_CTI
> +
> +int cti_map_trigger(struct cti *cti, int trig_in, int trig_out, int chan);
> +int cti_enable(struct cti *cti);
> +int cti_disable(struct cti *cti);
> +int cti_irq_ack(struct cti *cti);
> +struct cti *cti_get(const char *name);
> +void cti_put(struct cti *cti);

I wonder whether we should stick these all into a struct and have a general
way to see which coresight devices we have and then retrieve their ops
structures (so things like perf can walk a virtual coresight bus containing
initialised devices). It might also help if we decide to describe the
plumbing in the device tree, like Rob suggested.

What do you reckon?

Will

[RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver

[Jon Hunter]

On 12/13/2012 09:08 AM, Will Deacon wrote:
> On Wed, Dec 12, 2012 at 09:43:06PM +0000, Jon Hunter wrote:
>> Convert the Cross Trigger Interface (CTI) helpers in cti.h into a
>> AMBA bus driver so that we can use device-tree to look-up the hardware
>> specific information such as base address and interrupt number during
>> the device probe. This also add APIs to request, cti_get() and release,
>> cti_put(), a CTI module so that drivers can allocate a module at
>> runtime.
>>
>> Currently, the driver only supports looking-up the CTI hardware
>> information via device-tree, however, the driver could be extended to
>> support non-device-tree configurations if needed for a particular
>> architecture.
>>
>> The CTI driver only currently supports CTI modules that have a single
>> CPU interrupt, however, could be extended in the future to support more
>> interrupts if a device requires this.
> 
> Aha, so elaborating on my earlier comments, we basically want to do the same
> thing for ETB I reckon. This does raise the question about namespaces
> though...
> 
>> +/**
>> + * struct cti - Cross Trigger Interface (CTI) struct
>> + *
>> + * @node:      Connects CTI instance to list of CTI instances
>> + * @dev:       Pointer to device structure
>> + * @base:      Mapped virtual address of the CTI module
>> + * @name:      Name associated with CTI instance
>> + * @irq:       Interrupt associated with CTI instance
>> + * @trig_out:  Trigger output associated with interrupt (@irq)
>> + * @reserved:  Used to indicate if CTI instance has been allocated
>> + * @enabled:   Used to indicate if CTI instance has been enabled
>> + */
>> +struct cti {
>> +       struct list_head node;
>> +       struct device *dev;
>> +       void __iomem *base;
>> +       const char *name;
>> +       int irq;
>> +       int trig_out;
>> +       bool reserved;
>> +       bool enabled;
>> +};
>> +
>> +#ifdef CONFIG_ARM_AMBA_CTI
>> +
>> +int cti_map_trigger(struct cti *cti, int trig_in, int trig_out, int chan);
>> +int cti_enable(struct cti *cti);
>> +int cti_disable(struct cti *cti);
>> +int cti_irq_ack(struct cti *cti);
>> +struct cti *cti_get(const char *name);
>> +void cti_put(struct cti *cti);
> 
> I wonder whether we should stick these all into a struct and have a general
> way to see which coresight devices we have and then retrieve their ops
> structures (so things like perf can walk a virtual coresight bus containing
> initialised devices).

Yes we could use a struct here. Hopefully, the enable/disable/get/put
could be used across coresight devices. I would need to think more about
the custom functions such as map_trigger which are specific to CTI.

> It might also help if we decide to describe the
> plumbing in the device tree, like Rob suggested.

Yes, I did propose adding more information to the binding for CTI to
describe trigger-ins/outs for a device. However, we could go a step
further and try and come up with a way to link the devices. Though I am
not sure if there are any other possible use-cases for CTI where that
may not be suitable and we just want to be able to configure it to map
trigger input to trigger output. Anyway, open to any ideas to improve this.

Cheers
Jon

[RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver

[Pratik Patel]

On Wed, Dec 12, 2012 at 03:43:06PM -0600, Jon Hunter wrote:
> +
> +/**
> + * cti_irq_ack - acknowledges the CTI trigger output
> + * @cti: CTI instance
> + *
> + * Acknowledges the CTI trigger output by writting to the appropriate
> + * bit in the CTI interrupt acknowledge register.
> + */
> +int cti_irq_ack(struct cti *cti)
> +{
> +	u32 v;
> +
> +	if (!cti || !cti->enabled)
> +		return -EINVAL;
> +
> +	v = cti_readl(cti, CTIINTACK);

Just curious if CTIINTACK is a read-write register? This is a
read-only for us.

> +	v |= BIT(cti->trig_out);
> +	cti_writel(v, cti, CTIINTACK);
> +
> +	return 0;
> +}
> +
> +
> +static int cti_probe(struct amba_device *dev, const struct amba_id *id)
> +{
> +	struct cti *cti;
> +	struct device_node *np = dev->dev.of_node;
> +	int rc;
> +
> +	if (!np) {
> +		dev_err(&dev->dev, "device-tree not found!\n");
> +		return -ENODEV;
> +	}
> +
> +	cti = devm_kzalloc(&dev->dev, sizeof(struct cti), GFP_KERNEL);
> +	if (!cti) {
> +		dev_err(&dev->dev, "memory allocation failed!\n");
> +		return -ENOMEM;
> +	}
> +
> +	rc = of_property_read_string_index(np, "arm,cti-name", 0, &cti->name);
> +	if (rc) {
> +		dev_err(&dev->dev, "no name found for CTI!\n");
> +		return rc;
> +	}

Shouldn't the CTI driver have some kind of clock management that
it does for itself?

> +
> +	if (!dev->irq[0]) {
> +		dev_err(&dev->dev, "no CTI interrupt found!\n");
> +		return -ENODEV;
> +	}
> +
> +	cti->irq = dev->irq[0];
> +	cti->base = of_iomap(np, 0);
> +	if (!cti->base) {
> +		dev_err(&dev->dev, "unable to map CTI registers!\n");
> +		return -ENOMEM;
> +	}
> +
> +	cti->dev = &dev->dev;
> +	amba_set_drvdata(dev, cti);
> +	list_add_tail(&cti->node, &cti_list);
> +
> +	/*
> +	 * AMBA bus driver has already enabled RPM and incremented
> +	 * use-count, so now we can safely decrement the use-count
> +	 * and allow the CTI driver to manage RPM for the device.
> +	 */
> +	pm_runtime_put(&dev->dev);
> +
> +	dev_info(&dev->dev, "ARM CTI driver");
> +
> +	return 0;
> +}
> +

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver

[Pratik Patel]

On Fri, Dec 21, 2012 at 02:27:03PM -0800, Pratik Patel wrote:
> On Wed, Dec 12, 2012 at 03:43:06PM -0600, Jon Hunter wrote:
> > +
> > +/**
> > + * cti_irq_ack - acknowledges the CTI trigger output
> > + * @cti: CTI instance
> > + *
> > + * Acknowledges the CTI trigger output by writting to the appropriate
> > + * bit in the CTI interrupt acknowledge register.
> > + */
> > +int cti_irq_ack(struct cti *cti)
> > +{
> > +	u32 v;
> > +
> > +	if (!cti || !cti->enabled)
> > +		return -EINVAL;
> > +
> > +	v = cti_readl(cti, CTIINTACK);
> 
> Just curious if CTIINTACK is a read-write register? This is a
> read-only for us.
> 
Mistyped - its a write-only for us

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver

[Jon Hunter]

On 12/21/2012 04:35 PM, Pratik Patel wrote:
> On Fri, Dec 21, 2012 at 02:27:03PM -0800, Pratik Patel wrote:
>> On Wed, Dec 12, 2012 at 03:43:06PM -0600, Jon Hunter wrote:
>>> +
>>> +/**
>>> + * cti_irq_ack - acknowledges the CTI trigger output
>>> + * @cti: CTI instance
>>> + *
>>> + * Acknowledges the CTI trigger output by writting to the appropriate
>>> + * bit in the CTI interrupt acknowledge register.
>>> + */
>>> +int cti_irq_ack(struct cti *cti)
>>> +{
>>> +	u32 v;
>>> +
>>> +	if (!cti || !cti->enabled)
>>> +		return -EINVAL;
>>> +
>>> +	v = cti_readl(cti, CTIINTACK);
>>
>> Just curious if CTIINTACK is a read-write register? This is a
>> read-only for us.
>>
> Mistyped - its a write-only for us

You are right. Looking at the ARM documentation this is a write-only
register. I had copied this function from the original helpers but had
not checked if this was readable. I will correct this.

Cheers
Jon

[RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver

[Jon Hunter]

On 12/21/2012 04:27 PM, Pratik Patel wrote:
> On Wed, Dec 12, 2012 at 03:43:06PM -0600, Jon Hunter wrote:
>> +
>> +/**
>> + * cti_irq_ack - acknowledges the CTI trigger output
>> + * @cti: CTI instance
>> + *
>> + * Acknowledges the CTI trigger output by writting to the appropriate
>> + * bit in the CTI interrupt acknowledge register.
>> + */
>> +int cti_irq_ack(struct cti *cti)
>> +{
>> +	u32 v;
>> +
>> +	if (!cti || !cti->enabled)
>> +		return -EINVAL;
>> +
>> +	v = cti_readl(cti, CTIINTACK);
> 
> Just curious if CTIINTACK is a read-write register? This is a
> read-only for us.
> 
>> +	v |= BIT(cti->trig_out);
>> +	cti_writel(v, cti, CTIINTACK);
>> +
>> +	return 0;
>> +}
>> +
>> +
>> +static int cti_probe(struct amba_device *dev, const struct amba_id *id)
>> +{
>> +	struct cti *cti;
>> +	struct device_node *np = dev->dev.of_node;
>> +	int rc;
>> +
>> +	if (!np) {
>> +		dev_err(&dev->dev, "device-tree not found!\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	cti = devm_kzalloc(&dev->dev, sizeof(struct cti), GFP_KERNEL);
>> +	if (!cti) {
>> +		dev_err(&dev->dev, "memory allocation failed!\n");
>> +		return -ENOMEM;
>> +	}
>> +
>> +	rc = of_property_read_string_index(np, "arm,cti-name", 0, &cti->name);
>> +	if (rc) {
>> +		dev_err(&dev->dev, "no name found for CTI!\n");
>> +		return rc;
>> +	}
> 
> Shouldn't the CTI driver have some kind of clock management that
> it does for itself?

It does by using runtime PM. If you look at the cti_get/put functions,
you will see calls to pm_runtime_get/put. These calls will enable the
AMBA apb-clock. If you need to enable additional clocks then you could
register pm runtime resume/idle call backs to do this.

Cheers
Jon

[RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver

[Pratik Patel]

On Wed, Jan 02, 2013 at 01:23:32PM -0600, Jon Hunter wrote:
> 
> On 12/21/2012 04:27 PM, Pratik Patel wrote:
> > On Wed, Dec 12, 2012 at 03:43:06PM -0600, Jon Hunter wrote:
> >> +
> >> +/**
> >> + * cti_irq_ack - acknowledges the CTI trigger output
> >> + * @cti: CTI instance
> >> + *
> >> + * Acknowledges the CTI trigger output by writting to the appropriate
> >> + * bit in the CTI interrupt acknowledge register.
> >> + */
> >> +int cti_irq_ack(struct cti *cti)
> >> +{
> >> +	u32 v;
> >> +
> >> +	if (!cti || !cti->enabled)
> >> +		return -EINVAL;
> >> +
> >> +	v = cti_readl(cti, CTIINTACK);
> > 
> > Just curious if CTIINTACK is a read-write register? This is a
> > read-only for us.
> > 
> >> +	v |= BIT(cti->trig_out);
> >> +	cti_writel(v, cti, CTIINTACK);
> >> +
> >> +	return 0;
> >> +}
> >> +
> >> +
> >> +static int cti_probe(struct amba_device *dev, const struct amba_id *id)
> >> +{
> >> +	struct cti *cti;
> >> +	struct device_node *np = dev->dev.of_node;
> >> +	int rc;
> >> +
> >> +	if (!np) {
> >> +		dev_err(&dev->dev, "device-tree not found!\n");
> >> +		return -ENODEV;
> >> +	}
> >> +
> >> +	cti = devm_kzalloc(&dev->dev, sizeof(struct cti), GFP_KERNEL);
> >> +	if (!cti) {
> >> +		dev_err(&dev->dev, "memory allocation failed!\n");
> >> +		return -ENOMEM;
> >> +	}
> >> +
> >> +	rc = of_property_read_string_index(np, "arm,cti-name", 0, &cti->name);
> >> +	if (rc) {
> >> +		dev_err(&dev->dev, "no name found for CTI!\n");
> >> +		return rc;
> >> +	}
> > 
> > Shouldn't the CTI driver have some kind of clock management that
> > it does for itself?
> 
> It does by using runtime PM. If you look at the cti_get/put functions,
> you will see calls to pm_runtime_get/put. These calls will enable the
> AMBA apb-clock. If you need to enable additional clocks then you could
> register pm runtime resume/idle call backs to do this.
> 

Ok

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[RFC 4/5] ARM: dts: OMAP4: Add CTI nodes

[Jon Hunter]

Add device-tree nodes for the two Cross Trigger Interface (CTI) modules
in the OMAP4 devices.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/boot/dts/omap4.dtsi |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..40270c7 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -59,6 +59,29 @@
 		interrupts = <1 13 0x304>;
 	};
 
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		cti0: cti at 0x54148000 {
+			compatible = "arm,primecell";
+			interrupts = <0 1 0x4>;
+			reg = <0x54148000 0x1000>;
+			arm,cti-name = "cti0";
+			arm,primecell-periphid = <0x003bb906>;
+		};
+
+		cti1: cti at 0x54149000 {
+			compatible = "arm,primecell";
+			interrupts = <0 2 0x4>;
+			reg = <0x54149000 0x1000>;
+			arm,cti-name = "cti1";
+			arm,primecell-periphid = <0x003bb906>;
+		};
+	};
+
 	/*
 	 * The soc node represents the soc top level view. It is uses for IPs
 	 * that are not memory mapped in the MPU view or for the MPU itself.
-- 
1.7.10.4

[RFC 5/5] ARM: OMAP4: Add AMBA APB Clock

[Jon Hunter]

For OMAP4 devices, ARM AMBA peripherals such as program trace module
(PTM) or cross trigger interface (CTI) require that the DEBUG Sub-system
power and clock domain is turned on. Normally, the OMAP device and HMWOD
frameworks would be used to enable the power and clock domains, but
currently these frameworks only support platform devices and not AMBA
devices. Therefore, add a clock alias for the AMBA APB clock for OMAP4
devices to turn on the DEBUGSS power and clock domain.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/cclock44xx_data.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index aa56c3e..1ac3dc5 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1940,6 +1940,7 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK("4903c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4903e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
+	CLK(NULL,	"apb_pclk",		&trace_clk_div_ck,	CK_443X),
 };
 
 static const char *enable_init_clks[] = {
-- 
1.7.10.4