[lkml]   [2012]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH 0/9] Get rid of FIQ_START/enable/disable_fiq() + some FIQ cleanups
    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(<IRQ>) 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)

    static struct fiq_handler foo_fiq = {
    .name = "foo",
    .enable_fiq = foo_enable_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?


    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

     \ /
      Last update: 2012-08-06 01:21    [W:0.025 / U:2.332 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site