Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755238Ab2HEXFJ (ORCPT ); Sun, 5 Aug 2012 19:05:09 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:34869 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753065Ab2HEXFH (ORCPT ); Sun, 5 Aug 2012 19:05:07 -0400 Date: Sun, 5 Aug 2012 16:02:38 -0700 From: Anton Vorontsov To: Russell King Cc: John Stultz , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linaro-kernel@lists.linaro.org, patches@linaro.org, kernel-team@android.com, Ben Dooks , Kukjin Kim , Sascha Hauer , Tony Lindgren , Mark Brown , Liam Girdwood Subject: [PATCH 0/9] Get rid of FIQ_START/enable/disable_fiq() + some FIQ cleanups Message-ID: <20120805230238.GA1663@lizard> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3359 Lines: 88 Hello Russell, During KDB FIQ patches review you mentioned that I should not introduce another FIQ_START. It seems that in v3.6-rc the FIQ_START issue was somewhat band-aided, i.e. machines don't necessary need to define this stuff any longer, but I also read the background of the issue, and you once said that you don't want the FIQ subsystem to mess with genirq. It is surely makes sense as FIQs are arch-specific, plus FIQs are special in that way that platform makers are free to connects device directly to the FIQ line, avoiding IC routing, and then enable_fiq() would look awkward, at the best. So, given that, it seems that the only entity that knows for sure how the particular FIQ is routed is whoever claims the FIQ and fills-in the fiq_handler struct. It might make sense to introduce disable/enable callbacks in the fiq_handler struct, and then prototypes for disable/ enable FIQ calls would look like this: enable_fiq(struct fiq_handler *fh); disable_fiq(struct fiq_handler *fh); I.e. completely abstracted from the genirq. Although, to not duplicate IC code, I think it's pretty legitimate to call genirq functions iff the caller knows for sure that FIQ comes from IRQ line and it is is routed through the well-known platform IC. In that case (which is a majority), the typical user would do this: static int irq_line; void foo_enable_fiq(struct fiq_handler *fh) { enable_irq(irq_line); } static struct fiq_handler foo_fiq = { .name = "foo", .enable_fiq = foo_enable_fiq, }; claim_fiq(&foo_fiq); enable_fiq(&foo_fiq); Obviously, it's needless indirection, so I don't do this. If we ever pass 'foo_fiq' to some device, which does not know all the routing details, then it would make sense to introduce it, but not now. So, the patch set is pretty straightforward: - Get rid of FIQ_START. Nobody but platform-specific code (and drivers) should know the details about which interrupt can be routed to FIQ and which cannot; - Remove disable/enable_fiq() calls from the FIQ subsys (the calls can be reintroduced w/ new prototypes when/if needed). Does the approach make sense? Thanks! -- arch/arm/include/asm/fiq.h | 2 -- arch/arm/include/asm/mach/irq.h | 9 +++++++-- arch/arm/kernel/fiq.c | 22 +++------------------- arch/arm/kernel/irq.c | 2 -- arch/arm/mach-rpc/dma.c | 4 ++-- arch/arm/mach-rpc/include/mach/irqs.h | 8 ++++---- arch/arm/mach-rpc/irq.c | 21 +++++---------------- arch/arm/mach-s3c24xx/include/mach/irqs.h | 3 --- arch/arm/plat-mxc/avic.c | 4 +--- arch/arm/plat-mxc/include/mach/irqs.h | 2 -- arch/arm/plat-mxc/tzic.c | 4 +--- arch/arm/plat-omap/include/plat/irqs.h | 4 ---- arch/arm/plat-s3c24xx/irq.c | 6 ++---- drivers/media/video/mx1_camera.c | 6 +++--- sound/soc/fsl/imx-pcm-fiq.c | 4 ++-- 15 files changed, 30 insertions(+), 71 deletions(-) -- Anton Vorontsov Email: cbouatmailru@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/