lkml.org 
[lkml]   [2006]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
    Date
    On Monday 13 November 2006 12:15 pm, Paul Mundt wrote:
    > On Mon, Nov 13, 2006 at 01:29:24PM -0600, Bill Gatliff wrote:
    >
    > Pin muxing is somewhat of a decoupled issue,

    I'll continue to read that as "100% orthogonal to any GPIO API since it's
    so thoroughly platform-specific". :)


    > but it's quite related when
    > "GPIO" is just another pin state depending on the mux. The primary
    > concern here is where we end up doing the refcounting for the pins, so we
    > don't run in to a situation where a pin is toggled out from an existing
    > user with regards to drivers contending for pin functions.

    A fine example of two platform-specific notions. First, that GPIO signals
    are muxed in that way ... they could easily have dedicated pins!! Second,
    that there's even a one-to-one association between pins and GPIOs ... I'll
    repeat the previous example of OMAP1, where certain GPIOs could come out on
    any of several pins. And where some pins can be muxed to work with more
    than one GPIO (but only one at a time, of course). Clearly, neither pin
    refcounting nor GPIO claiming can be sufficient to prevent such problems ...


    Another issue that's orthogonal to a GPIO API is IRQ trigger modes:

    > > Think: today, most drivers don't know or care if an IRQ line is
    > > edge-triggered or level-triggered. That code is in the domain of the
    > > IRQ subsystem. What David is proposing is the same sort of thing for
    > > GPIO.
    > >
    > I would suggest that it's exactly the opposite, other than the blatantly
    > obvious cases (edge-triggered NMI, controllers with fixed detection
    > logic, etc.) it's _specifically_ up to the drivers to indicate where to
    > do the detection, as to allow the IRQ controller to adjust the sense
    > selection for that particular IRQ. Grepping drivers/ for IRQF_TRIGGER is
    > a pretty good indicator of this.

    It's easy to think that way, but then it's just as easy to assemble boards
    that happen to route IRQs through an inverting buffer because of signal
    level or strength issues. And with discrete controllers, I've certainly
    had to cope with drivers running on systems that don't support the ideal
    triggering mode ... typically there'd be an edge trigger mode (e.g. only
    "both edges" supported) for a chip whose IRQ is active low.

    It's better to make the board setup include the right IRQ triggering mode
    for each IRQ, so that drivers don't have to embed board-specific knowledge
    like that. It's bad enough to have to write the driver to cope with some
    unnatural trigger mode ... but it's really rude to make them have to try
    guess several times before they can find which one works!!

    Boards can pass the IORESOURCE_IRQ_* flags in irq resources, though it
    seems not many do.

    - Dave

    -
    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/

    \
     
     \ /
      Last update: 2006-11-20 23:21    [W:2.060 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site