- 16 Nov, 2016 11 commits
-
-
Dan Carpenter authored
We should return -ENOMEM instead of success if pcs_add_function() fails. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
gcc warns about a way that it could use an uninitialized variable: drivers/pinctrl/sunxi/pinctrl-sunxi.c: In function 'sunxi_pinctrl_init': drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: error: 'best_div' may be used uninitialized in this function [-Werror=maybe-uninitialized] This cannot really happen except if 'freq' is UINT_MAX and 'clock' is zero, and both of these are forbidden. To shut up the warning anyway, this changes the logic to initialize the return code to the first divider value before looking at the others. Fixes: 7c926492 ("pinctrl: sunxi: Add support for interrupt debouncing") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Linus Walleij authored
Merge tag 'sh-pfc-for-v4.10-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel pinctrl: sh-pfc: Updates for v4.10 (take two) - DU and EtherAVB pin groups for R-Car M3-W, - Bias handling cleanups and bug fixes, - Drive-strength for non-GPIO pins for R-Car H3, - EtherAVB MDIO & MII, and QSPI pin groups for R-Car H3.
-
Andy Yan authored
This add pinctrl support for Rockchip RK1108 Soc. Signed-off-by:
Andy Yan <andy.yan@rock-chips.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Series-changes: 2 - add pull and drive-strength functionality Series-changes: 3 - two minor CodingStyle fixes adviced by Heiko Signed-off-by:
-
Niklas Söderlund authored
Group the QSPI0 and QSPI1 pins into similar groups found in other sh-pfc drivers. The pins can not be muxed between functions other than QSPI, but their drive strength can be controlled. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be>
-
Niklas Söderlund authored
Group the AVB pins into similar groups found in other sh-pfc drivers. The pins can not be muxed between functions other then AVB but their drive strength can be controlled. The group avb_mdc containing ADV_MDC and ADV_MDIO are on other SoCs called avb_mdio. In pfc-r8a7795 the avb_mdc group already existed and is in use in DT. Therefore add the ADV_MDIO pin to the existing group instead of renaming it. Signed-off-by:
-
Niklas Söderlund authored
There are pins on the r8a7795 which are not part of a GPIO bank nor can be muxed between different functions. They do however allow for the drive-strength to be configured. Add those pins to the list of pins and to the drive-strength configuration registers. The pins can now be referred to in DT by function names and their drive-strength modified. Signed-off-by:
-
Niklas Söderlund authored
Pins not associated with a GPIO port can still have other configuration parameters. Add a new macro SH_PFC_PIN_NAMED_CFG which allows for named pins to be declared with a set of configurations. The new macro is an modification of SH_PFC_PIN_NAMED to allow for optional configuration to be assigned. The flag SH_PFC_PIN_CFG_NO_GPIO is still enforced as this should only be used to define pins not associated with a GPIO port. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Niklas Söderlund authored
Change the data structure and use the generic sh_pfc_pin_to_bias_info() function to get the register offset and bit information. Suggested-by:
-
Niklas Söderlund authored
There is a bug in the r8a7795 bias code where a WARN() is trigged anytime a pin from PUEN0/PUD0 is accessed. # cat /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins WARNING: CPU: 2 PID: 2391 at drivers/pinctrl/sh-pfc/pfc-r8a7795.c:5364 r8a7795_pinmux_get_bias+0xbc/0xc8 [..] Call trace: [<ffff0000083c442c>] r8a7795_pinmux_get_bias+0xbc/0xc8 [<ffff0000083c37f4>] sh_pfc_pinconf_get+0x194/0x270 [<ffff0000083b0768>] pin_config_get_for_pin+0x20/0x30 [<ffff0000083b11e8>] pinconf_generic_dump_one+0x168/0x188 [<ffff0000083b144c>] pinconf_generic_dump_pins+0x5c/0x98 [<ffff0000083b0628>] pinconf_pins_show+0xc8/0x128 [<ffff0000081fe3bc>] seq_read+0x16c/0x420 [<ffff00000831a110>] full_proxy_read+0x58/0x88 [<ffff0000081d7ad4>] __vfs_read+0x1c/0xf8 [<ffff0000081d8874>] vfs_read+0x84/0x148 [<ffff0000081d9d64>] SyS_read+0x44/0xa0 [<ffff000008082f4c>] __sys_trace_return+0x0/0x4 This is due to the WARN() check if the reg field of the pullups struct is zero, and this should be 0 for pins controlled by the PUEN0/PUD0 registers since PU0 is defined as 0. Change the data structure and use the generic sh_pfc_pin_to_bias_info() function to get the register offset and bit information. Fixes: 56065524 ("pinctrl: sh-pfc: r8a7795: Add bias pinconf support") Signed-off-by:
-
Niklas Söderlund authored
The last else statement is missing braces, and the indentation level can be reduced. Suggested-by:
-
- 15 Nov, 2016 13 commits
-
-
Niklas Söderlund authored
On some SoC there are no simple mapping of pins to bias register bits and a lookup table is needed. This logic is already implemented in some SoC specific drivers that could benefit from a generic implementation. Add helpers to deal with the lookup which later can be used by the SoC specific drivers. The logic used to lookup are different from the one it aims to replace, this is intentional. This new method reduces the memory consumption at the cost of increased CPU usage and fix a bug where a WARN() would incorrectly be triggered if the register offset is 0. Signed-off-by:
-
Niklas Söderlund authored
Always stating PIN_CONFIG_BIAS_DISABLE is supported gives untrue output when examining /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins if the operation get_bias() is implemented but the pin is not handled by the get_bias() implementation. In that case the output will state that "input bias disabled" indicating that this pin has bias control support. Make support for PIN_CONFIG_BIAS_DISABLE depend on that the pin either supports SH_PFC_PIN_CFG_PULL_UP or SH_PFC_PIN_CFG_PULL_DOWN. This also solves the issue where SoC specific implementations print error messages if their particular implementation of {set,get}_bias() is called with a pin it does not know about. Signed-off-by: -
Niklas Söderlund authored
Only the DU parallel RGB output signals are included, HDMI and TCON pins will be added in separate groups. Based on a similar patch from Laurent Pinchart for the r8a7795 PFC driver. Signed-off-by:
-
Takeshi Kihara authored
This patch adds AVB_LINK, AVB_MAGIC, AVB_PHY_INT, AVB_MDC, AVB_AVTP_PPS, AVB_AVTP_MATCH, AVB_AVTP_CAPTURE pins, groups and functions to R8A7796 SoC. Signed-off-by:
Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by:
-
Andy Yan authored
This adds the dt-binding documentation for rk1108 pinctrl Signed-off-by:
-
Maxime Ripard authored
The pin controller found in the Allwinner SoCs has support for interrupts debouncing. However, this is not done per-pin, preventing us from using the generic pinconf binding for that, but per irq bank, which, depending on the SoC, ranges from one to five. Introduce a device-wide property to deal with this using a microsecond resolution. We can re-use the per-pin input-debounce property for that, so let's do it! Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Chen-Yu Tsai authored
The sunxi_pconf_reg helper introduced in the last patch gives us the chance to rework sunxi_pconf_group_set to have it match the structure of sunxi_pconf_(group_)get and make it easier to understand. For each config to set, it: 1. checks if the parameter is supported. 2. checks if the argument is within limits. 3. converts argument to the register value. 4. writes to the register with spinlock held. As a result the function now blocks unsupported config parameters, instead of silently ignoring them. Signed-off-by:Chen-Yu Tsai <wens@csie.org> Acked-by:
-
Chen-Yu Tsai authored
The sunxi pinctrl driver only caches whatever pinconf setting was last set on a given pingroup. This is not particularly helpful, nor is it correct. Fix this by actually reading the hardware registers and returning the correct results or error codes. Also filter out unsupported pinconf settings. Since this driver has a peculiar setup of 1 pin per group, we can support both pin and pingroup pinconf setting read back with the same code. The sunxi_pconf_reg helper and code structure is inspired by pinctrl-msm. With this done we can also claim to support generic pinconf, by setting .is_generic = true in pinconf_ops. Also remove the cached config value. The behavior of this was never correct, as it only cached 1 setting instead of all of them. Since we can now read back settings directly from the hardware, it is no longer required. Signed-off-by:
-
Chen-Yu Tsai authored
According to pinconf-generic.h, the argument for PIN_CONFIG_BIAS_PULL_{DOWN,UP} is non-zero if the bias is enabled with a pull up/down resistor, zero if it is directly connected to VDD or ground. Since Allwinner hardware uses a weak pull resistor internally, the argument should be 1. Signed-off-by: -
Chen-Yu Tsai authored
In the recently refactored sunxi pinctrl library, we are only allocating one set of pin configs for each pinmux setting node. When the pinctrl_map structure is freed, the pin configs should also be freed. However the code assumed the first map would contain the configs, which actually never happens, as the mux function map gets added first. The proper way to do this is to look through all the maps and free the first one whose type is actually PIN_MAP_TYPE_CONFIGS_GROUP. Also slightly expand the comment explaining this. Fixes: f233dbca ("pinctrl: sunxi: Rework the pin config building code") Signed-off-by:
-
Paul Gortmaker authored
None of the Kconfigs for any of these drivers are tristate, meaning that they currently are not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the drivers there is no doubt they are builtin-only. All drivers get the exact same change, so they are handled in batch. Changes are (1) use builtin_platform_driver, (2) use init.h header (3) delete module_exit related code, (4) delete MODULE_DEVICE_TABLE, (5) delete MODULE_LICENCE/MODULE_AUTHOR and associated tags and (6) drop ".remove" code and prevent sysfs unbind attempts to call ".remove". Once this is done, the shared remove function in wmt.[ch] is no longer used and hence it is removed as well. Since module_platform_driver() uses the same init level priority as builtin_platform_driver() the init ordering remains unchanged with this commit. Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code. We also delete the MODULE_LICENSE etc. tags since all that information is already contained at the top of each file in the comments. Cc: Tony Prisk <linux@prisktech.co.nz> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Chanwoo Choi authored
This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need to support the multiple memory map because the registers of GPFx are located in the different domain. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Tomasz Figa <tomasz.figa@gmail.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: linux-gpio@vger.kernel.org Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
-
Chanwoo Choi authored
This patch supports the multiple IORESOURCE_MEM resources for one pin-bank. In the pre-existing Exynos series, the registers of the gpio bank are included in the one memory map. But, some gpio bank need to support the one more memory map (IORESOURCE_MEM) because the registers of gpio bank are separated into the different memory map. For example, The both ALIVE and IMEM domain have the different memory base address. The GFP[1-5] of exynos5433 are composed as following: - ALIVE domain : WEINT_* registers - IMEM domain : CON/DAT/PUD/DRV/CONPDN/PUDPDN register Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Tomasz Figa <tomasz.figa@gmail.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: linux-gpio@vger.kernel.org Suggested-by:
Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
- 14 Nov, 2016 2 commits
-
-
Phil Elwell authored
When dynamically unloading overlays, it is important that freed pins are restored to being inputs to prevent functions from being enabled in multiple places at once. Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
Phil Elwell <phil@raspberrypi.org> Acked-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Phil Elwell authored
Contrary to the documentation, the BCM2835 GPIO controller actually has four interrupt lines - one each for the three IRQ groups and one common. Confusingly, the GPIO interrupt groups don't correspond directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2. Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks, so split out a function to process the interrupts for a single GPIO bank. Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
-
- 11 Nov, 2016 2 commits
-
-
Axel Haslam authored
The pcs_parse_bits_in_pinctrl_entry function should search for the "pinctrl-single,bits" and not "pinctrl-single,pins" Signed-off-by:
Axel Haslam <ahaslam@baylibre.com> Acked-by:
-
Axel Haslam authored
pinctrl_count_index_with_args returns -ENOENT not -EINVAL. The return check would pass, and we would try to kzalloc with a negative error size throwing a warning. Instead of checking for -EINVAL specifically, lets check for any error and avoid negative size allocations. Signed-off-by:
-
- 08 Nov, 2016 12 commits
-
-
Heinrich Schuchardt authored
for_each_property_of_node(pins, pp) checks that pp is not NULL. So there is no need to check it inside the loop. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by:
Patrice Chotard <patrice.chotard@st.com> Signed-off-by:
-
Heinrich Schuchardt authored
function is defined as unsigned int. So we need %u to print it. Signed-off-by:
-
Linus Walleij authored
Merge tag 'sh-pfc-for-v4.10-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel pinctrl: sh-pfc: Updates for v4.10 - I2C and DRIF pin groups for R-Car M3-W, - Bug fixes for SDHI2/3 on R-Car M3-W.
-
Linus Walleij authored
Include <linux/gpio/driver.h> rather than <linux/gpio.h> Drop <linux/pinctrl/machine.h>. Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: -
Andrey Smirnov authored
Tested-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by:
-
Andrey Smirnov authored
Tested-by:
-
Andrey Smirnov authored
Althought the function passed as a "handler" during GPIO chip instantiation is not going to ever be called, specifying handle_edge_irq there makes for a rather confusing read, both because no "ack" callback in specified for irqchip and because there's no acking action is necessary. Specify handle_bad_irq instead a make a note of the situation. This commit should be a no-op behaviour wise. Tested-by:
-
Andrey Smirnov authored
Make use of for_each_set_bit macro and reduce boilerplate code. Tested-by:
-
Andrey Smirnov authored
Move actual code that configures oscio pin into a separate function and use it instead of calling sx150x_gpio_set to avoid calling sx150x_pin_is_oscio twice and correctly propagte error code in sx150x_gpio_direction_output. Tested-by:
-
Andrey Smirnov authored
Gpiochip and irqchip aspects of this driver do not access any shared registers on the chip itself and atomicity of various regmap operations is ensured by that API's implementation, so there doesn't seem to be a reason to hold the lock in as many places as it is held now. Tested-by:
-
Andrey Smirnov authored
The difference between 8 and 16 pin GPIO expanders can be accomodated by the means of regmap API without resorting to using driver-specific read/write accessors. This change, IMHO, brings the following benefits: - Replaces driver's idiosyncratic way of dealing with mult-register fields with regmap API, which, hopefuly, makes the code a bit easier for a new reader to understand - Removes various multi-read for-loop register read logic from various places in the code and puts it in a signle place - Removes ad-hoc IRQ register caching code in sx150x_irq_bus_sync_unlock, since that functionality is provided by regmap Besided aforementioned benefits this change also implements necessary RegSense byte swap necessary for SX1503 and SX1506 variants of the chip. Tested-by:
-
Andrey Smirnov authored
To allow for future code simplification Tested-by:
-
