From mboxrd@z Thu Jan 1 00:00:00 1970 From: ezequiel.garcia@free-electrons.com (Ezequiel Garcia) Date: Thu, 23 Oct 2014 08:51:27 -0300 Subject: [PATCH 5/7] ARM: mvebu: Enable Performance Monitor Unit on Armada 375 SoC In-Reply-To: <20141023111411.0d4c4a11@free-electrons.com> References: <1413985427-20918-1-git-send-email-ezequiel.garcia@free-electrons.com> <1413985427-20918-6-git-send-email-ezequiel.garcia@free-electrons.com> <20141022140421.GL22642@leverpostej> <54482CCA.9010002@free-electrons.com> <20141023111411.0d4c4a11@free-electrons.com> Message-ID: <5448EBBF.2060000@free-electrons.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 10/23/2014 06:14 AM, Thomas Petazzoni wrote: > Dear Ezequiel Garcia, > > On Wed, 22 Oct 2014 19:16:42 -0300, Ezequiel Garcia wrote: > >> The is a per CPU interrupt. >> >> Actually, the interrupt contains more than just PMU events, it contains >> a summary of several CPU events: Perf counters for each CPU, Power >> management interrupts for each CPU, L2 cache interrupt, among others. > > This is kind of a side discussion but if this interrupts does > much more than PMU events, then we should implement a separate irqchip > driver for this, to "demultiplex" the events notified by this interrupt. > Oh, I didn't realize this was possible. > Yes, today we are only using the PMU events from , but what if > tomorrow we need to be notified of other events in other drivers? We > would be screwed, because we would have to change the DT > representation: the PMU would no longer take <&mpic 3> as the > interrupt, but <&some_other_irq_controller XYZ> as the interrupt. > Yes, that sounds like a much better approach. I'll take a look and try to prepare something. -- Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com