1. 12 Mar, 2012 6 commits
    • Linus Walleij's avatar
      ARM: u300: configure some pins as an example · 51dddfe8
      Linus Walleij authored
      To show how the pin configuration is used on the U300, let's
      include some configs for two GPIO pins.
      
      ChangeLog v1->v2:
      - Provide a better example, set the clock return pin to pull-up
        and set the card detect pin to high impedance.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      51dddfe8
    • Linus Walleij's avatar
      pinctrl: support pinconfig on the U300 · dc0b1aa3
      Linus Walleij authored
      This adds pin configuration support for the U300 driver pair,
      we can now read out the biasing and drive mode in debugfs and
      configure it using the new configuration API.
      
      ChangeLog v1->v2:
      - Migrate to pin config and generic pin config changes.
      ChangeLog v2->v3:
      - Adjust to generic pin config changes in v7 patch set.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      dc0b1aa3
    • Linus Walleij's avatar
      pinctrl/coh901: use generic pinconf enums and parameters · a050b3ee
      Linus Walleij authored
      Adjust the COH 901 driver to use the standard enums for
      biasing and driving pins, alter signature of config function
      to suit the framework.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      a050b3ee
    • Linus Walleij's avatar
      pinctrl: introduce generic pin config · 394349f7
      Linus Walleij authored
      This is a split-off from the earlier patch set which adds generic
      pin configuration for the pin controllers that want it. Since
      we may have a system with mixed generic and custom pin controllers,
      we pass a boolean in the pin controller ops vtable to indicate
      if it is generic.
      
      ChangeLog v1->v5:
      - Follow parent patch versioning number system.
      - Document the semantic meaning of return values from pin config
        get functions, so we can iterate over pins and check their
        properties from debugfs as part of the generic config code.
      - Use proper cast functions in the generic debugfs pin config
        file.
      - Expand generic config to optionally cover groups too.
      ChangeLog v5->v6:
      - Update to match underlying changes.
      ChangeLog v6->v7:
      - Drop DRIVE_OFF parameter, use bias high impedance for this
      - Delete argument for drive modes push-pull, od and os. These
        are now just state transitions.
      - Delete slew rate rising/falling due to discussions on on
        proper semantics
      - Drop config wakeup, struct irq_chip does this for now, add
        back if need be.
      - Set PIN_CONFIG_END to 0x7fff making room for custom config
        parameters from 0x8000 and up.
      - Prefix accessor functions with pinconf_
      394349f7
    • Linus Walleij's avatar
      pinctrl: fix error path in pinconf_map_to_setting() · 70b36378
      Linus Walleij authored
      The code was using the union member
      setting->data.configs.group_or_pin to store a potential
      error code, but since that member is unsigned the
      < 0 comparison was not true, letting errors pass through,
      ending up as mapped to pin "-22". Fix this up and print
      the error.
      Acked-by: default avatarStephen Warren <swarren@wwwdotorg.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      70b36378
    • Stephen Warren's avatar
      pinctrl: allow concurrent gpio and mux function ownership of pins · 652162d4
      Stephen Warren authored
      Per recent updates to Documentation/gpio.txt, gpiolib drivers should
      inform pinctrl when a GPIO is requested. pinctrl then marks that pin as
      in-use for that GPIO function.
      
      When an SoC muxes pins in a group, it's quite possible for the group to
      contain e.g. 6 pins, but only 4 of them actually be needed by the HW
      module that's mux'd to them. In this case, the other 2 pins could be
      used as GPIOs. However, pinctrl marks all the pins within the group as
      in-use by the selected mux function. To allow the expected gpiolib
      interaction, separate the concepts of pin ownership into two parts: One
      for the mux function and one for GPIO usage. Finally, allow those two
      ownerships to exist in parallel.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      652162d4
  2. 06 Mar, 2012 6 commits
  3. 05 Mar, 2012 6 commits
    • Stephen Warren's avatar
      pinctrl: Show selected function and group in pinmux-pins debugfs · ba110d90
      Stephen Warren authored
      Until recently, the pinctrl pinmux-pins debugfs file displayed the
      selected function for each owned pin. This feature was removed during
      restructing in support of recent API rework. This change restoreds this
      feature, and also displays the group that the function was selected on,
      in case a pin is a member of multiple groups.
      
      Based on work by: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      ba110d90
    • Stephen Warren's avatar
      pinctrl: enhance mapping table to support pin config operations · 1e2082b5
      Stephen Warren authored
      The pinctrl mapping table can now contain entries to:
      * Set the mux function of a pin group
      * Apply a set of pin config options to a pin or a group
      
      This allows pinctrl_select_state() to apply pin configs settings as well
      as mux settings.
      
      v3: Fix find_pinctrl() to iterate over the correct list.
         s/_MUX_CONFIGS_/_CONFIGS_/ in mapping table macros.
         Fix documentation to use correct mapping table macro.
      v2: Added numerous extra PIN_MAP_*() special-case macros.
         Fixed kerneldoc typo. Delete pinctrl_get_pin_id() and
         replace it with pin_get_from_name(). Various minor fixes.
         Updates due to rebase.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      1e2082b5
    • Stephen Warren's avatar
      pinctrl: API changes to support multiple states per device · 6e5e959d
      Stephen Warren authored
      The API model is changed from:
      
      p = pinctrl_get(dev, "state1");
      pinctrl_enable(p);
      ...
      pinctrl_disable(p);
      pinctrl_put(p);
      p = pinctrl_get(dev, "state2");
      pinctrl_enable(p);
      ...
      pinctrl_disable(p);
      pinctrl_put(p);
      
      to this:
      
      p = pinctrl_get(dev);
      s1 = pinctrl_lookup_state(p, "state1");
      s2 = pinctrl_lookup_state(p, "state2");
      pinctrl_select_state(p, s1);
      ...
      pinctrl_select_state(p, s2);
      ...
      pinctrl_put(p);
      
      This allows devices to directly transition between states without
      disabling the pin controller programming and put()/get()ing the
      configuration data each time. This model will also better suit pinconf
      programming, which doesn't have a concept of "disable".
      
      The special-case hogging feature of pin controllers is re-written to use
      the regular APIs instead of special-case code. Hence, the pinmux-hogs
      debugfs file is removed; see the top-level pinctrl-handles files for
      equivalent data.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      6e5e959d
    • Stephen Warren's avatar
      pinctrl: add usecount to pins for muxing · 0e3db173
      Stephen Warren authored
      Multiple mapping table entries could reference the same pin, and hence
      "own" it. This would be unusual now that pinctrl_get() represents a single
      state for a client device, but in the future when it represents all known
      states for a device, this is quite likely. Implement reference counting
      for pin ownership to handle this.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      0e3db173
    • Stephen Warren's avatar
      pinctrl: refactor struct pinctrl handling in core.c vs pinmux.c · 7ecdb16f
      Stephen Warren authored
      This change separates two aspects of struct pinctrl:
      
      a) The data representation of the parsed mapping table, into:
      
         1) The top-level struct pinctrl object, a single entity returned
            by pinctrl_get().
      
         2) The parsed version of each mapping table entry, struct
            pinctrl_setting, of which there is one per mapping table entry.
      
      b) The code that handles this; the code for (1) above is in core.c, and
         the code to parse/execute each entry in (2) above is in pinmux.c, while
         the iteration over multiple settings is lifted to core.c.
      
      This will allow the following future changes:
      
      1) pinctrl_get() API rework, so that struct pinctrl represents all states
         for the device, and the device can select between them without calling
         put()/get() again.
      
      2) To support that, a struct pinctrl_state object will be inserted into
         the data model between the struct pinctrl and struct pinctrl_setting.
      
      3) The mapping table will be extended to allow specification of pin config
         settings too. To support this, struct pinctrl_setting will be enhanced
         to store either mux settings or config settings, and functions will be
         added to pinconf.c to parse/execute pin configuration settings.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      7ecdb16f
    • Stephen Warren's avatar
      pinctrl: fix and simplify locking · 57b676f9
      Stephen Warren authored
      There are many problems with the current pinctrl locking:
      
      struct pinctrl_dev's gpio_ranges_lock isn't effective;
      pinctrl_match_gpio_range() only holds this lock while searching for a gpio
      range, but the found range is return and manipulated after releading the
      lock. This could allow pinctrl_remove_gpio_range() for that range while it
      is in use, and the caller may very well delete the range after removing it,
      causing pinctrl code to touch the now-free range object.
      
      Solving this requires the introduction of a higher-level lock, at least
      a lock per pin controller, which both gpio range registration and
      pinctrl_get()/put() will acquire.
      
      There is missing locking on HW programming; pin controllers may pack the
      configuration for different pins/groups/config options/... into one
      register, and hence have to read-modify-write the register. This needs to
      be protected, but currently isn't. Related, a future change will add a
      "complete" op to the pin controller drivers, the idea being that each
      state's programming will be programmed into the pinctrl driver followed
      by the "complete" call, which may e.g. flush a register cache to HW. For
      this to work, it must not be possible to interleave the pinctrl driver
      calls for different devices.
      
      As above, solving this requires the introduction of a higher-level lock,
      at least a lock per pin controller, which will be held for the duration
      of any pinctrl_enable()/disable() call.
      
      However, each pinctrl mapping table entry may affect a different pin
      controller if necessary. Hence, with a per-pin-controller lock, almost
      any pinctrl API may need to acquire multiple locks, one per controller.
      To avoid deadlock, these would need to be acquired in the same order in
      all cases. This is extremely difficult to implement in the case of
      pinctrl_get(), which doesn't know which pin controllers to lock until it
      has parsed the entire mapping table, since it contains somewhat arbitrary
      data.
      
      The simplest solution here is to introduce a single lock that covers all
      pin controllers at once. This will be acquired by all pinctrl APIs.
      
      This then makes struct pinctrl's mutex irrelevant, since that single lock
      will always be held whenever this mutex is currently held.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      57b676f9
  4. 02 Mar, 2012 4 commits
  5. 29 Feb, 2012 3 commits
  6. 24 Feb, 2012 4 commits
  7. 22 Feb, 2012 11 commits