On Wed, 27 May 2015 13:06:29 -0700 Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: > On 05/27, Ankit Gupta wrote: > > > > > > How is this any better than irq tracepoints that we already have > > > for generic irqs? > > > > > It is better than generic irq tracepoints because it provides bus > > specific information (sid and address(pid) of slave write), driver > > specific information (apid (pmic-peripheral) and func_num) and > > statistics (apid range). > > Recall that *slave* read/write cannot be traced by the spmi > > framework ftrace. > > > > Don't we already get all this information based on how we map > interrupts to devices in DT? It feels to me that the same > argument here could be applied to all the random gpio expanders > and chained interrupt controllers that we support in the kernel. > We don't. We could get the same information if we had the irq-domain and hw-irq 32bit value. While these values are available from /proc/interrupt, they are not available from the irq event tracing. This patch traces spmi slave-originated events. If we had one such slave we could cross information from both sources to filter the trace events. However, we have hundreds of transaction-capable spmi slaves. Thanks, Gilad -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
