[PATCH 0/2] gpio: davinci: preparation fixes and updates to reuse it for Keystone

[Grygorii Strashko]

This series is a preparation step for reusing Davinci GPIO driver
for Keystone SoCs.
And it's been created in order to break the strict dependency of
Davinci GPIO driver from Davinci platform code.

Based on patch:
http://www.spinics.net/lists/kernel/msg1632405.html

Grygorii Strashko (2):
gpio: davinci: get rid of DAVINCI_N_GPIO
gpio: introduce GPIO_DAVINCI kconfig option

drivers/gpio/Kconfig | 7 +++++++
drivers/gpio/Makefile | 2 +-
drivers/gpio/gpio-davinci.c | 4 ++--
3 files changed, 10 insertions(+), 3 deletions(-)

--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Grygorii Strashko]

The compatible to Davinci GPIO HW block is used by other TI SoCs, like
Keystone, where GPIO support is declared as optional.

Hence, introduce GPIO_DAVINCI Kconfig option which will allow to enable
Davinci GPIO driver for Keystone SoCs when needed. At same time, kept
Davinci GPIO driver enabled for Davinci SoCs by default.

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

drivers/gpio/Kconfig | 7 +++++++
drivers/gpio/Makefile | 2 +-

2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0f04444..7c75f5a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -115,6 +115,13 @@ config GPIO_CLPS711X
help
Say yes here to support GPIO on CLPS711X SoCs.

+config GPIO_DAVINCI
+ bool "TI Davinci/Keystone GPIO support"
+ default y if ARCH_DAVINCI
+ depends on ARM && (ARCH_DAVINCI || ARCH_KEYSTONE)
+ help
+ Say yes here to enable GPIO support for TI Davinci/Keystone SoCs.
+
config GPIO_GENERIC_PLATFORM
tristate "Generic memory-mapped GPIO controller support (MMIO platform device)"
select GPIO_GENERIC
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 7971e36..28a0ffc 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_GPIO_CLPS711X) += gpio-clps711x.o
obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o
obj-$(CONFIG_GPIO_DA9055) += gpio-da9055.o
-obj-$(CONFIG_ARCH_DAVINCI) += gpio-davinci.o
+obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
obj-$(CONFIG_GPIO_F7188X) += gpio-f7188x.o

[Grygorii Strashko]

Since Davinci GPIO driver is moved to support gpiolib it has to use
ARCH_NR_GPIOS (can be configured using CONFIG_ARCH_NR_GPIO Kconfig
option) configuration instead of any mach/platform specific options.

Hence, replace private DAVINCI_N_GPIO with common ARCH_NR_GPIOS. This is
safe because default value for ARCH_NR_GPIOS=256 and maximum number of
supported GPIOs for Davinci is DAVINCI_N_GPIO=144.

More over, this is one of steps to re-use Davinci GPIO driver by other
mach/platform.

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

drivers/gpio/gpio-davinci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 1f33fcd..944c819 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -160,8 +160,8 @@ static int davinci_gpio_probe(struct platform_device *pdev)
return -EINVAL;
}

- if (WARN_ON(DAVINCI_N_GPIO < ngpio))
- ngpio = DAVINCI_N_GPIO;
+ if (WARN_ON(ARCH_NR_GPIOS < ngpio))
+ ngpio = ARCH_NR_GPIOS;

chips = devm_kzalloc(dev,
ngpio * sizeof(struct davinci_gpio_controller),

[Prabhakar Lad]

On Thu, Nov 21, 2013 at 9:04 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:
> Since Davinci GPIO driver is moved to support gpiolib it has to use
> ARCH_NR_GPIOS (can be configured using CONFIG_ARCH_NR_GPIO Kconfig
> option) configuration instead of any mach/platform specific options.
>
> Hence, replace private DAVINCI_N_GPIO with common ARCH_NR_GPIOS. This is
> safe because default value for ARCH_NR_GPIOS=256 and maximum number of
> supported GPIOs for Davinci is DAVINCI_N_GPIO=144.
>
> More over, this is one of steps to re-use Davinci GPIO driver by other
> mach/platform.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

Acked-by: Lad, Prabhakar <prabhaka...@gmail.com>

Regards,
--Prabhakar Lad

[Prabhakar Lad]

On Thu, Nov 21, 2013 at 9:04 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:

> The compatible to Davinci GPIO HW block is used by other TI SoCs, like
> Keystone, where GPIO support is declared as optional.
>
> Hence, introduce GPIO_DAVINCI Kconfig option which will allow to enable
> Davinci GPIO driver for Keystone SoCs when needed. At same time, kept
> Davinci GPIO driver enabled for Davinci SoCs by default.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

Acked-by: Lad, Prabhakar <prabhaka...@gmail.com>

Regards,
--Prabhakar Lad

[Grygorii Strashko]

The compatible to Davinci GPIO HW block is used by other TI SoCs, like
Keystone, where GPIO support is declared as optional.

Hence, introduce GPIO_DAVINCI Kconfig option which will allow to enable
Davinci GPIO driver for Keystone SoCs when needed. At same time, kept
Davinci GPIO driver enabled for Davinci SoCs by default.

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

[Grygorii Strashko]

It's unsafe to call IRQ chip callbacks (.irq_mask/irq_unmask/irq_ack)
from chained IRQ handler directly. Because, Davinci GPIO block is used
by different SoCs, which, in turn, have different Main IRQ controllers
(Davinci - aintc, cp-intc; Keystone - arm-gic) which may introduce
diffrent set of IRQ chip callbacks. As result, call of
gpio_irq_handler() on Keysone will simply cause crash the system,
because ARM-GIC implements .irq_eoi() instead of .irq_ack().

Hence, fix it by using Kernel chained_irq_enter/chained_irq_exit APIs as
they are intended to handle exact such cases.

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

drivers/gpio/gpio-davinci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 70b5f2f..ee7a2df 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -22,6 +22,7 @@
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/platform_data/gpio-davinci.h>
+#include <linux/irqchip/chained_irq.h>

struct davinci_gpio_regs {
u32 dir;
@@ -321,8 +322,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
mask <<= 16;

/* temporarily mask (level sensitive) parent IRQ */
- desc->irq_data.chip->irq_mask(&desc->irq_data);
- desc->irq_data.chip->irq_ack(&desc->irq_data);
+ chained_irq_enter(irq_desc_get_chip(desc), desc);
while (1) {
u32 status;
int bit;
@@ -343,7 +343,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
d->chip.base + bit));
}
}
- desc->irq_data.chip->irq_unmask(&desc->irq_data);
+ chained_irq_exit(irq_desc_get_chip(desc), desc);
/* now it may re-trigger */

[Grygorii Strashko]

The similar GPIO HW block is used by keystone SoCs as
in Davinci SoCs.
Hence, reuse Davinci GPIO driver for Keystone.

Documentation:
http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
drivers/gpio/gpio-davinci.c | 55 ++++++++++++++++++++
2 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d..4ce9862 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,7 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings

Required Properties:
-- compatible: should be "ti,dm6441-gpio"
+- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"

- reg: Physical base address of the controller and the size of memory mapped
registers.
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 6a48bf8..545f25c 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -542,11 +542,65 @@ static int davinci_gpio_banked_irq_init(struct platform_device *pdev)
return 0;
}

+static int keystone_gpio_unbanked_irq_init(struct platform_device *pdev)
+{
+ int base_irq, irq;
+ unsigned gpio, ngpio;
+ struct davinci_gpio_regs __iomem *g;
+ struct device *dev = &pdev->dev;
+ struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
+ struct davinci_gpio_platform_data *pdata = dev->platform_data;
+
+ static struct irq_chip gpio_unbanked;
+
+ if (pdata->gpio_unbanked > chips[0].chip.ngpio) {
+ dev_err(dev, "Invalid IRQ configuration\n");
+ return -EINVAL;
+ }
+
+ ngpio = pdata->ngpio;
+
+ base_irq = platform_get_irq(pdev, 0);
+ if (base_irq <= 0) {
+ dev_err(dev, "Invalid first banked IRQ number %d\n", base_irq);
+ return base_irq < 0 ? base_irq : -EINVAL;
+ }
+
+ /* pass "bank 0" GPIO IRQs to GIC */
+ chips[0].chip.to_irq = gpio_to_irq_unbanked;
+ chips[0].gpio_irq = base_irq;
+ chips[0].gpio_unbanked = pdata->gpio_unbanked;
+
+ /* GIC handles mask/unmask; GPIO handles triggering */
+ gpio_unbanked = *irq_get_chip(base_irq);
+ gpio_unbanked.name = "GPIO-GIC";
+ gpio_unbanked.irq_set_type = gpio_irq_type_unbanked;
+
+ /* default trigger: both edges */
+ g = gpio2regs(0);
+ writel(~0, &g->set_falling);
+ writel(~0, &g->set_rising);
+
+ irq = base_irq;
+ /* set the direct IRQs up to use that irqchip */
+ for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {
+ irq_set_chip(irq, &gpio_unbanked);
+ irq_set_handler_data(irq, &chips[gpio / 32]);
+ irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
+ }
+
+ return 0;
+};
+
static const struct davinci_gpio_init_data davinci_gpio_pdata = {
.unbanked_irq_init = davinci_gpio_unbanked_irq_init,
.banked_irq_init = davinci_gpio_banked_irq_init,
};

+static const struct davinci_gpio_init_data keystone_gpio_pdata = {
+ .unbanked_irq_init = keystone_gpio_unbanked_irq_init,
+};
+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()
@@ -622,6 +676,7 @@ done:
#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {
{ .compatible = "ti,dm6441-gpio", &davinci_gpio_pdata},
+ { .compatible = "ti,keystone-gpio", &keystone_gpio_pdata},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_gpio_ids);

