summaryrefslogtreecommitdiff
path: root/include/linux/pinctrl
AgeCommit message (Collapse)AuthorFilesLines
2019-01-28pinctrl: remove unused 'pinconf-config' debugfs interfaceVladimir Zapolskiy1-4/+0
The main goal of the change is to remove .pin_config_dbg_parse_modify callback before a driver with its support appears. So far the in-kernel interface did not attract any users since its introduction 5 years ago. Originally .pin_config_dbg_parse_modify callback and the associated 'pinconf-config' debugfs file were introduced in commit f07512e615dd ("pinctrl/pinconfig: add debug interface"), a short description of 'pinconf-config' usage for debugging can be expressed this way: Write to 'pinconf-config' (see pinconf_dbg_config_write() function): % echo -n modify $map_type $device_name $state_name $pin_name $config > \ /sys/kernel/debug/pinctrl/$pinctrl/pinconf-config It supposes to update a global (therefore single!) 'pinconf_dbg_conf' variable with an alternative setting, the arguments should match an existing pinconf device and some registered pinctrl mapping 'map': * $map_type is either 'config_pin' or 'config_group', it should match 'map->type' value of PIN_MAP_TYPE_CONFIGS_PIN or PIN_MAP_TYPE_CONFIGS_GROUP accordingly, * $device_name should match 'map->dev_name' string value, * $state_name should match 'map->name' string value, * $pin_name should match 'map->data.configs.group_or_pin' string value, If all above has matched, then $config is a new value to be set by calling pinconfops->pin_config_dbg_parse_modify(pctldev, config, matched_config). After a successful write into 'pinconf-config' a user can read the file to get information about that single modified pin configuration. The fact is .pin_config_dbg_parse_modify callback has never been defined in 'struct pinconf_ops' of any pinconf driver, thus an actual modification of a pin or group state on any present pinconf controller does not happen, and it declares that all related code is no more than dead code. I discovered the issue while attempting to add .pin_config_dbg_parse_modify support in some drivers and found that too short 'MAX_NAME_LEN' set by drivers/pinctrl/pinconf.c:372:#define MAX_NAME_LEN 15 is practically insufficient to store a regular pinctrl device name, which are like 'e6060000.pin-controller-sh-pfc' or pin names like 'MX6QDL_PAD_ENET_REF_CLK', thus it is another indicator that the code is barely usable, insufficiently tested and unprepossessing. Of course it might be possible to increase MAX_NAME_LEN, and then add .pin_config_dbg_parse_modify callbacks to the drivers, but the whole idea of such a limited debug option looks inviable. A more flexible way to functionally substitute the original approach is to implicitly or explicitly use pinctrl_select_state() function whenever needed. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Cc: Laurent Meunier <laurent.meunier@st.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-01-28pinctrl: remove pinctrl/machine.h inclusion from pinctrl/pinconf.hVladimir Zapolskiy1-2/+0
The change adds explicit inclusion of linux/pinctrl/machine.h header to the only needed pinctrl-madera-core.c file, and therefore inclusion of pinctrl/machine.h header from pinctrl/pinconf.h can be removed. The change is preparatory to a follow-up reversal of commit f07512e615dd ("pinctrl/pinconfig: add debug interface"). Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-07-09pinctrl: Document pin_config_group_get() return codes like pin_config_get()Douglas Anderson1-1/+2
The pinconf_generic_dump_one() function makes the assumption that pin_config_group_get() should return -EINVAL and -ENOTSUPP just like pin_config_get() does. Document that so it's more obvious. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-02-03pinctrl: remove include file from <linux/device.h>Linus Torvalds1-0/+1
When pulling the recent pinctrl merge, I was surprised by how a pinctrl-only pull request ended up rebuilding basically the whole kernel. The reason for that ended up being that <linux/device.h> included <linux/pinctrl/devinfo.h>, so any change to that file ended up causing pretty much every driver out there to be rebuilt. The reason for that was because 'struct device' has this in it: #ifdef CONFIG_PINCTRL struct dev_pin_info *pins; #endif but we already avoid header includes for these kinds of things in that header file, preferring to just use a forward-declaration of the structure instead. Exactly to avoid this kind of header dependency. Since some drivers seem to expect that <linux/pinctrl/devinfo.h> header to come in automatically, move the include to <linux/pinctrl/pinctrl.h> instead. It might be better to just make the includes more targeted, but I'm not going to review every driver. It would definitely be good to have a tool for finding and minimizing header dependencies automatically - or at least help with them. Right now we almost certainly end up having way too many of these things, and it's hard to test every single configuration. FWIW, you can get a sense of the "hotness" of a header file with something like this after doing a full build: find . -name '.*.o.cmd' -print0 | xargs -0 tail --lines=+2 | grep -v 'wildcard ' | tr ' \\' '\n' | sort | uniq -c | sort -n | less -S which isn't exact (there are other things in those '*.o.cmd' than just the dependencies, and the "--lines=+2" only removes the header), but might a useful approximation. With this patch, <linux/pinctrl/devinfo.h> drops to "only" having 833 users in the current x86-64 allmodconfig. In contrast, <linux/device.h> has 14857 build files including it directly or indirectly. Of course, the headers that absolutely _everybody_ includes (things like <linux/types.h> etc) get a score of 23000+. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-03Merge tag 'pinctrl-v4.16-1' of ↵Linus Torvalds1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control updates from Linus Walleij: "This is the bulk of pin control changes for the v4.16 kernel cycle. Like with GPIO it is actually a bit calm this time. Core changes: - After lengthy discussions and partly due to my ignorance, we have merged a patch making pinctrl_force_default() and pinctrl_force_sleep() reprogram the states into the hardware of any hogged pins, even if they are already in the desired state. This only apply to hogged pins since groups of pins owned by drivers need to be managed by each driver, lest they could not do things like runtime PM and put pins to sleeping state even if the system as a whole is not in sleep. New drivers: - New driver for the Microsemi Ocelot SoC. This is used in ethernet switches. - The X-Powers AXP209 GPIO driver was extended to also deal with pin control and moved over from the GPIO subsystem. This circuit is a mixed-mode integrated circuit which is part of AllWinner designs. - New subdriver for the Qualcomm MSM8998 SoC, core of a high end mobile devices (phones) chipset. - New subdriver for the ST Microelectronics STM32MP157 MPU and STM32F769 MCU from the STM32 family. - New subdriver for the MediaTek MT7622 SoC. This is used for routers, repeater, gateways and such network infrastructure. - New subdriver for the NXP (former Freescale) i.MX 6ULL. This SoC has multimedia features and target "smart devices", I guess in-car entertainment, in-flight entertainment, industrial control panels etc. General improvements: - Incremental improvements on the SH-PFC subdrivers for things like the CAN bus. - Enable the glitch filter on Baytrail GPIOs used for interrupts. - Proper handling of pins to GPIO ranges on the Semtec SX150X - An IRQ setup ordering fix on MCP23S08. - A good set of janitorial coding style fixes" * tag 'pinctrl-v4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (102 commits) pinctrl: mcp23s08: fix irq setup order pinctrl: Forward declare struct device pinctrl: sunxi: Use of_clk_get_parent_count() instead of open coding pinctrl: stm32: add STM32F769 MCU support pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping pinctrl: sx150x: Register pinctrl before adding the gpiochip pinctrl: sx150x: Unregister the pinctrl on release pinctrl: ingenic: Remove redundant dev_err call in ingenic_pinctrl_probe() pinctrl: sprd: Use seq_putc() in sprd_pinconf_group_dbg_show() pinctrl: pinmux: Use seq_putc() in pinmux_pins_show() pinctrl: abx500: Use seq_putc() in abx500_gpio_dbg_show() pinctrl: mediatek: mt7622: align error handling of mtk_hw_get_value call pinctrl: mediatek: mt7622: fix potential uninitialized value being returned pinctrl: uniphier: refactor drive strength get/set functions pinctrl: imx7ulp: constify struct imx_cfg_params_decode pinctrl: imx: constify struct imx_pinctrl_soc_info pinctrl: imx7d: simplify imx7d_pinctrl_probe pinctrl: imx: use struct imx_pinctrl_soc_info as a const pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly. pinctrl: qcom: Add msm8998 pinctrl driver ...
2018-01-22pinctrl: Forward declare struct deviceLadislav Michl1-0/+2
pinctrl/devinfo.h is using forward declaration from pinctrl/consumer.h for configurations with CONFIG_PINCTRL defined, however nothing declares it in the opposite case. Fix this by adding a forward declaration. Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-12-03gpio: gpiolib: Generalise state persistence beyond sleepAndrew Jeffery1-0/+2
General support for state persistence is added to gpiolib with the introduction of a new pinconf parameter to propagate the request to hardware. The existing persistence support for sleep is adapted to include hardware support if the GPIO driver provides it. Persistence continues to be enabled by default; in-kernel consumers can opt out, but userspace (currently) does not have a choice. The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are renamed, dropping the SLEEP prefix to reflect that the concept is no longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE could initially be misinterpreted, so I've further changed the symbols to *_TRANSITORY and *_PERSISTENT to address this. The sysfs interface is modified only to keep consistency with the chardev interface in enforcing persistence for userspace exports. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-16Merge tag 'pinctrl-v4.15-1' of ↵Linus Torvalds2-4/+9
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control updates from Linus Walleij: "This is the bulk of pin control changes for the v4.15 kernel cycle: Core: - The pin control Kconfig entry PINCTRL is now turned into a menuconfig option. This obviously has the implication of making the subsystem menu visible in menuconfig. This is happening because of two things: (a) Intel have started to deploy and depend on pin controllers in a way that is affecting users directly. This happens on the highly integrated laptop chipsets named after geographical places: baytrail, broxton, cannonlake, cedarfork, cherryview, denverton, geminilake, lewisburg, merrifield, sunrisepoint... It started a while back and now it is ever more evident that this is crucial infrastructure for x86 laptops and not an embedded obscurity anymore. Users need to be aware. (b) Pin control expanders on I2C and SPI that are arch-agnostic. Currently Semtech SX150X and Microchip MCP28x08 but more are expected. Users will have to be able to configure these in directly for their set-up. - Just go and select GPIOLIB now that we made sure that GPIOLIB is a very vanilla subsystem. Do not depend on it, if we need it, select it. - Exposing the pin control subsystem in menuconfig uncovered a bunch of obscure bugs that are now hopefully fixed, all more or less pertaining to Blackfin. - Unified namespace for cross-calls between pin control and GPIO. - New support for clock skew/delay generic DT bindings and generic pin config options for this. - Minor documentation improvements. Various: - The Renesas SH-PFC pin controller has evolved a lot. It seems Renesas are churning out new SoCs by the minute. - A bunch of non-critical fixes for the Rockchip driver. - Improve the use of library functions instead of open coding. - Support the MCP28018 variant in the MCP28x08 driver. - Static constifying" * tag 'pinctrl-v4.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (91 commits) pinctrl: gemini: Fix missing pad descriptions pinctrl: Add some depends on HAS_IOMEM pinctrl: samsung/s3c24xx: add CONFIG_OF dependency pinctrl: gemini: Fix GMAC groups pinctrl: qcom: spmi-gpio: Add pmi8994 gpio support pinctrl: ti-iodelay: remove redundant unused variable dev pinctrl: max77620: Use common error handling code in max77620_pinconf_set() pinctrl: gemini: Implement clock skew/delay config pinctrl: gemini: Use generic DT parser pinctrl: Add skew-delay pin config and bindings pinctrl: armada-37xx: Add edge both type gpio irq support pinctrl: uniphier: remove eMMC hardware reset pin-mux pinctrl: rockchip: Add iomux-route switching support for rk3288 pinctrl: intel: Add Intel Cedar Fork PCH pin controller support pinctrl: intel: Make offset to interrupt status register configurable pinctrl: sunxi: Enforce the strict mode by default pinctrl: sunxi: Disable strict mode for old pinctrl drivers pinctrl: sunxi: Introduce the strict flag pinctrl: sh-pfc: Save/restore registers for PSCI system suspend pinctrl: sh-pfc: r8a7796: Use generic IOCTRL register description ...
2017-11-08pinctrl: Add skew-delay pin config and bindingsLinus Walleij1-0/+5
Some pin controllers (such as the Gemini) can control the expected clock skew and output delay on certain pins with a sub-nanosecond granularity. This is typically done by shunting in a number of double inverters in front of or behind the pin. Make it possible to configure this with a generic binding. Cc: devicetree@vger.kernel.org Acked-by: Rob Herring <robh@kernel.org> Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-22pinctrl/gpio: Unify namespace for cross-callsLinus Walleij1-4/+4
The pinctrl_request_gpio() and pinctrl_free_gpio() break the nice namespacing in the other cross-calls like pinctrl_gpio_foo(). Just rename them and all references so we have one namespace with all cross-calls under pinctrl_gpio_*(). Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-08-31pinctrl: Add sleep related state to indicate sleep related configsBaolin Wang1-0/+2
In some scenarios, we should set some pins as input/output/pullup/pulldown when the specified system goes into deep sleep mode, then when the system goes into deep sleep mode, these pins will be set automatically by hardware. That means some pins are not controlled by any specific driver in the OS, but need to be controlled when entering sleep mode. Thus we introduce one sleep state config into pinconf-generic for users to configure. Signed-off-by: Baolin Wang <baolin.wang@spreadtrum.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-08-14pinctrl: move const qualifier before structMasahiro Yamada1-2/+2
Update subsystem wide for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-08-07pinctrl: generic: update references to Documentation/pinctrl.txtLudovic Desroches1-2/+2
Update deprecated references to Documentation/pinctrl.txt since it has been moved to Documentation/driver-api/pinctl.rst. Signed-off-by: Ludovic Desroches <ludovic.desroches@o2linux.fr> Fixes: 5a9b73832e9e ("pinctrl.txt: move it to the driver-api book") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-06-29pinctrl: generic: Add output-enable propertyJacopo Mondi1-4/+11
Add output-enable generic pin configuration property. This properties allows enabling/disabling pin's output capabilities without actually driving any value on the line. Acked-by: Rob Herring <robh@kernel.org> [Added inline elaborations on buffer enabling/disabling] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-05-22Revert "pinctrl: generic: Add bi-directional and output-enable"Linus Walleij1-3/+0
This reverts commit 8c58f1a7a4b6d1d723bf25fef9d842d5a11200d0. It turns out that applying these generic properties was premature: the properties used in the driver using this are of unclear electrical nature and the subject need to be discussed. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-05-03Merge tag 'pinctrl-v4.12-1' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control updates from Linus Walleij: "This is the bulk of pin control changes for the v4.12 cycle. The extra week before the merge window actually resulted in some of the type of fixes that usually arrive after the merge window already starting to trickle in from eager developers using -next, I'm impressed. I have recruited a Samsung subsubsystem maintainer (Krzysztof) to deal with the onset of Samsung patches. It works great. Apart from that it is a boring round, just incremental updates and fixes all over the place, no serious core changes or anything exciting like that. The most pleasing to see is Julia Cartwrights work to audit the irqchip-providing drivers for realtime locking compliance. It's one of those "I should really get around to looking into that" things that have been on my TODO list since forever. Summary: Core changes: - add bi-directional and output-enable pin configurations to the generic bindings and generic pin controlling core. New drivers or subdrivers: - Armada 37xx SoC pin controller and GPIO support. - Axis ARTPEC-6 SoC pin controller support. - AllWinner A64 R_PIO controller support, and opening up the AllWinner sunxi driver for ARM64 use. - Rockchip RK3328 support. - Renesas R-Car H3 ES2.0 support. - STM32F469 support in the STM32 driver. - Aspeed G4 and G5 pin controller support. Improvements: - a whole slew of realtime improvements to drivers implementing irqchips: BCM, AMD, SiRF, sunxi, rockchip. - switch meson driver to get the GPIO ranges from the device tree. - input schmitt trigger support on the Rockchip driver. - enable the sunxi (AllWinner) driver to also be used on ARM64 silicon. - name the Qualcomm QDF2xxx GPIO lines. - support GMMR GPIO regions on the Intel Cherryview. This fixes a serialization problem on these platforms. - pad retention support for the Samsung Exynos 5433. - handle suspend-to-ram in the AT91-pio4 driver. - pin configuration support in the Aspeed driver. Cleanups: - the final name of Rockchip RK1108 was RV1108 so rename the driver and variables to stay consistent" * tag 'pinctrl-v4.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (80 commits) pinctrl: mediatek: Add missing pinctrl bindings for mt7623 pinctrl: artpec6: Fix return value check in artpec6_pmx_probe() pinctrl: artpec6: Remove .owner field for driver pinctrl: tegra: xusb: Silence sparse warnings ARM: at91/at91-pinctrl documentation: fix spelling mistake: "contoller" -> "controller" pinctrl: make artpec6 explicitly non-modular pinctrl: aspeed: g5: Add pinconf support pinctrl: aspeed: g4: Add pinconf support pinctrl: aspeed: Add core pinconf support pinctrl: aspeed: Document pinconf in devicetree bindings pinctrl: Add st,stm32f469-pinctrl compatible to stm32-pinctrl pinctrl: stm32: Add STM32F469 MCU support Documentation: dt: Remove ngpios from stm32-pinctrl binding pinctrl: stm32: replace device_initcall() with arch_initcall() pinctrl: stm32: add possibility to use gpio-ranges to declare bank range pinctrl: armada-37xx: Add gpio support pinctrl: armada-37xx: Add pin controller support for Armada 37xx pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers pinctrl: core: Make pinctrl_init_controller() static pinctrl: generic: Add bi-directional and output-enable ...
2017-04-11pinctrl: generic: Add bi-directional and output-enableJacopo Mondi1-0/+3
Add bi-directional and output-enable pin configuration properties. bi-directional allows to specify when a pin shall operate in input and output mode at the same time. This is particularly useful in platforms where input and output buffers have to be manually enabled. output-enable is just syntactic sugar to specify that a pin shall operate in output mode, ignoring the provided argument. This pairs with input-enable pin configuration option. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-07pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()Tony Lindgren1-1/+2
Recent pinctrl changes to allow dynamic allocation of pins exposed one more issue with the pinctrl pins claimed early by the controller itself. This caused a regression for IMX6 pinctrl hogs. Before enabling the pin controller driver we need to wait until it has been properly initialized, then claim the hogs, and only then enable it. To fix the regression, split the code into pinctrl_claim_hogs() and pinctrl_enable(). And then let's require that pinctrl_enable() is always called by the pin controller driver when ready after calling pinctrl_register_and_init(). Depends-on: 950b0d91dc10 ("pinctrl: core: Fix regression caused by delayed work for hogs") Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs") Fixes: e566fc11ea76 ("pinctrl: imx: use generic pinctrl helpers for managing groups") Cc: Haojian Zhuang <haojian.zhuang@linaro.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Mika Penttilä <mika.penttila@nextfour.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Nishanth Menon <nm@ti.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Stefan Agner <stefan@agner.ch> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Gary Bisson <gary.bisson@boundarydevices.com> Tested-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-26Merge branch 'ib-pinctrl-genprops' into develLinus Walleij2-26/+32
2017-01-26pinctrl / gpio: Introduce .set_config() callback for GPIO chipsMika Westerberg1-18/+15
Currently we already have two pin configuration related callbacks available for GPIO chips .set_single_ended() and .set_debounce(). In future we expect to have even more, which does not scale well if we need to add yet another callback to the GPIO chip structure for each possible configuration parameter. Better solution is to reuse what we already have available in the generic pinconf. To support this, we introduce a new .set_config() callback for GPIO chips. The callback takes a single packed pin configuration value as parameter. This can then be extended easily beyond what is currently supported by just adding new types to the generic pinconf enum. If the GPIO driver is backed up by a pinctrl driver the GPIO driver can just assign gpiochip_generic_config() (introduced in this patch) to .set_config and that will take care configuration requests are directed to the pinctrl driver. We then convert the existing drivers over .set_config() and finally remove the .set_single_ended() and .set_debounce() callbacks. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-26pinctrl: Allow configuration of pins from gpiolib based driversMika Westerberg1-0/+6
When a GPIO driver is backed by a pinctrl driver the GPIO driver sometimes needs to call the pinctrl driver to configure certain things, like whether the pin is used as input or output. In addition to this there are other configurations applicable to GPIOs such as setting debounce time of the GPIO. To support this we introduce a new function pinctrl_gpio_set_config() that can be used by gpiolib based driver to pass configuration requests to the backing pinctrl driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-26pinctrl: Widen the generic pinconf argument from 16 to 24 bitsMika Westerberg1-8/+11
The current pinconf packed format allows only 16-bit argument limiting the maximum value 65535. For most types this is enough. However, debounce time can be in range of hundreths of milliseconds in case of mechanical switches so we cannot represent the worst case using the current format. In order to support larger values change the packed format so that the lower 8 bits are used as type which leaves 24 bits for the argument. This allows representing values up to 16777215 and debounce times up to 16 seconds. We also convert the existing users to use 32-bit integer when extracting argument from the packed configuration value. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-13pinctrl: core: Fix regression caused by delayed work for hogsTony Lindgren1-0/+15
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: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Gary Bisson <gary.bisson@boundarydevices.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-23pinctrl: pinconf: Add generic helper function for freeing mappingsJon Hunter1-0/+2
The pinconf-generic.h file exposes functions for creating generic mappings but it does not expose a function for freeing the mappings. Add a function for freeing generic mappings. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-04-21pinctrl: Add devm_ apis for pinctrl_{register, unregister}Laxman Dewangan1-0/+6
Add device managed APIs devm_pinctrl_register() and devm_pinctrl_unregister() for the APIs pinctrl_register() and pinctrl_unregister(). This helps in reducing code in error path and sometimes removal of .remove callback for driver unbind. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-27drivers/pinctrl: Add the concept of an "init" stateDouglas Anderson2-0/+18
For pinctrl the "default" state is applied to pins before the driver's probe function is called. This is normally a sensible thing to do, but in some cases can cause problems. That's because the pins will change state before the driver is given a chance to program how those pins should behave. As an example you might have a regulator that is controlled by a PWM (output high = high voltage, output low = low voltage). The firmware might leave this pin as driven high. If we allow the driver core to reconfigure this pin as a PWM pin before the PWM's probe function runs then you might end up running at too low of a voltage while we probe. Let's introudce a new "init" state. If this is defined we'll set pinctrl to this state before probe and then "default" after probe (unless the driver explicitly changed states already). An alternative idea that was thought of was to use the pre-existing "sleep" or "idle" states and add a boolean property that we should start in that mode. This was not done because the "init" state is needed for correctness and those other states are only present (and only transitioned in to and out of) when (optional) power management is enabled. Changes in v3: - Moved declarations to pinctrl/devinfo.h - Fixed author/SoB Changes in v2: - Added comment to pinctrl_init_done() as per Linus W. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Caesar Wang <wxt@rock-chips.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-03pinctrl: pinconf-generic: sort pin configuration params alphabeticallyMasahiro Yamada1-32/+32
Currently, the dt_params array in drivers/pinctrl/pinconf-generic.c is not sorted in the same order as the enum pin_config_param in include/linux/pinctrl/pinconf-generic.h. Sort enum pin_config_param, conf_items, dt_params, alphabetically for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-06-01pinctrl: use "const struct ..." rather than "struct ... const"Masahiro Yamada1-1/+1
Only this member, pins, is defined as "struct ... const *", but the others in this struct, pinlops, pmxops, confops, etc. are defined as "const struct ... *". Swap the "struct pinctrl_pin_desc" and "const" for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-06-01pinctrl: remove useless const qualifierMasahiro Yamada1-1/+1
This "const" claims the get_function_groups callback never changes the given num_groups pointer. It is always true in C language, so not worth mentioning. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06pinctrl: use ERR_CAST instead of ERR_PTR/PTR_ERRFabian Frederick1-1/+1
Inspired by scripts/coccinelle/api/err_cast.cocci Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06pinctrl: move strict option to pinmux_opsLinus Walleij2-3/+4
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: Linus Walleij <linus.walleij@linaro.org>
2015-05-06pinctrl: allow exlusive GPIO/mux pin allocationSonic Zhang1-0/+3
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 <sonic.zhang@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-05Revert "pinctrl: consumer: use correct retval for placeholder functions"Linus Walleij1-3/+3
This reverts commit 5a7d2efdd93f6c4bb6cd3d5df3d2f5611c9b87ac. As per discussion on the mailing list, this is not the right thing to do. NULL cookies are valid in the stubs. Reported-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14pinctrl: consumer: use correct retval for placeholder functionsWolfram Sang1-3/+3
These functions are supposed to return an error pointer, not NULL. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-14pinctrl: pinconf-generic: loose DT dependenceLinus Walleij2-8/+11
New pin controllers such as ACPI-based may also have custom properties to parse, and should be able to use generic pin config. Let's make the code compile on !OF systems and rename members a bit to underscore it is custom parameters and not necessarily DT parameters. This fixes a build regression for x86_64 on the zeroday kernel builds. Reported-by: kbuild test robot <fengguang.wu@intel.com> Reviewed-and-tested-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-12pinctrl: pinconf-generic: Allow driver to specify DT paramsSoren Brinkmann2-0/+27
Additionally to the generic DT parameters, allow drivers to provide driver-specific DT parameters to be used with the generic parser infrastructure. To achieve this 'struct pinctrl_desc' is extended to pass custom pinconf option to the core. In order to pass this kind of information, the related data structures - 'struct pinconf_generic_dt_params', 'pin_config_item' - are moved from pinconf internals to the pinconf-generic header. Additionally pinconfg-generic is refactored to not only iterate over the generic pinconf parameters but also take the parameters into account that are provided through the driver's 'struct pinctrl_desc'. In particular 'pinconf_generic_parse_dt_config()' and 'pinconf_generic_dump' helpers are split into two parts each. In order to have a more generic helper that can be used to process the generic parameters as well as the driver-specific ones. v2: - fix typo - add missing documentation for @conf_items member in struct - rebase to pinctrl/devel: conflict in abx500 - rename _pinconf_generic_dump() to pinconf_generic_dump_one() - removed '_' from _parse_dt_cfg() - removed BUG_ONs, error condition is handled in if statements - removed pinconf_generic_dump_group() & pinconf_generic_dump_pin helpers - fixed up corresponding call sites - renamed pinconf_generic_dump() to pinconf_generic_dump_pins() - added kernel-doc to pinconf_generic_dump_pins() - add kernel-doc - more verbose commit message Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Tested-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-12pinctrl: pinconf-generic: Infer map type from DT propertySoren Brinkmann1-0/+11
With the new 'groups' property, the DT parser can infer the map type from the fact whether 'pins' or 'groups' is used to specify the pin group to work on. To maintain backwards compatibitliy with current usage of the DT binding, this is only done when PIN_MAP_TYPE_INVALID is passed to the parsing function as type. Also, a new helper 'pinconf_generic_dt_node_to_map_all()' is introduced, which can be used by drivers as generic callback for dt_node_to_map() to leverage the new feature. Changes since v2: - rename dt_pin_specifier to subnode_target_type - add additional comment in header file explaining passing an invalid map type - mention map_all() helper in commit message Changes since RFC v2: - none Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Tested-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-04pinctrl: generic: Fix PIN_CONFIG_DRIVE_OPEN_SOURCE source/drain doc mismatchGeert Uytterhoeven1-1/+1
PIN_CONFIG_DRIVE_OPEN_SOURCE enables open source, not open drain. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-04pinctrl: clean up after enable refactoringLinus Walleij1-4/+3
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 <swarren@nvidia.com> Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Acked-by: Fan Wu <fwu@marvell.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-07-11pinctrl: avoid duplicated calling enable_pinmux_setting for a pinFan Wu1-2/+0
What the patch does: 1. Call pinmux_disable_setting ahead of pinmux_enable_setting each time pinctrl_select_state is called 2. Remove the HW disable operation in pinmux_disable_setting function. 3. Remove the disable ops in struct pinmux_ops 4. Remove all the disable ops users in current code base. Notes: 1. Great thanks for the suggestion from Linus, Tony Lindgren and Stephen Warren and Everyone that shared comments on this patch. 2. The patch also includes comment fixes from Stephen Warren. The reason why we do this: 1. To avoid duplicated calling of the enable_setting operation without disabling operation inbetween which will let the pin descriptor desc->mux_usecount increase monotonously. 2. The HW pin disable operation is not useful for any of the existing platforms. And this can be used to avoid the HW glitch after using the item #1 modification. In the following case, the issue can be reproduced: 1. There is a driver that need to switch pin state dynamically, e.g. between "sleep" and "default" state 2. The pin setting configuration in a DTS node may be like this: component a { pinctrl-names = "default", "sleep"; pinctrl-0 = <&a_grp_setting &c_grp_setting>; pinctrl-1 = <&b_grp_setting &c_grp_setting>; } The "c_grp_setting" config node is totally identical, maybe like following one: c_grp_setting: c_grp_setting { pinctrl-single,pins = <GPIO48 AF6>; } 3. When switching the pin state in the following official pinctrl sequence: pin = pinctrl_get(); state = pinctrl_lookup_state(wanted_state); pinctrl_select_state(state); pinctrl_put(); Test Result: 1. The switch is completed as expected, that is: the device's pin configuration is changed according to the description in the "wanted_state" group setting 2. The "desc->mux_usecount" of the corresponding pins in "c_group" is increased without being decreased, because the "desc" is for each physical pin while the setting is for each setting node in the DTS. Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead of enabling "c_grp_setting" in pinctrl-1, the desc->mux_usecount will keep increasing without any chance to be decreased. According to the comments in the original code, only the setting, in old state but not in new state, will be "disabled" (calling pinmux_disable_setting), which is correct logic but not intact. We still need consider case that the setting is in both old state and new state. We can do this in the following two ways: 1. Avoid to "enable"(calling pinmux_enable_setting) the "same pin setting" repeatedly 2. "Disable"(calling pinmux_disable_setting) the "same pin setting", actually two setting instances, ahead of enabling them. Analysis: 1. The solution #2 is better because it can avoid too much iteration. 2. If we disable all of the settings in the old state and one of the setting(s) exist in the new state, the pins mux function change may happen when some SoC vendors defined the "pinctrl-single,function-off" in their DTS file. old_setting => disabled_setting => new_setting. 3. In the pinmux framework, when a pin state is switched, the setting in the old state should be marked as "disabled". Conclusion: 1. To Remove the HW disabling operation to above the glitch mentioned above. 2. Handle the issue mentioned above by disabling all of the settings in old state and then enable the all of the settings in new state. Signed-off-by: Fan Wu <fwu@marvell.com> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Patrice Chotard <patrice.chotard@st.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Maxime Coquelin <maxime.coquelin@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-01-16pinctrl: Add void * to pinctrl_pin_descSherman Yin1-0/+2
drv_data is added to the pinctrl_pin_desc for drivers to define additional driver-specific per-pin data. Signed-off-by: Sherman Yin <syin@broadcom.com> Reviewed-by: Christian Daudt <bcm@fixthebug.org> Reviewed-by: Matt Porter <matt.porter@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-12-16pinctrl: Adds slew-rate, input-enable/disableSherman Yin1-0/+4
This commit adds slew-rate and input-enable/disable support for pinconf -generic. Signed-off-by: Sherman Yin <syin@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-12-03pinctrl: provide documentation pointerLinus Walleij1-2/+4
The PIN_CONFIG_OUTPUT parameter is really tricky to understand and needs an explicit pointer to the documentation. Cc: Tomasz Figa <t.figa@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-10-16pinctrl/gpio: non-linear GPIO ranges accesible from gpiolibChristian Ruppert1-0/+3
This patch adds the infrastructure required to register non-linear gpio ranges through gpiolib and the standard GPIO device tree bindings. Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-28pinctrl: Pass all configs to driver on pin_config_set()Sherman Yin1-2/+4
When setting pin configuration in the pinctrl framework, pin_config_set() or pin_config_group_set() is called in a loop to set one configuration at a time for the specified pin or group. This patch 1) removes the loop and 2) changes the API to pass the whole pin config array to the driver. It is now up to the driver to loop through the configs. This allows the driver to potentially combine configs and reduce the number of writes to pin config registers. All c files changed have been build-tested to verify the change compiles and that the corresponding .o is successfully generated. Signed-off-by: Sherman Yin <syin@broadcom.com> Reviewed-by: Christian Daudt <csd@broadcom.com> Reviewed-by: Matt Porter <matt.porter@linaro.org> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-23pinctrl: utils : add support to pass config type in generic util APIsLaxman Dewangan1-2/+20
Add support to pass the config type like GROUP or PIN when using the utils or generic pin configuration APIs. This will make the APIs more generic. Added additional inline APIs such that it can be use directly as callback for the pinctrl_ops. Changes from V1: - Remove separate implementation for pins and group for pinctrl_utils_dt_free_map and improve this function to support both i.e. PINS and GROUPs. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-16pinctrl: add includes and ifdefs for non-DT buildsLinus Walleij1-0/+9
Commit e81c8f18afc4fdd6e34d8c83814b8b5134dbb30f "pinctrl: pinconf-generic: add generic APIs for mapping pinctrl node" Added function prototypes with implicit dependencies on other header files causing build warnings like this: In file included from arch/arm/mach-ux500/board-mop500-pins.c:12:0: include/linux/pinctrl/pinconf-generic.h:142:3: warning: 'struct device_node' declared inside parameter list [enabled by default] unsigned *reserved_maps, unsigned *num_maps); ^ include/linux/pinctrl/pinconf-generic.h:142:3: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/pinctrl/pinconf-generic.h:142:3: warning: 'struct pinctrl_dev' declared inside parameter list [enabled by default] include/linux/pinctrl/pinconf-generic.h:145:3: warning: 'struct device_node' declared inside parameter list [enabled by default] unsigned *num_maps); ^ Let's just add ifdefs for non-DT systems (the actual code is already ifdefed) and #include <linux/device.h> to get the most important structs and forward-declare the pinctrl core structs. Reported-by: Olof Johansson <olof@lixom.net> Cc: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-14pinctrl: pinconf-generic: add generic APIs for mapping pinctrl nodeLaxman Dewangan1-0/+6
Add generic APIs to map the DT node and its sub node in pinconf generic driver. These APIs can be used from driver to parse the DT node who uses the pinconf generic APIs for defining their nodes. Changes from V1: - Add generic property for pins and functions in pinconf-generic. - Add APIs to map the DT and subnode. - Move common utils APIs to the pinctrl-utils from this file. - Update the binding document accordingly. Changes from V2: - Rebased the pinctrl binding doc on top of Stephen's cleanup. - Rename properties "pinctrl-pins" and "pinctrl-function" to "pins" and "function". Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-06-25pinctrl: set unit for debounce time pinconfig to usecHeiko Stübner1-1/+1
Currently the debounce time pinconfig option uses an unspecified "time units" unit. As pinconfig options should use SI units and a real unit is also necessary for generic dt bindings, change it to usec. Currently no driver is using the generic pinconfig option for this, so the unit change is safe to do. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>