[lkml]   [2005]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Fwd: [RFC] IRQ type flags

    > Good question - I'm not sure currently. In the places where set_irq_type
    > is used on ARM, we're mainly interested in setting the input according
    > to rising/falling edge or high/low levels rather than switching between
    > edge and level mode.
    > We could do as you suggest, but my concern would be adding extra
    > complexity to drivers, causing them to do something like:
    > ret = request_irq(..., SA_TRIGGER_HIGH, ...);
    > if (ret == -E<whatever>)
    > ret = request_irq(..., SA_TRIGGER_RISING, ...);
    > The alternative is:
    > ret = request_irq(..., SA_TRIGGER_HIGH | SA_TRIGGER_RISING, ...);
    > at which point the driver is telling the IRQ layer what it can support,
    > and allowing the IRQ layer to select the most appropriate type given
    > the driver and hardware constraints.

    We have similar things on ppc but dealt differently. The type of
    interrupt sense supported depends on the PIC (and you can have more than
    one PIC around). On Open Firmware based machines at least, the
    device-tree tells us the sense setting to use on all devices in the
    system, we program our PIC based on that information.

    Your proposal though is interesting as it would allow individual to
    override that setting (it may be broken, firmware occasionally are), and
    would probably be useful for embedded PPCs as well.

    However, I would suggest defining the absence of explicit trigger (0) as
    a constant rather than 0 (SA_TRIGGER_DEFAULT), just for consistency.That
    means using whatever the platform considers as a good default for this
    interrupt. In addition, I would still add a get_irq_trigger() function
    for a driver to enquire the kind of sense that was set by default by the
    platfrom for a given irq line.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-07 00:39    [W:0.020 / U:45.436 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site