- 08 Nov, 2016 19 commits
-
-
Heinrich Schuchardt authored
for_each_property_of_node(pins, pp) checks that pp is not NULL. So there is no need to check it inside the loop. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by:
Patrice Chotard <patrice.chotard@st.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Heinrich Schuchardt authored
function is defined as unsigned int. So we need %u to print it. Signed-off-by:
-
Linus Walleij authored
Merge tag 'sh-pfc-for-v4.10-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel pinctrl: sh-pfc: Updates for v4.10 - I2C and DRIF pin groups for R-Car M3-W, - Bug fixes for SDHI2/3 on R-Car M3-W.
-
Linus Walleij authored
Include <linux/gpio/driver.h> rather than <linux/gpio.h> Drop <linux/pinctrl/machine.h>. Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: -
Andrey Smirnov authored
Tested-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by:
-
Andrey Smirnov authored
Tested-by:
-
Andrey Smirnov authored
Althought the function passed as a "handler" during GPIO chip instantiation is not going to ever be called, specifying handle_edge_irq there makes for a rather confusing read, both because no "ack" callback in specified for irqchip and because there's no acking action is necessary. Specify handle_bad_irq instead a make a note of the situation. This commit should be a no-op behaviour wise. Tested-by:
-
Andrey Smirnov authored
Make use of for_each_set_bit macro and reduce boilerplate code. Tested-by:
-
Andrey Smirnov authored
Move actual code that configures oscio pin into a separate function and use it instead of calling sx150x_gpio_set to avoid calling sx150x_pin_is_oscio twice and correctly propagte error code in sx150x_gpio_direction_output. Tested-by:
-
Andrey Smirnov authored
Gpiochip and irqchip aspects of this driver do not access any shared registers on the chip itself and atomicity of various regmap operations is ensured by that API's implementation, so there doesn't seem to be a reason to hold the lock in as many places as it is held now. Tested-by:
-
Andrey Smirnov authored
The difference between 8 and 16 pin GPIO expanders can be accomodated by the means of regmap API without resorting to using driver-specific read/write accessors. This change, IMHO, brings the following benefits: - Replaces driver's idiosyncratic way of dealing with mult-register fields with regmap API, which, hopefuly, makes the code a bit easier for a new reader to understand - Removes various multi-read for-loop register read logic from various places in the code and puts it in a signle place - Removes ad-hoc IRQ register caching code in sx150x_irq_bus_sync_unlock, since that functionality is provided by regmap Besided aforementioned benefits this change also implements necessary RegSense byte swap necessary for SX1503 and SX1506 variants of the chip. Tested-by:
-
Andrey Smirnov authored
To allow for future code simplification Tested-by:
-
Andrey Smirnov authored
For Sx1504/5/6 only SX1506 has RegAdvanced, so put some code in place to account for that. Tested-by:
-
Andrey Smirnov authored
Move the code configuring explicit IRQ acking into a standalone function to declutter sx150x_init_hw a bit and make that code somewhat less repetitious. Tested-by:
-
Andrey Smirnov authored
According to the datasheet for SX1504/5/6, RegAdvanced's "Autoclear NINT" bit that turns the feature when set and disables it when cleared, so writing 0x04 to the register will have the opposite from desirable effect. Tested-by:
-
Andrey Smirnov authored
Tested-by:
-
Andrey Smirnov authored
Signed-off-by:
-
Andrey Smirnov authored
Tested-by:
-
Andrey Smirnov authored
Add proper device specific information to of_device_id table of the driver and add code to match against and fetch said data from it. Signed-off-by:
-
- 07 Nov, 2016 1 commit
-
-
Geert Uytterhoeven authored
Fix off-by-one (row and/or register) errors in links to Peripheral Function Select Register bitfields from GPIO/Peripheral Function Select Register 4 macros for SDHI2 and SDHI3 pins. Based on rev. 0.52E of the R-Car Gen3 User's Manual. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Tested-by:
Simon Horman <horms+renesas@verge.net.au>
-
- 04 Nov, 2016 9 commits
-
-
Michael Scott authored
Initial pinctrl driver for QCOM msm8994 platforms. In order to continue the initial board support for QCOM msm8994/msm8992 presented in patches from Jeremy McNicoll <jeremymc@redhat.com>, let's put a proper pinctrl driver in place. Currently, the DT for these platforms uses the msm8x74 pinctrl driver to enable basic UART. Beyond the first few pins the rest are different enough to justify it's own driver. Note: This driver is also used by QCOM's msm8992 platform as it's TLM block is the same. - Initial formatting and style was taken from the msm8x74 pinctrl driver added by Björn Andersson <bjorn.andersson@linaro.org> - Data was then adjusted per QCOM MSM8994v2 documentation for Top Level Multiplexing - Bindings documentation was based on qcom,msm8996-pinctrl.txt by Joonwoo Park <joonwoop@codeaurora.org> and then modified for msm8994 content Signed-off-by:
Michael Scott <michael.scott@linaro.org> Tested-by:
Jeremy McNicoll <jeremymc@redhat.com> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Paul Gortmaker authored
None of the Kconfigs for any of these drivers are tristate, meaning that they currently are not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the drivers there is no doubt they are builtin-only. All drivers get essentially the same change, so they are handled in batch. Changes are (1) use builtin_platform_driver, (2) use init.h header (3) delete module_exit related code, (4) delete MODULE_DEVICE_TABLE, and (5) delete MODULE_LICENCE/MODULE_AUTHOR and associated tags. 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 do delete the MODULE_LICENSE etc. tags since all that information is already contained at the top of each file in the comments. Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Hongzhou Yang <hongzhou.yang@mediatek.com> Cc: Fabian Frederick <fabf@skynet.be> Cc: Maxime Coquelin <maxime.coquelin@st.com> Cc: Vishnu Patekar <vishnupatekar0510@gmail.com> Cc: Mylene Josserand <mylene.josserand@free-electrons.com> Cc: linux-gpio@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Neil Armstrong authored
Add support for the Amlogic Meson GXL SoC, this is a partially complete definition only based on the Amlogic Vendor tree. This definition differs a lot from the GXBB and needs a separate entry. Acked-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Tony Lindgren authored
We can now use generic parser and keep things compatible with the old binding. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Tony Lindgren authored
We can now use generic parser. To support the legacy binding without #pinctrl-cells, add pcs_quirk_missing_pinctrl_cells() and warn about missing #pinctrl-cells. Let's also update the documentation for struct pcs_soc_data while at it as that seems to be out of date. Signed-off-by:
-
Tony Lindgren authored
Introduce #pinctrl-cells helper binding and generic helper functions pinctrl_count_index_with_args() and pinctrl_parse_index_with_args(). Acked-by:
-
Stefan Wahren authored
Since the BCM2835 datasheet doesn't exactly specify the set-up time for the GPIO Pull-up/down Clock Registers there was an assumption of 150 cycles at a clock rate of 1 MHz. During a discussion [1] in the Raspberry Pi forum it turns out that clock rate refers to the VPU which has a rate of 250 MHz. So we can reduce the delay to a sensible value and update the comment above. I tested this optimization with a Raspberry Pi B and a multimeter. [1] - https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=163352Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Mika Westerberg authored
Printing the prefix does not provide any additional information. In addition this makes the output look more consistent with pinctrl-intel.c. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Jason Gunthorpe authored
The hardware supports a 16 and 8 bit wide NAND bus, let users pick either. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Acked-by:
Sören Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by:
-
- 31 Oct, 2016 1 commit
-
-
Boris BREZILLON authored
Add support for pin output control through the pinctrl config: - support enabling/disabling output on a given pin - support output level setting (high or low) Signed-off-by:
Boris BREZILLON <b.brezillon@overkiz.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Wenyou Yang <wenyou.yang@atmel.com> Signed-off-by:
-
- 29 Oct, 2016 4 commits
-
-
Maxime Ripard authored
Even though the our binding had the assumption that the allwinner,pull and allwinner,drive properties were optional, the code never took that into account. Fix that. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Andy Shevchenko authored
Pin config get() and 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:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Laxman Dewangan authored
During pinmux registration, pinmux table is parsed from DT for making the pinmux table configuration of pins. Parse the only those node whose status is not disabled. This will help on reusing the pin configuration table across platform and disabling the node by status property if that node is not needed on given platform. Signed-off-by:
Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by:
-
Arnd Bergmann authored
Drivers using pinconf_generic_params tables cannot be built with CONFIG_OF disabled: drivers/pinctrl/pinctrl-max77620.c:53:44: error: array type has incomplete element type ‘struct pinconf_generic_params’ drivers/pinctrl/pinctrl-max77620.c:55:3: error: field name not in record or union initializer drivers/pinctrl/pinctrl-max77620.c:55:3: note: (near initialization for ‘max77620_cfg_params’) drivers/pinctrl/pinctrl-max77620.c:56:3: error: field name not in record or union initializer This adds a dependency for max77620 to disallow that configuration. Alternatively, we could rework the pinctrl infrastructure to make the configuration valid for compile-testing. Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Fixes: 453943dc8f45 ("mfd: Enable compile testing for max77620 and max77686") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 28 Oct, 2016 2 commits
-
-
Tony Lindgren authored
This is left over from initial experiments with more properties. It's only used in one place, so let's just get rid of it to make the code more readable. Signed-off-by:
-
Tony Lindgren authored
>From tony Mon Sep 17 00:00:00 2001 From: Tony Lindgren <tony@atomide.com> Date: Tue, 25 Oct 2016 08:33:34 -0700 Subject: [PATCHv2] pinctrl: single: Drop custom names We no longer need to allocate custom names as those are dynamically generated in pinctrl_register_one_pin() if no name is passed to pinctrl_register_pins(). Signed-off-by:
-
- 24 Oct, 2016 4 commits
-
-
Linus Walleij authored
-
Neil Armstrong authored
Since the I2C sx150x GPIO expander driver uses platform_data to manage the pins configurations, rewrite the driver as a pinctrl driver using pinconf to get/set pin configurations from DT or debugfs. The pinctrl driver is functionnally equivalent as the gpio-only driver and can use DT for pinconf. The platform_data confirmation is dropped. This patchset removed the gpio-only driver and selects the Pinctrl driver config instead. This patchset also migrates the gpio dt-bindings to pinctrl and add the pinctrl optional properties. The driver was tested with a SX1509 device on a BeagleBone black with interrupt support and on an X86_64 machine over an I2C to USB converter. This is a fixed version that builds and runs on non-OF platforms and on arm based OF. The GPIO version is removed and the bindings are also moved to the pinctrl bindings. Changes since v2 - rebased on v4.9-rc1 - removed MODULE_DEVICE_TABLE as in upstream bb411e77 ("gpio: sx150x: fix implicit assumption module.h is present") Changes since v1 - Fix Kconfig descriptions on pinctrl and gpio - Fix Kconfig dependency - Remove oscio support for non-789 devices - correct typo in dt bindings - remove probe reset for non-789 devices Changes since RFC - Put #ifdef CONFIG_OF/CONFIG_OF_GPIO to remove OF code for non-of platforms - No more rely on OF_GPIO config - Moved and enhanced bindings to pinctrl bindings - Removed gpio-sx150x.c - Temporary select PINCTRL_SX150X when GPIO_SX150X - Temporary mark GPIO_SX150X as deprecated Signed-off-by:
Peter Rosin <peda@axentia.se> Acked-by:
-
Maxime Ripard authored
The generic pin configuration and multiplexing should be preferred now, even though we still support the old one. Signed-off-by:
-
Maxime Ripard authored
Our bindings are mostly irrelevant now that we have generic pinctrl bindings that cover exactly the same uses cases. Add support for the new ones, and obviously keep our old binding support in order to keep the ABI stable. Acked-by:
-
