[RFC v1 0/9] gpio: davinci: reuse for keystone arch

[RFC v1 0/9] gpio: davinci: reuse for keystone arch

[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/devicetree@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(-)

-- 
1.7.9.5

[RFC v1 2/9] gpio: introduce GPIO_DAVINCI kconfig option

[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.strashko@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
-- 
1.7.9.5

Re: [RFC v1 2/9] gpio: introduce GPIO_DAVINCI kconfig option

[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.strashko@ti.com>
> ---
Already acked

[RFC v1 1/9] gpio: davinci: get rid of DAVINCI_N_GPIO

[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.strashko-l0cyMroinI0@public.gmane.org>
---
 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),
-- 
1.7.9.5

Re: [RFC v1 1/9] gpio: davinci: get rid of DAVINCI_N_GPIO

[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.strashko@ti.com>
> ---
Looks like you just combined the two earlier patches you have posted.
Ack applies here as well.

regards,
Santosh

[RFC v1 3/9] gpio: davinci: use chained_irq_enter/chained_irq_exit API

[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.strashko-l0cyMroinI0@public.gmane.org>
---
 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 */
 }
 
-- 
1.7.9.5

Re: [RFC v1 3/9] gpio: davinci: use chained_irq_enter/chained_irq_exit API

[Linus Walleij]

On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
<grygorii.strashko@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.strashko@ti.com>

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

Yours,
Linus Walleij

Re: [RFC v1 3/9] gpio: davinci: use chained_irq_enter/chained_irq_exit API

[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.strashko-l0cyMroinI0@public.gmane.org>
> ---
>
Acked-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>

Re: [RFC v1 3/9] gpio: davinci: use chained_irq_enter/chained_irq_exit API

[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.strashko@ti.com>

Queued with Linus's and Santosh's acks.

Thanks,
Sekhar

[RFC v1 4/9] gpio: davinci: make IRQ initialization soc specific

[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.strashko-l0cyMroinI0@public.gmane.org>
---
 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);
-- 
1.7.9.5

Re: [RFC v1 4/9] gpio: davinci: make IRQ initialization soc specific

[Linus Walleij]

On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
<grygorii.strashko@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

Re: [RFC v1 4/9] gpio: davinci: make IRQ initialization soc specific

[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.strashko@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.strashko@ti.com>
> ---
NAK. Lets drop this approach. Its easier to manage the
banked vs unbaked based on compatible as discussed over irc

Regards,
Santosh

[RFC v1 5/9] gpio: davinci: reuse for Keystone SoC

[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.strashko-l0cyMroinI0@public.gmane.org>
---
 .../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);
-- 
1.7.9.5

Re: [RFC v1 5/9] gpio: davinci: reuse for Keystone SoC

[Linus Walleij]

On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
<grygorii.strashko@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.strashko@ti.com>

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

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

Yours,
Linus Walleij

Re: [RFC v1 5/9] gpio: davinci: reuse for Keystone SoC

[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.strashko-l0cyMroinI0@public.gmane.org> 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.strashko-l0cyMroinI0@public.gmane.org>
> 
> 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

[RFC v1 6/9] arm: dts: keystone: add GPIO device entry

[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.strashko@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>;
+		};
 	};
 };
-- 
1.7.9.5

Re: [RFC v1 6/9] arm: dts: keystone: add GPIO device entry

[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.strashko@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

[RFC v1 7/9] ARM: keystone_defconfig: enable gpio support

[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.strashko@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
-- 
1.7.9.5

[RFC v1 8/9] arm: dts: keystone-evm: add LEDs supports

[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.strashko@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 */
+		};
+	};
 };
-- 
1.7.9.5

[RFC v1 9/9] ARM: keystone_defconfig: enable LED support

[Grygorii Strashko]

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

Signed-off-by: Grygorii Strashko <grygorii.strashko@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
-- 
1.7.9.5

Re: [RFC v1 0/9] gpio: davinci: reuse for keystone arch

[Linus Walleij]

On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
<grygorii.strashko@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/devicetree@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

Re: [RFC v1 0/9] gpio: davinci: reuse for keystone arch

[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.strashko@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/devicetree@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

Re: [RFC v1 0/9] gpio: davinci: reuse for keystone arch

[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.strashko@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/devicetree@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

Re: [RFC v1 0/9] gpio: davinci: reuse for keystone arch

[Prabhakar Lad]

Hi Grygorii,

Thanks for the patches.

On Wed, Nov 27, 2013 at 1:10 AM, Grygorii Strashko
<grygorii.strashko@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
>
> [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/devicetree@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
>
For patches 1, 2 and 3

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

Regards,
--Prabhakar Lad