- 20 Dec, 2017 12 commits
-
-
Tony Lindgren authored
Pinctrl single should just show how many pins were found, the physical address is already in the dev information. So let's remove the wrong information that claims to show the physical address but really prints a virtual address that is now hashed. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Merge tag 'sh-pfc-for-v4.16-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel pinctrl: sh-pfc: Updates for v4.16 - Add CAN pin groups on RZ/G1E, - Add CAN and CAN FD pin groups on R-Car H3 ES2.0, and R-Car D3, - Add support for the new R-Car V3M SoC, - Add support for I2C on R-Car D3, - Small fixes and cleanups.
-
Quentin Schulz authored
This fixes some compilation issues. GENERIC_PINCONF and OF at least for pinconf_generic_dt_*, PINMUX at least for pinmux_ops and GPIOLIB for at least gpio_chip. Fixes: 23f75d7d ("pinctrl: axp209: add pinctrl features") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Quentin Schulz <quentin.schulz@free-electrons.com> Acked-by:
-
Quentin Schulz authored
The number of GPIOs is gotten from a field within the structure referenced in the of_device.data but it was actually read before it was retrieved, thus it was dereferencing a null pointer. Set the number of GPIOs after retrieving of_device.data. Fixes: e1190083 ("pinctrl: axp209: add support for AXP813 GPIOs") Signed-off-by:
Mylène Josserand <mylene.josserand@free-electrons.com> Tested-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Brian Norris authored
We generally leave the GPIO clock disabled, unless an interrupt is requested or we're accessing IO registers. We forgot to do this for the ->get_direction() callback, which means we can sometimes [1] get incorrect results [2] from, e.g., /sys/kernel/debug/gpio. Enable the clock, so we get the right results! [1] Sometimes, because many systems have 1 or mor interrupt requested on each GPIO bank, so they always leave their clock on. [2] Incorrect, meaning the register returns 0, and so we interpret that as "input". Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Sean Wang authored
I work for MediaTek on maintaining the existing MediaTek SoC whose target to home gateway such as MT7622 and MT7623 that is reusing MT2701 related files and will keep adding support for the following such kinds of SoCs in the future. Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Reviewed-by:
Biao Huang <biao.huang@mediatek.com> Signed-off-by:
-
Sean Wang authored
Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has the registers for pinctrl, pinconf and gpio mixed up in the same register range. However, the IO core for the MT7622 SoC is completely distinct from anyone of previous MediaTek SoCs which already had support, such as the hardware internal, register address map and register detailed definition for each pin. Therefore, instead, the driver is being newly implemented by reusing generic methods provided from the core layer with GENERIC_PINCONF, GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code simplicity and rid of superfluous code. Where the function of pins determined by groups is utilized in this driver which can help developers less confused with what combinations of pins effective on the SoC and even reducing the mistakes during the integration of those relevant boards. As the gpio_chip handling is also only a few lines, the driver also implements the gpio functionality directly through GPIOLIB. Signed-off-by:
-
Sean Wang authored
Since lots of MediaTek drivers had been added, it seems slightly better for that adding cleanup for placing MediaTek pinctrl drivers under the independent menu as other kinds of drivers usually was done. Signed-off-by:
-
Sean Wang authored
Add devicetree bindings for MediaTek MT7622 pinctrl driver. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Ludovic Barre authored
This driver consists of 2 controllers due to a hole in mapping: -1 controller for GPIO bankA to K. -1 controller for GPIO bankZ. Signed-off-by:
Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Reviewed-by:
-
Ludovic Barre authored
This adds a list of supported STM32 SoC bindings. Signed-off-by:
Gwenael Treuveur <gwenael.treuveur@st.com> Signed-off-by:
-
Florian Fainelli authored
In case a platform only defaults a "default" set of pins, but not a "sleep" set of pins, and this particular platform suspends and resumes in a way that the pin states are not preserved by the hardware, when we resume, we would call pinctrl_single_resume() -> pinctrl_force_default() -> pinctrl_select_state() and the first thing we do is check that the pins state is the same as before, and do nothing. In order to fix this, decouple the actual state change from pinctrl_select_state() and move it pinctrl_commit_state(), while keeping the p->state == state check in pinctrl_select_state() not to change the caller assumptions. pinctrl_force_sleep() and pinctrl_force_default() are updated to bypass the state check by calling pinctrl_commit_state(). [Linus Walleij] The forced pin control states are currently only used in some pin controller drivers that grab their own reference to their own pins. This is equal to the pin control hogs: pins taken by pin control devices since there are no corresponding device in the Linux device hierarchy, such as memory controller lines or unused GPIO lines, or GPIO lines that are used orthogonally from the GPIO subsystem but pincontrol-wise managed as hogs (non-strict mode, allowing simultaneous use by GPIO and pin control). For this case forcing the state from the drivers' suspend()/resume() callbacks makes sense and should semantically match the name of the function. Fixes: 6e5e959d ("pinctrl: API changes to support multiple states per device") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
- 13 Dec, 2017 2 commits
-
-
Alexandre Torgue authored
Add missing copyright and add SPDX identifier. Signed-off-by:
-
Alexandre Belloni authored
Add the documentation for the Microsemi Ocelot pinmuxing and gpio controller. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
-
- 12 Dec, 2017 1 commit
-
-
Yixun Lan authored
According to datasheet, we should use numbers for the pin naming instead of letters. The patch here try to fix this to keep the consistency. This patch should not bring any functional change. Fixes: 83c56680 ("pinctrl: meson-axg: Add new pinctrl driver for Meson AXG SoC") Suggested-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
Yixun Lan <yixun.lan@amlogic.com> Acked-by:
-
- 07 Dec, 2017 11 commits
-
-
Linus Walleij authored
-
Quentin Schulz authored
The AXP813 has only two GPIOs. GPIO0 can either be used as a GPIO, an LDO regulator or an ADC. GPIO1 can be used either as a GPIO or an LDO regulator. Moreover, the status bit of the GPIOs when in input mode is not offset by 4 unlike the AXP209. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
-
Quentin Schulz authored
To prepare for patches that will add support for a new PMIC that has a different GPIO adc muxing value, add an adc_mux within axp20x_pctl structure and use it. Signed-off-by:
-
Quentin Schulz authored
To prepare for patches that will add support for a new PMIC that has a different GPIO input status register, add a gpio_status_offset within axp20x_pctl structure and use it. Signed-off-by:
-
Quentin Schulz authored
This driver used to do only GPIO features of the GPIOs in X-Powers AXP20X. Now that we have migrated everything to the pinctrl subsystem and added pinctrl features, rename everything related to pinctrl from gpio to pctl to ease the understanding of differences between GPIO and pinctrl features. Signed-off-by:
-
Quentin Schulz authored
The X-Powers AXP209 has 3 GPIOs. GPIO0/1 can each act either as a GPIO, an ADC or a LDO regulator. GPIO2 can only act as a GPIO. This adds the pinctrl features to the driver so GPIO0/1 can be used as ADC or LDO regulator. Signed-off-by:
-
Quentin Schulz authored
The X-Powers AXP209 has 3 GPIOs. GPIO0/1 can each act either as a GPIO, an ADC or a LDO regulator. GPIO2 can only act as a GPIO. This adds the pinctrl features to the driver so GPIO0/1 can be used as ADC or LDO regulator. Signed-off-by:
-
Quentin Schulz authored
To prepare the driver for the upcoming pinctrl features, move the GPIO driver AXP209 from GPIO to pinctrl subsystem. Signed-off-by:
-
Quentin Schulz authored
Checkpatch complains with the following message: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' Let's make it happy by switching over to unsigned int. Signed-off-by:
-
Colin Ian King authored
In the (unlikely) event that community->ngpps is zero, or if every gpp->gpio_base is less than zero, then an ininitialized value in ret is returned by function intel_gpio_add_pin_ranges. Fix this by ensuring ret is initialized to zero. It's a moot point, but I think it is worthwhile ensuring this corner case is fixed. Detected by CoverityScan, CID#1462415 ("Uninitialized scalar variable") Fixes: a60eac32 ("pinctrl: intel: Allow custom GPIO base for pad groups") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Linus Walleij authored
The Gemini pin controller can set drive strength for a few select groups of pins (not individually). Implement this for GMAC0 and 1 (ethernet ports), IDE and PCI. Cc: devicetree@vger.kernel.org Reviewed-by:
-
- 05 Dec, 2017 12 commits
-
-
Ulrich Hecht authored
This patch adds CAN FD[0-1] pinmux support to the r8a77995 SoC. Signed-off-by:
Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be>
-
Ulrich Hecht authored
This patch adds CAN[0-1] pinmux support to the r8a77995 SoC. Signed-off-by:
-
Takeshi Kihara authored
This patch renames the pin function macro definitions of the GPSR5 and IPSR{0,3,5,6,12} registers value for the RTS{0,1,3,4}# pin. This is a correction because GPSR and IPSR register specification for R8A7796 SoC was changed in R-Car Gen3 Hardware User's Manual Rev.0.54E. Signed-off-by:Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by:
-
Takeshi Kihara authored
This patch renames the pin function macro definitions of the GPSR and IPSR registers value for the RTS{0,1,3,4}# pin. This is a correction because GPSR and IPSR register specification for R8A7795 ES2.0 SoC was changed in R-Car Gen3 Hardware User's Manual Rev.0.54E. Signed-off-by: -
Takeshi Kihara authored
This patch fixes the macro definitions of A20..A25 pins function deleted. This is a correction because IPSR register specification for R8A7796 SoC was changed in R-Car Gen3 Hardware User's Manual Rev.0.53E. Fixes: f9aece73 ("pinctrl: sh-pfc: Initial R8A7796 PFC support") Signed-off-by:
-
Takeshi Kihara authored
This patch fixes the macro definitions of A20..A25 pins function deleted. This is a correction because IPSR register specification for R8A7795 ES2.0 SoC was changed in R-Car Gen3 Hardware User's Manual Rev.0.53E. Fixes: b205914c ("pinctrl: sh-pfc: r8a7795: Add support for R-Car H3 ES2.0") Signed-off-by:
-
Takeshi Kihara authored
This patch fixes the implementation incorrect of MOD_SEL1 bit[25:24] value when STP_ISEN_1_D pin function is selected for IPSR16 bit[27:24]. This is a correction to the incorrect implementation of MOD_SEL register pin assignment for R8A7795 SoC specification of R-Car Gen3 Hardware User's Manual Rev.0.51E. Fixes: 0b0ffc96 ("pinctrl: sh-pfc: Initial R8A7795 PFC support) Signed-off-by:
-
Takeshi Kihara authored
This patch supports GP-1-28 port pin of R8A7795 ES2.0 SoC added in Rev.0.54E of the R-Car Gen3 Hardware User's Manual or later version. Signed-off-by:
-
Ulrich Hecht authored
Required for I2C0 operation. Signed-off-by:
-
Fabrizio Castro authored
This patch adds can_clk function to r8a7743/r8a7791 which is cleaner, and allows for independent configuration. We keep the can_clk* pins definitions from within can0_groups and can1_groups for uniformity and backwards compatibility. Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com> Signed-off-by:
-
Fabrizio Castro authored
This patch adds can_clk function to r8a7745/r8a7794 which is cleaner, and allows for independent configuration. We keep the can_clk* pins definitions from within can0_groups and can1_groups for uniformity and backwards compatibility. Signed-off-by:
-
Sergei Shtylyov authored
Add the PFC support for the R8A77970 SoC including pin groups for some on-chip devices such as CAN-FD, [H]SCIF, I2C, INTC-EX, MMC, MSIOF, PWM, VIN... Based on the original (and large) patch by Daisuke Matsushita <daisuke.matsushita.ns@hitachi.com>. Signed-off-by:
Vladimir Barinov <vladimir.barinov@cogentembedded.com> Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Acked-by:
-
- 02 Dec, 2017 2 commits
-
-
Masahiro Yamada authored
The driver has been in the tree for a while, but its binding document is missing. Hence, here it is. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
-
Benjamin Gaignard authored
Uniformize STMicroelectronics copyrights header Add SPDX identifier Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by:
Maxime Coquelin <mcoquelin.stm32@gmail.com> Signed-off-by:
-
