lkml.org 
[lkml]   [2011]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRE: [PATCH 2/2 v5] pinctrl: introduce generic pin config
    Linus Walleij wrote at Tuesday, December 06, 2011 3:54 PM:
    > On Mon, Dec 5, 2011 at 6:36 PM, Stephen Warren <swarren@nvidia.com> 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:
    > >
    > > set PIN_CONFIG_PULL_UP_RESISTANCE 100000
    > > set PIN_CONFIG_BIAS PULL_UP
    >
    > So two calls to set the pull up instead of one?
    > That does not look good.

    Worry about that seems a bit like a micro-optimization to me, but I
    somewhat see your point.

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

    Yes, that's true.

    > >> Don't you mean we would then have
    > >>
    > >> pin_config_param {
    > >>    PIN_CONFIG_INPUT_MODE,
    > >>    ...
    > >> }
    > >>
    > >> enum pin_config_input_mode_value {
    > >>     PIN_CONFIG_INPUT_MODE_SCHMITT,
    > >>     PIN_CONFIG_INPUT_MODE_DEBOUNCE,
    > >> };
    > >
    > > 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'd expect that each pin_config_param has exactly one single value
    associated with it. Hence, having Schmitt and debounce as the values
    rather than the parameters does make them mutually exclusive.

    --
    nvpublic

    --
    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: 2011-12-08 01:15    [W:0.029 / U:89.112 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site