Re: [PATCH 1/2] net: davinci_mdio: reuse for keystone2 arch
On Wednesday 09 July 2014 09:10 AM, Grygorii Strashko wrote:
The similar MDIO HW blocks is used by keystone 2 SoCs as
in Davinci SoCs:
- one in Gigabit Ethernet (GbE) Switch Subsystem
See http://www.ti.com/lit/ug/sprugv9d/sprugv9d.pdf
- one in 10 Gigabit Ethernet Subsystem
See http://www.ti.com/lit/ug/spruhj5/spruhj5.pdf
Hence, reuse Davinci MDIO driver for Keystone 2 and
enable TI networking for Keystone 2 devices
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
Looks good to me.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
.../devicetree/bindings/net/davinci-mdio.txt |8
drivers/net/ethernet/ti/Kconfig|4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/davinci-mdio.txt
b/Documentation/devicetree/bindings/net/davinci-mdio.txt
index 72efaaf..d2e68e7 100644
--- a/Documentation/devicetree/bindings/net/davinci-mdio.txt
+++ b/Documentation/devicetree/bindings/net/davinci-mdio.txt
@@ -1,8 +1,8 @@
-TI SoC Davinci MDIO Controller Device Tree Bindings
+TI SoC Davinci/Keystone2 MDIO Controller Device Tree Bindings
---
Required properties:
-- compatible : Should be ti,davinci_mdio
+- compatible : Should be ti,davinci_mdio or ti,keystone-mdio
- reg: physical base address and size of the davinci
mdio
registers map
- bus_freq : Mdio Bus frequency
@@ -19,7 +19,7 @@ file.
Examples:
mdio: davinci_mdio@4A101000 {
- compatible = ti,cpsw;
+ compatible = ti,davinci_mdio;
reg = 0x4A101000 0x1000;
bus_freq = 100;
};
@@ -27,7 +27,7 @@ Examples:
(or)
mdio: davinci_mdio@4A101000 {
- compatible = ti,cpsw;
+ compatible = ti,davinci_mdio;
ti,hwmods = davinci_mdio;
bus_freq = 100;
};
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 53150c2..1769700 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -5,7 +5,7 @@
config NET_VENDOR_TI
bool Texas Instruments (TI) devices
default y
- depends on PCI || EISA || AR7 || (ARM (ARCH_DAVINCI || ARCH_OMAP3 ||
SOC_AM33XX))
+ depends on PCI || EISA || AR7 || (ARM (ARCH_DAVINCI || ARCH_OMAP3 ||
SOC_AM33XX || ARCH_KEYSTONE))
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -32,7 +32,7 @@ config TI_DAVINCI_EMAC
config TI_DAVINCI_MDIO
tristate TI DaVinci MDIO Support
- depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 || SOC_AM33XX )
+ depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 || SOC_AM33XX ||
ARCH_KEYSTONE )
select PHYLIB
---help---
This driver supports TI's DaVinci MDIO module.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] net: davinci_mdio: allow to create phys from dt
On Wednesday 09 July 2014 09:10 AM, Grygorii Strashko wrote:
This patch allows to create PHYs from DT in case
if they are explicitly defined. The of_mdiobus_register() is
used for such purposes.
For backward compatibility, call of_mdiobus_register() only in case
if at least one PHY's child is defined in DT, otherwise rollback to
mdiobus_register().
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/net/ethernet/ti/davinci_mdio.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
b/drivers/net/ethernet/ti/davinci_mdio.c
index 735dc53..22d3dab 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -38,6 +38,7 @@
#include linux/davinci_emac.h
#include linux/of.h
#include linux/of_device.h
+#include linux/of_mdio.h
#include linux/pinctrl/consumer.h
/*
@@ -95,6 +96,7 @@ struct davinci_mdio_data {
struct mii_bus *bus;
boolsuspended;
unsigned long access_time; /* jiffies */
+ boolskip_scan;
The vairiable name is not too intutive so probably add a little
bit description on what are you skipping with it.
};
static void __davinci_mdio_reset(struct davinci_mdio_data *data)
@@ -144,6 +146,9 @@ static int davinci_mdio_reset(struct mii_bus *bus)
dev_info(data-dev, davinci mdio revision %d.%d\n,
(ver 8) 0xff, ver 0xff);
+ if (data-skip_scan)
+ return 0;
+
/* get phy mask from the alive register */
phy_mask = __raw_readl(data-regs-alive);
if (phy_mask) {
@@ -369,8 +374,17 @@ static int davinci_mdio_probe(struct platform_device
*pdev)
goto bail_out;
}
- /* register the mii bus */
- ret = mdiobus_register(data-bus);
+ /* register the mii bus
+ * Create PHYs from DT only in case if PHY child nodes are explicitly
+ * defined to support backward compatibility with DTs which assume that
+ * Davinci MDIO will always scan the bus for PHYs detection.
+ */
multi line comment is not as per coding style. Please fix that.
Patch as such looks good to me so with those minor fixes, feel
free to append my review tag.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
+ if (dev-of_node of_get_child_count(dev-of_node)) {
+ data-skip_scan = true;
+ ret = of_mdiobus_register(data-bus, dev-of_node);
+ } else {
+ ret = mdiobus_register(data-bus);
+ }
if (ret)
goto bail_out;
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 0/4] introduce devm_mdiobus_alloc/free and clean up davinci mdio
On Wednesday 30 April 2014 08:23 AM, Grygorii Strashko wrote: Introduce a resource managed devm_mdiobus_alloc[_size]()/devm_mdiobus_free() to automatically clean up MDIO bus alocations made by MDIO drivers, thus leading to simplified MDIO drivers code. Clean up Davinci MDIO driver and use new devm API. Changes in v3: - added devm_mdiobus_alloc_size() and devm_mdiobus_alloc() converted to be just a simple wrapper now. Changes in v2: - minor comments taken into account - additional patches added for cleaning up Davinci MDIO driver Cc: Florian Fainelli f.faine...@gmail.com Grygorii Strashko (4): mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free net: davinci_mdio: use devm_* api net: davinci_mdio: drop pinctrl_pm_select_default_state from probe net: davinci_mdio: simplify IO memory mapping Thanks for the updates. The series looks good to me. Feel free to my ack if you need one... Acked-by: Santosh Shilimkarsantosh.shilim...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RESEND][PATCH v4] gpio: davinci: reuse for keystone soc
Linus,
On Thursday 13 February 2014 10:58 AM, Grygorii Strashko 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
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
- rebased on top of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
branch: devel
top commit: ef70bbe gpio: make gpiod_direction_output take a logical value
Can you please pick this one ? Its rebased as per your suggestion.
.../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
Re: [PATCH v3 0/2] gpio: davinci: reuse for keystone arch
On Thursday 09 January 2014 05:31 AM, Sekhar Nori wrote: On Wednesday 08 January 2014 07:38 PM, Santosh Shilimkar wrote: On Tuesday 07 January 2014 11:06 PM, Sekhar Nori wrote: On Tuesday 07 January 2014 11:22 PM, Santosh Shilimkar wrote: Sekhar, On Tuesday 24 December 2013 06:41 AM, 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 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.wall...@linaro.org Cc: Alexandre Courbot gnu...@gmail.com Cc: Sekhar Nori nsek...@ti.com Cc: Santosh Shilimkar santosh.shilim...@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(-) Have you picked up the $subject series in your queue ? Not yet, at least on the new compatible introduction, I need an ack from DT folks. 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 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 !! ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 0/2] gpio: davinci: reuse for keystone arch
On Tuesday 07 January 2014 11:06 PM, Sekhar Nori wrote: On Tuesday 07 January 2014 11:22 PM, Santosh Shilimkar wrote: Sekhar, On Tuesday 24 December 2013 06:41 AM, 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 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.wall...@linaro.org Cc: Alexandre Courbot gnu...@gmail.com Cc: Sekhar Nori nsek...@ti.com Cc: Santosh Shilimkar santosh.shilim...@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(-) Have you picked up the $subject series in your queue ? Not yet, at least on the new compatible introduction, I need an ack from DT folks. 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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 0/2] gpio: davinci: reuse for keystone arch
On Friday 20 December 2013 04:40 AM, Linus Walleij wrote: On Wed, Dec 18, 2013 at 11:07 AM, Grygorii Strashko grygorii.stras...@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.wall...@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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/2] gpio: davinci: reuse for keystone arch
On Sunday 15 December 2013 08:50 AM, Sekhar Nori wrote: On Sunday 15 December 2013 12:41 AM, Santosh Shilimkar wrote: 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/devicetree@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 ? 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. The $subject series (2 patches) don't seems to be on your branch. Regards, Santosh ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] gpio: davinci: don't create irq_domain in case of unbanked irqs
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.wall...@linaro.org CC: Sekhar Nori nsek...@ti.com CC: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] gpio: davinci: reuse for Keystone SoC
On Thursday 12 December 2013 01:12 PM, Grygorii Strashko 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.wall...@linaro.org
CC: Sekhar Nori nsek...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
CC: devicet...@vger.kernel.org
Signed-off-by: Grygorii Strashko grygorii.stras...@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;
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.shilim...@ti.com
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/2] gpio: davinci: reuse for keystone arch
On Monday 16 December 2013 10:09 AM, Santosh Shilimkar wrote: On Sunday 15 December 2013 08:50 AM, Sekhar Nori wrote: On Sunday 15 December 2013 12:41 AM, Santosh Shilimkar wrote: 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/devicetree@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 ? 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. 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. Regards, Santosh ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/2] gpio: davinci: reuse for keystone arch
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/devicetree@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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 0/9] gpio: davinci: reuse for keystone arch
Sekhar, On Friday 29 November 2013 03:37 AM, Linus Walleij wrote: On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko grygorii.stras...@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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 1/9] gpio: davinci: get rid of DAVINCI_N_GPIO
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.stras...@ti.com --- Looks like you just combined the two earlier patches you have posted. Ack applies here as well. regards, Santosh ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 3/9] gpio: davinci: use chained_irq_enter/chained_irq_exit API
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.stras...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 2/9] gpio: introduce GPIO_DAVINCI kconfig option
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.stras...@ti.com --- Already acked ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 4/9] gpio: davinci: make IRQ initialization soc specific
On Friday 29 November 2013 04:21 AM, Linus Walleij wrote:
On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko
grygorii.stras...@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.stras...@ti.com
---
NAK. Lets drop this approach. Its easier to manage the
banked vs unbaked based on compatible as discussed over irc
Regards,
Santosh
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 5/9] gpio: davinci: reuse for Keystone SoC
On Friday 29 November 2013 04:25 AM, Linus Walleij wrote: On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko grygorii.stras...@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.stras...@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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 6/9] arm: dts: keystone: add GPIO device entry
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.stras...@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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 00/14] DMA Engine support for AM33XX
On Friday 25 January 2013 02:19 AM, Matt Porter wrote: On Thu, Jan 24, 2013 at 05:12:05AM +, Shilimkar, Santosh wrote: On Thursday 24 January 2013 02:19 AM, Matt Porter wrote: On Wed, Jan 23, 2013 at 04:37:55PM +0530, Santosh Shilimkar wrote: Matt, On Wednesday 16 January 2013 02:02 AM, Matt Porter wrote: [...] Thanks for the catch, I'll add this in with your tested line as well for the series. BTW, since I'm dropping mmc support from this series, I'll move your patch into a separate series with only the mmc pieces. Fine by me ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 00/14] DMA Engine support for AM33XX
Matt,
On Wednesday 16 January 2013 02:02 AM, Matt Porter wrote:
[..]
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
The series applies on top of 3.8-rc3 and the following patches:
- TPS65910 REGMAP_IRQ build fix:
https://patchwork.kernel.org/patch/1857701/
- dmaengine DT support from Vinod's dmaengine_dt branch in
git://git.infradead.org/users/vkoul/slave-dma.git since
027478851791df751176398be02a3b1c5f6aa824
- edma dmaengine driver fix:
https://patchwork.kernel.org/patch/1961521/
- dmaengine dma_get_channel_caps v2:
https://patchwork.kernel.org/patch/1961601/
- dmaengine edma driver channel caps support v2:
https://patchwork.kernel.org/patch/1961591/
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.
With this series both BeagleBone and the AM335x EVM have working
MMC and SPI support.
This is tested on BeagleBone with a SPI framebuffer driver and MMC
rootfs. A trivial gpio DMA event misc driver was used to test the
crossbar DMA event support. It is also tested on the AM335x EVM
with the onboard SPI flash and MMC rootfs. The branch at
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v4
has the complete series, dependencies, and some test
drivers/defconfigs.
Regression testing was done on AM180x-EVM (which also makes use
of the EDMA dmaengine driver and the EDMA private API) using SD,
SPI flash, and the onboard audio supported by the ASoC Davinci
driver. Regression testing was also done on a BeagleBoard xM
booting from the legacy board file using MMC rootfs.
Matt Porter (14):
ARM: davinci: move private EDMA API to arm/common
ARM: edma: remove unused transfer controller handlers
ARM: edma: add AM33XX support to the private EDMA API
dmaengine: edma: enable build for AM33XX
dmaengine: edma: Add TI EDMA device tree binding
ARM: dts: add AM33XX EDMA support
dmaengine: add dma_request_slave_channel_compat()
mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
mmc: omap_hsmmc: set max_segs based on dma engine limitations
mmc: omap_hsmmc: add generic DMA request support to the DT binding
ARM: dts: add AM33XX MMC support
spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
spi: omap2-mcspi: add generic DMA request support to the DT binding
ARM: dts: add AM33XX SPI DMA support
While going through the series and testing it out, I observed an issue
with MMC driver. You need patch in the end of the email to avoid the
issue. Same is attached in case mailer damages it. Can you please
add it with your series if you agree ?
Overall the series looks good to my eyes.
Acked-tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Regards,
Santosh
From 2dcc90b7a4b2dcdb52ddd052ca7f3e88a78e83e4 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 23 Jan 2013 16:04:32 +0530
Subject: [PATCH] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt
case
MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.
Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f74bd69..d4655e7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1897,21 +1897,23 @@ static int omap_hsmmc_probe(struct
platform_device *pdev)
omap_hsmmc_conf_bus_power(host);
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
- if (!res) {
- dev_err(mmc_dev(host-mmc), cannot get DMA TX channel\n);
- ret = -ENXIO;
- goto err_irq;
- }
- tx_req = res-start;
+ if (!pdev-dev.of_node) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA TX
channel\n);
+ ret = -ENXIO
Re: [PATCH v5 00/14] DMA Engine support for AM33XX
On Thursday 24 January 2013 02:19 AM, Matt Porter wrote: On Wed, Jan 23, 2013 at 04:37:55PM +0530, Santosh Shilimkar wrote: Matt, On Wednesday 16 January 2013 02:02 AM, Matt Porter wrote: [..] This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. The series applies on top of 3.8-rc3 and the following patches: - TPS65910 REGMAP_IRQ build fix: https://patchwork.kernel.org/patch/1857701/ - dmaengine DT support from Vinod's dmaengine_dt branch in git://git.infradead.org/users/vkoul/slave-dma.git since 027478851791df751176398be02a3b1c5f6aa824 - edma dmaengine driver fix: https://patchwork.kernel.org/patch/1961521/ - dmaengine dma_get_channel_caps v2: https://patchwork.kernel.org/patch/1961601/ - dmaengine edma driver channel caps support v2: https://patchwork.kernel.org/patch/1961591/ The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. With this series both BeagleBone and the AM335x EVM have working MMC and SPI support. This is tested on BeagleBone with a SPI framebuffer driver and MMC rootfs. A trivial gpio DMA event misc driver was used to test the crossbar DMA event support. It is also tested on the AM335x EVM with the onboard SPI flash and MMC rootfs. The branch at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v4 has the complete series, dependencies, and some test drivers/defconfigs. Regression testing was done on AM180x-EVM (which also makes use of the EDMA dmaengine driver and the EDMA private API) using SD, SPI flash, and the onboard audio supported by the ASoC Davinci driver. Regression testing was also done on a BeagleBoard xM booting from the legacy board file using MMC rootfs. Matt Porter (14): ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add AM33XX support to the private EDMA API dmaengine: edma: enable build for AM33XX dmaengine: edma: Add TI EDMA device tree binding ARM: dts: add AM33XX EDMA support dmaengine: add dma_request_slave_channel_compat() mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: set max_segs based on dma engine limitations mmc: omap_hsmmc: add generic DMA request support to the DT binding ARM: dts: add AM33XX MMC support spi: omap2-mcspi: convert to dma_request_slave_channel_compat() spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add AM33XX SPI DMA support While going through the series and testing it out, I observed an issue with MMC driver. You need patch in the end of the email to avoid the issue. Same is attached in case mailer damages it. Can you please add it with your series if you agree ? Yes, by inspection this makes sense. As you noticed, we've been relying on the fact that DMA resources still don't come from DT, we only use our DT data in conjunction with the DMA OF helpers to do channel filtering. I was figuring we would address that separately later, but I see how even omap4 has this issue with DMA resources named with tx1, for example. A good followup once this series is taken will be to only use hwmod resources on a !populated-dt platform like we do for other resources now. Baby steps. :) We are already on it :-) Thanks for the catch, I'll add this in with your tested line as well for the series. Thanks. Regards, Santosh ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v2 PATCH 1/2] memory: davinci - add aemif controller platform driver
On Tuesday 06 November 2012 03:47 PM, Murali Karicheri wrote:
This is a platform driver for asynchronous external memory interface
available on TI SoCs. This driver was previously located inside the
mach-davinci folder. As this DaVinci IP is re-used across multiple
family of devices such as c6x, keystone etc, the driver is moved to drivers.
The driver configures async bus parameters associated with a particular
chip select. For DaVinci NAND controller driver and driver for other async
devices such as NOR flash, ASRAM etc, the bus confuguration is
done by this driver at probe. A set of APIs (set/get) are provided to
update the values based on specific driver usage.
This supports configuration of the bus either through platform_data or
through DT bindings.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
.../devicetree/bindings/memory/davinci-aemif.txt | 103 +
drivers/memory/Kconfig | 10 +
drivers/memory/Makefile|1 +
drivers/memory/davinci-aemif.c | 479
include/linux/platform_data/davinci-aemif.h| 47 ++
5 files changed, 640 insertions(+)
create mode 100644 Documentation/devicetree/bindings/memory/davinci-aemif.txt
create mode 100644 drivers/memory/davinci-aemif.c
create mode 100644 include/linux/platform_data/davinci-aemif.h
Please split the DT and drivers/memory/* changes in two seperate
patches.
diff --git a/Documentation/devicetree/bindings/memory/davinci-aemif.txt
b/Documentation/devicetree/bindings/memory/davinci-aemif.txt
new file mode 100644
index 000..a79b3ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory/davinci-aemif.txt
@@ -0,0 +1,103 @@
+* Texas Instruments Davinci AEMIF bus interface
+
+This file provides information for the davinci-emif device and
+async bus bindings.
+
+Required properties:=
+- compatible: ti,davinci-aemif;
+- #address-cells : Should be either two or three. The first cell is the
+ chipselect number, and the remaining cells are the
+ offset into the chipselect.
+- #size-cells : Either one or two, depending on how large each chipselect
+can be.
+- reg : contains offset/length value for AEMIF control registers space
+- ranges : Each range corresponds to a single chipselect, and cover
+ the entire access window as configured.
+
+Child device nodes describe the devices connected to IFC such as NOR (e.g.
+cfi-flash) and NAND (ti,davinci-nand, see Documentation/devicetree/bindings/
+mtd/davinci-nand.txt). There might be board specific devices like FPGAs.
+
+In addition, optional child sub nodes contains bindings for the async bus
+interface for a given chip select.
+
+Optional cs node properties:-
+- compatible: ti,davinci-cs
+
+ All of the params below in nanoseconds and are optional
+
+- ti,davinci-cs-asize - asynchronous data bus width (0 - 8bit, 1 - 16 bit)
+- ti,davinci-cs-ta - Minimum turn around time
+- ti,davinci-cs-rhold - read hold width
+- ti,davinci-cs-rstobe - read strobe width
+- ti,davinci-cs-rsetup - read setup width
+- ti,davinci-cs-whold - write hold width
+- ti,davinci-cs-wstrobe - write strobe width
+- ti,davinci-cs-wsetup - write setup width
+- ti,davinci-cs-ss - enable/disable select strobe (0 - disable, 1 - enable)
+- ti,davinci-cs-ew - enable/disable extended wait cycles (0 - disable, 1 -
enable)
+
+if any of the above parameters are absent, hardware register default or that
+set by a boot loader are used.
+
+Example for aemif, davinci nand and nor flash chip select shown below.
+
+aemif@6000 {
+ compatible = ti,davinci-aemif;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0x6800 0x8;
+ ranges = 2 0 0x6000 0x0200
+ 3 0 0x6200 0x0200
+ 4 0 0x6400 0x0200
+ 5 0 0x6600 0x0200
+ 6 0 0x6800 0x0200;
+
+ nand_cs:cs2@6000 {
+ compatible = ti,davinci-cs;
+ #address-cells = 1;
+ #size-cells = 1;
+ /* all timings in nanoseconds */
+ ti,davinci-cs-ta = 0;
+ ti,davinci-cs-rhold = 7;
+ ti,davinci-cs-rstrobe = 42;
+ ti,davinci-cs-rsetup = 14;
+ ti,davinci-cs-whold = 7;
+ ti,davinci-cs-wstrobe = 42;
+ ti,davinci-cs-wsetup = 14;
+ };
+
+ nor_cs:cs3@6200 {
+ compatible = ti,davinci-cs;
+ #address-cells = 1;
+ #size-cells = 1;
+ /* all timings in nanoseconds */
+ ti,davinci-cs-ta = 0;
+ ti,davinci-cs-rhold = 7;
+ ti,davinci-cs-rstrobe = 42;
+ ti,davinci-cs-rsetup = 14;
+ ti,davinci-cs-whold = 7;
+ ti,davinci-cs-wstrobe = 42;
+ ti,davinci-cs-wsetup = 14;
+
Re: [RFC PATCH v3] Consolidate SRAM support
Russell, On 5/12/2011 11:15 PM, Russell King - ARM Linux wrote: On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote: This is work in progress. Tried this patch on OMAP and found couple of issues. 1. Compilation break. Below is the fix for the same. diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index 68f57ff..78d1af4 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -75,6 +75,7 @@ static unsigned long omap_sram_start; static unsigned long omap_sram_base; static unsigned long omap_sram_size; +static unsigned long omap_sram_ceil; /* * Depending on the target RAMFS firewall setup, the public usable amount of -- 1.6.0.4 2. The boot takes data abort while allocating memory for struct pv_pool. Here is the back-trace. I haven't debugged it further though. -000|NSR:0x0010(asm) --|exception -001|kmem_cache_alloc_trace(size = 0x0C, cachep = 0x0, flags = 0x80D0) -002|pv_pool_create(addr = 0xFE40, phys = 0x4020, len = 0x0001, min_alloc_order = 0x3) -003|omap_sram_init() -004|paging_init(?) -005|setup_arch(cmdline_p = 0xC058BFE4) -006|start_kernel() -007|NSR:0x8000803C(asm) ---|end of frame | Regards Santosh ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/3] davinci: Map sram using MT_MEMORY_NONCACHED instead of MT_DEVICE
On Davinci SRAM is mapped as MT_DEVICE becasue of the section
mapping pre-requisite instead of intended MT_MEMORY_NONCACHED
Since the section mapping limitation gets fixed with first
patch in this series, the MT_MEMORY_NONCACHED can be used now.
Have not tested this, so somebody with Davinci hardware can
try this out
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/dm355.c |3 +--
arch/arm/mach-davinci/dm365.c |3 +--
arch/arm/mach-davinci/dm644x.c |3 +--
arch/arm/mach-davinci/dm646x.c |3 +--
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 3834781..e7bd2ad 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -767,8 +767,7 @@ static struct map_desc dm355_io_desc[] = {
.virtual= SRAM_VIRT,
.pfn= __phys_to_pfn(0x0001),
.length = SZ_32K,
- /* MT_MEMORY_NONCACHED requires supersection alignment */
- .type = MT_DEVICE,
+ .type = MT_MEMORY_NONCACHED,
},
};
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index a146849..5dee032 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -967,8 +967,7 @@ static struct map_desc dm365_io_desc[] = {
.virtual= SRAM_VIRT,
.pfn= __phys_to_pfn(0x0001),
.length = SZ_32K,
- /* MT_MEMORY_NONCACHED requires supersection alignment */
- .type = MT_DEVICE,
+ .type = MT_MEMORY_NONCACHED,
},
};
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 7ad1520..5112d51 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -651,8 +651,7 @@ static struct map_desc dm644x_io_desc[] = {
.virtual= SRAM_VIRT,
.pfn= __phys_to_pfn(0x8000),
.length = SZ_16K,
- /* MT_MEMORY_NONCACHED requires supersection alignment */
- .type = MT_DEVICE,
+ .type = MT_MEMORY_NONCACHED,
},
};
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 9404565..97078f4 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -735,8 +735,7 @@ static struct map_desc dm646x_io_desc[] = {
.virtual= SRAM_VIRT,
.pfn= __phys_to_pfn(0x0001),
.length = SZ_32K,
- /* MT_MEMORY_NONCACHED requires supersection alignment */
- .type = MT_DEVICE,
+ .type = MT_MEMORY_NONCACHED,
},
};
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