[Grygorii Strashko]

This patch adds Keystone GPIO IP device definitions in DT which supports
up to 32 GPIO lines and each GPIO line can be configured as separate
interrupt source (so called "unbanked" IRQ).

For more information see:

http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

arch/arm/boot/dts/keystone.dtsi | 45 +++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index f6d6d9e..6e93bf5 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -7,6 +7,7 @@
*/

#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/gpio/gpio.h>

#include "skeleton.dtsi"

@@ -181,5 +182,49 @@
interrupts = <GIC_SPI 300 IRQ_TYPE_EDGE_RISING>;
clocks = <&clkspi>;
};
+
+ gpio0: gpio@260bf00 {
+ compatible = "ti,keystone-gpio";
+ reg = <0x0260bf00 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ /* HW Interrupts mapped to GPIO pins */
+ interrupts = <GIC_SPI 120 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 121 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 122 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 123 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 124 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 125 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 126 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 127 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 128 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 129 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 130 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 131 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 132 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 133 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 134 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 135 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 136 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 137 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 138 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 139 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 140 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 141 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 142 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 143 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 144 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 145 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 146 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 147 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 148 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 149 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 150 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 151 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkgpio>;
+ clock-names = "gpio";
+ ti,ngpio = <32>;
+ ti,davinci-gpio-unbanked = <32>;
+ };
};

[Grygorii Strashko]

Since Davinci GPIO driver is moved to support gpiolib it has to use
ARCH_NR_GPIOS (can be configured using CONFIG_ARCH_NR_GPIO Kconfig
option) configuration instead of any mach/platform specific options.

Hence, replace private DAVINCI_N_GPIO with common ARCH_NR_GPIOS. This is
safe because default value for ARCH_NR_GPIOS=256 and maximum number of
supported GPIOs for Davinci is DAVINCI_N_GPIO=144.

More over, this is one of steps to re-use Davinci GPIO driver by other
mach/platform.

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

drivers/gpio/gpio-davinci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 5bdd9f8..70b5f2f 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -200,8 +200,8 @@ static int davinci_gpio_probe(struct platform_device *pdev)

return -EINVAL;
}

- if (WARN_ON(DAVINCI_N_GPIO < ngpio))
- ngpio = DAVINCI_N_GPIO;
+ if (WARN_ON(ARCH_NR_GPIOS < ngpio))
+ ngpio = ARCH_NR_GPIOS;

chips = devm_kzalloc(dev,
ngpio * sizeof(struct davinci_gpio_controller),

[Grygorii Strashko]

This series is intended to update Davinci GPIO driver and reuse
it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci.
Keystone GPIO IP: supports:
- up to 32 GPIO lines;
- only unbanked irqs;

See Documentation:
Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf

[1] Depends on patch:
"[PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio"
https://lkml.org/lkml/2013/11/8/22

[2] and depends on series from Prabhakar Lad:
"[PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement"
https://www.mail-archive.com/devic...@vger.kernel.org/msg05970.html

Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
branch: keystone/master

This series has been marked as RFC because it's based on an unfinished
series of patches [2], but with hope that it will help to reach final decisions
and satisfy all interested parties.

Grygorii Strashko (9):

gpio: davinci: get rid of DAVINCI_N_GPIO
gpio: introduce GPIO_DAVINCI kconfig option

gpio: davinci: use chained_irq_enter/chained_irq_exit API
gpio: davinci: make IRQ initialization soc specific
gpio: davinci: reuse for Keystone SoC
arm: dts: keystone: add GPIO device entry
ARM: keystone_defconfig: enable gpio support
arm: dts: keystone-evm: add LEDs supports
ARM: keystone_defconfig: enable LED support

.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
arch/arm/boot/dts/k2hk-evm.dts | 23 ++
arch/arm/boot/dts/keystone.dtsi | 45 +++
arch/arm/configs/keystone_defconfig | 11 +
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 2 +-
drivers/gpio/gpio-davinci.c | 306 ++++++++++++++------
7 files changed, 305 insertions(+), 93 deletions(-)

[Grygorii Strashko]

The Keystone GPIO functionality is ready for use, so LED support can be
enabled in config.

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

arch/arm/configs/keystone_defconfig | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index e911f7f..fb1eb8a 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -161,3 +161,11 @@ CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_DAVINCI=y
+CONFIG_LEDS_CLASS=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_BACKLIGHT=y
+CONFIG_LEDS_TRIGGER_GPIO=y

[Grygorii Strashko]

The Davinci GPIO IRQs initialization may need to be performed in a
different way depending on SoC which use it. For example:
- Davinci dm365 has AINTC irq controller, implemented using Generic IRQ
chip, SPARSE_IRQ off;
- Davinci da850 has cp-intc controller, implemented using IRQ chip;
SPARSE_IRQ off;
- Kestone has arm-gic controller, implemented using IRQ chip;
SPARSE_IRQ on;

Hence, introduce SoC specific initialization data
struct davinci_gpio_init_data {
int (*unbanked_irq_init)(struct platform_device *pdev);
int (*banked_irq_init)(struct platform_device *pdev);
};
which can be selected using "compatibility" property in case of DT-boot
and update code accordingly by splitting IRQ initialization code to
banked and unbanked IRQs initialization functions.

Select Davinci specific initialization data by default for non-DT boot
case.

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

drivers/gpio/gpio-davinci.c | 241 ++++++++++++++++++++++++++++---------------
1 file changed, 156 insertions(+), 85 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index ee7a2df..6a48bf8 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -37,12 +37,18 @@ struct davinci_gpio_regs {
u32 intstat;
};

+struct davinci_gpio_init_data {
+ int (*unbanked_irq_init)(struct platform_device *pdev);
+ int (*banked_irq_init)(struct platform_device *pdev);
+};
+
#define BINTEN 0x8 /* GPIO Interrupt Per-Bank Enable Register */

#define chip2controller(chip) \
container_of(chip, struct davinci_gpio_controller, chip)

static void __iomem *gpio_base;
+static const struct davinci_gpio_init_data *gpio_init_data;

static struct davinci_gpio_regs __iomem *gpio2regs(unsigned gpio)
{
@@ -138,20 +144,32 @@ davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
writel((1 << offset), value ? &g->set_data : &g->clr_data);
}

+static const struct of_device_id davinci_gpio_ids[];
+
static struct davinci_gpio_platform_data *
davinci_gpio_get_pdata(struct platform_device *pdev)
{
struct device_node *dn = pdev->dev.of_node;
struct davinci_gpio_platform_data *pdata;
+ const struct of_device_id *match;
int ret;
u32 val;

if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
return pdev->dev.platform_data;

+ match = of_match_device(of_match_ptr(davinci_gpio_ids), &pdev->dev);
+ if (!match) {
+ ret = -ENODEV;
+ goto of_err;
+ }
+ gpio_init_data = match->data;
+
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
- if (!pdata)
- return NULL;
+ if (!pdata) {
+ ret = -ENOMEM;
+ goto of_err;
+ }

ret = of_property_read_u32(dn, "ti,ngpio", &val);
if (ret)
@@ -351,7 +369,11 @@ static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
{
struct davinci_gpio_controller *d = chip2controller(chip);

- return irq_create_mapping(d->irq_domain, d->chip.base + offset);
+ if (d->irq_domain)
+ return irq_create_mapping(d->irq_domain,
+ d->chip.base + offset);
+ else
+ return -ENXIO;
}

static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
@@ -410,6 +432,121 @@ static const struct irq_domain_ops davinci_gpio_irq_ops = {
.xlate = irq_domain_xlate_onetwocell,
};

+static int davinci_gpio_unbanked_irq_init(struct platform_device *pdev)

+{
+ int base_irq, irq;
+ unsigned gpio, ngpio;
+ struct davinci_gpio_regs __iomem *g;
+ struct device *dev = &pdev->dev;
+ struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
+ struct davinci_gpio_platform_data *pdata = dev->platform_data;
+

+ static struct irq_chip_type gpio_unbanked;

+
+ if (pdata->gpio_unbanked > chips[0].chip.ngpio) {
+ dev_err(dev, "Invalid IRQ configuration\n");
+ return -EINVAL;
+ }
+
+ ngpio = pdata->ngpio;
+
+ base_irq = platform_get_irq(pdev, 0);
+ if (base_irq <= 0) {
+ dev_err(dev, "Invalid first banked IRQ number %d\n", base_irq);
+ return base_irq < 0 ? base_irq : -EINVAL;
+ }
+

+ /* pass "bank 0" GPIO IRQs to AINTC */

+ chips[0].chip.to_irq = gpio_to_irq_unbanked;
+ chips[0].gpio_irq = base_irq;
+ chips[0].gpio_unbanked = pdata->gpio_unbanked;
+

+ /* AINTC handles mask/unmask; GPIO handles triggering */
+ gpio_unbanked = *container_of(irq_get_chip(base_irq),
+ struct irq_chip_type, chip);
+ gpio_unbanked.chip.name = "GPIO-AINTC";
+ gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;

+
+ /* default trigger: both edges */
+ g = gpio2regs(0);
+ writel(~0, &g->set_falling);
+ writel(~0, &g->set_rising);
+
+ irq = base_irq;
+ /* set the direct IRQs up to use that irqchip */
+ for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {

+ irq_set_chip(irq, &gpio_unbanked.chip);

+ irq_set_handler_data(irq, &chips[gpio / 32]);
+ irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
+ }
+
+ return 0;
+};
+

+static int davinci_gpio_banked_irq_init(struct platform_device *pdev)

+{
+ int base_irq, irq;

+ unsigned gpio, ngpio, bank;

+ struct davinci_gpio_regs __iomem *g;
+ struct device *dev = &pdev->dev;
+ struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
+ struct davinci_gpio_platform_data *pdata = dev->platform_data;

+ struct irq_domain *irq_domain = NULL;

+
+ ngpio = pdata->ngpio;
+
+ base_irq = platform_get_irq(pdev, 0);
+ if (base_irq <= 0) {
+ dev_err(dev, "Invalid first banked IRQ number %d\n", base_irq);
+ return base_irq < 0 ? base_irq : -EINVAL;
+ }
+

+ irq = irq_alloc_descs(-1, 0, ngpio, 0);
+ if (irq < 0) {
+ dev_err(dev, "Couldn't allocate IRQ numbers\n");
+ return irq;
+ }
+
+ irq_domain = irq_domain_add_legacy(dev->of_node, ngpio, irq, 0,
+ &davinci_gpio_irq_ops,
+ chips);
+ if (!irq_domain) {
+ dev_err(dev, "Couldn't register an IRQ domain\n");
+ return -ENOMEM;
+ }
+
+ /*
+ * Or, AINTC can handle IRQs for banks of 16 GPIO IRQs, which we
+ * then chain through our own handler.
+ */
+ for (gpio = 0, bank = 0; gpio < ngpio; bank++, base_irq++, gpio += 16) {
+ /* disabled by default, enabled only as needed */
+ g = gpio2regs(gpio);
+ writel(~0, &g->clr_falling);
+ writel(~0, &g->clr_rising);
+
+ /* set up all irqs in this bank */
+ irq_set_chained_handler(base_irq, gpio_irq_handler);
+
+ /*
+ * Each chip handles 32 gpios, and each irq bank consists of 16
+ * gpio irqs. Pass the irq bank's corresponding controller to
+ * the chained irq handler.
+ */
+ irq_set_handler_data(base_irq, &chips[gpio / 32]);
+
+ if (!(gpio % 32))
+ chips[gpio / 32].irq_domain = irq_domain;

+ }
+
+ return 0;
+}
+

+static const struct davinci_gpio_init_data davinci_gpio_pdata = {
+ .unbanked_irq_init = davinci_gpio_unbanked_irq_init,
+ .banked_irq_init = davinci_gpio_banked_irq_init,

+};
+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()

@@ -420,30 +557,12 @@ static const struct irq_domain_ops davinci_gpio_irq_ops = {

static int davinci_gpio_irq_setup(struct platform_device *pdev)
{
- unsigned gpio, irq, bank;
+ unsigned gpio, bank;
struct clk *clk;
u32 binten = 0;
- unsigned ngpio, bank_irq;

struct device *dev = &pdev->dev;

- struct resource *res;

struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);

struct davinci_gpio_platform_data *pdata = dev->platform_data;

- struct davinci_gpio_regs __iomem *g;
- struct irq_domain *irq_domain;
-
- ngpio = pdata->ngpio;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(dev, "Invalid IRQ resource\n");
- return -EBUSY;
- }
-
- bank_irq = res->start;
-
- if (!bank_irq) {
- dev_err(dev, "Invalid IRQ resource\n");
- return -ENODEV;
- }

clk = devm_clk_get(dev, "gpio");
if (IS_ERR(clk)) {
@@ -453,19 +572,12 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
}
clk_prepare_enable(clk);

- irq = irq_alloc_descs(-1, 0, ngpio, 0);
- if (irq < 0) {
- dev_err(dev, "Couldn't allocate IRQ numbers\n");
- return -ENODEV;
- }
-
- irq_domain = irq_domain_add_legacy(NULL, ngpio, irq, 0,
- &davinci_gpio_irq_ops,
- chips);
- if (!irq_domain) {
- dev_err(dev, "Couldn't register an IRQ domain\n");
- return -ENODEV;
- }
+ /*
+ * Use Davinci GPIO init data by default for compatibility
+ * with non-DT platforms
+ */
+ if (!gpio_init_data)
+ gpio_init_data = &davinci_gpio_pdata;

/*
* Arrange gpio_to_irq() support, handling either direct IRQs or
@@ -473,11 +585,8 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
* IRQs, while the others use banked IRQs, would need some setup
* tweaks to recognize hardware which can do that.
*/
- for (gpio = 0, bank = 0; gpio < ngpio; bank++, gpio += 32) {
+ for (gpio = 0, bank = 0; gpio < pdata->ngpio; bank++, gpio += 32)
chips[bank].chip.to_irq = gpio_to_irq_banked;
- if (!pdata->gpio_unbanked)
- chips[bank].irq_domain = irq_domain;
- }

/*
* AINTC can handle direct/unbanked IRQs for GPIOs, with the GPIO
@@ -485,33 +594,9 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (pdata->gpio_unbanked) {
- static struct irq_chip_type gpio_unbanked;
-
- /* pass "bank 0" GPIO IRQs to AINTC */
- chips[0].chip.to_irq = gpio_to_irq_unbanked;
- chips[0].gpio_irq = bank_irq;
- chips[0].gpio_unbanked = pdata->gpio_unbanked;
- binten = BIT(0);
-
- /* AINTC handles mask/unmask; GPIO handles triggering */
- irq = bank_irq;
- gpio_unbanked = *container_of(irq_get_chip(irq),
- struct irq_chip_type, chip);
- gpio_unbanked.chip.name = "GPIO-AINTC";
- gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;
-
- /* default trigger: both edges */
- g = gpio2regs(0);
- writel(~0, &g->set_falling);
- writel(~0, &g->set_rising);
-
- /* set the direct IRQs up to use that irqchip */
- for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_unbanked.chip);
- irq_set_handler_data(irq, &chips[gpio / 32]);
- irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
- }
-
+ if (gpio_init_data && gpio_init_data->unbanked_irq_init)
+ if (!gpio_init_data->unbanked_irq_init(pdev))
+ binten = BIT(0);
goto done;
}

