IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
To be crystal clear on what the arguments mean in this
funtion dealing with both GPIO and PIN ranges with confusing
naming, we now have gpio_offset and pin_offset and we are
on the clear that these are offsets into the specific GPIO
and pin controller respectively. The GPIO chip itself will
of course keep track of the base offset into the global
GPIO number space.
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If we try to create a range for a certain GPIO chip and the
target pin controller is not yet available it may return
a probe deferral error code, so handle this all the way
our by checking the error code.
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Rename the function find_pinctrl_and_add_gpio_range()
to pinctrl_find_and_add_gpio_range() so as to be consistent
with the rest of the functions.
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76
it is not always enough to specify all the pins of a gpio_chip
from offset zero to be added to a pin map range, since the
mapping from GPIO to pin controller may not be linear at all,
but need to be broken into a few consecutive sub-ranges or
1-pin entries for complicated cases. The ranges may also be
sparse.
This alters the signature of the function to accept offsets
into both the GPIO-chip local pinspace and the pin controller
local pinspace.
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This adds the mfd cell to use the gpio a and gpio b part
of the Nano River Technologies viperboard.
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Convert to the new da9052 interrupt functions, so that we can get rid of
irq_base references.
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
SPEAr platform provides a provision to control chipselects of ARM PL022
Prime Cell spi controller through its system registers, which otherwise
remains under PL022 control which some protocols do not want.
This commit intends to provide the spi chipselect control in software over
gpiolib interface. spi chip drivers can use the exported gpiolib interface to
define their chipselect through DT or platform data.
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
Reviewed-by: Vipin Kumar <vipin.kumar@st.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The driver has both SPI and I2C pieces. The appropriate pieces are built based
on whether SPI and/or I2C is/are enabled. However, it was only checking if I2C
was built-in, never if it was built as a module. This patch checks for either
since building both this driver and I2C as modules is possible.
Signed-off-by: Daniel M. Weeks <dan@danweeks.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The driver accesses the of_node field of struct gpio_chip, which is only
available if OF_GPIO is selected. This solves a build issue on SPARC
which conflicts with OF_GPIO and therefore does not provide this field.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The plat-orion GPIO driver would disable any pin blinking whenever
using a pin for output. Do the same here, as a blinking LED will
continue to blink regardless of what the GPIO pin level is.
Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For probing via device tree, we need to support the case without platform_data.
In this case, chip.base is set to -1 for automatic numbering.
Signed-off-by: Roland Stigge <stigge@antcom.de>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Avoid using the TWL4030_MODULE_PWMA/B as module ID. The LEDEN, PWMA ON/OFF
and PWMB ON/OFF registers are in a continuous range starting from LED base.
This is going to be helpful for further cleanup in the twl stack.
No functional changes.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Read the output value when gpio is set for the output mode for
gpio_get_value(). Reading input value in direction out does not
give correct value.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Even though the device tree binding code was already written, the
compatible strings were not yet in the driver.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The PCA953x used to register no IRQ domain, which made it impossible to
use it as an interrupt-parent from the device tree.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
PXA95x isn't widely used. And it adds the effort on supporting
multiple platform. So remove it.
The assumption is that nobody will miss this support. If you are
reading this text because you actually require pxa95x support on
a new kernel, we can work out a way to revert this patch or add
support to the mmp platform.
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The TPS6586x adds the interrupt of this device using
linear mapping on irq domain.
Hence, implement gpio_to_irq to get the irq number
corresponding to TPS6586x GPIOs which is created
dynamically.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.
So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.
This is done by:
- Adding a return code to gpiochip_add_pin_range() so we can
reliably check whether this succeeds.
- Get rid of the custom of_pinctrl_add_gpio_range() from
pinctrl. Instead create of_pinctrl_get() to just retrive the
pin controller per se from an OF node. This composite
function was just begging to be deleted, it was way to
purpose-specific.
- Use pinctrl_dev_get_name() to get the name of the retrieved
pin controller and use that to call back into the generic
gpiochip_add_pin_range().
Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This makes us call gpiochio_remove_pin_ranges() in the
gpiochip_remove() function, so we get rid of ranges when
freeing the chip.
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"
Introduced both of_gpiochip_remove_pin_range() and
gpiochip_remove_pin_ranges(). But the contents are exactly
the same so remove the OF one and rely on the range deletion
in the core.
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"
Declared the of_gpiochip_[add|remove]_pin_range() global
while they should be static as they are only ever used in
this file. Let's convert them to static.
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"
Got most of it's function prototypes wrong, so fix this up by:
- Moving the void declarations into static inlines in
<linux/gpio.h> (previously the actual prototypes were declared
here...)
- Declare the gpiochip_add_pin_range() and
gpiochip_remove_pin_ranges() functions in <asm-generic/gpio.h>
together with the pin range struct declaration itself.
- Actually only implement these very functions in gpiolib.c
if CONFIG_PINCTRL is set.
- Additionally export the symbols since modules will need to
be able to do this.
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl subsystem needs gpio chip base to prepare set of gpio
pin ranges, which a given pinctrl driver can handle. This is
important to handle pinctrl gpio request calls in order to
program a given pin properly for gpio operation.
As gpio base is allocated dynamically during gpiochip
registration, presently there exists no clean way to pass this
information to the pinctrl subsystem.
After few discussions from [1], it was concluded that may be
gpio controller reporting the pin range it supports, is a
better way than pinctrl subsystem directly registering it.
[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
[Edited documentation a bit]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull sparc fixes from David Miller:
"Several build/bug fixes for sparc, including:
1) Configuring a mix of static vs. modular sparc64 crypto modules
didn't work, remove an ill-conceived attempt to only have to build
the device match table for these drivers once to fix the problem.
Reported by Meelis Roos.
2) Make the montgomery multiple/square and mpmul instructions actually
usable in 32-bit tasks. Essentially this involves providing 32-bit
userspace with a way to use a 64-bit stack when it needs to.
3) Our sparc64 atomic backoffs don't yield cpu strands properly on
Niagara chips. Use pause instruction when available to achieve
this, otherwise use a benign instruction we know blocks the strand
for some time.
4) Wire up kcmp
5) Fix the build of various drivers by removing the unnecessary
blocking of OF_GPIO when SPARC.
6) Fix unintended regression wherein of_address_to_resource stopped
being provided. Fix from Andreas Larsson.
7) Fix NULL dereference in leon_handle_ext_irq(), also from Andreas
Larsson."
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Fix build with mix of modular vs. non-modular crypto drivers.
sparc: Support atomic64_dec_if_positive properly.
of/address: sparc: Declare of_address_to_resource() as an extern function for sparc again
sparc32, leon: Check for existent irq_map entry in leon_handle_ext_irq
sparc: Add sparc support for platform_get_irq()
sparc: Allow OF_GPIO on sparc.
qlogicpti: Fix build warning.
sparc: Wire up sys_kcmp.
sparc64: Improvde documentation and readability of atomic backoff code.
sparc64: Use pause instruction when available.
sparc64: Fix cpu strand yielding.
sparc64: Make montmul/montsqr/mpmul usable in 32-bit threads.
We call pinctrl_request_gpio() in request callback, thus we need to call
pinctrl_free_gpio() in free callback.
Both mvebu_gpio_request() and mvebu_gpio_free() are not referenced outside of
this file, make them static.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Both tegra_gpio_enable() and tegra_gpio_disable() are static functions, it does
not make sense to export them.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Both tegra_gpio_request() and tegra_gpio_free() are not referenced outside of
this file, make them static.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Following are changes done to fix the suspend/resume
functionality of tegra gpio driver:
- Protect suspend/resume callbacks with CONFIG_PM_SLEEP
because CONFIG_PM doesn't actually enable any of the PM callbacks, it
only allows to enable CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME.
This means if CONFIG_PM is used to protect system sleep callbacks
then it may end up unreferenced if only runtime PM is enabled.
- Fix the suspend/resume APIs declaration as per callback prototype.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch uses pr_* instead of printk. Also, gpio_dbg
is replaced with pr_debug.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by/Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch modifies the Samsung GPIO driver to check for pinctrl driver
presence earlier and use generic matching instead of a single compatible
value.
This allows us to fix warning about unrecognized SoC in case of
EXYNOS4X12, which is not supported by this driver.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This will show the gpio chip as a child node
under /sys/bus/pci/devices/xxxx:xx:xx.x/
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix below build errors:
CC [M] drivers/gpio/gpio-em.o
drivers/gpio/gpio-em.c: In function 'em_gio_probe':
drivers/gpio/gpio-em.c:306: error: 'err' undeclared (first use in this function)
drivers/gpio/gpio-em.c:306: error: (Each undeclared identifier is reported only once
drivers/gpio/gpio-em.c:306: error: for each function it appears in.)
drivers/gpio/gpio-em.c:308: error: label 'err3' used but not defined
drivers/gpio/gpio-em.c:279: error: label 'err2' used but not defined
drivers/gpio/gpio-em.c:265: error: label 'err1' used but not defined
drivers/gpio/gpio-em.c:250: error: label 'err0' used but not defined
drivers/gpio/gpio-em.c:309: warning: no return statement in function returning non-void
drivers/gpio/gpio-em.c: At top level:
drivers/gpio/gpio-em.c:311: error: expected identifier or '(' before 'if'
drivers/gpio/gpio-em.c:317: error: expected identifier or '(' before 'if'
drivers/gpio/gpio-em.c:323: warning: data definition has no type or storage class
drivers/gpio/gpio-em.c:323: warning: type defaults to 'int' in declaration of 'ret'
drivers/gpio/gpio-em.c:323: error: 'gpio_chip' undeclared here (not in a function)
drivers/gpio/gpio-em.c:323: error: initializer element is not constant
drivers/gpio/gpio-em.c:324: error: expected identifier or '(' before 'if'
drivers/gpio/gpio-em.c:328: error: expected identifier or '(' before 'return'
drivers/gpio/gpio-em.c:330: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
drivers/gpio/gpio-em.c:332: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
drivers/gpio/gpio-em.c:334: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
drivers/gpio/gpio-em.c:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
drivers/gpio/gpio-em.c:338: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
drivers/gpio/gpio-em.c:340: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
drivers/gpio/gpio-em.c:342: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
drivers/gpio/gpio-em.c:344: error: expected identifier or '(' before '}' token
drivers/gpio/gpio-em.c: In function 'em_gio_remove':
drivers/gpio/gpio-em.c:361: error: implicit declaration of function 'em_gio_irq_domain_cleanup'
make[2]: *** [drivers/gpio/gpio-em.o] Error 1
make[1]: *** [drivers/gpio] Error 2
make: *** [drivers] Error 2
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- Fix a potential bit wrap issue in the Timberdale driver
- Fix up the buffer allocation size in the 74x164 driver
- Set the value in direction_output() right in the mvebu driver
- Return proper error codes for invalid GPIOs
- Fix an off-mode bug for the OMAP
- Don't initialized the mask_cach on the mvebu driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQkFIMAAoJEEEQszewGV1zN4YQAKzSPyC4lsdr5sf3Ua0Xxr0l
7Qb2tbIc9WT9E5m13h0V+sF6XVN+e3Ideg7ZFQOkuqmijA17W1Gm+hRMFYNLvhT9
ZbVlLdzDMNrKA3VEkP4Eo4KO34awYUBkWE4UglW0PAWz1W222nn9c8HC14tasKke
i80K55v82l8t7VhfotXhAf1DYhzxpTTzD2CBvGsgpACrNrEXMuKE68ZjeNft/HQU
CyKmxO5bcmdkF20W2IlQtyAUJridBe5YzUdPQ0PjWi3Ejvpo13i+RHDudiDJfHpv
5CNddMpXCC5Dl16j5EdEaKLq62mtDYlxzc65NwrRT1SYMsTyluk8faHhzqcACICS
EoP1mbUWPOkXZxPKLudMqsT0N8ud+XSDfaFIItaP7CMEE/Omf5Ql6Rann0mWxHEP
m8b913NAwIXtrtBn5/JAk5yqgon2Ns5+b4QxP5nc2Zzge8o9H7I1gLCsh2NFiwV4
3aABVWUq9EFOiiCvc6K7ZaEH+5/oUrw0qnEEoEUw79Qz/XFlkVvVxcLX9ZOy6Vhd
3RIgQPnJkNMX1Ncu+Jgd5GMJu1xMsy+urRf+VpaOReKkwiK+s6QTfeSxQBc2g+L5
n2GR0LvnN9yDFWb9g/NUTSNJ2EjHlWtQPU7KdZRYIxey67FMRdjgA8CSnEFyiI+x
Wq2Fx2uLE1dv/oYzFbck
=GXA+
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-v3.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
- Fix a potential bit wrap issue in the Timberdale driver
- Fix up the buffer allocation size in the 74x164 driver
- Set the value in direction_output() right in the mvebu driver
- Return proper error codes for invalid GPIOs
- Fix an off-mode bug for the OMAP
- Don't initialize the mask_cach on the mvebu driver
* tag 'gpio-fixes-v3.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
GPIO: mvebu-gpio: Don't initialize the mask_cache
gpio/omap: fix off-mode bug: clear debounce settings on free/reset
gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios
gpio: mvebu: correctly set the value in direction_output()
gpio-74x164: Fix buffer allocation size
gpio-timberdale: fix a potential wrapping issue
Due to the SMP nature of some of the chips, which have per CPU
registers, the driver does not use the generic irq_gc_mask_set_bit() &
irq_gc_mask_clr_bit() functions, which only support a single register.
The driver has its own implementation of these functions, which can
pick the correct register depending on the CPU being used. The
functions do however use the gc->mask_cache value.
The call to irq_setup_generic_chip() was passing
IRQ_GC_INIT_MASK_CACHE, which caused the gc->mask_cache to be
initialized to the contents of some random register. This resulted in
unexpected interrupts been delivered from random GPIO lines.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Jamie Lentin <jm@lentin.co.uk>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Michael Walle <michael@walle.cc>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
clock enable mask on free/reset". The title has been updated slightly to
reflect (what should be) the final fix.
When a GPIO is freed or shutdown, we need to ensure that any debounce settings
are cleared and if the GPIO is the only GPIO in the bank that is currently
using debounce, then disable the debounce clock as well to save power.
Currently, the debounce settings are not cleared on a GPIO free or shutdown and
so during a context restore on subsequent off-mode transition, the previous
debounce values are restored from the shadow copies (bank->context.debounce*)
leading to mismatch state between driver state and hardware state.
This was discovered when board code was doing
gpio_request_one()
gpio_set_debounce()
gpio_free()
which was leaving the GPIO debounce settings in a confused state. If that GPIO
bank is subsequently used with off-mode enabled, bogus state would be restored,
leaving GPIO debounce enabled which then prevented the CORE powerdomain from
transitioning.
To fix this, introduce a new function called _clear_gpio_debounce() to clear
any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
last debounce-enabled GPIO in the bank, the debounce will also be cut.
Please note that we cannot use _gpio_dbck_disable() to disable the debounce
clock because this has been specifically created for the gpio suspend path
and is intended to shutdown the debounce clock while debounce is enabled.
Special thanks to Kevin Hilman for root causing the bug. This fix is a
collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
Santosh Shilimkar.
Testing:
- This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
enabling debounce and then freeing the gpio and checking the register
contents, the saved register context and the debounce clock state.
- Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
ads7846 touchscreen in its board file using the above sequence, and so was
failing off-mode tests in dynamic idle. Verified that off-mode tests are
passing with this patch.
V5 changes:
- Corrected author
Reported-by: Paul Walmsley <paul@pwsan.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
platform_device_unregister() only calls platform_device_del() and
platform_device_put(), thus use platform_device_unregister() to
simplify the code.
Also the documents in platform.c shows that platform_device_del
and platform_device_put must _only_ be externally called in error
cases. All other usage is a bug.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The special checks for whether we have a base IRQ offset or not
is surplus if we use the simple IRQ domain. The IRQ offset
zero will be interpreted as a linear domain case.
Plus this makes sure we allocate descriptors where need be, or
warn if they are preallocated with SPARSE_IRQ.
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The code in the em driver seems to want to try to do the job of
the linear IRQ domain (allocate descriptors and grab a virtual
range). So why not just use the linear IRQ domain? The code is
now cut down so we don't need isolated functions for this.
Also note that we use irq_create_mapping() to make sure
descriptors are allocated for these IRQs.
Also fixed the FIXME to remove the domain after use.
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Magnus Damm <damm@opensource.se>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The MVEBU driver probably just wants a few IRQs. Using the simple
domain has the upside of allocating IRQ descriptors if need be,
especially in a SPARSE_IRQ environment.
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Tegra driver tries to do the work of irq_domain_add_linear()
by reserving a bunch of descriptors somewhere and keeping track
of the base offset, then calling irq_domain_add_legacy(). Let's
stop doing that and simply use the linear IRQ domain.
For this to work: use irq_create_mapping() in the IRQ iterator
so that the descriptors get allocated here.
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We need to unlock here before returning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpios requested with invalid numbers, or gpios requested from userspace via sysfs
should not try to be deferred on failure.
Cc: stable@kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add .get_direction callback to gpio_chip. This allows gpiolib
to check the current direction of a gpio.
Used to show the correct gpio direction in sysfs and debug entries.
If callback is not set then gpiolib will work as previously;
e.g. guessing everything is input until a direction is set.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
PORTD have different direction logic, i.e. "0" is output and "1" is input.
This patch fix this issue.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The ->direction_output() operation of gpio_chip is supposed to set the
direction to output but also to set the GPIO to an initial
value. Unfortunately, this last part was not done until now, causing
for example the LEDs to not be properly set to their default initial
value. This patch fixes this by calling the mvebu_gpio_set() function
from mvebu_gpio_direction_output() before configuring the GPIO as an
output GPIO.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch makes GPIO pin to INTERRUPT mode or INPUT mode according
to bitmap_gpio_int. When the related bit of bitmap_gpio_int is set,
it makes GPIO pin to INTERRUPT mode instrad of INPUT mode in the
samsung_gpiolib_4bit_input function.
Signed-off-by: Eunki Kim <eunki_kim@samsung.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
The gpio_export function uses nested if statements and the status
variable to handle the failure cases. This makes the function logic
difficult to follow. Refactor the code to abort immediately on failure
using goto. This makes the code slightly longer, but significantly
reduces the nesting and number of split lines and makes the code easier
to read.
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
These SoC's have an extended bank of GPIO's seperate to the main
GPIO block. This patch adds the additional 5 GPIO's located in this
block which control I2C and PWMOUT.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
