1. 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: default avatarLinus Walleij <linus.walleij@linaro.org>
      950b0d91
  2. 23 Jun, 2016 1 commit
  3. 13 Jun, 2016 3 commits
  4. 06 May, 2015 2 commits
    • Linus Walleij's avatar
      pinctrl: move strict option to pinmux_ops · 8c4c2016
      Linus Walleij authored
      While the pinmux_ops are ideally just a vtable for pin mux
      calls, the "strict" setting belongs so intuitively with the
      pin multiplexing that we should move it here anyway. Putting
      it in the top pinctrl_desc makes no sense.
      
      Cc: Sonic Zhang <sonic.zhang@analog.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      8c4c2016
    • Sonic Zhang's avatar
      pinctrl: allow exlusive GPIO/mux pin allocation · fa76a3db
      Sonic Zhang authored
      Disallow simultaneous use of the the GPIO and peripheral mux
      functions by setting a flag "strict" in struct pinctrl_desc.
      
      The blackfin pinmux and gpio controller doesn't allow user to
      set up a pin for both GPIO and peripheral function. So, add flag
      strict in struct pinctrl_desc to check both gpio_owner and
      mux_owner before approving the pin request.
      
      v2-changes:
      - if strict flag is set, check gpio_owner and mux_onwer in if and
        else clause
      
      v3-changes:
      - add kerneldoc for this struct
      - augment Documentation/pinctrl.txt
      Signed-off-by: default avatarSonic Zhang <sonic.zhang@analog.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      fa76a3db
  5. 18 Mar, 2015 4 commits
  6. 09 Mar, 2015 1 commit
  7. 04 Sep, 2014 1 commit
  8. 15 Jan, 2014 1 commit
  9. 16 Oct, 2013 1 commit
  10. 23 Aug, 2013 1 commit
  11. 20 Aug, 2013 1 commit
  12. 14 Aug, 2013 1 commit
  13. 22 Jul, 2013 1 commit
  14. 25 Jun, 2013 1 commit
    • Linus Walleij's avatar
      pinctrl: rip out the direct pinconf API · ad42fc6c
      Linus Walleij authored
      From the inception ot the pin config API there has been the
      possibility to get a handle at a pin directly and configure
      its electrical characteristics. For this reason we had:
      
      int pin_config_get(const char *dev_name, const char *name,
                     unsigned long *config);
      int pin_config_set(const char *dev_name, const char *name,
                     unsigned long config);
      int pin_config_group_get(const char *dev_name,
                     const char *pin_group,
                     unsigned long *config);
      int pin_config_group_set(const char *dev_name,
                     const char *pin_group,
                     unsigned long config);
      
      After the introduction of the pin control states that will
      control pins associated with devices, and its subsequent
      introduction to the device core, as well as the
      introduction of pin control hogs that can set up states on
      boot and optionally also at sleep, this direct pin control
      API is a thing of the past.
      
      As could be expected, it has zero in-kernel users.
      Let's delete this API and make our world simpler.
      Reported-by: default avatarTony Lindgren <tony@atomide.com>
      Reviewed-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      ad42fc6c
  15. 17 Jun, 2013 1 commit
  16. 16 Jun, 2013 1 commit
  17. 28 May, 2013 1 commit
  18. 18 Mar, 2013 1 commit
    • Linus Walleij's avatar
      pinctrl: document the "GPIO mode" pitfall · fdba2d06
      Linus Walleij authored
      Recently as adoption of the pinctrl framework is reaching
      niches where the pins are reconfigured during system sleep
      and datasheets often talk about something called "GPIO mode",
      some engineers become confused by this, thinking that since
      it is named "GPIO (something something)" it must be modeled
      in the kernel using <linux/gpio.h>.
      
      To clarify things, let's put in this piece of documentation,
      or just start off the discussion here.
      
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Pankaj Dev <pankaj.dev@st.com>
      Reviewed-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      fdba2d06
  19. 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: default 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: default avatarLinus Walleij <linus.walleij@linaro.org>
      ab78029e
  20. 11 Nov, 2012 2 commits
    • Shiraz Hashim's avatar
      gpiolib: provide provision to register pin ranges · f23f1516
      Shiraz Hashim authored
      pinctrl subsystem needs gpio chip base to prepare set of gpio
      pin ranges, which a given pinctrl driver can handle. This is
      important to handle pinctrl gpio request calls in order to
      program a given pin properly for gpio operation.
      
      As gpio base is allocated dynamically during gpiochip
      registration, presently there exists no clean way to pass this
      information to the pinctrl subsystem.
      
      After few discussions from [1], it was concluded that may be
      gpio controller reporting the pin range it supports, is a
      better way than pinctrl subsystem directly registering it.
      
      [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816
      
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarShiraz Hashim <shiraz.hashim@st.com>
      [Edited documentation a bit]
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f23f1516
    • 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: default avatarLinus Walleij <linus.walleij@linaro.org>
      1a78958d
  21. 17 Sep, 2012 1 commit
  22. 17 Aug, 2012 1 commit
  23. 18 Apr, 2012 5 commits
  24. 05 Mar, 2012 2 commits
    • 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
  25. 02 Mar, 2012 2 commits
  26. 29 Feb, 2012 1 commit
  27. 24 Feb, 2012 1 commit