@@ -519,24 +604,10 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
* Or, AINTC can handle IRQs for banks of 16 GPIO IRQs, which we
* then chain through our own handler.
*/
- for (gpio = 0, bank = 0; gpio < ngpio; bank++, bank_irq++, gpio += 16) {
- /* disabled by default, enabled only as needed */
- g = gpio2regs(gpio);
- writel(~0, &g->clr_falling);
- writel(~0, &g->clr_rising);
-
- /* set up all irqs in this bank */
- irq_set_chained_handler(bank_irq, gpio_irq_handler);
-
- /*
- * Each chip handles 32 gpios, and each irq bank consists of 16
- * gpio irqs. Pass the irq bank's corresponding controller to
- * the chained irq handler.
- */
- irq_set_handler_data(bank_irq, &chips[gpio / 32]);
-
- binten |= BIT(bank);
- }
+ if (gpio_init_data && gpio_init_data->banked_irq_init)
+ if (!gpio_init_data->banked_irq_init(pdev))
+ /* calculate biten mask - one bit per 16 GPIOs */
+ binten |= BIT((pdata->ngpio / 16) + 1) - 1;

done:
/*
@@ -550,7 +621,7 @@ done:

#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {

- { .compatible = "ti,dm6441-gpio", },
+ { .compatible = "ti,dm6441-gpio", &davinci_gpio_pdata},

{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_gpio_ids);

[Grygorii Strashko]

Keystone EVMK2HX supports 4 debug LEDs controlled by GPIO lines as
following (active level is high);

DBG_D1 green gpio12
DBG_D1 red gpio13
DBG_D1 blue gpio14
DBG_D1 blue gpio15

For more information see schematics:
http://wfcache.advantech.com/www/support/TI-EVM/download/Schematics/PDF/K2H_K2EVM-HK_SCH_A102_Rev1_0.pdf

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

arch/arm/boot/dts/k2hk-evm.dts | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/k2hk-evm.dts b/arch/arm/boot/dts/k2hk-evm.dts
index 15b3a95..07bf1e9 100644
--- a/arch/arm/boot/dts/k2hk-evm.dts
+++ b/arch/arm/boot/dts/k2hk-evm.dts
@@ -52,4 +52,27 @@
};
};
};
+
+ leds {
+ compatible = "gpio-leds";
+ debug1_1 {
+ label = "keystone:green:debug1";
+ gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>; /* 12 */
+ };
+
+ debug1_2 {
+ label = "keystone:red:debug1";
+ gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>; /* 13 */
+ };
+
+ debug2 {
+ label = "keystone:blue:debug2";
+ gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; /* 14 */
+ };
+
+ debug3 {
+ label = "keystone:blue:debug3";
+ gpios = <&gpio0 15 GPIO_ACTIVE_HIGH>; /* 15 */
+ };
+ };
};

[Grygorii Strashko]

Enable enable GPIO support for Keystone by setting CONFIG_GPIOLIB and
CONFIG_GPIO_DAVINCI options in keystone_defconfig.

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

arch/arm/configs/keystone_defconfig | 3 +++
1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index 9943e5d..e911f7f 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -158,3 +158,6 @@ CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_DAVINCI=y

[Linus Walleij]

On Thu, Nov 21, 2013 at 4:34 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:

