1. 04 7月, 2012 1 次提交
  2. 11 5月, 2012 1 次提交
  3. 10 5月, 2012 1 次提交
  4. 27 4月, 2012 2 次提交
  5. 25 4月, 2012 1 次提交
  6. 18 4月, 2012 6 次提交
  7. 11 4月, 2012 2 次提交
  8. 13 3月, 2012 1 次提交
    • L
      pinctrl: introduce generic pin config · 394349f7
      Linus Walleij 提交于
      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
  9. 07 3月, 2012 2 次提交
  10. 05 3月, 2012 3 次提交
    • S
      pinctrl: enhance mapping table to support pin config operations · 1e2082b5
      Stephen Warren 提交于
      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: NStephen Warren <swarren@nvidia.com>
      Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      1e2082b5
    • S
      pinctrl: API changes to support multiple states per device · 6e5e959d
      Stephen Warren 提交于
      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: NStephen Warren <swarren@nvidia.com>
      Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      6e5e959d
    • S
      pinctrl: fix and simplify locking · 57b676f9
      Stephen Warren 提交于
      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: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      57b676f9
  11. 02 3月, 2012 1 次提交
  12. 01 3月, 2012 1 次提交
  13. 24 2月, 2012 1 次提交
  14. 11 2月, 2012 4 次提交
  15. 02 2月, 2012 1 次提交
  16. 03 1月, 2012 11 次提交
    • C
      pinctrl: remove unnecessary max pin number · 0d2006bb
      Chanho Park 提交于
      This patch removes maxpin member in the pin control descriptor
      because we don't need this value as we enumerate a pin space
      using offset.
      Signed-off-by: NChanho Park <chanho61.park@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      0d2006bb
    • S
      pinctrl: pass name instead of device to pin_config_* · 43699dea
      Stephen Warren 提交于
      Obtaining a "struct pinctrl_dev *" is difficult for code not directly
      related to the pinctrl subsystem. However, the device name of the pinctrl
      device is fairly well known. So, modify pin_config_*() to take the device
      name instead of the "struct pinctrl_dev *".
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      [rebased on top of refactoring code]
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      43699dea
    • S
      pinctrl: add "struct seq_file;" to pinconf.h · 63fd5984
      Stephen Warren 提交于
      This allows one to include pinconf.h without having to include other
      headers first.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      63fd5984
    • L
      pinctrl: add a group-specific hog macro · 23750196
      Linus Walleij 提交于
      To create elegant tables for pinmux hogs on the PXA MMP platform,
      we need this hog macro that can specify both function and group in
      one go.
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      23750196
    • S
      pinctrl: don't create a device for each pin controller · 51cd24ee
      Stephen Warren 提交于
      Pin controllers should already be instantiated as a device, so there's
      no need for the pinctrl core to create a new struct device for each
      controller.
      
      This allows the controller's real name to be used in the mux mapping
      table, rather than e.g. "pinctrl.0", "pinctrl.1", etc.
      
      This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since
      their sole purpose was to hard-code the .ctrl_dev_name field to be
      "pinctrl.0".
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      51cd24ee
    • S
      pinctrl: implement PINMUX_MAP_SYS_HOG · 1ddb6ff0
      Stephen Warren 提交于
      This is the same as PINMUX_MAP_PRIMARY_SYS_HOG, except that it allows
      you to specify a particular control device.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      1ddb6ff0
    • L
      pinctrl: add a pin config interface · ae6b4d85
      Linus Walleij 提交于
      This add per-pin and per-group pin config interfaces for biasing,
      driving and other such electronic properties. The details of passed
      configurations are passed in an opaque unsigned long which may be
      dereferences to integer types, structs or lists on either side
      of the configuration interface.
      
      ChangeLog v1->v2:
      - Clear split of terminology: we now have pin controllers, and
        those may support two interfaces using vtables: pin
        multiplexing and pin configuration.
      - Break out pin configuration to its own C file, controllers may
        implement only config without mux, and vice versa, so keep each
        sub-functionality of pin controllers separate. Introduce
        CONFIG_PINCONF in Kconfig.
      - Implement some core logic around pin configuration in the
        pinconf.c file.
      - Remove UNKNOWN config states, these were just surplus baggage.
      - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
        everyone.
      - PIN_CONFIG_POWER_SOURCE added to handle switching the power
        supply for the pin logic between different sources
      - Explicit DISABLE config enums to turn schmitt-trigger,
        wakeup etc OFF.
      - Update documentation to reflect all the recent reasoning.
      ChangeLog v2->v3:
      - Twist API around to pass around arrays of config tuples instead
        of (param, value) pairs everywhere.
      - Explicit drive strength semantics for push/pull and similar
        drive modes, this shall be the number of drive stages vs
        nominal load impedance, which should match the actual
        electronics used in push/pull CMOS or TTY totempoles.
      - Drop load capacitance configuration - I probably don't know
        what I'm doing here so leave it out.
      - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
        PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
      - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
        argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
      - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
        PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
      - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
        on input lines.
      - Fix a bug when we tried to configure pins for pin controllers
        without pinconf support.
      - Initialized debugfs properly so it works.
      - Initialize the mutex properly and lock around config tampering
        sections.
      - Check the return value from get_initial_config() properly.
      ChangeLog v3->v4:
      - Export the pin_config_get(), pin_config_set() and
        pin_config_group() functions.
      - Drop the entire concept of just getting initial config and
        keeping track of pin states internally, instead ask the pins
        what state they are in. Previous idea was plain wrong, if the
        device cannot keep track of its state, the driver should do
        it.
      - Drop the generic configuration layout, it seems this impose
        too much restriction on some pin controllers, so let them do
        things the way they want and split off support for generic
        config as an optional add-on.
      ChangeLog v4->v5:
      - Introduce two symmetric driver calls for group configuration,
        .pin_config_group_[get|set] and corresponding external calls.
      - Remove generic semantic meanings of return values from config
        calls, these belong in the generic config patch. Just pass the
        return value through instead.
      - Add a debugfs entry "pinconf-groups" to read status from group
        configuration only, also slam in a per-group debug callback in
        the pinconf_ops so custom drivers can display something
        meaningful for their pins.
      - Fix some dangling newline.
      - Drop dangling #else clause.
      - Update documentation to match the above.
      ChangeLog v5->v6:
      - Change to using a pin name as parameter for the
        [get|set]_config() functions, as suggested by Stephen Warren.
        This is more natural as names will be what a developer has
        access to in written documentation etc.
      ChangeLog v6->v7:
      - Refactor out by-pin and by-name get/set functions, only expose
        the by-name functions externally, expose the by-pin functions
        internally.
      - Show supported pin control functionality in the debugfs
        pinctrl-devices file.
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      ae6b4d85
    • L
      pinctrl: make a copy of pinmux map · 97607d15
      Linus Walleij 提交于
      This makes a deep copy of the pinmux function map instead of
      keeping the copy supplied from the platform around. This makes
      it possible to tag the platforms map with __initdata as is also
      done as part of this patch.
      
      Rationale: a certain target platform (PXA) has numerous
      pinmux maps, many of which will be lying around unused after
      boot in a multi-platform binary. Instead, deep-copy the one
      we're going to use and tag them all __initdata so they go away
      after boot.
      
      ChangeLog v1->v2:
      - Fixup the deep copy, missed a few items on the struct,
        plus mark bool member non-const since we're making runtime
        copies if this stuff now.
      ChangeLog v2->v3:
      - Make a shallow copy (just copy the array of map structs)
        as Arnd noticed, string constants never get discarded by the
        kernel anyway, so these pointers may be safely copied over.
      Reviewed-by: NArnd Bergmann <arnd.bergmann@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      97607d15
    • L
      pinctrl: GPIO direction support for muxing · 542e704f
      Linus Walleij 提交于
      When requesting a single GPIO pin to be muxed in, some controllers
      will need to poke a different value into the control register
      depending on whether the pin will be used for GPIO output or GPIO
      input. So create pinmux counterparts to gpio_direction_[input|output]
      in the pinctrl framework.
      
      ChangeLog v1->v2:
      - This also amends the documentation to make it clear the this
        function and associated machinery is *ONLY* intended as a backend
        to gpiolib machinery, not for everyone and his dog to start playing
        around with pins.
      ChangeLog v2->v3:
      - Don't pass an argument to the common request function, instead
        provide pinmux_* counterparts to the gpio_direction_[input|output]
        calls, simpler and anyone can understand it.
      ChangeLog v3->v4:
      - Fix numerous spelling mistakes and dangling text in documentation.
        Add Ack and Rewewed-by.
      
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Reviewed-by: NThomas Abraham <thomas.abraham@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      542e704f
    • C
      pinctrl: add a pin_base for sparse gpio-ranges · 3c739ad0
      Chanho Park 提交于
      This patch enables mapping a base offset of gpio ranges with
      a pin offset even if does'nt matched. A base of pinctrl_gpio_range
      means a base offset of gpio. However, we cannot convert gpio to pin
      number for sparse gpio ranges just only using a gpio base offset.
      We can convert a gpio to real pin number(even if not matched) using
      a new pin_base which means a base pin offset of requested gpio range.
      Now, the pin control subsystem passes the pin base offset to the
      pinmux driver.
      
      For example, let's assume below two gpio ranges in the system.
      
      static struct pinctrl_gpio_range gpio_range_a = {
          .name = "chip a",
          .id = 0,
          .base = 32,
          .pin_base = 32,
          .npins = 16,
          .gc = &chip_a;
      };
      
      static struct pinctrl_gpio_range gpio_range_b = {
          .name = "chip b",
          .id = 0,
          .base = 48,
          .pin_base = 64,
          .npins = 8,
          .gc = &chip_b;
      };
      
      We can calucalate a exact pin ranges even if doesn't matched with gpio ranges.
      
      chip a:
          gpio-range : [32 .. 47]
          pin-range  : [32 .. 47]
      chip b:
          gpio-range : [48 .. 55]
          pin-range  : [64 .. 71]
      Signed-off-by: NChanho Park <chanho61.park@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      3c739ad0
    • S
      pinctrl: add explicit gpio_disable_free pinmux_op · 3712a3c4
      Stephen Warren 提交于
      Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a
      completely different manner than they select which function to mux out of
      that pin. In order to support a single "free" pinmux_op, the driver would
      need to maintain a per-pin state of requested-for-gpio vs. requested-for-
      function. However, that's a lot of work when the core already has explicit
      separate paths for gpio request/free and function request/free.
      
      So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free()
      call it when appropriate.
      
      When doing this, I noticed that when calling pin_request():
      
          !!gpio == (gpio_range != NULL)
      
      ... and so I collapsed those two parameters in both pin_request(), and
      when adding writing the new code in pin_free().
      
      Also, for pin_free():
      
          !!free_func == (gpio_range != NULL)
      
      However, I didn't want pin_free() to know about the GPIO function naming
      special case, so instead, I reworked pin_free() to always return the pin's
      previously requested function, and now pinmux_free_gpio() calls
      kfree(function). This is much more balanced with the allocation having
      been performed in pinmux_request_gpio().
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      3712a3c4
  17. 09 11月, 2011 1 次提交