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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