> Since Davinci GPIO driver is moved to support gpiolib it has to use
> ARCH_NR_GPIOS (can be configured using CONFIG_ARCH_NR_GPIO Kconfig
> option) configuration instead of any mach/platform specific options.
>
> Hence, replace private DAVINCI_N_GPIO with common ARCH_NR_GPIOS. This is
> safe because default value for ARCH_NR_GPIOS=256 and maximum number of
> supported GPIOs for Davinci is DAVINCI_N_GPIO=144.
>
> More over, this is one of steps to re-use Davinci GPIO driver by other
> mach/platform.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

Acked-by: Linus Walleij <linus....@linaro.org>

Now we have a handful of people patching DaVinci GPIOs...

Sekhar: can you coordinate the different DaVinci patches? If you want me
to take a complete set of stuff at the end of the day you can give me a
pull request for inclusion into the GPIO tree.

Yours,
Linus Walleij

[Linus Walleij]

On Thu, Nov 21, 2013 at 4:34 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:

> The compatible to Davinci GPIO HW block is used by other TI SoCs, like
> Keystone, where GPIO support is declared as optional.
>
> Hence, introduce GPIO_DAVINCI Kconfig option which will allow to enable
> Davinci GPIO driver for Keystone SoCs when needed. At same time, kept
> Davinci GPIO driver enabled for Davinci SoCs by default.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

Acked-by: Linus Walleij <linus....@linaro.org>

Sekhar, same comment here.

Yours,
Linus Walleij

[Linus Walleij]

On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:

> [1] Depends on patch:
> "[PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio"
> https://lkml.org/lkml/2013/11/8/22
>
> [2] and depends on series from Prabhakar Lad:
> "[PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement"
> https://www.mail-archive.com/devic...@vger.kernel.org/msg05970.html

So this needs to go through the same tree as these patches.

And I suggested that Sekhar queue them and either take them
directly up to ARM SoC or send me a pull request to take it through
the GPIO tree.

I'm going to go in and review these now...

Yours,
Linus Walleij

[Linus Walleij]

On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:

> It's unsafe to call IRQ chip callbacks (.irq_mask/irq_unmask/irq_ack)
> from chained IRQ handler directly. Because, Davinci GPIO block is used
> by different SoCs, which, in turn, have different Main IRQ controllers
> (Davinci - aintc, cp-intc; Keystone - arm-gic) which may introduce
> diffrent set of IRQ chip callbacks. As result, call of
> gpio_irq_handler() on Keysone will simply cause crash the system,
> because ARM-GIC implements .irq_eoi() instead of .irq_ack().
>
> Hence, fix it by using Kernel chained_irq_enter/chained_irq_exit APIs as
> they are intended to handle exact such cases.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

Acked-by: Linus Walleij <linus....@linaro.org>

Yours,
Linus Walleij

[Linus Walleij]

On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:

> The similar GPIO HW block is used by keystone SoCs as
> in Davinci SoCs.
> Hence, reuse Davinci GPIO driver for Keystone.
>
> Documentation:
> http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

This is really nice, and we want to reuse stuff.

Just waiting for some comments on the previous patch...

Yours,
Linus Walleij

[Linus Walleij]

On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:

> The Davinci GPIO IRQs initialization may need to be performed in a
> different way depending on SoC which use it. For example:
> - Davinci dm365 has AINTC irq controller, implemented using Generic IRQ
> chip, SPARSE_IRQ off;
> - Davinci da850 has cp-intc controller, implemented using IRQ chip;
> SPARSE_IRQ off;
> - Kestone has arm-gic controller, implemented using IRQ chip;
> SPARSE_IRQ on;

Now this is a pretty big patch ...

The big question that enters my mind is *why* is the da850 and
dm365 not using SPARSE_IRQ?

As it happens I'm on an ARM32 crusade to get everyone and its
dog to use, among other things, SPARSE_IRQ.

I would feel *much* *much* better if there was first a patch
to the DaVinci tree to turn on SPARSE_IRQ for this subarch,
and then this patch may look a bit different, maybe smaller
I take it?

Is this totally unattainable?

Yours,
Linus Walleij

[Santosh Shilimkar]

On Tuesday 26 November 2013 02:40 PM, Grygorii Strashko wrote:
> Since Davinci GPIO driver is moved to support gpiolib it has to use
> ARCH_NR_GPIOS (can be configured using CONFIG_ARCH_NR_GPIO Kconfig
> option) configuration instead of any mach/platform specific options.
>
> Hence, replace private DAVINCI_N_GPIO with common ARCH_NR_GPIOS. This is
> safe because default value for ARCH_NR_GPIOS=256 and maximum number of
> supported GPIOs for Davinci is DAVINCI_N_GPIO=144.
>
> More over, this is one of steps to re-use Davinci GPIO driver by other
> mach/platform.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
> ---

Looks like you just combined the two earlier patches you have posted.
Ack applies here as well.

regards,
Santosh

[Santosh Shilimkar]

On Tuesday 26 November 2013 02:40 PM, Grygorii Strashko wrote:

> It's unsafe to call IRQ chip callbacks (.irq_mask/irq_unmask/irq_ack)
> from chained IRQ handler directly. Because, Davinci GPIO block is used
> by different SoCs, which, in turn, have different Main IRQ controllers
> (Davinci - aintc, cp-intc; Keystone - arm-gic) which may introduce
> diffrent set of IRQ chip callbacks. As result, call of
> gpio_irq_handler() on Keysone will simply cause crash the system,
> because ARM-GIC implements .irq_eoi() instead of .irq_ack().
>
> Hence, fix it by using Kernel chained_irq_enter/chained_irq_exit APIs as
> they are intended to handle exact such cases.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
> ---
>

Acked-by: Santosh Shilimkar <santosh....@ti.com>

[Santosh Shilimkar]

On Tuesday 26 November 2013 02:40 PM, Grygorii Strashko wrote:

> The compatible to Davinci GPIO HW block is used by other TI SoCs, like
> Keystone, where GPIO support is declared as optional.
>
> Hence, introduce GPIO_DAVINCI Kconfig option which will allow to enable
> Davinci GPIO driver for Keystone SoCs when needed. At same time, kept
> Davinci GPIO driver enabled for Davinci SoCs by default.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
> ---

Already acked

[Santosh Shilimkar]

On Thursday 21 November 2013 10:34 AM, Grygorii Strashko wrote:
> This series is a preparation step for reusing Davinci GPIO driver
> for Keystone SoCs.
> And it's been created in order to break the strict dependency of
> Davinci GPIO driver from Davinci platform code.
>
> Based on patch:
> http://www.spinics.net/lists/kernel/msg1632405.html
>
> Grygorii Strashko (2):
> gpio: davinci: get rid of DAVINCI_N_GPIO
> gpio: introduce GPIO_DAVINCI kconfig option
>
> drivers/gpio/Kconfig | 7 +++++++
> drivers/gpio/Makefile | 2 +-
> drivers/gpio/gpio-davinci.c | 4 ++--
> 3 files changed, 10 insertions(+), 3 deletions(-)
>

Thanks Grygorii and clean-up is inline as discussed off-list.
FWIW,
Acked-by: Santosh Shilimkar <santosh....@ti.com>

[Santosh Shilimkar]

On Friday 29 November 2013 04:21 AM, Linus Walleij wrote:
> On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
> <grygorii...@ti.com> wrote:
>
>> The Davinci GPIO IRQs initialization may need to be performed in a
>> different way depending on SoC which use it. For example:
>> - Davinci dm365 has AINTC irq controller, implemented using Generic IRQ
>> chip, SPARSE_IRQ off;
>> - Davinci da850 has cp-intc controller, implemented using IRQ chip;
>> SPARSE_IRQ off;
>> - Kestone has arm-gic controller, implemented using IRQ chip;
>> SPARSE_IRQ on;
>
> Now this is a pretty big patch ...
>
> The big question that enters my mind is *why* is the da850 and
> dm365 not using SPARSE_IRQ?
>
> As it happens I'm on an ARM32 crusade to get everyone and its
> dog to use, among other things, SPARSE_IRQ.
>
> I would feel *much* *much* better if there was first a patch
> to the DaVinci tree to turn on SPARSE_IRQ for this subarch,
> and then this patch may look a bit different, maybe smaller
> I take it?
>
> Is this totally unattainable?
>

Probably Sekhar can comment but as such the GPIO driver should
work with and without SPARSE_IRQ and thats doable.

> Hence, introduce SoC specific initialization data
> struct davinci_gpio_init_data {
> int (*unbanked_irq_init)(struct platform_device *pdev);
> int (*banked_irq_init)(struct platform_device *pdev);
> };
> which can be selected using "compatibility" property in case of DT-boot
> and update code accordingly by splitting IRQ initialization code to
> banked and unbanked IRQs initialization functions.
>
> Select Davinci specific initialization data by default for non-DT boot
> case.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
> ---

NAK. Lets drop this approach. Its easier to manage the
banked vs unbaked based on compatible as discussed over irc

Regards,
Santosh

[Santosh Shilimkar]

On Friday 29 November 2013 04:25 AM, Linus Walleij wrote:
> On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
> <grygorii...@ti.com> wrote:
>
>> The similar GPIO HW block is used by keystone SoCs as
>> in Davinci SoCs.
>> Hence, reuse Davinci GPIO driver for Keystone.
>>
>> Documentation:
>> http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>>
>> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
>
> This is really nice, and we want to reuse stuff.
>

Ofcourse we want to re-use as much as possible.

> Just waiting for some comments on the previous patch...
>

Previous patch can be completely dropped as commented.

Regards,
Santosh

[Santosh Shilimkar]

On Tuesday 26 November 2013 02:40 PM, Grygorii Strashko wrote:

