From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753469AbbESIk1 (ORCPT ); Tue, 19 May 2015 04:40:27 -0400 Received: from mail-oi0-f50.google.com ([209.85.218.50]:36401 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751817AbbESIkW (ORCPT ); Tue, 19 May 2015 04:40:22 -0400 MIME-Version: 1.0 In-Reply-To: References: <1426676484-21812-1-git-send-email-marc.zyngier@arm.com> <1426676484-21812-3-git-send-email-marc.zyngier@arm.com> Date: Tue, 19 May 2015 10:40:21 +0200 Message-ID: Subject: Re: [PATCH v4 2/3] irqchip: GIC: Add support for irq_{get,set}_irqchip_state From: Linus Walleij To: Feng Kan , Marc Zyngier Cc: Abhijeet Dharmapurikar , Stephen Boyd , Phong Vo , Tin Huynh , Y Vo , Thomas Gleixner , Toan Le , Bjorn Andersson , Jason Cooper , Arnd Bergmann , linux-arm-msm , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-gpio@vger.kernel.org" , Alexandre Courbot Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 14, 2015 at 10:14 PM, Feng Kan wrote: > On Thu, May 14, 2015 at 3:32 AM, Linus Walleij wrote: >> But surely the GPIO block has its own status register, so are >> you saying that this register is unreliable? > > When the GPIO is used as interrupt, the gpio block does not report the > status anymore. Which leaves us stuck with SPISR. >> >> I can think of a few reasons, like transient IRQs etc but >> what is actually causing this? > > I won't say the obvious. Yeah I see your problem now :( I think it's better to fix the access functions so that you can cross-call to the GIC driver to get the SPISR flag out though. Let's see what Marc says. >> Which GPIO driver is this? Is it upstream? > > Yes, it is upstream. It is the xgene slimpro gpio driver. I am starting to > think that we ought to switch to use some gpio poll driver rather than > using gpio-key. There is both gpio_keys_polled and IRQ-driven gpio_keys so yeah that's possible. But honestly I think it's better to deal with this problem for real because IRQ is more efficient. So the way I perceive it this is the real problem: +static int gic_irq_get_irqchip_state(struct irq_data *d, + enum irqchip_irq_state which, bool *val) +{ + switch (which) { (...) + case IRQCHIP_STATE_ACTIVE: + *val = gic_peek_irq(d, GIC_DIST_ACTIVE_SET); + break; Here it reads the status from 0x300 where DIST_ACTIVE_SET is, so if you change GIC_DIST_ACTIVE_SET to 0xd04 (SPISR), does it start working? I would *guess* that maybe you want to implement and ask for IRQCHIP_STATE_LINE_LEVEL instead of IRQCHIP_STATE_ACTIVE, and have that case: read from 0xd04 (SPISR) instead, because that makes more sense to me, or am I wrong at it? + case IRQCHIP_STATE_LINE_LEVEL: + *val = gic_peek_irq(d, GIC_DIST_SPISR); + break; And then put a define into for GIC_DIST_SPISR. Yours, Linus Walleij