[lkml]   [2011]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/2 v5] pinctrl: introduce generic pin config
    On Mon, Dec 5, 2011 at 6:36 PM, Stephen Warren <> wrote:
    > Linus Walleij wrote at Monday, December 05, 2011 9:01 AM:
    >> But if I can control the resistance of the pull-up resistor
    >> that brings us to a triplet: {parameter, type, argument}
    >> like this to set the generic pull-up to 100 kOhm:
    >> set_generic_bias(PIN_CONFIG_BIAS, PIN_CONFIG_BIAS_PULL_UP, 100000);
    >> parameter = BIAS
    >> type = PULL_UP
    >> argument = 100 kOhm
    > I think that selecting what the value of pull-up is and enabling/disabling
    > pull-up are separate things, so you'd have:

    So two calls to set the pull up instead of one?
    That does not look good.

    > Of course, this probably ties into which of the following options your chip
    > HW has:
    > a) Pull-up 100K or pull-up 10K or pull-down or tri-state
    > b) Pull-up or pull-down or tri-state, with a second register field to
    > set pull-up at 100k or 10k.

    But what registers to write and in which order doesn't matter
    for this interface. That is up to the driver and that is the kind
    of stuff drivers are supposed to figure out.

    If the driver gets a single call which says "pull up" and
    a parameter "100k" it can very well figure out what to do
    with that.

    > ... which then goes back to the discussion of whether attempting to
    > shoe-horn every SoC into a standardized parameter set makes sense.

    Which is why the generic parameter set is now optional in
    the first place, right?

    >> Don't you mean we would then have
    >> pin_config_param {
    >>    ...
    >> }
    >> enum pin_config_input_mode_value {
    >> };
    > Schmitt and debounce seem like completely orthogonal HW features to me,
    > so I wouldn't make them mutually exclusive.

    True. But the above enumerators does not make them
    mutually exclusive do they? You can very well set both
    with two calls.

    >> I think it might be sub-dividing it too much, but it certainly
    >> doesn't hurt the implementation much to split it in three,
    >> say 8 bits parameter 8 bits type 16 bits argument if that is
    >> preferable what do others say?
    > That doesn't seem quite right to me. I guess I can't really describe why
    > though; it just feels wrong to be going that way.

    I feel the same way, so let's think about this.

    I think we need some more air into this discussion, what
    does other people think?

    Linus Walleij
    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: 2011-12-06 23:57    [W:0.035 / U:150.116 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site