> This patch adds Keystone GPIO IP device definitions in DT which supports
> up to 32 GPIO lines and each GPIO line can be configured as separate
> interrupt source (so called "unbanked" IRQ).
>
> For more information see:
> http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
> ---
> arch/arm/boot/dts/keystone.dtsi | 45 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>

Patch 6/9, 7/9, 8/9 and 9/9 needs to be in
a separate series. They all good to me and I
will take them once the GPIO driver re-use gets
sorted out.

Regards,
Santosh

[Grygorii Strashko]

Hi All,

On 11/29/2013 10:37 AM, Linus Walleij wrote:
> On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
> <grygorii...@ti.com> wrote:
>
>> [1] Depends on patch:
>> "[PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio"
>> https://lkml.org/lkml/2013/11/8/22
>>
>> [2] and depends on series from Prabhakar Lad:
>> "[PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement"
>> https://www.mail-archive.com/devic...@vger.kernel.org/msg05970.html
>
> So this needs to go through the same tree as these patches.
>
> And I suggested that Sekhar queue them and either take them
> directly up to ARM SoC or send me a pull request to take it through
> the GPIO tree.
>
> I'm going to go in and review these now...

Thanks for you review.

I'll update, rebase and repost patches once the "Depends On" series
will be accepted.

Regards,
- grygorii

[Santosh Shilimkar]

Sekhar,

On Friday 29 November 2013 03:37 AM, Linus Walleij wrote:
> On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
> <grygorii...@ti.com> wrote:
>
>> [1] Depends on patch:
>> "[PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio"
>> https://lkml.org/lkml/2013/11/8/22
>>
>> [2] and depends on series from Prabhakar Lad:
>> "[PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement"
>> https://www.mail-archive.com/devic...@vger.kernel.org/msg05970.html
>
> So this needs to go through the same tree as these patches.
>
> And I suggested that Sekhar queue them and either take them
> directly up to ARM SoC or send me a pull request to take it through
> the GPIO tree.
>

Are you going to collect all the Davinci gpio patches create a pull
request for Linus Walleij ?

Let us know so that if needed, we can put these patches together
on a tree for Linus W to pull from.

I would like to get these patches in 3.14 queue. Thanks

Regards,
Ssantosh

[Prabhakar Lad]

Hi Grygorii,

Thanks for the patches.

For patches 1, 2 and 3

Acked-and-tested-by: Lad, Prabhakar <prabhaka...@gmail.com>

Regards,
--Prabhakar Lad

[Grygorii Strashko]

This series is intended to update Davinci GPIO driver and reuse
it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci.
Keystone GPIO IP: supports:
- up to 32 GPIO lines;
- only unbanked irqs;

See Documentation:
Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf

This series depends on:
[1] "[PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio"
https://lkml.org/lkml/2013/11/8/22
[2] "[PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement"
https://www.mail-archive.com/devic...@vger.kernel.org/msg05970.html
[3] "gpio: davinci: get rid of DAVINCI_N_GPIO"
https://lkml.org/lkml/2013/11/26/405
[4] "gpio: introduce GPIO_DAVINCI kconfig option"
https://lkml.org/lkml/2013/11/26/435
[5] "gpio: davinci: use chained_irq_enter/chained_irq_exit API"
https://lkml.org/lkml/2013/11/26/428

To handle all dependencies, I've created a branch where I collected all
"ready to merge" patches (all acks added in patches) and this series:
- https://github.com/grygoriyS/linux.git
- branch: keystone-master-gpio-for-next

The "keystone-master-gpio-for-next" based on:
https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux-keystone.git
branch: keystone/master

+ where I've merged in:
https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git
branch: fixes

List of commits:
6fb66de gpio: davinci: reuse for Keystone SoC
c0c5422 gpio: davinci: don't create irq_domain in case of unbanked irqs
df9f7bc gpio: davinci: use chained_irq_enter/chained_irq_exit API
6230c92 gpio: davinci: introduce GPIO_DAVINCI kconfig option
8b0c1a8 gpio: davinci: get rid of DAVINCI_N_GPIO
5eb07f7 gpio: davinci: add OF support
df3e59d gpio: davinci: remove unused variable intc_irq_num
38804b6 gpio: davinci: converts to use irqdomain
94eac24 gpio: davinci: use {readl|writel}_relaxed() instead of __raw_*

CC: Linus Walleij <linus....@linaro.org>
CC: Sekhar Nori <nse...@ti.com>
CC: Santosh Shilimkar <santosh....@ti.com>

Grygorii Strashko (2):
gpio: davinci: don't create irq_domain in case of unbanked irqs

gpio: davinci: reuse for Keystone SoC

.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
drivers/gpio/gpio-davinci.c | 83 ++++++++++++++------
2 files changed, 59 insertions(+), 28 deletions(-)

--
1.7.9.5

[Grygorii Strashko]

The system may crash if:
- there are more then 1 bank
- unbanked irqs are enabled
- someone will call gpio_to_irq() for GPIO from bank2 or above

Hence, fix it by not creating irq_domain if unbanked irqs are enabled
and correct gpio_to_irq_banked() to handle this properly.

CC: Linus Walleij <linus....@linaro.org>
CC: Sekhar Nori <nse...@ti.com>
CC: Santosh Shilimkar <santosh....@ti.com>

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

drivers/gpio/gpio-davinci.c | 34 +++++++++++++++++++---------------
1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 9379b4d..73f65ca 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -351,7 +351,10 @@ static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)

{
struct davinci_gpio_controller *d = chip2controller(chip);

- return irq_create_mapping(d->irq_domain, d->chip.base + offset);
+ if (d->irq_domain)

+ return irq_create_mapping(d->irq_domain, d->chip.base + offset);

+ else
+ return -ENXIO;
}

static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)

@@ -429,7 +432,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
struct davinci_gpio_platform_data *pdata = dev->platform_data;

struct davinci_gpio_regs __iomem *g;
- struct irq_domain *irq_domain;

+ struct irq_domain *irq_domain = NULL;

ngpio = pdata->ngpio;

res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

@@ -453,18 +456,20 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

}
clk_prepare_enable(clk);

- irq = irq_alloc_descs(-1, 0, ngpio, 0);
- if (irq < 0) {
- dev_err(dev, "Couldn't allocate IRQ numbers\n");
- return -ENODEV;
- }

+ if (!pdata->gpio_unbanked) {

+ irq = irq_alloc_descs(-1, 0, ngpio, 0);
+ if (irq < 0) {
+ dev_err(dev, "Couldn't allocate IRQ numbers\n");

+ return -ENODEV;
+ }

- irq_domain = irq_domain_add_legacy(NULL, ngpio, irq, 0,
- &davinci_gpio_irq_ops,
- chips);
- if (!irq_domain) {
- dev_err(dev, "Couldn't register an IRQ domain\n");
- return -ENODEV;

+ irq_domain = irq_domain_add_legacy(NULL, ngpio, irq, 0,

+ &davinci_gpio_irq_ops,
+ chips);
+ if (!irq_domain) {
+ dev_err(dev, "Couldn't register an IRQ domain\n");

+ return -ENODEV;
+ }
}

/*
@@ -475,8 +480,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
*/

for (gpio = 0, bank = 0; gpio < ngpio; bank++, gpio += 32) {

chips[bank].chip.to_irq = gpio_to_irq_banked;
- if (!pdata->gpio_unbanked)
- chips[bank].irq_domain = irq_domain;

+ chips[bank].irq_domain = irq_domain;
}

/*

[Grygorii Strashko]

The similar GPIO HW block is used by keystone SoCs as
in Davinci SoCs.

Hence, reuse Davinci GPIO driver for Keystone taking into
account that Keystone contains ARM GIC IRQ controller which
is implemented using IRQ Chip.

Documentation:
http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf

CC: Linus Walleij <linus....@linaro.org>
CC: Sekhar Nori <nse...@ti.com>
CC: Santosh Shilimkar <santosh....@ti.com>

CC: devic...@vger.kernel.org

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
drivers/gpio/gpio-davinci.c | 49 +++++++++++++++-----
2 files changed, 40 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d..4ce9862 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,7 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings

Required Properties:
-- compatible: should be "ti,dm6441-gpio"
+- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"

- reg: Physical base address of the controller and the size of memory mapped
registers.
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 73f65ca..3e44e0c 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -413,6 +413,27 @@ static const struct irq_domain_ops davinci_gpio_irq_ops = {
.xlate = irq_domain_xlate_onetwocell,
};

+static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)

+{
+ static struct irq_chip_type gpio_unbanked;
+

+ gpio_unbanked = *container_of(irq_get_chip(irq),

+ struct irq_chip_type, chip);
+

+ return &gpio_unbanked.chip;
+};
+
+static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip gpio_unbanked;
+
+ gpio_unbanked = *irq_get_chip(irq);
+ pr_err("keystone_gpio_get_irq_chip\n");
+ return &gpio_unbanked;
+};
+
+static const struct of_device_id davinci_gpio_ids[];

+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()

@@ -433,6 +454,15 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;

struct irq_domain *irq_domain = NULL;

+ const struct of_device_id *match;

+ struct irq_chip *irq_chip;
+ struct irq_chip *(*gpio_get_irq_chip)(unsigned int irq);
+
+ gpio_get_irq_chip = davinci_gpio_get_irq_chip;
+ match = of_match_device(of_match_ptr(davinci_gpio_ids),
+ dev);
+ if (match)
+ gpio_get_irq_chip = match->data;

ngpio = pdata->ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

@@ -442,7 +472,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

}

bank_irq = res->start;
-

if (!bank_irq) {

dev_err(dev, "Invalid IRQ resource\n");

return -ENODEV;
@@ -484,25 +513,22 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
}

/*
- * AINTC can handle direct/unbanked IRQs for GPIOs, with the GPIO
+ * INTC can handle direct/unbanked IRQs for GPIOs, with the GPIO
* controller only handling trigger modes. We currently assume no

* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (pdata->gpio_unbanked) {
- static struct irq_chip_type gpio_unbanked;
-

/* pass "bank 0" GPIO IRQs to AINTC */

chips[0].chip.to_irq = gpio_to_irq_unbanked;

chips[0].gpio_irq = bank_irq;

chips[0].gpio_unbanked = pdata->gpio_unbanked;

binten = BIT(0);

- /* AINTC handles mask/unmask; GPIO handles triggering */

+ /* INTC handles mask/unmask; GPIO handles triggering */

irq = bank_irq;
- gpio_unbanked = *container_of(irq_get_chip(irq),
- struct irq_chip_type, chip);
- gpio_unbanked.chip.name = "GPIO-AINTC";
- gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;

+ irq_chip = gpio_get_irq_chip(irq);
+ irq_chip->name = "GPIO-AINTC";
+ irq_chip->irq_set_type = gpio_irq_type_unbanked;

/* default trigger: both edges */

g = gpio2regs(0);
@@ -511,7 +537,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

/* set the direct IRQs up to use that irqchip */

for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_unbanked.chip);

