summaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpio-syscon.c
AgeCommit message (Collapse)Author
2015-03-27gpio: syscon: reduce message level when direction reg offset not in dtGrygorii Strashko
Now GPIO syscon driver produces bunch of warnings during the boot of Kesytone 2 SoCs: gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset! gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset! This message unintentionally was added using dev_err(), but its actual log level is debug, because third cell of "ti,syscon-dev" is optional. Hence change it to dev_dbg() as it should be. This patch fixes commit: 5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt") Reported-by: Russell King <linux@arm.linux.org.uk> Tested-by: Murali Karicheri <m-karicheri2@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-10-20gpio: drop owner assignment from platform_driversWolfram Sang
A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-09-16gpio: syscon: reuse for keystone 2 socsGrygorii Strashko
On Keystone SOCs, ARM host can send interrupts to DSP cores using the DSP GPIO controller IP. Each DSP GPIO controller provides 28 IRQ signals for each DSP core. This is one of the component used by the IPC mechanism used on Keystone SOCs. Keystone 2 DSP GPIO controller has specific features: - each GPIO can be configured only as output pin; - setting GPIO value to 1 causes IRQ generation on target DSP core; - reading pin value returns 0 - if IRQ was handled or 1 - IRQ is still pending. This patch updates gpio-syscon driver to be reused by Keystone 2 SoCs, because the Keystone 2 DSP GPIO controller is controlled through Syscon devices and, as requested by Linus Walleij, such kind of GPIO controllers should be integrated with drivers/gpio/gpio-syscon.c driver. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-16gpio: syscon: retrive syscon node and regs offsets from dtGrygorii Strashko
This patch adds handling of new "gpio,syscon-dev" DT property, which allows to specify syscon node and data/direction registers offsets in DT. "gpio,syscon-dev" has following format: gpio,syscon-dev = <&syscon_dev data_reg_offset [direction_reg_offset]>; where - syscon_dev - phandle on syscon node - data_reg_offset - offset of data register (in bytes) - direction_reg_offset - offset of dirrection register (optional, in bytes) for example: gpio,syscon-dev = <&devctrl 0x254>; In such way, the support of multiple Syscon GPIO devices is added. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-16gpio: syscon: add soc specific callback to assign output valueGrygorii Strashko
Some SoCs (like Keystone) may require to perform special sequence of operations to assign output GPIO value, so default implementation of .set() callback from gpio-syscon driver can't be used. Hence, add optional, SoC specific callback to assign output gpio value. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-07-22gpio: remove all usage of gpio_remove retval in driver/gpioabdoulaye berthe
Signed-off-by: abdoulaye berthe <berthe.ab@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-18gpio: Driver for SYSCON-based GPIOsAlexander Shiyan
SYSCON driver was designed for using memory areas (registers) that are used in several subsystems. There are systems (CPUs) which use bits in one register for various purposes and thus should be handled by various kernel subsystems. This driver allows you to use the individual SYSCON bits as GPIOs. ARM CLPS711X SYSFLG1 input lines has been added as first user of this driver. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>