summaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpio-mvebu.c
AgeCommit message (Collapse)AuthorFilesLines
2021-02-15gpio: mvebu: add pwm support for Armada 8K/7KBaruch Siach1-33/+68
Use the marvell,pwm-offset DT property to store the location of PWM signal duration registers. Since we have more than two GPIO chips per system, we can't use the alias id to differentiate between them. Use the offset value for that. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-02-15gpio: mvebu: improve handling of pwm zero on/off valuesBaruch Siach1-16/+23
Hardware appears to treat zero value as 2^32. Take advantage of this fact to support on/off values of up to UINT_MAX+1 == 2^32. Adjust both .apply and .get_state to handle zero as a special case. Rounded up division result in .get_state can't be zero, since the dividend is now larger than 0. Remove check for this case. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Analyzed-by: Russell King <linux@armlinux.org.uk> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-02-15gpio: mvebu: don't limit pwm period/duty_cycle to UINT_MAXBaruch Siach1-6/+2
PWM on/off registers are limited to UINT_MAX. However the state period and duty_cycle fields are ns values of type u64. There is no reason to limit them to UINT_MAX. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-02-15gpio: mvebu: make pwm .get_state closer to idempotentBaruch Siach1-2/+2
Round up the divisions in .get_state() to make applying the read out configuration idempotent in most cases as .apply rounds down. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-02-15gpio: mvebu: improve pwm period calculation accuracyBaruch Siach1-2/+2
Change 'off' register value calculation from $off = (period - duty_cycle) * clkrate / NSEC_PER_SEC to $off = (period * clkrate / NSEC_PER_SEC) - $on That is, divide the full period value to reduce rounding error. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-01-19gpio: mvebu: fix pwm .get_state period calculationBaruch Siach1-11/+8
The period is the sum of on and off values. That is, calculate period as ($on + $off) / clkrate instead of $off / clkrate - $on / clkrate that makes no sense. Reported-by: Russell King <linux@armlinux.org.uk> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 757642f9a584e ("gpio: mvebu: Add limited PWM support") Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-12-17Merge tag 'gpio-v5.11-1' of ↵Linus Torvalds1-34/+37
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This is the bulk of the GPIO changes for the v5.11 kernel cycle: Core changes: - Retired the old set-up function for GPIO IRQ chips. All chips now use the template struct gpio_irq_chip and pass that to the core to be set up alongside the gpio_chip. We can finally get rid of the old cruft. - Some refactoring and clean up of the core code. - Support edge event timestamps to be stamped using REALTIME (wall clock) timestamps. We have found solid use cases for this, so we support it. New drivers: - MStar MSC313 GPIO driver. - HiSilicon GPIO driver. Driver improvements: - The PCA953x driver now also supports the NXP PCAL9554B/C chips. - The mockup driver can now be probed from the device tree which is pretty useful for virtual prototyping of devices. - The Rcar driver now supports .get_multiple() - The MXC driver dropped some legacy and became a pure device tree client. - The Exar driver was moved over to the IDA interface for enumerating, and also switched over to using regmap for register access" * tag 'gpio-v5.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (87 commits) MAINTAINERS: Remove reference to non-existing file gpio: hisi: Do not require ACPI for COMPILE_TEST MAINTAINERS: Add maintainer for HiSilicon GPIO driver gpio: gpio-hisi: Add HiSilicon GPIO support gpio: cs5535: Simplify the return expression of cs5535_gpio_probe() gpiolib: irq hooks: fix recursion in gpiochip_irq_unmask dt-bindings: mt7621-gpio: convert bindings to YAML format gpiolib: cdev: Flag invalid GPIOs as used gpio: put virtual gpio device into their own submenu drivers: gpio: amd8111: use SPDX-License-Identifier drivers: gpio: amd8111: prefer dev_err()/dev_info() over raw printk drivers: gpio: bt8xx: prefer dev_err()/dev_warn() over of raw printk gpio: Add TODO item for debugfs interface gpio: just plain warning when nonexisting gpio requested tools: gpio: add option to report wall-clock time to gpio-event-mon tools: gpio: add support for reporting realtime event clock to lsgpio gpiolib: cdev: allow edge event timestamps to be configured as REALTIME gpio: msc313: MStar MSC313 GPIO driver dt-bindings: gpio: Binding for MStar MSC313 GPIO controller dt-bindings: gpio: Add a binding header for the MSC313 GPIO driver ...
2020-12-02gpio: mvebu: switch pwm duration registers to regmapBaruch Siach1-32/+36
Commit 2233bf7a92e ("gpio: mvebu: switch to regmap for register access") changed most readl/writel registers access calls to the regmap API in preparation for Armada 7K/8K support. PWM duration registers were left using readl/writel, as the driver does not support PWM for Armada 7K/8K. Switch PWM duration registers to regmap as first step in adding Armada 7K/8K PWM functionality support. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-12-02gpio: mvebu: update Armada XP per-CPU commentBaruch Siach1-2/+1
Commit 2233bf7a92e ("gpio: mvebu: switch to regmap for register access") introduced percpu_regs to replace percpu_membase. Update the comment to match. Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Fixes: 2233bf7a92e7 ("gpio: mvebu: switch to regmap for register access") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-12-02gpio: mvebu: fix potential user-after-free on probeBaruch Siach1-5/+11
When mvebu_pwm_probe() fails IRQ domain is not released. Move pwm probe before IRQ domain allocation. Add pwm cleanup code to the failure path. Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support") Reported-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-06-20gpio: mvebu: Make use of for_each_requested_gpio()Andy Shevchenko1-6/+2
Make use of for_each_requested_gpio() instead of home grown analogue. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> Cc: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200615150545.87964-4-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-04-24gpio: mvebu: Fix probing for chips without PWMSascha Hauer1-6/+9
The PWM iomem resource is optional and its presence indicates whether the GPIO chip has a PWM or not, which is why mvebu_pwm_probe() returned successfully when the PWM resource was not present. With f51b18d92b66 the driver switched to devm_platform_ioremap_resource_byname() and its error return is propagated to the caller, so now a missing PWM resource leads to a probe error in the driver. To fix this explicitly test for the presence of the PWM resource and return successfully when it's not there. Do this check before the check for the clock is done (which GPIO chips without a PWM do not have). Also move the existing comment why the PWM resource is optional up to the actual check. Fixes: f51b18d92b66 ("gpio: mvebu: use devm_platform_ioremap_resource_byname()") Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-25gpio: mvebu: avoid error message for optional IRQChris Packham1-1/+1
platform_get_irq() will generate an error message if the requested irq is not present mvebu-gpio f1010140.gpio: IRQ index 3 not found use platform_get_irq_optional() to avoid the error message being generated. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-01-23gpio: mvebu: clear irq in edge cause register before unmask edge irqMaxim Kiselev1-0/+1
When input GPIO set from 0 to 1, the interrupt bit asserted in the GPIO Interrupt Cause Register (ICR) even if the corresponding interrupt masked in the GPIO Interrupt Mask Register. Because interrupt mask register only affects assertion of the interrupt bits in Main Interrupt Cause Register and it does not affect the setting of bits in the GPIO ICR. So, there is problem, when we unmask interrupt with already asserted bit in the GPIO ICR, then false interrupt immediately occurs even if GPIO don't change their value since last unmask. Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com> Link: https://lore.kernel.org/r/20200115073811.24438-1-bigunclemax@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-11gpio: mvebu: use platform_irq_countPeng Fan1-2/+5
platform_irq_count() is the more generic way (independent of device trees) to determine the count of available interrupts. So use this instead. As platform_irq_count() might return an error code (which of_irq_count doesn't) some additional handling is necessary. Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2019-11-12Merge remote-tracking branch 'driver-core/driver-core-next' into gpio/for-nextBartosz Golaszewski1-12/+7
2019-11-07gpio: Use new GPIO_LINE_DIRECTIONMatti Vaittinen1-1/+4
It's hard for occasional GPIO code reader/writer to know if values 0/1 equal to IN or OUT. Use defined GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT to help them out. NOTE - for gpio-amd-fch and gpio-bd9571mwv: This commit also changes the return value for direction get to equal 1 for direction INPUT. Prior this commit these drivers might have returned some other positive value but 1 for INPUT. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Scott Branden <scott.branden@broadcom.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-11-05gpio: mvebu: use devm_platform_ioremap_resource_byname()Bartosz Golaszewski1-12/+7
Use devm_platform_ioremap_resource_byname() instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191022084318.22256-8-brgl@bgdev.pl Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-21pwm: Ensure pwm_apply_state() doesn't modify the state argumentUwe Kleine-König1-1/+1
It is surprising for a PWM consumer when the variable holding the requested state is modified by pwm_apply_state(). Consider for example a driver doing: #define PERIOD 5000000 #define DUTY_LITTLE 10 ... struct pwm_state state = { .period = PERIOD, .duty_cycle = DUTY_LITTLE, .polarity = PWM_POLARITY_NORMAL, .enabled = true, }; pwm_apply_state(mypwm, &state); ... state.duty_cycle = PERIOD / 2; pwm_apply_state(mypwm, &state); For sure the second call to pwm_apply_state() should still have state.period = PERIOD and not something the hardware driver chose for a reason that doesn't necessarily apply to the second call. So declare the state argument as a pointer to a const type and adapt all drivers' .apply callbacks. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-07gpio: pass lookup and descriptor flags to request_ownLinus Walleij1-7/+4
When a gpio_chip wants to request a descriptor from itself using gpiochip_request_own_desc() it needs to be able to specify fully how to use the descriptor, notably line inversion semantics. The workaround in the gpiolib.c can be removed and cases (such as SPI CS) where we need at times to request a GPIO with line inversion semantics directly on a chip for workarounds, can be fully supported with this call. Fix up some users of the API that weren't really using the last flag to set up the line as input or output properly but instead just calling direction setting explicitly after requesting the line. Cc: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-04-05drivers: gpio: mvebu: use devm_platform_ioremap_resource()Enrico Weigelt, metux IT consult1-5/+2
Use the new helper that wraps the calls to platform_get_resource() and devm_ioremap_resource() together. Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-01-10gpio: mvebu: implement get_directionBaruch Siach1-0/+11
struct gpio_chip documentation recommends to always implement this callback function. A more concrete motivation is to be able (in combination with GPIOD_ASIS) to detect whether the bootloader has changed the state of a GPIO signal. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-12-28Merge tag 'gpio-v4.21-1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.21 kernel series. Core changes: - Some core changes are already in outside of this pull request as they came through the regulator tree, most notably devm_gpiod_unhinge() that removes devres refcount management from a GPIO descriptor. This is needed in subsystems such as regulators where the regulator core need to take over the reference counting and lifecycle management for a GPIO descriptor. - We dropped devm_gpiochip_remove() and devm_gpio_chip_match() as nothing needs it. We can bring it back if need be. - Add a global TODO so people see where we are going. This helps setting the direction now that we are two GPIO maintainers. - Handle the MMC CD/WP properties in the device tree core. (The bulk of patches activating this code is already merged through the MMC/SD tree.) - Augment gpiochip_request_own_desc() to pass a flag so we as gpiochips can request lines as active low or open drain etc even from ourselves. New drivers: - New driver for Cadence GPIO blocks. - New driver for Atmel SAMA5D2 PIOBU GPIO lines. Driver improvements: - A major refactoring of the PCA953x driver - this driver has been around for ages, and is now modernized to reduce code duplication that has stacked up and is using regmap to read write and cache registers. - Intel drivers are now maintained in a separate tree and start with a round of cleanups and unifications" * tag 'gpio-v4.21-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (99 commits) gpio: sama5d2-piobu: Depend on OF_GPIO gpio: Add Cadence GPIO driver dt-bindings: gpio: Add bindings for Cadence GPIO gpiolib-acpi: remove unused variable 'err', cleans up build warning gpio: mxs: read pin level directly instead of using .get gpio: aspeed: remove duplicated statement gpio: add driver for SAMA5D2 PIOBU pins dt-bindings: arm: atmel: describe SECUMOD usage as a GPIO controller gpio/mmc/of: Respect polarity in the device tree dt-bindings: gpio: rcar: Add r8a774c0 (RZ/G2E) support memory: omap-gpmc: Get the header of the enum ARM: omap1: Fix new user of gpiochip_request_own_desc() gpio: pca953x: Add regmap dependency for PCA953x driver gpio: raspberrypi-exp: decrease refcount on firmware dt node gpiolib: Fix return value of gpio_to_desc() stub if !GPIOLIB gpio: pca953x: Restore registers after suspend/resume cycle gpio: pca953x: Zap single use of pca953x_read_single() gpio: pca953x: Zap ad-hoc reg_output cache gpio: pca953x: Zap ad-hoc reg_direction cache gpio: pca953x: Perform basic regmap conversion ...
2018-12-21gpio: mvebu: only fail on missing clk if pwm is actually to be usedUwe Kleine-König1-3/+3
The gpio IP on Armada 370 at offset 0x18180 has neither a clk nor pwm registers. So there is no need for a clk as the pwm isn't used anyhow. So only check for the clk in the presence of the pwm registers. This fixes a failure to probe the gpio driver for the above mentioned gpio device. Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-12-14gpio: Pass a flag to gpiochip_request_own_desc()Linus Walleij1-1/+1
Before things go out of hand, make it possible to pass flags when requesting "own" descriptors from a gpio_chip. This is necessary if the chip wants to request a GPIO with active low semantics, for example. Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Roger Quadros <rogerq@ti.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-05-16gpio: mvebu: Use the proper APIsLinus Walleij1-12/+8
The MVEBU driver is requesting GPIO descriptors from itself, which is fine, but we have proper APIs to do this in a controlled way, so stop calling into the private functions of the GPIO library and use the gpiochip_* functions instead. Only include <linux/gpio/driver.h> and <linux/gpio/consumer.h> since we are both producers and consumers in this case. Cc: Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-08-14gpio: mvebu: Fix cause computation in irq handlerGregory CLEMENT1-1/+1
When switching to regmap, the way to compute the irq cause was reorganized. However while doing it, a typo was introduced: a 'xor' replaced a 'and'. This lead to wrong behavior in the interrupt handler ans one of the symptom was wrong irq handler called on the Armada 388 GP: "->handle_irq(): c016303c, handle_bad_irq+0x0/0x278 ->irq_data.chip(): c0b0ec0c, 0xc0b0ec0c ->action(): (null) IRQ_NOPROBE set IRQ_NOREQUEST set unexpected IRQ trap at vector 00 irq 0, desc: ee804800, depth: 1, count: 0, unhandled: 0" Fixes: 2233bf7a92e7 ("gpio: mvebu: switch to regmap for register access") Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-07-07Merge tag 'gpio-v4.13-1' of ↵Linus Torvalds1-208/+332
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.13 series. Some administrativa: I have a slew of 8250 serial patches and the new IOT2040 serial+GPIO driver coming in through this tree, along with a whole bunch of Exar 8250 fixes. These are ACKed by Greg and also hit drivers/platform/* where they are ACKed by Andy Shevchenko. Speaking about drivers/platform/* there is also a bunch of ACPI stuff coming through that route, again ACKed by Andy. The MCP23S08 changes are coming in here as well. You already have the commits in your tree, so this is just a result of sharing an immutable branch between pin control and GPIO. Core: - Export add/remove for lookup tables so that modules can export GPIO descriptor tables. - Handle GPIO sleep states: it is now possible to flag that a GPIO line may loose its state during suspend/resume of the system to save power. This is used in the Wolfson Micro Arizona driver. - ACPI-based GPIO was tightened up a lot around the edges. - Use bitmap_fill() to speed up a loop. New drivers: - Exar XRA1403 SPI-based GPIO. - MVEBU driver now supports Armada 7K and 8K. - LP87565 PMIC GPIO. - Renesas R-CAR R8A7743 (RZ/G1M). - The new IOT2040 8250 serial/GPIO also comes in through this changeset. Substantial driver changes: - Seriously fix the Exar 8250 GPIO portions to work. - The MCP23S08 was moved out to a pin control driver. - Convert MEVEBU to use regmap for register access. - Drop Vulcan support from the Broadcom driver. - Serious cleanup and improvement of the mockup driver, giving us a better test coverage. Misc: - Lots of janitorial clean up. - A bunch of documentation fixes" * tag 'gpio-v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (70 commits) serial: exar: Add support for IOT2040 device gpio-exar/8250-exar: Make set of exported GPIOs configurable platform: Accept const properties serial: exar: Factor out platform hooks gpio-exar/8250-exar: Rearrange gpiochip parenthood gpio: exar: Fix iomap request gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards serial: uapi: Add support for bus termination gpio: rcar: Add R8A7743 (RZ/G1M) support gpio: gpio-wcove: Fix GPIO control register offset calculation gpio: lp87565: Add support for GPIO gpio: dwapb: fix missing first irq for edgeboth irq type MAINTAINERS: Take maintainership for GPIO ACPI support gpio: exar: Fix reading of directions and values gpio: exar: Allocate resources on behalf of the platform device gpio-exar/8250-exar: Fix passing in of parent PCI device gpio: mockup: use devm_kcalloc() where applicable gpio: mockup: add myself as author gpio: mockup: improve the error message gpio: mockup: don't return magic numbers from probe() ...
2017-06-20gpio: mvebu: change compatible string for PWM supportRalph Sennhauser1-3/+3
As it turns out more than just Armada 370 and XP support using GPIO lines as PWM lines. For example the Armada 38x family has the same hardware support. As such "marvell,armada-370-xp-gpio" for the compatible string is a misnomer. Change the compatible string to "marvell,armada-370-gpio" before the driver makes it out of the -rc stage. This also follows the practice of using only the first device family supported as part of the name. Also update the documentation and comments in the code accordingly. Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support") Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-06-16gpio: mvebu: Add support for the Armada 7K/8K SoCsGregory CLEMENT1-71/+141
The Armada 7K and 8K SoCs use the same gpio controller as most of the other mvebu SoCs. However, the main difference is that the GPIO controller is part of a bigger system controller, and a syscon is used to control the overall system controller. Therefore, the driver needs to be adjusted to retrieve the regmap of the syscon to access registers, and account for the fact that registers are located at a certain offset within the regmap. This commit add the support of the syscon and introduce a new variant for this case. It was based on the preliminary work of Thomas Petazzoni. Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-06-16gpio: mvebu: fix regmap_update_bits usageGregory CLEMENT1-2/+2
In some place in the driver regmap_update_bits was misused. Indeed the last argument is not the value of the bit (or group of bits) itself but the mask value inside the register. So when setting the bit N, then the value must be BIT(N) and not 1. CC: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Tested-by: Chris Packham <Chris.Packham@alliedtelesis.co.nz> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-06-09gpio: mvebu: fix gpio bank registration when pwm is usedRichard Genoud1-0/+7
If more than one gpio bank has the "pwm" property, only one will be registered successfully, all the others will fail with: mvebu-gpio: probe of f1018140.gpio failed with error -17 That's because in alloc_pwms(), the chip->base (aka "int pwm"), was not set (thus, ==0) ; and 0 is a meaningful start value in alloc_pwm(). What was intended is mvpwm->chip->base = -1. Like that, the numbering will be done auto-magically Moreover, as the region might be already occupied by another pwm, we shouldn't force: mvpwm->chip->base = 0 nor mvpwm->chip->base = id * MVEBU_MAX_GPIO_PER_BANK; Tested on clearfog-pro (Marvell 88F6828) Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support") Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-06-09gpio: mvebu: fix blink counter register selectionRichard Genoud1-1/+1
The blink counter A was always selected because 0 was forced in the blink select counter register. The variable 'set' was obviously there to be used as the register value, selecting the B counter when id==1 and A counter when id==0. Tested on clearfog-pro (Marvell 88F6828) Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support") Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-05-23gpio: mvebu: switch to regmap for register accessThomas Petazzoni1-191/+245
In order to be able to use this driver with the Armada 7K/8K SoCs, we need to use the regmap to access the registers. Indeed for these new SoCs, the gpio node will be part of a syscon. [gregory.clement@free-electrons.com: - fixed merge conflcit from 4.10 to 4.12-rc1 - added a commit log] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-05-23gpio: mvebu: sort header includeGregory CLEMENT1-8/+8
This commit sorts alphabetically the header files. Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-24gpio: mvebu: Add limited PWM supportAndrew Lunn1-12/+315
Armada 370/XP devices can 'blink' GPIO lines with a configurable on and off period. This can be modelled as a PWM. However, there are only two sets of PWM configuration registers for all the GPIO lines. This driver simply allows a single GPIO line per GPIO chip of 32 lines to be used as a PWM. Attempts to use more return EBUSY. Due to the interleaving of registers it is not simple to separate the PWM driver from the GPIO driver. Thus the GPIO driver has been extended with a PWM driver. Signed-off-by: Andrew Lunn <andrew@lunn.ch> URL: https://patchwork.ozlabs.org/patch/427287/ URL: https://patchwork.ozlabs.org/patch/427295/ [Ralph Sennhauser: * Port forward * Merge PWM portion into gpio-mvebu.c * Switch to atomic PWM API * Add new compatible string marvell,armada-370-xp-gpio * Update and merge documentation patch * Update MAINTAINERS] Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-03-23gpio: mvebu: use BIT macro instead of bit shiftingRalph Sennhauser1-16/+17
Use the BIT macro instead of explicitly shifting bits for some added clarity. Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-03-16gpio: mvebu: let the compiler inlineRalph Sennhauser1-11/+7
A modern compiler should know better when to inline, so drop the inline keywords. Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-03-16gpio: mvebu: extra whitespace fixesRalph Sennhauser1-7/+6
Fix whitespace errors missed by checkpatch. Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-03-16gpio: mvebu: checkpatch: whitespace fixesRalph Sennhauser1-0/+1
Fix whitespace errors reported by checkpatch. Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-03-16gpio: mvebu: checkpatch: unsigned int fixesRalph Sennhauser1-6/+7
Use unsigned int instead of plain unsigned as reported by checkpatch. Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-03-16gpio: mvebu: start multiline block comments with blank lineRalph Sennhauser1-2/+4
While this isn't an issue according to checkpatch two styles are used. Add a blank line to the block comments missing a blank line at the start so multiline block comments look the same across the file. Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-03-16gpio: mvebu: checkpatch: block comment fixesRalph Sennhauser1-8/+16
Fix issues in block comments reported by checkpatch. Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-11gpio: mvebu: fix warning when building on 64-bitRussell King1-1/+1
Casting a pointer to an int is not portable, and provokes a compiler warning. Cast to unsigned long instead to avoid the warning. drivers/gpio/gpio-mvebu.c: In function 'mvebu_gpio_probe': drivers/gpio/gpio-mvebu.c:662:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] soc_variant = (int) match->data; ^ This will be needed when building gpio-mvebu for Armada 7k/8k ARM64 SoCs. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-11-01gpio/mvebu: Use irq_domain_add_linearJason Gunthorpe1-49/+43
This fixes the irq allocation in this driver to not print: irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated Which happens because the driver already called irq_alloc_descs() and so the change to use irq_domain_add_simple resulted in calling irq_alloc_descs() twice. Modernize the irq allocation in this driver to use the irq_domain_add_linear flow directly and eliminate the use of irq_domain_add_simple/legacy Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()") Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-03-31gpio: mvebu: make explicitly non-modularPaul Gortmaker1-3/+2
The Kconfig currently controlling compilation of this code is: drivers/gpio/Kconfig:config GPIO_MVEBU drivers/gpio/Kconfig: def_bool y ...meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the driver there is no doubt it is builtin-only. 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. Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-gpio@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-23gpio: mvebu: Use devm_gpiochip_add_data() for gpio registrationLaxman Dewangan1-8/+3
Use devm_gpiochip_add_data() for GPIO registration and clean the error path. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
2016-01-05gpio: mvebu: use gpiochip data pointerLinus Walleij1-15/+8
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-11-19gpio: change member .dev to .parentLinus Walleij1-1/+1
The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Alek Du <alek.du@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-16gpio: replace trivial implementations of request/free with generic oneJonas Gorski1-12/+2
Replace all trivial request/free callbacks that do nothing but call into pinctrl code with the generic versions. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: James Hogan <james.hogan@imgtec.com> Acked-by: Stefan Agner <stefan@agner.ch> Acked-by: Joachim Eastwood <manabian@gmail.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-13 11:37:11 +0000