+ irq_set_chip(irq, irq_chip);

irq_set_handler_data(irq, &chips[gpio / 32]);

irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}
@@ -554,7 +580,8 @@ done:

#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {
- { .compatible = "ti,dm6441-gpio", },

+ { .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
+ { .compatible = "ti,dm6441-gpio", davinci_gpio_get_irq_chip},

{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_gpio_ids);

[Santosh Shilimkar]

Linus, Sekhar,

On Thursday 12 December 2013 01:12 PM, Grygorii Strashko wrote:
> This series is intended to update Davinci GPIO driver and reuse
> it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci.
> Keystone GPIO IP: supports:
> - up to 32 GPIO lines;
> - only unbanked irqs;
>
> See Documentation:
> Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>
> This series depends on:
> [1] "[PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio"
> https://lkml.org/lkml/2013/11/8/22
> [2] "[PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement"
> https://www.mail-archive.com/devic...@vger.kernel.org/msg05970.html
> [3] "gpio: davinci: get rid of DAVINCI_N_GPIO"
> https://lkml.org/lkml/2013/11/26/405
> [4] "gpio: introduce GPIO_DAVINCI kconfig option"
> https://lkml.org/lkml/2013/11/26/435
> [5] "gpio: davinci: use chained_irq_enter/chained_irq_exit API"
> https://lkml.org/lkml/2013/11/26/428
>
> To handle all dependencies, I've created a branch where I collected all
> "ready to merge" patches (all acks added in patches) and this series:
> - https://github.com/grygoriyS/linux.git
> - branch: keystone-master-gpio-for-next
>

Can one of you pull all these patches ?

If needed I can take these patches to arm-soc with Linus's ack
or can prepare a pull request which Linus W can pull from from.

Regards,
Santosh

[Sekhar Nori]

On Friday 29 November 2013 02:03 PM, Linus Walleij wrote:
> On Thu, Nov 21, 2013 at 4:34 PM, Grygorii Strashko
> <grygorii...@ti.com> wrote:
>
>> Since Davinci GPIO driver is moved to support gpiolib it has to use
>> ARCH_NR_GPIOS (can be configured using CONFIG_ARCH_NR_GPIO Kconfig
>> option) configuration instead of any mach/platform specific options.
>>
>> Hence, replace private DAVINCI_N_GPIO with common ARCH_NR_GPIOS. This is
>> safe because default value for ARCH_NR_GPIOS=256 and maximum number of
>> supported GPIOs for Davinci is DAVINCI_N_GPIO=144.
>>
>> More over, this is one of steps to re-use Davinci GPIO driver by other
>> mach/platform.
>>
>> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
>
> Acked-by: Linus Walleij <linus....@linaro.org>

Added to v3.14/gpio of my k.org tree with Prabhakar's, Santosh's and
your acks.

>
> Now we have a handful of people patching DaVinci GPIOs...
>
> Sekhar: can you coordinate the different DaVinci patches? If you want me
> to take a complete set of stuff at the end of the day you can give me a
> pull request for inclusion into the GPIO tree.

Will do.

Thanks,
Sekhar

[Sekhar Nori]

On Friday 29 November 2013 02:05 PM, Linus Walleij wrote:
> On Thu, Nov 21, 2013 at 4:34 PM, Grygorii Strashko
> <grygorii...@ti.com> wrote:
>
>> The compatible to Davinci GPIO HW block is used by other TI SoCs, like
>> Keystone, where GPIO support is declared as optional.
>>
>> Hence, introduce GPIO_DAVINCI Kconfig option which will allow to enable
>> Davinci GPIO driver for Keystone SoCs when needed. At same time, kept
>> Davinci GPIO driver enabled for Davinci SoCs by default.
>>
>> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
>
> Acked-by: Linus Walleij <linus....@linaro.org>
>
> Sekhar, same comment here.

Queuing this with your's, Santosh's and Prabhakar's acks.

Thanks,
Sekhar

[Sekhar Nori]

On Wednesday 27 November 2013 01:10 AM, Grygorii Strashko wrote:
> It's unsafe to call IRQ chip callbacks (.irq_mask/irq_unmask/irq_ack)
> from chained IRQ handler directly. Because, Davinci GPIO block is used
> by different SoCs, which, in turn, have different Main IRQ controllers
> (Davinci - aintc, cp-intc; Keystone - arm-gic) which may introduce
> diffrent set of IRQ chip callbacks. As result, call of
> gpio_irq_handler() on Keysone will simply cause crash the system,
> because ARM-GIC implements .irq_eoi() instead of .irq_ack().
>
> Hence, fix it by using Kernel chained_irq_enter/chained_irq_exit APIs as
> they are intended to handle exact such cases.
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

Queued with Linus's and Santosh's acks.

[Sekhar Nori]

On Sunday 15 December 2013 07:20 PM, Sekhar Nori wrote:

> So I went through my backlog and queued all that I think is ready. Here
> is the branch. Let me know if there is anything else missing.

Forgot to mention that I have not been able to test them today though.
They will hit linux-next only after I have been able to test them and I
send a pull request to arm-soc or Linus W.

Thanks,
Sekhar

[Sekhar Nori]

On Sunday 15 December 2013 12:41 AM, Santosh Shilimkar wrote:

So I went through my backlog and queued all that I think is ready. Here
is the branch. Let me know if there is anything else missing.

https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio

Thanks,
Sekhar

[Alexandre Courbot]

Do you intend this pr_err() to remain here?

According to the other renamings I see in this file, shouldn't the
string also be changed to "GPIO-INTC"?

[Grygorii Strashko]

Looks like everything are in place. Thanks.

>
> Forgot to mention that I have not been able to test them today though.
> They will hit linux-next only after I have been able to test them and I
> send a pull request to arm-soc or Linus W.
>

Regards,
-grygorii

[Grygorii Strashko]

No, thanks - will remove.

Right. Will change, it should be more generic now.

I'll wait a bit for other comments and resend.

Regards,
-grygorii

[Santosh Shilimkar]

The $subject series (2 patches) don't seems to be on your branch.

Regards,
Santosh

[Santosh Shilimkar]

On Thursday 12 December 2013 01:12 PM, Grygorii Strashko wrote:

> The system may crash if:
> - there are more then 1 bank
> - unbanked irqs are enabled
> - someone will call gpio_to_irq() for GPIO from bank2 or above
>
> Hence, fix it by not creating irq_domain if unbanked irqs are enabled
> and correct gpio_to_irq_banked() to handle this properly.
>
> CC: Linus Walleij <linus....@linaro.org>
> CC: Sekhar Nori <nse...@ti.com>
> CC: Santosh Shilimkar <santosh....@ti.com>
>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
> ---

Acked-by: Santosh Shilimkar <santosh....@ti.com>

[Santosh Shilimkar]

On Thursday 12 December 2013 01:12 PM, Grygorii Strashko wrote:

and if the DT node is not populated ?

>
> ngpio = pdata->ngpio;
> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> @@ -442,7 +472,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
> }
>
> bank_irq = res->start;
> -

stray change..

