From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752900AbbJZEfs (ORCPT ); Mon, 26 Oct 2015 00:35:48 -0400 Received: from mail-ob0-f180.google.com ([209.85.214.180]:35656 "EHLO mail-ob0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751000AbbJZEfr (ORCPT ); Mon, 26 Oct 2015 00:35:47 -0400 MIME-Version: 1.0 In-Reply-To: <20151026011036.2cb5b7a8@free-electrons.com> References: <1445347435-2333-1-git-send-email-thomas.petazzoni@free-electrons.com> <1445347435-2333-4-git-send-email-thomas.petazzoni@free-electrons.com> <20151026011036.2cb5b7a8@free-electrons.com> Date: Mon, 26 Oct 2015 05:35:46 +0100 Message-ID: Subject: Re: [PATCH 3/5] irqchip: armada-370-xp: re-enable per-CPU interrupts at resume time From: Marcin Wojtas To: Thomas Petazzoni Cc: Thomas Gleixner , Jason Cooper , Marc Zyngier , Lior Amsalem , Andrew Lunn , Tawfik Bayouk , linux-kernel@vger.kernel.org, Nadav Haklai , Gregory Clement , "linux-arm-kernel@lists.infradead.org" , Sebastian Hesselbarth Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas, 2015-10-26 1:10 GMT+01:00 Thomas Petazzoni : > Marcin, > > On Sun, 25 Oct 2015 22:22:37 +0100, Marcin Wojtas wrote: > >> > @@ -550,16 +572,27 @@ static void armada_370_xp_mpic_resume(void) >> > if (virq == 0) >> > continue; >> > >> > - if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ) >> > + data = irq_get_irq_data(virq); >> > + >> > + if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ) { >> > + /* Non per-CPU interrupts */ >> > writel(irq, per_cpu_int_base + >> >> For "Non per-CPU interrupts" per_cpu_int_base is used - is it >> intentional? In armada_370_xp_irq_mask/unmask the condition looks >> exactly opposite... > > Yes, this is normal. Carefully read PATCH 5/5, which adds a big > comment, which explains the logic of the HW and how the > irq-armada-370-xp driver copes with it. > > Each interrupt can be masked at two levels. One level is enabled when > the interrupted is mapped, the other upon ->mask()/->unmask(). So > when we're resuming, we need to re-enable the interrupt at the level it > was enabled in ->map(), and have ->mask()/->unmask() continue to > mask/unmask the interrupt at the other level. > > For per-CPU interrupts, ->map() and ->resume() enable the interrupt at > the global level, and leave ->mask()/->unmask() enable/disable at the > per-CPU level. > > For global interrupts, ->map() and ->resume() enable the interrupt at > the per-CPU level, and leave ->mask()/->unmask() enable/disable at the > global level. > > Again, see PATCH 5/5, and let me know if there are still some unclear > aspects. > Thanks for the explanation - now it's clear. Btw, I checked the patches with mvneta in both 'standby' and 'mem' modes on A38x (with not-yet-submitted support for PM in mvneta and pinctrl) and everything works properly. Hence: Tested-by: Marcin Wojtas Best regards, Marcin From mboxrd@z Thu Jan 1 00:00:00 1970 From: mw@semihalf.com (Marcin Wojtas) Date: Mon, 26 Oct 2015 05:35:46 +0100 Subject: [PATCH 3/5] irqchip: armada-370-xp: re-enable per-CPU interrupts at resume time In-Reply-To: <20151026011036.2cb5b7a8@free-electrons.com> References: <1445347435-2333-1-git-send-email-thomas.petazzoni@free-electrons.com> <1445347435-2333-4-git-send-email-thomas.petazzoni@free-electrons.com> <20151026011036.2cb5b7a8@free-electrons.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Thomas, 2015-10-26 1:10 GMT+01:00 Thomas Petazzoni : > Marcin, > > On Sun, 25 Oct 2015 22:22:37 +0100, Marcin Wojtas wrote: > >> > @@ -550,16 +572,27 @@ static void armada_370_xp_mpic_resume(void) >> > if (virq == 0) >> > continue; >> > >> > - if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ) >> > + data = irq_get_irq_data(virq); >> > + >> > + if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ) { >> > + /* Non per-CPU interrupts */ >> > writel(irq, per_cpu_int_base + >> >> For "Non per-CPU interrupts" per_cpu_int_base is used - is it >> intentional? In armada_370_xp_irq_mask/unmask the condition looks >> exactly opposite... > > Yes, this is normal. Carefully read PATCH 5/5, which adds a big > comment, which explains the logic of the HW and how the > irq-armada-370-xp driver copes with it. > > Each interrupt can be masked at two levels. One level is enabled when > the interrupted is mapped, the other upon ->mask()/->unmask(). So > when we're resuming, we need to re-enable the interrupt at the level it > was enabled in ->map(), and have ->mask()/->unmask() continue to > mask/unmask the interrupt at the other level. > > For per-CPU interrupts, ->map() and ->resume() enable the interrupt at > the global level, and leave ->mask()/->unmask() enable/disable at the > per-CPU level. > > For global interrupts, ->map() and ->resume() enable the interrupt at > the per-CPU level, and leave ->mask()/->unmask() enable/disable at the > global level. > > Again, see PATCH 5/5, and let me know if there are still some unclear > aspects. > Thanks for the explanation - now it's clear. Btw, I checked the patches with mvneta in both 'standby' and 'mem' modes on A38x (with not-yet-submitted support for PM in mvneta and pinctrl) and everything works properly. Hence: Tested-by: Marcin Wojtas Best regards, Marcin