- 11 Jul, 2014 40 commits
-
-
Himangi Saraogi authored
This patch moves data allocated using regulator_register to devm_regulator_register and does away the calls to regulator_unregister. The sh73a0_pinmux_soc_exit function is no longer needed and is removed. Signed-off-by:
Himangi Saraogi <himangi774@gmail.com> Acked-by:
Julia Lawall <julia.lawall@lip6.fr> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Geert Uytterhoeven authored
The driver already supports the r8a7791 SoC, and "renesas,pfc-r8a7791" is already in use. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
Linus Walleij authored
We have four Qualcomm-related pin control drivers, and now there are drivers coming in for the PMICs on these systems, so let's create a qcom subdirectory to hold all the Qualcomm stuff. Acked-by:
Ivan T. Ivanov <iivanov@mm-sol.com> Acked-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
-
Bjorn Andersson authored
Signed-off-by:
-
Tomasz Figa authored
This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins, which is useful for pins that are not supposed to be used by any dedicated driver, but need certain board-specific setting. Signed-off-by:
Tomasz Figa <t.figa@samsung.com> Acked-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
-
Tomasz Figa authored
One of remaining limitations of current pinctrl-samsung driver was the inability to parse multiple pinmux/pinconf group nodes grouped inside a single device tree node. It made defining groups of pins for single purpose, but with different parameters very inconvenient. This patch implements Tegra-like support for grouping multiple pinctrl groups inside one device tree node, by completely changing the way pin groups and functions are parsed from device tree. The code creating pinctrl maps from DT nodes has been borrowed from pinctrl-tegra, while the initial creation of groups and functions has been completely rewritten with following assumptions: - each group consists of just one pin and does not depend on data from device tree, - each function is represented by a device tree child node of the pin controller, which in turn can contain multiple child nodes for pins that need to have different configuration values. Device Tree bindings are fully backwards compatible. New functionality can be used by defining a new pinctrl group consisting of several child nodes, as on following example: sd4_bus8: sd4-bus-width8 { part-1 { samsung,pins = "gpk0-3", "gpk0-4", "gpk0-5", "gpk0-6"; samsung,pin-function = <3>; samsung,pin-pud = <3>; samsung,pin-drv = <3>; }; part-2 { samsung,pins = "gpk1-3", "gpk1-4", "gpk1-5", "gpk1-6"; samsung,pin-function = <4>; samsung,pin-pud = <4>; samsung,pin-drv = <3>; }; }; Tested on Exynos4210-Trats board and a custom Exynos4212-based one. Signed-off-by:Stephen Warren <swarren@nvidia.com> Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Tomasz Figa authored
Handling of irq_chip operations for GPIO and WKUP external interrupts is mostly the same, with the difference being offset of registers. However currently the driver has all the code duplicated for both EINT types, which is undesirable, because changes in irq_chip operations have to be done to both instances of the same code. This patch fixes this by creating exynos_irq_chip struct that has normal irq_chip struct embedded and contain differences between particular EINT types, which are three register offsets. One instance of code is removed and the new structure is used instead to fetch necessary data instead of samsung_pin_ctrl struct used previously. While at it, the patch removes Exynos-specific fields from aforementioned structure to improve layering of the driver. Signed-off-by:
-
Tomasz Figa authored
This patch adds .request() and .free() operations to gpio_chip of pinctrl-samsung driver, which call pinctrl request and free helpers to request and free pinctrl pin along with GPIO pin. Signed-off-by:
-
Tomasz Figa authored
This patch makes the pinctrl-samsung driver configure GPIO direction on its own, without using the pinctrl_gpio_direction_*() "helpers". The rationale behind this change is as follows: - pinctrl-samsung does not need translation from GPIO namespace to pinctrl namespace to handle GPIO operations - GPIO chip and offset therein are enough to calculate necessary offsets and bit masks in constant time, - the pinctrl_gpio_direction_*() functions do not do anything useful other than translating the pin into pinctrl namespace and calling the .gpio_set_direction() from pinmux_ops of the controller, - the undesirable side effect of using those helpers is losing the ability to change GPIO direction in atomic context, because they explicitly use a mutex for synchronization, Results of this patch are: - fixed warnings about scheduling while atomic in code that needs to set GPIO direction in atomic context (e.g. interrupt handler), - reduced overhead of bitbanging drivers that use gpio_direction_*(), e.g. i2c-gpio. Signed-off-by:
-
Sergei Shtylyov authored
Add CAN0/1 data/clock pin groups to R8A7791 PFC driver. Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Acked-by:
-
Eric Ernst authored
For Baytrail, you should never set a GPIO set to direct_irq to output mode. When direct_irq_en is set for a GPIO, it is tied directly to an APIC internally, and making the pad output does not make any sense. Assert a WARN() in the event this happens. Signed-off-by:
Eric Ernst <eric.ernst@linux.intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Rickard Strandqvist authored
Remove variable that are never used This was found using a static code analysis program called cppcheck. Signed-off-by:
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Acked-by:
Patrice Chotard <patrice.chotard@st.com> Signed-off-by:
-
Rickard Strandqvist authored
%d in format string used, but the type is unsigned int This was found using a static code analysis program called cppcheck Signed-off-by:
-
Rickard Strandqvist authored
%d in format string used, but the type is unsigned int This was found using a static code analysis program called cppcheck Signed-off-by:
-
Rickard Strandqvist authored
Remove variable that are never used This was found using a static code analysis program called cppcheck. Signed-off-by:
-
Rickard Strandqvist authored
Remove variable that are never used This was found using a static code analysis program called cppcheck. Signed-off-by:
-
Rickard Strandqvist authored
Remove checking if a unsigned is less than zero This was found using a static code analysis program called cppcheck. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by:
Maxime Coquelin <maxime.coquelin@st.com> Signed-off-by:
-
Rickard Strandqvist authored
Remove checking if a unsigned is less than zero This was found using a static code analysis program called cppcheck. Signed-off-by:
-
Rickard Strandqvist authored
Remove checking if a unsigned is less than zero This was found using a static code analysis program called cppcheck. Signed-off-by:
-
Rickard Strandqvist authored
Remove checking if a unsigned is less than zero This was found using a static code analysis program called cppcheck. Signed-off-by:
-
David PARIS authored
no .irq_set_wake API is available for pinctrl-st driver. Add the IRQCHIP_SKIP_SET_WAKE flag to inform irq handler not to call this API. Signed-off-by:
David Paris <david.paris@st.com> Signed-off-by:
-
Sachin Kamat authored
bcm281xx_pinctrl_probe is local to this file. Make it static. Signed-off-by:
Sachin Kamat <sachin.kamat@samsung.com> Signed-off-by:
-
Andy Gross authored
This patch adds the BUS_HOLD (Keeper) bias option for pins. Signed-off-by:
Andy Gross <agross@codeaurora.org> Acked-by:
-
Chen-Yu Tsai authored
The A23 has a R_PIO pin controller, similar to the one found on the A31 SoC. Add support for the pins controlled by the R_PIO controller. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Chen-Yu Tsai authored
The A23 uses the same pin controller as previous SoC's from Allwinner. Add support for the pins controlled by the main PIO controller. Signed-off-by:
-
Maxime Ripard authored
The PINCTRL_SUNXI configuration was kept only to deal with the introduction of per-machine symbols and the various pintrl drivers through different tree. Now that it's not useful anymore, we can just remove it. Signed-off-by:
-
Chen-Yu Tsai authored
The A13 user manual states pins PG0/1/2 only have GPIO input and interrupt functions. Remove the gpio_out functions for these pins. Signed-off-by:
-
Heiko Stübner authored
The pin-controller of the new RK3288 contains all the quirks just added in the previous patches. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Heiko Stübner authored
On the upcoming RK3288 SoC contain some unrouted pins in their banks. So while for example pin8 of bank5 stays pin8 with all its settings (register offset etc), pins 0 to 7 are not routed outside the SoC at all. Therefore add a flag to mark these unrouted iomuxes to prevent people from using them. Signed-off-by:
-
Heiko Stübner authored
The upcoming rk3288 moves some iomux settings to the pmu register space. Therefore add a flag for this and adapt the mux functions accordingly. Signed-off-by:
-
Heiko Stübner authored
In the upcoming rk3288 SoC some iomux settings are 4bit wide instead of the regular 2bit. Therefore add a flag to mark iomuxes as such and adapt the mux-access as well as the offset calculation accordingly. Signed-off-by:
-
Heiko Stübner authored
An upcoming SoC introduces an interesting quirk to iomux handling making the calculation of the iomux register-offset harder. To keep the complexity down when getting/setting the mux, precalculate the actual register offset at probe-time. Signed-off-by:
-
Heiko Stübner authored
Upcoming Rockchip SoCs have additional quirks to handle. Currently they would be handled by giving the bank a special compatible property. But the nature of the new quirks would require a lot of them. Also as we want to move to the separate dw_gpio driver in the future, these bank-definitions should be extended at all. Describing the bank quirks this way also enables us to deprecate the special bank compatible string for bank0 on rk3188 and simplify the handling code. Signed-off-by:
-
Fan Wu authored
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:
-
Alexander Shiyan authored
Pads for PB0-PB3, PC0-PC4, PE26-PE31 and PF24-PF31 does not exist on the i.MX27 SOC. There is no reason to define them, the presence of such definitions in the DTS files is a bug. This patch removes these nonexistent pad definitions. Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
Alexander Shiyan authored
struct imx27_pinctrl_private is not used in the driver. Remove this definition. Signed-off-by:
-
Alexander Shiyan authored
This patch adds pincontrol driver for Freescale i.MX1 SOCs. Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Chen-Yu Tsai authored
When mapping the interrupts, the gpio_to_irq function did not consider the bank number of the gpio pin in question, only the offset or the interrupt number in the bank. As a result, requests for interrupts in the later banks get mapped to the first bank. This issue was discovered while enabling mmc on the new sun8i platform. The tablet I have uses a pin/interrupt from the second bank to do mmc card detection. Tested on this very device with register inspection and actual mmc card insertion/removal. Signed-off-by:
-
Hans de Goede authored
Some drivers use disable_irq / enable_irq and do the work clearing the source in another thread instead of using a threaded interrupt handler. The irqchip used not having irq_disable and irq_enable callbacks in this case, will lead to unnecessary spurious interrupts: On a disable_irq in a chip without a handler for this, the irq core will remember the disable, but not actually call into the irqchip. With a level triggered interrupt (where the source has not been cleared) this will lead to an immediate retrigger, at which point the irq-core will mask the irq. So having an irq_disable callback in the irqchip will save us the interrupt firing a 2nd time for nothing. Drivers using disable / enable_irq like this, will call enable_irq when they finally have cleared the interrupt source, without an enable_irq callback, this will turn into an unmask, at which point the irq will trigger immediately because when it was originally acked the level was still high, so the ack was a nop. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Hans de Goede authored
For level triggered gpio interrupts we need to use handle_fasteoi_irq, like we do with the irq-sunxi-nmi driver. This is necessary to give threaded interrupt handlers a chance to actuall clear the source of the interrupt (which may involve sleeping waiting for i2c / spi / mmc transfers), before acknowledging the interrupt. Signed-off-by:
-