> if (!bank_irq) {
> dev_err(dev, "Invalid IRQ resource\n");
> return -ENODEV;
> @@ -484,25 +513,22 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
> }
>
> /*
> - * AINTC can handle direct/unbanked IRQs for GPIOs, with the GPIO
> + * INTC can handle direct/unbanked IRQs for GPIOs, with the GPIO

So you want to have a generic name here. If you are changing it, change it
across the driver in a separate patch or leave it as is...
I don't think it matters much..

With those comments addressed, you can add my ack.
Acked-by: Santosh Shilimkar <santosh....@ti.com>

[Santosh Shilimkar]

Ofcourse Linus needs to ack them before they can be considered.
I have couple of comments as well so refresh of the series
would be needed.

Linus, Can you also please look at them.

[Grygorii Strashko]

Uh. Ok. I'll drop renaming.

[Grygorii Strashko]

This series is intended to update Davinci GPIO driver and reuse
it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci.
Keystone GPIO IP: supports:
- up to 32 GPIO lines;
- only unbanked irqs;

See Documentation:
Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf

This series based on:
https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio

Changes in v2:
- minor comments applied, no functional changes

v1: https://lkml.org/lkml/2013/12/12/366

Cc: Linus Walleij <linus....@linaro.org>
Cc: Alexandre Courbot <gnu...@gmail.com>
Cc: Sekhar Nori <nse...@ti.com>
Cc: Santosh Shilimkar <santosh....@ti.com>

Grygorii Strashko (2):
gpio: davinci: don't create irq_domain in case of unbanked irqs
gpio: davinci: reuse for Keystone SoC

.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-

drivers/gpio/gpio-davinci.c | 80 ++++++++++++++------
2 files changed, 59 insertions(+), 25 deletions(-)

--
1.7.9.5

[Grygorii Strashko]

The system may crash if:
- there are more then 1 bank
- unbanked irqs are enabled
- someone will call gpio_to_irq() for GPIO from bank2 or above

Hence, fix it by not creating irq_domain if unbanked irqs are enabled
and correct gpio_to_irq_banked() to handle this properly.

Cc: Linus Walleij <linus....@linaro.org>
Cc: Alexandre Courbot <gnu...@gmail.com>
Cc: Sekhar Nori <nse...@ti.com>

Acked-by: Santosh Shilimkar <santosh....@ti.com>

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

drivers/gpio/gpio-davinci.c | 34 +++++++++++++++++++---------------
1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 5d163c0..1b33806 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c

@@ -351,7 +351,10 @@ static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
{
struct davinci_gpio_controller *d = chip2controller(chip);

- return irq_create_mapping(d->irq_domain, d->chip.base + offset);
+ if (d->irq_domain)
+ return irq_create_mapping(d->irq_domain, d->chip.base + offset);
+ else
+ return -ENXIO;
}

static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)

@@ -429,7 +432,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);

struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;

- struct irq_domain *irq_domain;
+ struct irq_domain *irq_domain = NULL;

ngpio = pdata->ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

@@ -453,18 +456,20 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
}
clk_prepare_enable(clk);

- irq = irq_alloc_descs(-1, 0, ngpio, 0);
- if (irq < 0) {
- dev_err(dev, "Couldn't allocate IRQ numbers\n");

- return irq;

[Grygorii Strashko]

The similar GPIO HW block is used by keystone SoCs as
in Davinci SoCs.
Hence, reuse Davinci GPIO driver for Keystone taking into
account that Keystone contains ARM GIC IRQ controller which
is implemented using IRQ Chip.

Documentation:
http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf

Cc: Linus Walleij <linus....@linaro.org>
Cc: Alexandre Courbot <gnu...@gmail.com>
Cc: Sekhar Nori <nse...@ti.com>

Cc: devic...@vger.kernel.org

Acked-by: Santosh Shilimkar <santosh....@ti.com>
Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
drivers/gpio/gpio-davinci.c | 46 ++++++++++++++++----
2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d..4ce9862 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,7 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings

Required Properties:
-- compatible: should be "ti,dm6441-gpio"
+- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"

- reg: Physical base address of the controller and the size of memory mapped
registers.

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 1b33806..38741cc 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -413,6 +413,26 @@ static const struct irq_domain_ops davinci_gpio_irq_ops = {

.xlate = irq_domain_xlate_onetwocell,
};

+static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip_type gpio_unbanked;
+
+ gpio_unbanked = *container_of(irq_get_chip(irq),
+ struct irq_chip_type, chip);
+
+ return &gpio_unbanked.chip;
+};
+
+static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip gpio_unbanked;
+
+ gpio_unbanked = *irq_get_chip(irq);

+ return &gpio_unbanked;
+};
+
+static const struct of_device_id davinci_gpio_ids[];
+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()

@@ -433,6 +453,18 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;

struct irq_domain *irq_domain = NULL;

+ const struct of_device_id *match;
+ struct irq_chip *irq_chip;
+ struct irq_chip *(*gpio_get_irq_chip)(unsigned int irq);
+

+ /*
+ * Use davinci_gpio_get_irq_chip by default to handle non DT cases
+ */

+ gpio_get_irq_chip = davinci_gpio_get_irq_chip;
+ match = of_match_device(of_match_ptr(davinci_gpio_ids),
+ dev);
+ if (match)
+ gpio_get_irq_chip = match->data;

ngpio = pdata->ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

@@ -489,8 +521,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (pdata->gpio_unbanked) {
- static struct irq_chip_type gpio_unbanked;
-
/* pass "bank 0" GPIO IRQs to AINTC */
chips[0].chip.to_irq = gpio_to_irq_unbanked;
chips[0].gpio_irq = bank_irq;

@@ -499,10 +529,9 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

/* AINTC handles mask/unmask; GPIO handles triggering */

irq = bank_irq;
- gpio_unbanked = *container_of(irq_get_chip(irq),
- struct irq_chip_type, chip);
- gpio_unbanked.chip.name = "GPIO-AINTC";
- gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;
+ irq_chip = gpio_get_irq_chip(irq);
+ irq_chip->name = "GPIO-AINTC";

+ irq_chip->irq_set_type = gpio_irq_type_unbanked;

/* default trigger: both edges */
g = gpio2regs(0);

@@ -511,7 +540,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_unbanked.chip);
+ irq_set_chip(irq, irq_chip);
irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}

@@ -554,7 +583,8 @@ done:

#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {
- { .compatible = "ti,dm6441-gpio", },
+ { .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
+ { .compatible = "ti,dm6441-gpio", davinci_gpio_get_irq_chip},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_gpio_ids);

[Linus Walleij]

On Mon, Dec 16, 2013 at 5:39 PM, Santosh Shilimkar
<santosh....@ti.com> wrote:
> On Monday 16 December 2013 10:09 AM, Santosh Shilimkar wrote:

>> The $subject series (2 patches) don't seems to be on your branch.
>>
> Ofcourse Linus needs to ack them before they can be considered.
> I have couple of comments as well so refresh of the series
> would be needed.
>
> Linus, Can you also please look at them.

I'm looking, sorry for the delay. Busy before christmas.

Yours,
Linus Walleij

[Linus Walleij]

On Wed, Dec 18, 2013 at 11:07 AM, Grygorii Strashko
<grygorii...@ti.com> wrote:

> This series is intended to update Davinci GPIO driver and reuse
> it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci.
> Keystone GPIO IP: supports:
> - up to 32 GPIO lines;
> - only unbanked irqs;
>
> See Documentation:
> Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>
> This series based on:
> https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio
>
> Changes in v2:
> - minor comments applied, no functional changes
>
> v1: https://lkml.org/lkml/2013/12/12/366

Acked-by: Linus Walleij <linus....@linaro.org>

For this v2 series.

Expecting this to go in through the DaVinci tree!

Yours,
Linus Walleij

[Santosh Shilimkar]

On Friday 20 December 2013 04:40 AM, Linus Walleij wrote:
> On Wed, Dec 18, 2013 at 11:07 AM, Grygorii Strashko
> <grygorii...@ti.com> wrote:
>
>> This series is intended to update Davinci GPIO driver and reuse
>> it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci.
>> Keystone GPIO IP: supports:
>> - up to 32 GPIO lines;
>> - only unbanked irqs;
>>
>> See Documentation:
>> Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>>
>> This series based on:
>> https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio
>>
>> Changes in v2:
>> - minor comments applied, no functional changes
>>
>> v1: https://lkml.org/lkml/2013/12/12/366
>
> Acked-by: Linus Walleij <linus....@linaro.org>
>

Great !!

> For this v2 series.
>
> Expecting this to go in through the DaVinci tree!
>

Sekhar, Can you please include these to your DaVinci gpio branch ?

Regards,
Santosh

[Prabhakar Lad]

On Wed, Dec 18, 2013 at 3:37 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:
> The system may crash if:
> - there are more then 1 bank
> - unbanked irqs are enabled
> - someone will call gpio_to_irq() for GPIO from bank2 or above
>
> Hence, fix it by not creating irq_domain if unbanked irqs are enabled
> and correct gpio_to_irq_banked() to handle this properly.
>
> Cc: Linus Walleij <linus....@linaro.org>
> Cc: Alexandre Courbot <gnu...@gmail.com>
> Cc: Sekhar Nori <nse...@ti.com>
>
> Acked-by: Santosh Shilimkar <santosh....@ti.com>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

Acked-by: Lad, Prabhakar <prabhaka...@gmail.com>

Regards,
--Prabhakar Lad

[Prabhakar Lad]

On Wed, Dec 18, 2013 at 3:37 PM, Grygorii Strashko
<grygorii...@ti.com> wrote:

> The similar GPIO HW block is used by keystone SoCs as
> in Davinci SoCs.
> Hence, reuse Davinci GPIO driver for Keystone taking into
> account that Keystone contains ARM GIC IRQ controller which
> is implemented using IRQ Chip.
>
> Documentation:
> http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>
> Cc: Linus Walleij <linus....@linaro.org>
> Cc: Alexandre Courbot <gnu...@gmail.com>
> Cc: Sekhar Nori <nse...@ti.com>
> Cc: devic...@vger.kernel.org
>
> Acked-by: Santosh Shilimkar <santosh....@ti.com>
> Signed-off-by: Grygorii Strashko <grygorii...@ti.com>

Acked-by: Lad, Prabhakar <prabhaka...@gmail.com>

Regards,
--Prabhakar Lad

[Sekhar Nori]

Rob,

Can I get your ack for this change? Its pretty trivial, but still..

Thanks,
Sekhar

[Sekhar Nori]

On Wednesday 18 December 2013 03:37 PM, Grygorii Strashko wrote:

This produces a sparse warning:

