[lkml]   [2011]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [PATCH 0/2] pin controller subsystem v7
    Linus Walleij wrote at Friday, September 16, 2011 6:13 AM:
    > From: Linus Walleij <>
    > This is the sixth iteration of the controller subsystem...

    Overall, the changelog sounds like a great move in the right direction.
    There's just one small thing I'd comment on here:

    > ChangeLog v6->v7:
    > - Make it possible to have several map entries matching the
    > same device, pin controller and function, but using
    > a different group, and alter the semantics so that
    > pinmux_get() will pick all matching map entries, and
    > store the associated groups in a list. The list will
    > then be iterated over at pinmux_enable()/pinmux_disable()
    > and corresponding driver functions called for each
    > defined group. Notice that you're only allowed to map
    > multiple *groups* to the same
    > { device, pin controller, function } triplet, attempts
    > to map the same device to multiple pin controllers will
    > for example fail. This is hopefully the crucial feature
    > requested by Stephen Warren.

    I've been viewing the map table as:

    input: (device, device's function)
    output: list of (controller, controller's group, controller's function)

    ... hence I was surprised to see that you explicitly note that mapping a
    single device to multiple controllers was disallowed.

    That said, I suppose this restriction won't cause any issues for any
    use-case I'm aware of; the only possibilities might be:

    a) Multiple pinmux controllers within the SoC, but perhaps the driver
    should just aggregate multiple HW modules into a single Linux device

    b) Where the pinmux map wants to affect the pinmux on both ends of some
    bus, where the two ends are different chips each having obviously separate
    pinmux controllers.

    Then again, if this need ever does arise, we should be able to just relax
    this restriction without causing any backwards-compatibility issues, so
    I don't see a specific need to change this now; I just thought I'd mention
    it so you're aware of what I'm thinking.

    I'll go review the code now.


     \ /
      Last update: 2011-09-20 22:13    [W:0.022 / U:52.776 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site