[lkml]   [2011]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [PATCH] drivers: create a pinmux subsystem v2
    I'd like to step back and take a look at the data model.

    As I understand it, the data model is that the SoC's pinmux driver defines
    every possible set of pins that could be used for all groups of signals
    (SSP, I2C, ...) that's affected by the pinmux. Each combination of pins
    is a FUNCTION in the documentation in the patch. The set of FUNCTIONS must
    include all options for: muxing a given controller's signals out of
    different sets of pins, different bit-widths of ports, etc. The SoC pinmux
    driver must expose every single possible option so that boards can pick
    whichever one they want. This is particular important e.g. if devicetree
    comes into play, where people will expect to pick the correct FUNCTION in
    their devicetree file without having to add a definition of that FUNCTION
    to the kernel. Even with new boards, it'd be best if the SoC pinmux driver
    already contained the definitions that arbitrary boards might use.

    It's then up to the board to define which particular SoC-defined FUNCTION
    is used by each driver on the given board. For each driver, a single
    FUNCTION can be selected at a time (although there is the option to
    associate multiple FUNCTIONs to a single driver, those are alternatives
    rather than aggregateable options).

    Consider Tegra's keyboard controller: For rows, the controller can use
    KB_ROW[2:0], perhaps also KB_ROW[6:3], and perhaps also KB_ROW[15:7]. For
    columns, the controller can use KB_COL[1:0], perhaps also KB_COL[6:2],
    perhaps also KB_COL[7]. Thus, the pinmux driver must expose FUNCTIONs for
    all combinations of rows (3) cross-product all combinations of columns
    (3) so 3*3==9.

    That's all assuming that for each of those sets of pins, there's only one
    set of physical pads they can be routed out to. While Tegra's pinmux
    doesn't support this for the keyboard controller signals, let's assume
    for flexibility that KB_ROW[2:0] could be routed out pins X0/X1/X2 or
    Y0/Y1/Y2, and similarly for KB_COL[1:0] to two other sets of pins. That
    then means the SoC pinmux driver would have to define 9 * 2 * 2 == 36
    different FUNCTIONs.

    That's just catering for a pretty simple keyboard controller. I believe
    this quickly grows unmanageable.

    Instead, what if the SoC pinmux driver just defined groups of pins. For
    each group, there would be a list of the physical pins that was part of
    the group, and a list of functions (SD1, SD2, I2S1, I2S2, ...) that could
    be assigned to that group. For many SoCs, there would be a single pin per
    group. At least Tegra would have many groups containing more than one pin.

    Now, the SoC's pinmux driver's list of configurations would be just roughly
    number_of_groups * average_number_of_functions_supported_per_group. I think
    this would be much lower than the number of FUNCTIONs in the existing
    proposed model.

    Of course, this approach would mean the SoC pinmux driver would define a
    little less information about the SoC. We'd have to shift more data into
    the board/machine definition.

    Specifically, the current pinmux API defines that for each driver, there
    is a single FUNCTION active at a time. To make my proposed data model
    work, we'd have to expand that from a 1:1 to a 1:n mapping, such that for
    each driver, we define a set of possible configurations, and for each
    configuration, we define a set of (group, function) used, rather than just
    a single FUNCTION.

    This would shift all the burden of defining whether e.g. "the keyboard
    controller uses 1, 2, or 3 of the column groups of pins" into the board/
    machine driver, and eventually perhaps into devicetree. Arguably, that's
    where all the complexity should be.

    The core pinmux driver still would have enough information to know for
    each group whether any (and which) function was assigned, and so could
    still implement all the exclusion/sharing logic. Equally, the mapping
    from the data exported by the SoC pinmux driver (list of groups, and
    supported functions for each) would probably map much better to actual
    register writes; For Tegra, there'd probably be a 1:1 mapping for each
    group rather than a 1:N mapping for each FUNCTION. Other SoC pinmux
    drivers would probably be roughly unchanged, i.e. have a 1:1 mapping
    between group and pin configuration register.

    So, what are people's thoughts on this?

    Thanks for reading so far!

    (I'll have to go away and read up on some of the issues Colin Cross
    mentioned, namely that the auxiliary configuration such as drive strength,
    pullup, etc. was also configured in groups, but the pins associated with
    those groups are not aligned with the groupings used for the pinmux)


     \ /
      Last update: 2011-05-13 23:31    [W:0.036 / U:0.548 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site