- 05 Aug, 2019 31 commits
-
-
Kunihiko Hayashi authored
SD uses the following pins starting from 247: SDCD, SDWP, SDVOLC, SDCLK, SDCMD, SDDAT{0,1,2,3} Signed-off-by:Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Acked-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/1564465410-9165-6-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Kunihiko Hayashi authored
Pro5 PCIe interface uses the following pins: XPERST, XPEWAKE, XPECLKRQ Signed-off-by: -
Kunihiko Hayashi authored
The 5th serial TS interface uses the following pins: hscin4_s: PCA[11-14] Signed-off-by:
-
Kunihiko Hayashi authored
This adds support for pinmux settings of aout1b group. This group includes audio I/O signals derived from xirq pins, and it is equivalent to "aout1" in functionality. Signed-off-by:
-
Kunihiko Hayashi authored
It depends on the board implementation whether to have each pins of CTS/RTS, and others for modem. So it is necessary to divide current uart_ctsrts group into uart_ctsrts and uart_modem groups. Since the number of implemented pins for modem differs depending on SoC, each uart_modem group also has a different number of pins. Signed-off-by:
-
Neil Armstrong authored
Add the missing pinmux for the pwm_a function on the GPIOE_2 pin. Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20190729125838.6498-1-narmstrong@baylibre.comSigned-off-by:
-
Andrew Jeffery authored
Guide readers away from using the aspeed,g[45].* compatible patterns. Signed-off-by:
Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190724081313.12934-4-andrew@aj.id.auReviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Andrew Jeffery authored
Otherwise they look odd in the face of not being listed in the bindings documents. Signed-off-by:
-
Andrew Jeffery authored
The AST2600 pinmux is fairly similar to the previous generations of ASPEED BMC SoCs in terms of architecture, though differ in some of the design details. The complexity of the pin expressions is largely reduced (e.g. there are no-longer signals with multiple expressions muxing them to the associated pin), and there are now signals and buses with multiple pin groups. The driver implements pinmux support for all 244 GPIO-capable pins plus a further four pins that are not GPIO capable but which expose multiple signals. pinconf will be implemented in a follow-up patch. The implementation has been smoke-tested under qemu, and run on hardware by ASPEED. Debugged-by:
Johnny Huang <johnny_huang@aspeedtech.com> Signed-off-by:
-
Andrew Jeffery authored
The complement of SIG_DESC_SET(). Signed-off-by:
-
Andrew Jeffery authored
The AST2400 and AST2500 SoCs only exposed one pin group per function. Lone pin groups drove some implementation simplifications in the ASPEED pinmux infrastructure that is now invalid for the AST2600, which supports multiple groups per function for some functions on the chip (SMBus Alert pins and UARTs among others). This patch reworks the macro jungle to enable support for multiple pin groups. In the process we inflict some collateral damage on the existing AST2400 and AST2500 drivers, but the rework is mostly a relatively straight-forward, automated transform of adding the pin name as an argument to some macro calls and implementing wrappers to paper over groups in the cases where there aren't multiple. As previously documented, the macro infrastructure exposes mux configuration as symbols in the source file which are used to detect accidental duplication. Previously these symbols were named in terms of the signal for a given expression. As the AST2600 supports multiple pin groups for a function, the signal name on its own is no-longer unique, and we must switch to the (signal, group) tuple. However, this means that we can no-longer derive the signal expression symbol name from the signal name alone, which among other cases, impacts the operation of the PIN_DECL_x() macros. To fix that and avoid requiring we awkwardly provide the associated group name for every signal for every PIN_DECL_x() invocation, instead opportunistically alias the name of the signal expression symbol from the unique (signal, group) tuple to the also unique (pin, signal) tuple, then reference the alias symbol in the tables generated by PIN_DECL_x(). This way we do not require extra group parameters for PIN_DECL_x() as the pin name was already provided as an argument, and instead simply require that the pin name be provided to the expression declaration macros in order to generate the alias symbol. The patch implements the alias strategy and fixes up all the expression definition macro calls in the AST2400 and AST2500 drivers to account for pin groups. Given the implementation strategy has the property that compilation either fails or loudly warns for bad pin descriptions, this patch is theoretically tested by successfully compiling both affected drivers. For a more practical test I've inspected the diff of the content of the pinctrl debugfs entries before and after the patch under qemu; all pins, functions and groups match. Signed-off-by:
-
Andrew Jeffery authored
This case is common in the AST2600, so add to the collection. Signed-off-by:
-
Andrew Jeffery authored
Rename macros as follows: * s/SS_PIN_DECL()/PIN_DECL_1()/ * s/MS_PIN_DECL()/PIN_DECL_2()/ * s/MS_PIN_DECL_()/PIN_DECL_()/ This is in preparation for adding PIN_DECL_3(). We could clean this up with e.g. CPPMAGIC_MAP() from ccan, but that might be a bridge too far given how much of a macro jungle we already have. Signed-off-by:
-
Andrew Jeffery authored
The AST260 differs from the 2400 and 2500 in that it supports multiple groups for a subset of functions. Signed-off-by:
-
Icenowy Zheng authored
Introduce the GPIO pins that is only available on V3 (not on V3s) to the V3s pinctrl driver. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://lore.kernel.org/r/20190728031227.49140-2-icenowy@aosc.ioSigned-off-by:
-
Anders Roxell authored
When fall-through warnings was enabled by default the following warnings was starting to show up: ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c: In function ‘pmic_gpio_populate’: ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:815:20: warning: this statement may fall through [-Wimplicit-fallthrough=] pad->have_buffer = true; ~~~~~~~~~~~~~~~~~^~~~~~ ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:816:2: note: here case PMIC_GPIO_SUBTYPE_GPIOC_4CH: ^~~~ ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:820:20: warning: this statement may fall through [-Wimplicit-fallthrough=] pad->have_buffer = true; ~~~~~~~~~~~~~~~~~^~~~~~ ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:821:2: note: here case PMIC_GPIO_SUBTYPE_GPIOC_8CH: ^~~~ Rework so that the compiler doesn't warn about fall-through. Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning") Signed-off-by:Anders Roxell <anders.roxell@linaro.org> Link: https://lore.kernel.org/r/20190726112816.19723-1-anders.roxell@linaro.orgSigned-off-by:
-
Anders Roxell authored
When fall-through warnings was enabled by default the following warning was starting to show up: ../drivers/pinctrl/pinctrl-rockchip.c: In function ‘rockchip_gpio_set_config’: ../drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=] rockchip_gpio_set_debounce(gc, offset, true); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/pinctrl/pinctrl-rockchip.c:2795:2: note: here default: ^~~~~~~ Rework so that the compiler doesn't warn about fall-through. Add 'return -ENOTSUPP;' to match the comment. Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning") Signed-off-by: -
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/pinctrl/pinctrl-oxnas.c: In function oxnas_ox810se_pinconf_set: drivers/pinctrl/pinctrl-oxnas.c:905:6: warning: variable arg set but not used [-Wunused-but-set-variable] drivers/pinctrl/pinctrl-oxnas.c: In function oxnas_ox820_pinconf_set: drivers/pinctrl/pinctrl-oxnas.c:944:6: warning: variable arg set but not used [-Wunused-but-set-variable] It is never used since commit 4b0c0c25 ("pinctrl: oxnas: Add support for OX820"), so can be removed. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190725142419.29892-1-yuehaibing@huawei.comSigned-off-by:
-
Alexandre Torgue authored
According to the following tab (coming from STMFX datasheet), updates have to done in stmfx_pinconf_set function: -"type" has to be set when "bias" is configured as "pull-up or pull-down" -PIN_CONFIG_DRIVE_PUSH_PULL should only be used when gpio is configured as output. There is so no need to check direction. DIR | TYPE | PUPD | MFX GPIO configuration ----|------|------|--------------------------------------------------- 1 | 1 | 1 | OUTPUT open drain with internal pull-up resistor ----|------|------|--------------------------------------------------- 1 | 1 | 0 | OUTPUT open drain with internal pull-down resistor ----|------|------|--------------------------------------------------- 1 | 0 | 0/1 | OUTPUT push pull no pull ----|------|------|--------------------------------------------------- 0 | 1 | 1 | INPUT with internal pull-up resistor ----|------|------|--------------------------------------------------- 0 | 1 | 0 | INPUT with internal pull-down resistor ----|------|------|--------------------------------------------------- 0 | 0 | 1 | INPUT floating ----|------|------|--------------------------------------------------- 0 | 0 | 0 | analog (GPIO not used, default setting) Signed-off-by:
Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/1564053416-32192-1-git-send-email-amelie.delaunay@st.comSigned-off-by:
-
Baolin Wang authored
Since the follow-up pin design on Spreadtrum platform has some changes, some configuration of MISC_PIN moved to COMMON_PIN. To support current pin design and keep backward compatibility, we should combine the condition of MISC_PIN and COMMON_PIN to configure an individual pin. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Link: https://lore.kernel.org/r/17af5e761e0515d288a7ea4078ac9aa4a82a7a4e.1564048446.git.baolin.wang@linaro.orgSigned-off-by:
-
Baolin Wang authored
The devm_platform_ioremap_resource() function wraps platform_get_resource() and devm_ioremap_resource() in a single helper, thus use it to simplify the code. Signed-off-by:
-
Andy Shevchenko authored
Use use device_property_count_uXX() directly, that makes code neater. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190723192738.68486-2-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Use use device_property_count_uXX() directly, that makes code neater. Signed-off-by:
-
Charles Keepax authored
This adds the pinctrl configuration for the CS47L92 codec to the madera pinctrl driver. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20190722091015.20884-3-ckeepax@opensource.cirrus.comSigned-off-by:
-
Richard Fitzgerald authored
This adds the pinctrl configuration for the CS47L15 codec to the madera pinctrl driver. Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by:
-
Charles Keepax authored
A local copy of the pdata exists and it should be used rather than pulling a fresh copy. Signed-off-by:
-
Stefan Wahren authored
The BCM2711 has a new way of selecting the pull-up/pull-down setting for a GPIO pin. The registers used for the BCM2835, GP_PUD and GP_PUDCLKn0, are no longer connected. A new set of registers, GP_GPIO_PUP_PDN_CNTRL_REGx must be used. This commit will add a new compatible string "brcm,bcm2711-gpio" and the kernel driver will use it to select which method is used to select pull-up/pull-down. This patch based on a patch by Al Cooper which was intended for the BCM7211. This is a bugfixed and improved version. Signed-off-by:
Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/1563776607-8368-3-git-send-email-wahrenst@gmx.netSigned-off-by:
-
Stefan Wahren authored
Add a new compatible for the BCM2711. Signed-off-by:
-
Sowjanya Komatineni authored
This patch adds suspend and resume functionality to Tegra210 pinctrl. Signed-off-by:
Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1564607463-28802-3-git-send-email-skomatineni@nvidia.comSigned-off-by:
-
Sowjanya Komatineni authored
This patch adds support for Tegra pinctrl driver suspend and resume. During suspend, context of all pinctrl registers are stored and on resume they are all restored to have all the pinmux and pad configuration for normal operation. Acked-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Masahiro Yamada authored
Add a header include guard just in case. Signed-off-by:
-
- 02 Aug, 2019 1 commit
-
-
YueHaibing authored
Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by:
-
- 29 Jul, 2019 8 commits
-
-
Zhou Yanjie authored
Add support for probing the pinctrl-ingenic driver on the X1500 Soc from Ingenic. Signed-off-by:
Zhou Yanjie <zhouyanjie@zoho.com> Link: https://lore.kernel.org/r/1563076436-5338-7-git-send-email-zhouyanjie@zoho.comSigned-off-by:
-
Zhou Yanjie authored
Add the pinctrl bindings for the X1500 Soc from Ingenic. Signed-off-by:
-
Zhou Yanjie authored
Add support for probing the pinctrl-ingenic driver on the X1000 Soc and the X1000E Soc from Ingenic. Signed-off-by:
-
Zhou Yanjie authored
Add the pinctrl bindings for the X1000 Soc and the X1000E Soc from Ingenic. Signed-off-by:
-
Zhou Yanjie authored
Add support for probing the pinctrl-ingenic driver on the JZ4760 Soc and the JZ4760B Soc from Ingenic. Signed-off-by:
-
Zhou Yanjie authored
Add the pinctrl bindings for the JZ4760 Soc and the JZ4760B Soc from Ingenic. Signed-off-by:
-
Andrew Jeffery authored
Rob pointed out that we didn't need the noise of the quotes in a separate review[1], so strip them out for consistency and avoid setting a bad example. [1] https://lists.ozlabs.org/pipermail/linux-aspeed/2019-July/002009.htmlSigned-off-by:
-
Marc Gonzalez authored
TSIF is the Transport Stream Interface. First, rename tsif1 to tsif0, and tsif2 to tsif1. Then squash all 5 tsif0 pins into a single function. Same for tsif1. Signed-off-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Link: https://lore.kernel.org/r/503b2ae8-ead6-70cd-7b21-ce5f5166a23a@free.frReviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by:
-
