23 Jun, 2016

1 commit


13 Jun, 2016

3 commits


06 May, 2015

2 commits

  • 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
    Signed-off-by: Linus Walleij

    Linus Walleij
     
  • 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: Sonic Zhang
    Signed-off-by: Linus Walleij

    Sonic Zhang
     

18 Mar, 2015

4 commits


10 Mar, 2015

1 commit


04 Sep, 2014

1 commit

  • commit 2243a87d90b42eb38bc281957df3e57c712b5e56
    "pinctrl: avoid duplicated calling enable_pinmux_setting for a pin"
    removed the .disable callback from the struct pinmux_ops,
    making the .enable() callback the only remaining callback.

    However .enable() is a bad name as it seems to imply that a
    muxing can also be disabled. Rename the callback to .set_mux()
    and also take this opportunity to clean out any remaining
    mentions of .disable() from the documentation.

    Acked-by: Stephen Warren
    Acked-by: Bjorn Andersson
    Acked-by: Fan Wu
    Signed-off-by: Linus Walleij

    Linus Walleij
     

15 Jan, 2014

1 commit


16 Oct, 2013

1 commit


23 Aug, 2013

1 commit


15 Aug, 2013

1 commit


23 Jul, 2013

1 commit

  • This elaborates a bit on the pin control and pin muxing
    logic vs GPIO arangements in the hardware.

    Inspired by some drawings in a mail from Christian Ruppert.
    Both arrangements are confirmed to exist in practice.

    Cc: Rob Landley
    Reviewed-by: Christian Ruppert
    Reviewed-by: Stephen Warren
    Signed-off-by: Linus Walleij

    Linus Walleij
     

05 Jul, 2013

1 commit

  • Pull trivial tree updates from Jiri Kosina:
    "The usual stuff from trivial tree"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (34 commits)
    treewide: relase -> release
    Documentation/cgroups/memory.txt: fix stat file documentation
    sysctl/net.txt: delete reference to obsolete 2.4.x kernel
    spinlock_api_smp.h: fix preprocessor comments
    treewide: Fix typo in printk
    doc: device tree: clarify stuff in usage-model.txt.
    open firmware: "/aliasas" -> "/aliases"
    md: bcache: Fixed a typo with the word 'arithmetic'
    irq/generic-chip: fix a few kernel-doc entries
    frv: Convert use of typedef ctl_table to struct ctl_table
    sgi: xpc: Convert use of typedef ctl_table to struct ctl_table
    doc: clk: Fix incorrect wording
    Documentation/arm/IXP4xx fix a typo
    Documentation/networking/ieee802154 fix a typo
    Documentation/DocBook/media/v4l fix a typo
    Documentation/video4linux/si476x.txt fix a typo
    Documentation/virtual/kvm/api.txt fix a typo
    Documentation/early-userspace/README fix a typo
    Documentation/video4linux/soc-camera.txt fix a typo
    lguest: fix CONFIG_PAE -> CONFIG_x86_PAE in comment
    ...

    Linus Torvalds
     

25 Jun, 2013

1 commit

  • 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: Tony Lindgren
    Reviewed-by: Stephen Warren
    Acked-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Linus Walleij
     

18 Jun, 2013

1 commit


16 Jun, 2013

1 commit


28 May, 2013

1 commit


18 Mar, 2013

1 commit

  • 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 .

    To clarify things, let's put in this piece of documentation,
    or just start off the discussion here.

    Cc: Laurent Pinchart
    Cc: Pankaj Dev
    Reviewed-by: Stephen Warren
    Signed-off-by: Linus Walleij

    Linus Walleij
     

23 Jan, 2013

