Re: [PATCH] spmi-pmic-arb: add irq tracepoints to the pmic-arb driver

[Gilad Avidov <gavidov@codeaurora.org>]

On Thu, 28 May 2015 18:15:59 -0700
Stephen Boyd <sboyd@codeaurora.org> wrote:

> On 05/28/2015 04:02 PM, Gilad Avidov wrote:
> > On Wed, 27 May 2015 13:06:29 -0700
> > Stephen Boyd <sboyd@codeaurora.org> 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.
> 
> Hm.. maybe we should add those trace events then into the irq domain 
> layer? Or even extend the irq tracepoints to include the hw-irq and 
> irq-domain name?
> 
I agree, adding hw-irq and irq-domain name to irq-tracing is a better
idea.

> >
> > 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.
> >
> 
> Sorry I'm not following this point. If it was about tracing 
> slave-originated events wouldn't it be more than irqs then?
> 
Slave originated events are converted to irqs by the spmi controller.

Thanks,
Gilad