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