CHECK drivers/gpio/gpio-davinci.c
drivers/gpio/gpio-davinci.c:467:35: warning: incorrect type in assignment (different modifiers)
drivers/gpio/gpio-davinci.c:467:35: expected struct irq_chip *( *[assigned] gpio_get_irq_chip )( ... )
drivers/gpio/gpio-davinci.c:467:35: got void const *const data

Thanks,
Sekhar

[Sekhar Nori]

On Wednesday 18 December 2013 03:37 PM, Grygorii Strashko wrote:

> The system may crash if:
> - there are more then 1 bank

s/then/than

The code was correct before moving. Any objections to doing

return irq;

instead?

Thanks,
Sekhar

[Grygorii Strashko]

I'll fix it, thanks.

[Grygorii Strashko]

This is mistake. I'll update. Thanks

[Grygorii Strashko]

The system may crash if:

- there are more than 1 bank

- unbanked irqs are enabled
- someone will call gpio_to_irq() for GPIO from bank2 or above

Hence, fix it by not creating irq_domain if unbanked irqs are enabled
and correct gpio_to_irq_banked() to handle this properly.

Cc: Alexandre Courbot <gnu...@gmail.com>
Cc: Sekhar Nori <nse...@ti.com>

Acked-by: Santosh Shilimkar <santosh....@ti.com>

Acked-by: Linus Walleij <linus....@linaro.org>

Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---
drivers/gpio/gpio-davinci.c | 34 +++++++++++++++++++---------------
1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c

index 5d163c0..7629b4f 100644

+ return irq;

+ }

- irq_domain = irq_domain_add_legacy(NULL, ngpio, irq, 0,
- &davinci_gpio_irq_ops,
- chips);
- if (!irq_domain) {
- dev_err(dev, "Couldn't register an IRQ domain\n");
- return -ENODEV;
+ irq_domain = irq_domain_add_legacy(NULL, ngpio, irq, 0,
+ &davinci_gpio_irq_ops,
+ chips);
+ if (!irq_domain) {

+ dev_err(dev, "Couldn't register an IRQ domain\n");
+ return -ENODEV;

+ }
}

/*
@@ -475,8 +480,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
*/
for (gpio = 0, bank = 0; gpio < ngpio; bank++, gpio += 32) {
chips[bank].chip.to_irq = gpio_to_irq_banked;
- if (!pdata->gpio_unbanked)
- chips[bank].irq_domain = irq_domain;
+ chips[bank].irq_domain = irq_domain;
}

/*
--
1.7.9.5

[Grygorii Strashko]

This series is intended to update Davinci GPIO driver and reuse
it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci.
Keystone GPIO IP: supports:
- up to 32 GPIO lines;
- only unbanked irqs;

See Documentation:
Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf

This series based on:
https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio

Changes in v3:
- fixed code, changed by mistake; fixed sparse warning

Changes in v2:
- minor comments applied, no functional changes

v2: https://lkml.org/lkml/2013/12/18/135

v1: https://lkml.org/lkml/2013/12/12/366

Cc: Linus Walleij <linus....@linaro.org>

Cc: Alexandre Courbot <gnu...@gmail.com>
Cc: Sekhar Nori <nse...@ti.com>

Cc: Santosh Shilimkar <santosh....@ti.com>

Grygorii Strashko (2):
gpio: davinci: don't create irq_domain in case of unbanked irqs
gpio: davinci: reuse for Keystone SoC

.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-

drivers/gpio/gpio-davinci.c | 82 ++++++++++++++------
2 files changed, 61 insertions(+), 25 deletions(-)

[Grygorii Strashko]

The similar GPIO HW block is used by keystone SoCs as
in Davinci SoCs.
Hence, reuse Davinci GPIO driver for Keystone taking into
account that Keystone contains ARM GIC IRQ controller which
is implemented using IRQ Chip.

Documentation:
http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf

Cc: Alexandre Courbot <gnu...@gmail.com>
Cc: Sekhar Nori <nse...@ti.com>

Cc: devic...@vger.kernel.org

Acked-by: Santosh Shilimkar <santosh....@ti.com>
Acked-by: Linus Walleij <linus....@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii...@ti.com>
---

.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
drivers/gpio/gpio-davinci.c | 48 ++++++++++++++++----
2 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d..4ce9862 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,7 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings

Required Properties:
-- compatible: should be "ti,dm6441-gpio"
+- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"

- reg: Physical base address of the controller and the size of memory mapped
registers.

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 7629b4f..d0f135d 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -37,6 +37,8 @@ struct davinci_gpio_regs {
u32 intstat;
};

+typedef struct irq_chip *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
+
#define BINTEN 0x8 /* GPIO Interrupt Per-Bank Enable Register */

#define chip2controller(chip) \
@@ -413,6 +415,26 @@ static const struct irq_domain_ops davinci_gpio_irq_ops = {

.xlate = irq_domain_xlate_onetwocell,
};

+static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip_type gpio_unbanked;
+
+ gpio_unbanked = *container_of(irq_get_chip(irq),
+ struct irq_chip_type, chip);
+
+ return &gpio_unbanked.chip;
+};
+
+static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip gpio_unbanked;
+
+ gpio_unbanked = *irq_get_chip(irq);
+ return &gpio_unbanked;
+};
+
+static const struct of_device_id davinci_gpio_ids[];
+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()

@@ -433,6 +455,18 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;

struct irq_domain *irq_domain = NULL;

+ const struct of_device_id *match;
+ struct irq_chip *irq_chip;

+ gpio_get_irq_chip_cb_t gpio_get_irq_chip;

+
+ /*
+ * Use davinci_gpio_get_irq_chip by default to handle non DT cases
+ */
+ gpio_get_irq_chip = davinci_gpio_get_irq_chip;
+ match = of_match_device(of_match_ptr(davinci_gpio_ids),
+ dev);
+ if (match)

+ gpio_get_irq_chip = (gpio_get_irq_chip_cb_t)match->data;

ngpio = pdata->ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

@@ -489,8 +523,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (pdata->gpio_unbanked) {
- static struct irq_chip_type gpio_unbanked;
-
/* pass "bank 0" GPIO IRQs to AINTC */
chips[0].chip.to_irq = gpio_to_irq_unbanked;
chips[0].gpio_irq = bank_irq;

@@ -499,10 +531,9 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

/* AINTC handles mask/unmask; GPIO handles triggering */
irq = bank_irq;
- gpio_unbanked = *container_of(irq_get_chip(irq),
- struct irq_chip_type, chip);
- gpio_unbanked.chip.name = "GPIO-AINTC";
- gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;
+ irq_chip = gpio_get_irq_chip(irq);
+ irq_chip->name = "GPIO-AINTC";
+ irq_chip->irq_set_type = gpio_irq_type_unbanked;

/* default trigger: both edges */
g = gpio2regs(0);

@@ -511,7 +542,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)

/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_unbanked.chip);
+ irq_set_chip(irq, irq_chip);
irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}

@@ -554,7 +585,8 @@ done:

#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {
- { .compatible = "ti,dm6441-gpio", },
+ { .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
+ { .compatible = "ti,dm6441-gpio", davinci_gpio_get_irq_chip},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_gpio_ids);

[Prabhakar Lad]

Hi Grygorii,

Thanks for the patch.

Can you make it something like this ? It isn't readable.

- compatible : value should be either one among the following
(a) "ti,dm6441-gpio" for davinci.
(b) "ti,keystone-gpio" for keystone.

Sorry didn't notice that earlier the data structure of_match_ptr()
protects is always compiled in.
so of_match_ptr() is not needed.
While you are at it you can also fix it in davinci_gpio_driver
structure as a sperate
patch.

Regards,
--Prabhakar Lad

[Grygorii Strashko]

Not sure. davinci_gpio_ids defined as:

#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {

And seems, Davinci may still be compiled without OF enabled.

Regards,
- grygorii

[Prabhakar Lad]

On Tue, Dec 24, 2013 at 6:57 PM, Grygorii Strashko

My Bad, yes its gaurded by CONFIG_OF so my above suggestion doesn't hold good.

Thanks,
--Prabhakar Lad

[Grygorii Strashko]

Hi Rob,

Do you agree with this bindings changes?
They are very simple

[Santosh Shilimkar]

Sekhar,

Have you picked up the $subject series in your queue ?

Regards,
Santosh

[Sekhar Nori]

Not yet, at least on the new compatible introduction, I need an ack from
DT folks.

I am happy with the patches though and have tested them as well, In case
I do not get an ack from 2/2 in time, I can at least send 1/2 for
inclusion after my first gpio pull request to ARM-SoC gets pulled.

Thanks,
Sekhar

[Santosh Shilimkar]

I noticed that but the usual 2 weeks period to get ack is over I guess ;-)
The DT part is really trivial as well but I let you decide.

> I am happy with the patches though and have tested them as well, In case
> I do not get an ack from 2/2 in time, I can at least send 1/2 for
> inclusion after my first gpio pull request to ARM-SoC gets pulled.
>

Would be great to get both of them but if not both at least 1/2.

Regards,
Santosh

[Sekhar Nori]

I just realize that Rob's e-mail address bounces. I have added his
updated address now and hopefully he will see this to provide his ack.

Rob,

We need your ack on 2/2 of this series. If you do not have the patch, I
can forward it to you.

>
>> I am happy with the patches though and have tested them as well, In case
>> I do not get an ack from 2/2 in time, I can at least send 1/2 for
>> inclusion after my first gpio pull request to ARM-SoC gets pulled.
>>
> Would be great to get both of them but if not both at least 1/2.

I had already sent it with my first pull request. Hmph. Everything
except 2/2 of tis series should be in linux-next now.

Thanks,
Sekhar

[Santosh Shilimkar]

Thanks !!