1. 12 11月, 2012 2 次提交
    • V
      Revert "pinctrl: remove pinctrl_remove_gpio_range" · 7e10ee68
      Viresh Kumar 提交于
      This reverts earlier commit which removed
      pinctrl_remove_gpio_range(), because at that time there
      weren't any more users of that routine. It was removed as the
      removal of ranges was done in unregister of pinctrl.
      
      But as we are now registering stuff from gpiolib, we may
      remove and insert a gpio module multiple times. So, we
      need this routine again.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      7e10ee68
    • L
      pinctrl: reserve pins when states are activated · 1a78958d
      Linus Walleij 提交于
      This switches the way that pins are reserved for multiplexing:
      
      We used to do this when the map was parsed, at the creation of
      the settings inside the pinctrl handle, in pinmux_map_to_setting().
      
      However this does not work for us, because we want to use the
      same set of pins with different devices at different times: the
      current code assumes that the pin groups in a pinmux state will
      only be used with one single device, albeit different groups can
      be active at different times. For example if a single I2C driver
      block is used to drive two different busses located on two
      pin groups A and B, then the pins for all possible states of a
      function are reserved when fetching the pinctrl handle: the
      I2C bus can choose either set A or set B by a mux state at
      runtime, but all pins in both group A and B (the superset) are
      effectively reserved for that I2C function and mapped to the
      device. Another device can never get in and use the pins in
      group A, even if the device/function is using group B at the
      moment.
      
      Instead: let use reserve the pins when the state is activated
      and drop them when the state is disabled, i.e. when we move to
      another state. This way different devices/functions can use the
      same pins at different times.
      
      We know that this is an odd way of doing things, but we really
      need to switch e.g. an SD-card slot to become a tracing output
      sink at runtime: we plug in a special "tracing card" then mux
      the pins that used to be an SD slot around to the tracing
      unit and push out tracing data there instead of SD-card
      traffic.
      
      As a side effect pinmux_free_setting() is unused but the stubs
      are kept for future additions of code.
      
      Cc: Patrice Chotard <patrice.chotard@st.com>
      Cc: Loic Pallardy <loic.pallardy@st.com>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Tested-by: NJean Nicolas Graux <jean-nicolas.graux@stericsson.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      1a78958d
  2. 23 10月, 2012 1 次提交
  3. 27 9月, 2012 1 次提交
  4. 17 8月, 2012 1 次提交
  5. 04 7月, 2012 3 次提交
  6. 04 6月, 2012 1 次提交
  7. 02 5月, 2012 1 次提交
  8. 27 4月, 2012 2 次提交
    • D
      pinctrl: add pinctrl_provide_dummies interface for platforms to use · 5b3aa5f7
      Dong Aisheng 提交于
      Add a interface pinctrl_provide_dummies for platform to indicate
      whether it needs use pinctrl dummy state.
      
      ChangeLog v3->v4:
      * remove dummy gpio support in pinctrl subsystem.
        Let gpio driver decide whether it wants to use pinctrl gpio mux
        function.
      ChangeLog v2->v3:
      * Also changed the missed pinctrl gpio APIs in v1.
      ChangeLog v1->v2:
      * Based on sascha's suggestion, drop using kconfig since it will hide
        pinctrl errors on all other boards.
        See: https://lkml.org/lkml/2012/4/18/282
        It seemed both Linus and Stephen agreed with this way, so i'm ok
        with it too.
      * Add dummy gpio support.
        pinctrl gpio in the same situation as state.
      * Patch name changed.
        Original is pinctrl: handle dummy state in core.
      * Split removing old dt dummy interface into a separate patch
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Acked-by: NStephen Warren <swarren@wwwdotorg.org>
      Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      5b3aa5f7
    • J
      pinctrl: enhance reporting of errors when loading from DT · ad6e1107
      John Crispin 提交于
      There are a few places in the api where the code simply returns -EINVAL when
      it finds an error. An example is pinmux_map_to_setting() which now reports an
      error if we try to match a group with a function that it does not support.
      
      The reporting of errors in pinconf_check_ops and pinmux_check_ops now has the
      same style and is located inside the according functions and not the calling
      code.
      
      When the map is found in the DT but the default state can not be selected we
      get an error to know that the code at least tried.
      
      The patch also removes a stray word from one comment and a "->" from another
      for the sake of consistency.
      
      Finally we replace a few pr_err/debug() calls with dev_err/dbg().
      
      Thanks go to Stephen Warren for reviewing the patch and enhancing the reporting
      inside pinmux_map_to_setting().
      Signed-off-by: NJohn Crispin <blogic@openwrt.org>
      Acked-by: NStephen Warren <swarren@wwwdotorg.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      ad6e1107
  9. 26 4月, 2012 1 次提交
  10. 18 4月, 2012 6 次提交
  11. 11 4月, 2012 1 次提交
  12. 05 3月, 2012 4 次提交
    • 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: refactor struct pinctrl handling in core.c vs pinmux.c · 7ecdb16f
      Stephen Warren 提交于
      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: NStephen Warren <swarren@nvidia.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      7ecdb16f
    • 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
  13. 02 3月, 2012 2 次提交
  14. 01 3月, 2012 1 次提交
  15. 24 2月, 2012 4 次提交
  16. 23 2月, 2012 8 次提交
  17. 11 2月, 2012 1 次提交