- 11 Jul, 2014 37 commits
-
-
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 <t.figa@samsung.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-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:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-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:
Stephen Warren <swarren@nvidia.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:
-
Hans de Goede authored
With level triggered interrupt mask / unmask will get called for each interrupt, doing the somewhat expensive mux setting on each unmask thus is not a good idea. Instead add a request_resources callback and do it there. Signed-off-by:
-
Chen-Yu Tsai authored
The sunxi pinctrl irq chip driver does not support wakeup at the moment. Adding IRQCHIP_SKIP_SET_WAKE lets the irqs work with drivers using wakeup. Signed-off-by:
-
Nobuhiro Iwamatsu authored
Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Acked-by:
-
Uwe Kleine-König authored
These symbols are supposed to be selected by the drivers actually needing them. The only situation where it would make sense to enable them without a driver selecting them is when an out-of-tree pinctrl driver is used or for compile testing. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
- 19 Jun, 2014 3 commits
-
-
Linus Walleij authored
This switches the SPEAr PLGPIO driver over to using the irqchip helpers. As part of this effort, also get rid of the strange irq_base calculation and failure to use d->hwirq for obtaining a local irqchip offset. Cc: Viresh Kumar <viresh.linux@gmail.com> Cc: Shiraz Hashim <shiraz.linux.kernel@gmail.com> Cc: spear-devel@list.st.com Signed-off-by: -
Maxime Ripard authored
The A23 and A31 support multiple interrupt banks. Support it by adding a linear domain covering all the banks. It's trickier than it should because there's an interrupt per bank, so we have multiple interrupts using the same domain. Signed-off-by:
-
Maxime Ripard authored
The primary pinctrl device has 4 interrupt banks. As usual, to be able to generate interrupts, the pins supporting it need to be muxed to a special function. Declare these functions in the pins array. Signed-off-by:
-