1 commit

  • 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
    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
    Cc: Benoit Cousson
    Cc: Dmitry Torokhov
    Cc: Thomas Petazzoni
    Cc: Mitch Bradley
    Cc: Ulf Hansson
    Cc: Rafael J. Wysocki
    Cc: Jean-Christophe PLAGNIOL-VILLARD
    Cc: Rickard Andersson
    Cc: Russell King
    Reviewed-by: Mark Brown
    Acked-by: Greg Kroah-Hartman
    Signed-off-by: Linus Walleij
    [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: Stephen Warren
    Signed-off-by: Linus Walleij

    Linus Walleij
     

12 Nov, 2012

2 commits

  • 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
    Signed-off-by: Viresh Kumar
    Signed-off-by: Shiraz Hashim
    [Edited documentation a bit]
    Signed-off-by: Linus Walleij

    Shiraz Hashim
     
  • 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
    Cc: Loic Pallardy
    Acked-by: Stephen Warren
    Tested-by: Jean Nicolas Graux
    Signed-off-by: Linus Walleij

    Linus Walleij
     

17 Sep, 2012

1 commit

  • The semantics of the interactions between GPIO and pinctrl may be
    unclear, e.g. which one do you request first? This amends the
    documentation to make this clear.

    Reported-by: Domenico Andreoli
    Acked-by: Domenico Andreoli
    Acked-by: Stephen Warren
    Signed-off-by: Linus Walleij

    Linus Walleij
     

17 Aug, 2012

1 commit


18 Apr, 2012

5 commits

  • These functions allow the driver core to automatically clean up any
    allocations made by drivers, thus leading to simplified drivers.

    Signed-off-by: Stephen Warren
    Signed-off-by: Linus Walleij

    Stephen Warren
     
  • If drivers try to obtain pinctrl handles for a pin controller that
    has not yet registered to the subsystem, we need to be able to
    back out and retry with deferred probing. So let's return
    -EPROBE_DEFER whenever this location fails. Also downgrade the
    errors to info, maybe we will even set them to debug once the
    deferred probing is commonplace.

    Cc: Arnd Bergmann
    Reviewed-by: Mark Brown
    Acked-by: Stephen Warren
    Signed-off-by: Linus Walleij

    Linus Walleij
     
  • Most of the SoC drivers implement list_groups() and list_functions()
    routines for pinctrl and pinmux. These routines continue returning
    zero until the selector argument is greater than total count of
    available groups or functions.

    This patch replaces these list_*() routines with get_*_count()
    routines, which returns the number of available selection for SoC
    driver. pinctrl layer will use this value to check the range it can
    choose.

    This patch fixes all user drivers for this change. There are other
    routines in user drivers, which have checks to check validity of
    selector passed to them. It is also no more required and hence
    removed.

    Documentation updated as well.

    Acked-by: Stephen Warren
    Signed-off-by: Viresh Kumar
    [Folded in fix and fixed a minor merge artifact manually]
    Signed-off-by: Linus Walleij

    Viresh Kumar
     
  • As long as there is no other non-const variable marked __initdata in the
    same compilation unit it doesn't hurt. If there were one however
    compilation would fail with

    error: $variablename causes a section type conflict

    because a section containing const variables is marked read only and so
    cannot contain non-const variables.

    Signed-off-by: Uwe Kleine-König
    Cc: Randy Dunlap
    Signed-off-by: Linus Walleij

    Uwe Kleine-König
     
  • Missed one group from the documentation when proofreading.

    Signed-off-by: Viresh Kumar
    Signed-off-by: Linus Walleij

    Viresh Kumar
     

05 Mar, 2012

2 commits

  • 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: Stephen Warren
    Acked-by: Dong Aisheng
    Signed-off-by: Linus Walleij

    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: Stephen Warren
    Acked-by: Dong Aisheng
    Signed-off-by: Linus Walleij

    Stephen Warren
     

02 Mar, 2012

2 commits

  • pinctrl_register_mappings() already requires that every mapping table
    entry have a non-NULL name field.

    Logically, this makes sense too; drivers should always request a specific
    named state so they know what they're getting. Relying on getting the
    first mentioned state in the mapping table is error-prone, and a nasty
    special case to implement, given that a given the mapping table may define
    multiple states for a device.

    Remove a small part of the documentation that talked about optionally
    requesting a specific state; it's mandatory now.

    Signed-off-by: Stephen Warren
    Acked-by: Dong Aisheng
    Signed-off-by: Linus Walleij

    Stephen Warren
     
  • This provides a single centralized name for the default state.

    Update PIN_MAP_* macros to use this state name, instead of requiring the
    user to pass a state name in.

    With this change, hog entries in the mapping table are defined as those
    with state name PINCTRL_STATE_DEFAULT, i.e. all entries have the same
    name. This interacts badly with the nested iteration over mapping table
    entries in pinctrl_hog_maps() and pinctrl_hog_map() which would now
    attempt to claim each hog mapping table entry multiple times. Replacing
    the custom hog code with a simple pinctrl_get()/pinctrl_enable().

    Update documentation and mapping tables to use this.

    Signed-off-by: Stephen Warren
    Acked-by: Dong Aisheng
    Signed-off-by: Linus Walleij

    Stephen Warren
     

01 Mar, 2012

1 commit

  • The lookup key in struct pinctrl_map is (.dev_name, .name). Re-order the
    struct definition to put the lookup key fields first, and the result
    values afterwards. To me at least, this slightly better reflects the
    lookup process.

    Update the documentation in a similar fashion.

    Note: PIN_MAP*() macros aren't updated; I plan to update this once later
    when enhancing the mapping table format to support pin config to reduce
    churn.

    Signed-off-by: Stephen Warren
    Acked-by: Dong Aisheng
    [Rebased for cherry-picking]
    Signed-off-by: Linus Walleij

    Stephen Warren
     

24 Feb, 2012

1 commit

  • Hog entries are mapping table entries with .ctrl_dev_name == .dev_name.
    All other mapping table entries need .dev_name set so that they will
    match some pinctrl_get() call. All extant PIN_MAP*() macros set
    .dev_name.

    So, there is no reason to allow mapping table entries without .dev_name
    set. Update the code and documentation to disallow this.

    Signed-off-by: Stephen Warren
    Acked-by: Dong Aisheng
    Signed-off-by: Linus Walleij

    Stephen Warren
     

11 Feb, 2012

1 commit

  • Instead of a specific boolean field to indicate if a map entry shall
    be hogged, treat self-reference as an indication of desired hogging.
    This drops one field off the map struct and has a nice Douglas R.
    Hofstadter-feel to it.

    Acked-by: Dong Aisheng
    Acked-by: Stephen Warren
    Signed-off-by: Linus Walleij

    Linus Walleij