- 22 Jun, 2016 1 commit
-
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: config PINCTRL_PALMAS bool "Pinctrl driver for the PALMAS Series MFD devices" ...meaning that it currently is not being built as a module by anyone. During an audit for non-modular drivers using modular infrastructure this driver showed up. But rather than demodularize it, Laxman indicated that it would be prefereable to instead convert the driver option to tristate. This does that, and confirms that it will compile and modpost as such. However, since I do not have the hardware to confirm that no new runtime issues exist when modular, that remains untested. Cc: Laxman Dewangan <ldewangan@nvidia.com> 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:
Linus Walleij <linus.walleij@linaro.org>
-
- 18 Jun, 2016 5 commits
-
-
Jon Hunter authored
When pinctrl_get() is called for a device, it will return a valid handle even if the device itself has no pinctrl state entries defined in device-tree. This is caused by the function pinctrl_dt_to_map() which will return success even if the first pinctrl state, 'pinctrl-0', is not found in the device-tree node for a device. According to the pinctrl device-tree binding documentation, pinctrl states must be numbered starting from 0 and so 'pinctrl-0' should always be present if a device uses pinctrl and therefore, if 'pinctrl-0' is not present it seems valid that we should not return a valid pinctrl handle. Fix this by returning an error code if the property 'pinctrl-0' is not present for a device. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
Mika Westerberg authored
The pinctrl-intel needs to use request_irq() instead of chained interrupt handling because it shares the interrupt with multiple GPIO host controllers found on Intel CPUs. In -rt all such interrupts are forced to run in thread context which triggers following warning: WARNING: CPU: 0 PID: 530 at kernel/irq/handle.c:151 handle_irq_event_percpu+0x23d/0x240 irq 348 handler irq_default_primary_handler+0x0/0x10 enabled interrupts Modules linked in: CPU: 0 PID: 530 Comm: irq/14-INT3452: Not tainted 4.6.2-rt5 #1060 0000000000000000 ffff88007a257c98 ffffffff812d8494 ffff88007a257ce8 0000000000000000 ffff88007a257cd8 ffffffff8105e554 000000977a257d90 ffff88007a37a380 000000000000015c 0000000000000002 0000000000000000 Call Trace: [<ffffffff812d8494>] dump_stack+0x4f/0x6b [<ffffffff8105e554>] __warn+0xe4/0x100 [<ffffffff8105e5bf>] warn_slowpath_fmt+0x4f/0x60 [<ffffffff810b18f0>] ? __synchronize_hardirq+0x60/0x60 [<ffffffff810b17fd>] handle_irq_event_percpu+0x23d/0x240 [<ffffffff810b1862>] handle_irq_event+0x62/0x90 [<ffffffff810b4e1f>] handle_edge_irq+0x8f/0x190 [<ffffffff810b0d82>] generic_handle_irq+0x22/0x30 [<ffffffff81307abc>] intel_gpio_irq+0xdc/0x150 [<ffffffff810b2293>] irq_forced_thread_fn+0x23/0x70 [<ffffffff810b250b>] irq_thread+0x13b/0x1d0 [<ffffffff8167b844>] ? __schedule+0x2e4/0x5a0 [<ffffffff810b2270>] ? irq_finalize_oneshot.part.37+0xd0/0xd0 [<ffffffff810b25a0>] ? irq_thread+0x1d0/0x1d0 [<ffffffff810b23d0>] ? wake_threads_waitq+0x30/0x30 [<ffffffff8107e624>] kthread+0xd4/0xf0 [<ffffffff8167ec27>] ? _raw_spin_unlock_irq+0x17/0x40 [<ffffffff8167f592>] ret_from_fork+0x22/0x40 [<ffffffff8107e550>] ? kthread_worker_fn+0x190/0x190 The handle_irq_event_* functions (and I suppose generic_handle_irq()) is expected to be called with interrupts disabled and they rightfully complain here because we run in thread context with interrupts enabled. Fix this by adding IRQF_NO_THREAD flag when the master interrupt is requested. This prevents forced threading of the interrupt used by the GPIO host controllers. Reported-by:
Kim Tatt Chuah <kim.tatt.chuah@intel.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Mika Westerberg authored
When running -rt kernel and GPIO interrupt happens we get following BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931 in_atomic(): 1, irqs_disabled(): 0, pid: 530, name: irq/14-INT3452: Preemption disabled at:[<ffffffff810b4dab>] handle_edge_irq+0x1b/0x190 CPU: 0 PID: 530 Comm: irq/14-INT3452: Not tainted 4.6.2-rt5 #1060 0000000000000000 ffff88007a257d58 ffffffff812d8494 0000000000000000 ffff88017a330000 ffff88007a257d78 ffffffff81083a11 ffff88007a252430 ffff88007a252430 ffff88007a257d90 ffffffff8167ef20 000000000000001a Call Trace: [<ffffffff812d8494>] dump_stack+0x4f/0x6b [<ffffffff81083a11>] ___might_sleep+0xe1/0x160 [<ffffffff8167ef20>] rt_spin_lock+0x20/0x50 [<ffffffff81308c6d>] intel_gpio_irq_ack+0x2d/0x80 [<ffffffff810b4e0b>] handle_edge_irq+0x7b/0x190 [<ffffffff810b0d82>] generic_handle_irq+0x22/0x30 [<ffffffff81307abc>] intel_gpio_irq+0xdc/0x150 [<ffffffff810b2293>] irq_forced_thread_fn+0x23/0x70 [<ffffffff810b250b>] irq_thread+0x13b/0x1d0 [<ffffffff8167b844>] ? __schedule+0x2e4/0x5a0 [<ffffffff810b2270>] ? irq_finalize_oneshot.part.37+0xd0/0xd0 [<ffffffff810b25a0>] ? irq_thread+0x1d0/0x1d0 [<ffffffff810b23d0>] ? wake_threads_waitq+0x30/0x30 [<ffffffff8107e624>] kthread+0xd4/0xf0 [<ffffffff8167ec27>] ? _raw_spin_unlock_irq+0x17/0x40 [<ffffffff8167f592>] ret_from_fork+0x22/0x40 [<ffffffff8107e550>] ? kthread_worker_fn+0x190/0x190 The reason why this happens is because intel_gpio_irq_ack() is called with desc->lock raw_spinlock locked which cannot sleep but our normal spinlock (which is converted to rtmutex in -rt) is allowed to sleep. This causes might_sleep() to trigger. Fix this by converting the normal spinlock to a raw_spinlock. Reported-by:
-
Masahiro Yamada authored
These are input-only pins. They do not support drive controlling in the first place. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Masahiro Yamada authored
According to the hardware document, setting the drive control is prohibited for these pins (N-channel Open Drain pins). Set their drive control attribute to "fixed". Signed-off-by:
-
- 15 Jun, 2016 8 commits
-
-
Tan Jui Nee authored
This is to cater the need for non-ACPI system whereby a platform device has to be created in order to bind with the Apollo Lake Pinctrl GPIO platform driver. Signed-off-by:
Tan Jui Nee <jui.nee.tan@intel.com> Acked-by:
-
Arnd Bergmann authored
The recently added max77620 driver fails to build when CONFIG_PINMUX is not set: pinctrl/pinctrl-max77620.c:272:21: error: variable 'max77620_pinmux_ops' has initializer but incomplete type static const struct pinmux_ops max77620_pinmux_ops = { ^~~~~~~~~~ pinctrl/pinctrl-max77620.c:273:2: error: unknown field 'get_functions_count' specified in initializer This adds the Kconfig 'select' statement that was clearly meant to be there and is used in all other pinmux drivers. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
When building with 'make W=1', we get harmless warnings about five drivers in drivers/pinctrl, which all contain a copy of the same line: drivers/pinctrl/freescale/pinctrl-imx1-core.c:160:1: error: 'inline' is not at beginning of declaration [-Werror=old-style-declaration] This replaces the somewhat nonstandard 'static const inline' with 'static inline const', which has the same meaning but does not cause this warning. Signed-off-by:
-
Jon Hunter authored
The strucuture 'max77620_cfg_param' is defined but never used by the max77620 driver. Remove this structure definition. Signed-off-by:
-
Dan O'Donovan authored
Pin config get/set handlers for pin groups were previously not implemented by this driver. The pin_config_group_set is particularly useful for applying a common config setting to all pins in a specified group with a single call, without the caller needing to reference each individual pin by name. Signed-off-by:
Dan O'Donovan <dan@emutex.com> Acked-by:
-
Dan O'Donovan authored
On some CHV platforms, we need an option to configure the open-drain setting for these pins. This adds support for the PIN_CONFIG_DRIVE_PUSH_PULL and PIN_CONFIG_DRIVE_OPEN_DRAIN to disable/enable open-drain mode for a specific pin. Signed-off-by:
-
Dan O'Donovan authored
Due to a silicon issue on the Atom X5-Z8000 "Cherry Trail" processor series, a common lock must be used to prevent concurrent accesses across the 4 GPIO controllers managed by this driver. See Intel Atom Z8000 Processor Series Specification Update (Rev. 005), errata #CHT34, for further information. Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Linus Walleij authored
The PM8058 is found in connection to the APQ8060 on the APQ8060 Dragonboard. Works the same as all others, just add the compatible string for this variant. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Andy Gross <andy.gross@linaro.org> Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
- 13 Jun, 2016 14 commits
-
-
Amitoj Kaur Chawla authored
Replace the in order struct initialisation style with explicit field style. The Coccinelle semantic patch used to make this change is as follows: @decl@ identifier i1,fld; type T; field list[n] fs; @@ struct i1 { fs T fld; ...}; @@ identifier decl.i1,i2,decl.fld; expression e; position bad.p, bad.fix; @@ struct i1 i2@p = { ..., + .fld = e - e@fix ,...}; Signed-off-by:Amitoj Kaur Chawla <amitoj1606@gmail.com> Signed-off-by:
-
Andrew Jeffery authored
Signed-off-by:
Andrew Jeffery <andrew@aj.id.au> Signed-off-by:
-
Andrew Jeffery authored
Signed-off-by:
-
Andrew Jeffery authored
Signed-off-by:
-
Ben Dooks authored
The array u300_pmx_registers is not declared or used outside of the driver, so make it static to avoid the following warning: drivers/pinctrl/pinctrl-u300.c:673:11: warning: symbol 'u300_pmx_registers' was not declared. Should it be static? Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by:
-
Florian Fainelli authored
drivers/pinctrl/bcm/Makefile properly builds individual drivers based on their respective Kconfig symbols. ARCH_BCM is currently a menuconfig option from arch/arm/mach-bcm/Kconfig, which is fine, but prevents ARM64 platforms which do not have such menuconfig option from building their pinctrl drivers, so let's get rid of that dependency. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Scott Branden <scott.branden@broadcom.com> Acked-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Ben Dooks authored
There are five functions in the driver that are defined but only used locally. Since these are not used in the current kernel, delete them to avoid the following warnings: drivers/pinctrl/nomadik/pinctrl-nomadik.c:1036:6: warning: symbol 'nmk_gpio_clocks_enable' was not declared. Should it be static? drivers/pinctrl/nomadik/pinctrl-nomadik.c:1050:6: warning: symbol 'nmk_gpio_clocks_disable' was not declared. Should it be static? drivers/pinctrl/nomadik/pinctrl-nomadik.c:1073:6: warning: symbol 'nmk_gpio_wakeups_suspend' was not declared. Should it be static? drivers/pinctrl/nomadik/pinctrl-nomadik.c:1094:6: warning: symbol 'nmk_gpio_wakeups_resume' was not declared. Should it be static? drivers/pinctrl/nomadik/pinctrl-nomadik.c:1120:6: warning: symbol 'nmk_gpio_read_pull' was not declared. Should it be static? Signed-off-by:
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: drivers/pinctrl/Kconfig:config PINCTRL_AT91PIO4 drivers/pinctrl/Kconfig: bool "AT91 PIO4 pinctrl driver" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. We explicitly disallow a driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. 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 tag etc. since all that information is already contained at the top of the file in the comments. Cc: linux-gpio@vger.kernel.org Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: drivers/pinctrl/Kconfig:config PINCTRL_DIGICOLOR drivers/pinctrl/Kconfig: bool ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. We explicitly disallow a driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. 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. Cc: linux-gpio@vger.kernel.org Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: config PINCTRL_ZYNQ bool "Pinctrl driver for Xilinx Zynq" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. 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 tag etc. since all that information is already contained at the top of the file in the comments. Cc: Michal Simek <michal.simek@xilinx.com> Cc: Sören Brinkmann" <soren.brinkmann@xilinx.com> Cc: linux-gpio@vger.kernel.org Signed-off-by:Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: config PINCTRL_AMD bool "AMD GPIO pin control" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. We explicitly disallow a driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. 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 tag etc. since all that information is already contained at the top of the file in the comments. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Cc: Ken Xue <Ken.Xue@amd.com> Cc: Jeff Wu <Jeff.Wu@amd.com> Signed-off-by: -
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: config PINCTRL_LPC18XX bool "NXP LPC18XX/43XX SCU pinctrl driver" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. We explicitly disallow a driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. 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 tag etc. since all that information is already contained at the top of the file in the comments. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Joachim Eastwood <manabian@gmail.com> Cc: linux-gpio@vger.kernel.org Signed-off-by: -
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: drivers/pinctrl/Kconfig:config PINCTRL_AT91 drivers/pinctrl/Kconfig: bool "AT91 pinctrl driver" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init was not being used in this driver, we don't need to be concerned with initcall ordering changes when removing it. We also delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Signed-off-by:
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: config PINCTRL_BAYTRAIL bool "Intel Baytrail GPIO pin control" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. We explicitly disallow a driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. Since module_init() was already not in use in this driver, we don't have any concerns with init ordering changes here. Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code. We also delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: linux-gpio@vger.kernel.org Signed-off-by:
-
- 08 Jun, 2016 4 commits
-
-
Ben Dooks authored
The atmel_pctl_find_group_by_pin() and the atmel_pinctrl_remove() functions are not exported, so fix the warnings about these being exported without definitions by making them static. drivers/pinctrl/pinctrl-at91-pio4.c:424:20: warning: symbol 'atmel_pctl_find_group_by_pin' was not declared. Should it be static? drivers/pinctrl/pinctrl-at91-pio4.c:1077:5: warning: symbol 'atmel_pinctrl_remove' was not declared. Should it be static? Signed-off-by:
-
Ben Dooks authored
Fixup warnings from functions that are not exported and therefore should be marked static. Fixes: drivers/pinctrl/bcm/pinctrl-nsp-gpio.c:461:5: warning: symbol 'nsp_pin_config_group_get' was not declared. Should it be static? drivers/pinctrl/bcm/pinctrl-nsp-gpio.c:467:5: warning: symbol 'nsp_pin_config_group_set' was not declared. Should it be static? Signed-off-by:
Ray Jui <ray.jui@broadcom.com> Signed-off-by:
-
Masahiro Yamada authored
My mistake in the initial support patches. Signed-off-by:
-
hongkun.cao authored
An irq which is a wake up source maybe masked unexpectedly if the wake up source irq was triggered after pinctrl irqchip suspend and before suspend_device_irqs finished. Use *_noirq callbacks to guarantee pinctrl irqchip suspend would be called after suspend_devices_irqs. Signed-off-by:
hongkun.cao <hongkun.cao@mediatek.com> Signed-off-by:
-
- 31 May, 2016 8 commits
-
-
Neil Armstrong authored
Rename pinctrl_utils_dt_free_map to pinctrl_utils_free_map, introduced in d32f7fd3 ("pinctrl: Rename pinctrl_utils_dt_free_map to pinctrl_utils_free_map") but not reported into oxnas driver. Fixes: 611dac1e ("pinctrl: Add Oxford Semiconductor OXNAS pinctrl and gpio driver") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Masahiro Yamada authored
Add pin configuration and pinmux support for UniPhier PH1-LD20 SoC. Signed-off-by:
-
Masahiro Yamada authored
Add pin configuration and pinmux support for UniPhier PH1-LD11 SoC. Signed-off-by:
-
Masahiro Yamada authored
Currently, the UniPhier pinctrl driver itself is a syscon, but it turned out much more reasonable to make it a child node of a syscon because our syscon node consists of a bunch of system configuration registers, not only pinctrl, but also phy, and misc registers. It is difficult to split the node. To allow to migrate to the new DT structure, this commit adds new compatible strings to not disturb the existing DT. After a while, the old binding will be removed. Signed-off-by:
-
Masahiro Yamada authored
This is needed to get access to UniPhier System Bus (external bus). Signed-off-by:
-
Masahiro Yamada authored
These pins do not support pin-muxing, but it is useful to support pin configuration for them. Signed-off-by:
-
Masahiro Yamada authored
PH1-LD4 and PH1-sLD8 SoCs have pins that support pin configuration (pin biasing, drive strength control), but not pin-muxing. Allow to fill the mux value table with -1 for those pins; pins with mux value -1 will be skipped in the pin-mux set function. The mux value type should be changed from "unsigned" to "int" in order to accommodate -1 as a special case. Signed-off-by:
-
Masahiro Yamada authored
Upcoming new pinctrl drivers for PH1-LD11 and PH-LD20 support input signal gating for each pin. (While, existing ones only support it per pin-group.) This commit updates the core part for that. Signed-off-by:
-
