[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150529135604.541eee30@gavidov-lnx.qualcomm.com>
Date: Fri, 29 May 2015 13:56:04 -0600
From: Gilad Avidov <gavidov@...eaurora.org>
To: Stephen Boyd <sboyd@...eaurora.org>
Cc: Ankit Gupta <ankgupta@...eaurora.org>, sdharia@...eaurora.org,
ivan.ivanov@...aro.org, svarbanov@...sol.com, rostedt@...dmis.org,
linux-arm-msm@...r.kernel.org, gregkh@...uxfoundation.org,
collinsd@...eaurora.org, osvaldob@...eaurora.org,
linux-kernel@...r.kernel.org, mlocke@...eaurora.org,
galak@...eaurora.org, agross@...eaurora.org
Subject: Re: [PATCH] spmi-pmic-arb: add irq tracepoints to the pmic-arb
driver
On Thu, 28 May 2015 18:15:59 -0700
Stephen Boyd <sboyd@...eaurora.org> wrote:
> On 05/28/2015 04:02 PM, Gilad Avidov wrote:
> > On Wed, 27 May 2015 13:06:29 -0700
> > Stephen Boyd <sboyd@...eaurora.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists