1. 17 Jul, 2018 1 commit
  2. 22 Sep, 2017 1 commit
  3. 14 Aug, 2017 1 commit
  4. 13 Jan, 2017 1 commit
    • Tony Lindgren's avatar
      pinctrl: core: Fix regression caused by delayed work for hogs · 950b0d91
      Tony Lindgren authored
      Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
      regression at least with sh-pfc that is also a GPIO controller as
      noted by Geert Uytterhoeven <geert@linux-m68k.org>.
      
      As the original pinctrl_register() has issues calling pin controller
      driver functions early before the controller has finished registering,
      we can't just revert commit df61b366af26. That would break the drivers
      using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.
      
      So let's fix the issue with the following steps as a single patch:
      
      1. Revert the late_init parts of commit df61b366af26.
      
         The late_init clearly won't work and we have to just give up
         on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
         GENERIC_PINMUX_FUNCTIONS.
      
      2. Split pinctrl_register() into two parts
      
         By splitting pinctrl_register() into pinctrl_init_controller()
         and pinctrl_create_and_start() we have better control over when
         it's safe to call pinctrl_create().
      
      3. Introduce a new pinctrl_register_and_init() function
      
         As suggested by Linus Walleij <linus.walleij@linaro.org>, we
         can just introduce a new function for the controllers that need
         pinctrl_create() called later.
      
      4. Convert the four known problem cases to use new function
      
         Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
         to use the new function to fix the issues. The rest of the drivers
         can be converted later. Let's also update Documentation/pinctrl.txt
         accordingly because of the known issues with pinctrl_register().
      
      Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Gary Bisson <gary.bisson@boundarydevices.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      950b0d91
  5. 03 Jan, 2017 4 commits
  6. 31 May, 2016 1 commit
    • Masahiro Yamada's avatar
      pinctrl: copy per-pin driver private data to struct pin_desc · cd8f61f1
      Masahiro Yamada authored
      Currently, struct pinctrl_pin_desc can have per-pin driver private
      data, but it is not copied to struct pin_desc.
      
      For a driver with sparse pin space, for-loop search like below would
      be necessary in order to get the driver-specific data for a desired
      pin number.
      
        for (i = 0; i < pctldev->desc->npins; i++)
                if (pin_number == pctldev->desc->pins[i].number)
                        return pctldev->desc->pins[i].drv_data;
      
      This is not efficient for a driver with a large number of pins.
      So, copy the data to struct pin_desc when each pin is registered
      for the faster radix tree lookup.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      cd8f61f1
  7. 07 Mar, 2016 1 commit
  8. 06 May, 2015 1 commit
    • Doug Anderson's avatar
      pinctrl: Don't just pretend to protect pinctrl_maps, do it for real · c5272a28
      Doug Anderson authored
      Way back, when the world was a simpler place and there was no war, no
      evil, and no kernel bugs, there was just a single pinctrl lock.  That
      was how the world was when (57291ce2 pinctrl: core device tree mapping
      table parsing support) was written.  In that case, there were
      instances where the pinctrl mutex was already held when
      pinctrl_register_map() was called, hence a "locked" parameter was
      passed to the function to indicate that the mutex was already locked
      (so we shouldn't lock it again).
      
      A few years ago in (42fed7ba pinctrl: move subsystem mutex to
      pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex.
      ...but (oops) we forgot to re-think about the whole "locked" parameter
      for pinctrl_register_map().  Basically the "locked" parameter appears
      to still refer to whether the bigger pinctrl_dev mutex is locked, but
      we're using it to skip locks of our (now separate) pinctrl_maps_mutex.
      
      That's kind of a bad thing(TM).  Probably nobody noticed because most
      of the calls to pinctrl_register_map happen at boot time and we've got
      synchronous device probing.  ...and even cases where we're
      asynchronous don't end up actually hitting the race too often.  ...but
      after banging my head against the wall for a bug that reproduced 1 out
      of 1000 reboots and lots of looking through kgdb, I finally noticed
      this.
      
      Anyway, we can now safely remove the "locked" parameter and go back to
      a war-free, evil-free, and kernel-bug-free world.
      
      Fixes: 42fed7ba ("pinctrl: move subsystem mutex to pinctrl_dev struct")
      Signed-off-by: default avatarDoug Anderson <dianders@chromium.org>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      c5272a28
  9. 26 Apr, 2013 1 commit
    • Patrice Chotard's avatar
      pinctrl: move subsystem mutex to pinctrl_dev struct · 42fed7ba
      Patrice Chotard authored
      This mutex avoids deadlock in case of use of multiple pin
      controllers. Before this modification, by using a global
      mutex, deadlock appeared when, for example, a call to
      pinctrl_pins_show() locked the pinctrl_mutex, called the
      ops->pin_dbg_show of a particular pin controller. If this
      pin controller needs I2C access to retrieve configuration
      information and I2C driver is using pinctrl to drive its
      pins, a call to pinctrl_select_state() try to lock again
      pinctrl_mutex which leads to a deadlock.
      
      Notice that the mutex grab from the two direction functions
      was moved into pinctrl_gpio_direction().
      
      For several cases, we can't replace pinctrl_mutex by
      pctldev->mutex, because at this stage, pctldev is
      not accessible :
      	- pinctrl_get()/pinctrl_put()
      	- pinctrl_register_maps()
      
      So add respectively pinctrl_list_mutex and
      pinctrl_maps_mutex in order to protect
      pinctrl_list and pinctrl_maps list instead.
      
      Reintroduce pinctrldev_list_mutex in
      find_pinctrl_by_of_node(),
      pinctrl_find_and_add_gpio_range()
      pinctrl_request_gpio(), pinctrl_free_gpio(),
      pinctrl_gpio_direction(), pinctrl_devices_show(),
      pinctrl_register() and pinctrl_unregister() to
      protect pinctrldev_list.
      
      Changes v2->v3:
      - Fix a missing EXPORT_SYMBOL_GPL() for pinctrl_select_state().
      
      Changes v1->v2:
      - pinctrl_select_state_locked() is removed, all lock mechanism
        is located inside pinctrl_select_state(). When parsing
        the state->setting list, take the per-pin-controller driver
        lock. (Patrice).
      - Introduce pinctrldev_list_mutex to protect pinctrldev_list
        in all functions which parse or modify pictrldev_list.
        (Patrice).
      - move find_pinctrl_by_of_node() from pinctrl/devicetree.c to
        pinctrl/core.c in order to protect pinctrldev_list.
        (Patrice).
      - Sink mutex:es into some functions and remove some _locked
        variants down to where the lists are actually accessed to
        make things simpler. (Linus)
      - Drop *all* mutexes completely from pinctrl_lookup_state()
        and pinctrl_select_state() - no relevant mutex was taken
        and it was unclear what this was protecting against. (Linus)
      
      Reported by : Seraphin Bonnaffe <seraphin.bonnaffe@stericsson.com>
      Signed-off-by: default avatarPatrice Chotard <patrice.chotard@st.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      42fed7ba
  10. 27 Mar, 2013 1 commit
  11. 10 Feb, 2013 1 commit
    • Laurent Meunier's avatar
      pinctrl/pinconfig: add debug interface · 6f9e41f4
      Laurent Meunier authored
      This update adds a debugfs interface to modify a pin configuration
      for a given state in the pinctrl map. This allows to modify the
      configuration for a non-active state, typically sleep state.
      This configuration is not applied right away, but only when the state
      will be entered.
      
      This solution is mandated for us by HW validation: in order
      to test and verify several pin configurations during sleep without
      recompiling the software.
      Signed-off-by: default avatarLaurent Meunier <laurent.meunier@st.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      6f9e41f4
  12. 23 Jan, 2013 1 commit
    • Linus Walleij's avatar
      drivers/pinctrl: grab default handles from device core · ab78029e
      Linus Walleij authored
      This makes the device core auto-grab the pinctrl handle and set
      the "default" (PINCTRL_STATE_DEFAULT) state for every device
      that is present in the device model right before probe. This will
      account for the lion's share of embedded silicon devcies.
      
      A modification of the semantics for pinctrl_get() is also done:
      previously if the pinctrl handle for a certain device was already
      taken, the pinctrl core would return an error. Now, since the
      core may have already default-grabbed the handle and set its
      state to "default", if the handle was already taken, this will
      be disregarded and the located, previously instanitated handle
      will be returned to the caller.
      
      This way all code in drivers explicitly requesting their pinctrl
      handlers will still be functional, and drivers that want to
      explicitly retrieve and switch their handles can still do that.
      But if the desired functionality is just boilerplate of this
      type in the probe() function:
      
      struct pinctrl  *p;
      
      p = devm_pinctrl_get_select_default(&dev);
      if (IS_ERR(p)) {
         if (PTR_ERR(p) == -EPROBE_DEFER)
              return -EPROBE_DEFER;
              dev_warn(&dev, "no pinctrl handle\n");
      }
      
      The discussion began with the addition of such boilerplate
      to the omap4 keypad driver:
      http://marc.info/?l=linux-input&m=135091157719300&w=2
      
      A previous approach using notifiers was discussed:
      http://marc.info/?l=linux-kernel&m=135263661110528&w=2
      This failed because it could not handle deferred probes.
      
      This patch alone does not solve the entire dilemma faced:
      whether code should be distributed into the drivers or
      if it should be centralized to e.g. a PM domain. But it
      solves the immediate issue of the addition of boilerplate
      to a lot of drivers that just want to grab the default
      state. As mentioned, they can later explicitly retrieve
      the handle and set different states, and this could as
      well be done by e.g. PM domains as it is only related
      to a certain struct device * pointer.
      
      ChangeLog v4->v5 (Stephen):
      - Simplified the devicecore grab code.
      - Deleted a piece of documentation recommending that pins
        be mapped to a device rather than hogged.
      ChangeLog v3->v4 (Linus):
      - Drop overzealous NULL checks.
      - Move kref initialization to pinctrl_create().
      - Seeking Tested-by from Stephen Warren so we do not disturb
        the Tegra platform.
      - Seeking ACK on this from Greg (and others who like it) so I
        can merge it through the pinctrl subsystem.
      ChangeLog v2->v3 (Linus):
      - Abstain from using IS_ERR_OR_NULL() in the driver core,
        Russell recently sent a patch to remove it. Handle the
        NULL case explicitly even though it's a bogus case.
      - Make sure we handle probe deferral correctly in the device
        core file. devm_kfree() the container on error so we don't
        waste memory for devices without pinctrl handles.
      - Introduce reference counting into the pinctrl core using
        <linux/kref.h> so that we don't release pinctrl handles
        that have been obtained for two or more places.
      ChangeLog v1->v2 (Linus):
      - Only store a pointer in the device struct, and only allocate
        this if it's really used by the device.
      
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Mitch Bradley <wmb@firmworks.com>
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      Cc: Rickard Andersson <rickard.andersson@stericsson.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      [swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
      correctly handle deferred probe. Removed admonition from docs not to use
      pinctrl hogs for devices]
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      ab78029e
  13. 11 Jan, 2013 1 commit
  14. 11 Nov, 2012 1 commit
    • Linus Walleij's avatar
      pinctrl: reserve pins when states are activated · 1a78958d
      Linus Walleij authored
      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: default avatarStephen Warren <swarren@nvidia.com>
      Tested-by: default avatarJean Nicolas Graux <jean-nicolas.graux@stericsson.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      1a78958d
  15. 18 Apr, 2012 2 commits
  16. 12 Mar, 2012 1 commit
    • 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: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      652162d4
  17. 06 Mar, 2012 1 commit
  18. 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: Linus Walleij's 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: Linus Walleij's 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: Linus Walleij's 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: Linus Walleij's 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: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarDong Aisheng <dong.aisheng@linaro.org>
      Signed-off-by: Linus Walleij's 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: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      57b676f9
  19. 02 Mar, 2012 3 commits
  20. 24 Feb, 2012 1 commit
  21. 22 Feb, 2012 2 commits
  22. 10 Feb, 2012 2 commits
  23. 01 Feb, 2012 1 commit
  24. 24 Jan, 2012 1 commit
  25. 03 Jan, 2012 3 commits
    • Linus Walleij's avatar
      pinctrl: conjure names for unnamed pins · ca53c5f1
      Linus Walleij authored
      If pins with blank names are registered, we assign them names on-the-fly
      on the form "PINn" where n is the pin number for that pin on the specific
      controller.
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      ca53c5f1
    • Stephen Warren's avatar
      pinctrl: don't create a device for each pin controller · 51cd24ee
      Stephen Warren authored
      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: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      51cd24ee
    • Linus Walleij's avatar
      pinctrl: add a pin config interface · ae6b4d85
      Linus Walleij authored
      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: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      ae6b4d85