* [PATCH 00/13] OMAP3+: Add DT support for early devices and i2c / twl6030
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson
Hi Grant, Tony,
This series is a rework of several series:
[RFC PATCH 00/10] OMAP: Add DT support for early init OMAP4 devices
http://www.spinics.net/lists/linux-omap/msg55977.html
[PATCH 00/13] OMAP4: Add DT support for i2c and twl6030
http://www.spinics.net/lists/linux-omap/msg56524.html
[PATCH 0/7] OMAP3: Add basic DT support + i2c + twl
http://www.spinics.net/lists/linux-omap/msg56538.html
It adds a minimal i2c and twl support to allow the removal of the static
i2c init. A couple of basic i2c devices are added for panda, beagle and
sdp4430 boards.
Some early devices (gpio, spinlock) are added as well to remove any init
previously done before the machine_init.
It fixes several comments:
- Simplify the twl children creation thanks to Arnd proposal
- Add the twl-rtc DT support needed by the usage of regular
of_platform_populate method to create twl children.
- Fix hwspinlock driver that was not building correctly as module
- Allow lecacy device initialization mechanism to work in case no dtb is
passed by the bootloader.
Patches are based on for_3.2/3_omap_devicetree
and are available here:
git://gitorious.org/omap-pm/linux.git for_3.2/4_omap_dt_i2c_twl
Tested on PandaBoard, sdp4430 and BeagleBoard-xM with and without CONFIG_OF.
Comments are welcome.
Regards,
Benoit
Benoit Cousson (13):
hwspinlock: OMAP4: Add spinlock support in DT
gpio/omap: Adapt GPIO driver to DT
arm/dts: OMAP4: Add gpio nodes
irq: Add stub for none DT build in irqdomain.h
i2c: OMAP: Add DT support for i2c controller
mfd: twl-core: Add initial DT support for twl4030/twl6030
rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030
arm/dts: OMAP4: Add i2c controller nodes
arm/dts: OMAP3: Add i2c controller nodes
arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
OMAP2+: board-generic: Remove i2c static init
.../devicetree/bindings/gpio/gpio-omap.txt | 33 ++++++
.../bindings/hwspinlock/omap-spinlock.txt | 5 +
Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++++++
.../devicetree/bindings/mfd/twl-familly.txt | 47 +++++++++
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12 ++
arch/arm/boot/dts/omap3-beagle.dts | 38 +++++++
arch/arm/boot/dts/omap3.dtsi | 27 +++++
arch/arm/boot/dts/omap4-panda.dts | 44 ++++++++
arch/arm/boot/dts/omap4-sdp.dts | 62 +++++++++++
arch/arm/boot/dts/omap4.dtsi | 106 +++++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 41 +-------
arch/arm/mach-omap2/gpio.c | 8 +-
arch/arm/mach-omap2/hwspinlock.c | 5 +
drivers/gpio/gpio-omap.c | 108 ++++++++++++++++++--
drivers/hwspinlock/omap_hwspinlock.c | 11 ++
drivers/i2c/busses/i2c-omap.c | 26 ++++-
drivers/mfd/twl-core.c | 53 +++++++++-
drivers/rtc/rtc-twl.c | 10 ++-
include/linux/irqdomain.h | 2 +
19 files changed, 609 insertions(+), 59 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt
create mode 100644 Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt
create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 00/13] OMAP3+: Add DT support for early devices and i2c / twl6030
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi Grant, Tony,
This series is a rework of several series:
[RFC PATCH 00/10] OMAP: Add DT support for early init OMAP4 devices
http://www.spinics.net/lists/linux-omap/msg55977.html
[PATCH 00/13] OMAP4: Add DT support for i2c and twl6030
http://www.spinics.net/lists/linux-omap/msg56524.html
[PATCH 0/7] OMAP3: Add basic DT support + i2c + twl
http://www.spinics.net/lists/linux-omap/msg56538.html
It adds a minimal i2c and twl support to allow the removal of the static
i2c init. A couple of basic i2c devices are added for panda, beagle and
sdp4430 boards.
Some early devices (gpio, spinlock) are added as well to remove any init
previously done before the machine_init.
It fixes several comments:
- Simplify the twl children creation thanks to Arnd proposal
- Add the twl-rtc DT support needed by the usage of regular
of_platform_populate method to create twl children.
- Fix hwspinlock driver that was not building correctly as module
- Allow lecacy device initialization mechanism to work in case no dtb is
passed by the bootloader.
Patches are based on for_3.2/3_omap_devicetree
and are available here:
git://gitorious.org/omap-pm/linux.git for_3.2/4_omap_dt_i2c_twl
Tested on PandaBoard, sdp4430 and BeagleBoard-xM with and without CONFIG_OF.
Comments are welcome.
Regards,
Benoit
Benoit Cousson (13):
hwspinlock: OMAP4: Add spinlock support in DT
gpio/omap: Adapt GPIO driver to DT
arm/dts: OMAP4: Add gpio nodes
irq: Add stub for none DT build in irqdomain.h
i2c: OMAP: Add DT support for i2c controller
mfd: twl-core: Add initial DT support for twl4030/twl6030
rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030
arm/dts: OMAP4: Add i2c controller nodes
arm/dts: OMAP3: Add i2c controller nodes
arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
OMAP2+: board-generic: Remove i2c static init
.../devicetree/bindings/gpio/gpio-omap.txt | 33 ++++++
.../bindings/hwspinlock/omap-spinlock.txt | 5 +
Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++++++
.../devicetree/bindings/mfd/twl-familly.txt | 47 +++++++++
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12 ++
arch/arm/boot/dts/omap3-beagle.dts | 38 +++++++
arch/arm/boot/dts/omap3.dtsi | 27 +++++
arch/arm/boot/dts/omap4-panda.dts | 44 ++++++++
arch/arm/boot/dts/omap4-sdp.dts | 62 +++++++++++
arch/arm/boot/dts/omap4.dtsi | 106 +++++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 41 +-------
arch/arm/mach-omap2/gpio.c | 8 +-
arch/arm/mach-omap2/hwspinlock.c | 5 +
drivers/gpio/gpio-omap.c | 108 ++++++++++++++++++--
drivers/hwspinlock/omap_hwspinlock.c | 11 ++
drivers/i2c/busses/i2c-omap.c | 26 ++++-
drivers/mfd/twl-core.c | 53 +++++++++-
drivers/rtc/rtc-twl.c | 10 ++-
include/linux/irqdomain.h | 2 +
19 files changed, 609 insertions(+), 59 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt
create mode 100644 Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt
create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 01/13] hwspinlock: OMAP4: Add spinlock support in DT
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson, Ohad Ben-Cohen
Add a device-tree node for the spinlock.
Remove the static device build code if CONFIG_OF
is set.
Update the hwspinlock driver to use the of_match method.
Add the information in Documentation/devicetree.
Add documentation for the HW spinlock in OMAP4.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
---
.../bindings/hwspinlock/omap-spinlock.txt | 5 +++++
arch/arm/boot/dts/omap4.dtsi | 5 +++++
arch/arm/mach-omap2/hwspinlock.c | 5 +++++
drivers/hwspinlock/omap_hwspinlock.c | 11 +++++++++++
4 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
diff --git a/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
new file mode 100644
index 0000000..4cea7cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
@@ -0,0 +1,5 @@
+* HW spinlock on OMAP4 platform:
+
+Required properties:
+- compatible : Must be "ti,omap4-spinlock";
+- ti,hwmods : "spinlock"
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..7a7f31e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -99,5 +99,10 @@
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
};
+
+ spinlock {
+ compatible = "ti,omap4-spinlock";
+ ti,hwmods = "spinlock";
+ };
};
};
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
index 36e2109..80fc18f 100644
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ b/arch/arm/mach-omap2/hwspinlock.c
@@ -19,6 +19,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/err.h>
+#include <linux/of.h>
#include <plat/omap_hwmod.h>
#include <plat/omap_device.h>
@@ -31,6 +32,10 @@ int __init hwspinlocks_init(void)
const char *oh_name = "spinlock";
const char *dev_name = "omap_hwspinlock";
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
/*
* Hwmod lookup will fail in case our platform doesn't support the
* hardware spinlock module, so it is safe to run this initcall
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index a8f0273..8dfa730 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -203,11 +203,22 @@ static int omap_hwspinlock_remove(struct platform_device *pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id spinlock_match[] = {
+ {.compatible = "ti,omap4-spinlock", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, spinlock_match);
+#else
+#define spinlock_match NULL
+#endif
+
static struct platform_driver omap_hwspinlock_driver = {
.probe = omap_hwspinlock_probe,
.remove = omap_hwspinlock_remove,
.driver = {
.name = "omap_hwspinlock",
+ .of_match_table = spinlock_match,
},
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 01/13] hwspinlock: OMAP4: Add spinlock support in DT
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Add a device-tree node for the spinlock.
Remove the static device build code if CONFIG_OF
is set.
Update the hwspinlock driver to use the of_match method.
Add the information in Documentation/devicetree.
Add documentation for the HW spinlock in OMAP4.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
---
.../bindings/hwspinlock/omap-spinlock.txt | 5 +++++
arch/arm/boot/dts/omap4.dtsi | 5 +++++
arch/arm/mach-omap2/hwspinlock.c | 5 +++++
drivers/hwspinlock/omap_hwspinlock.c | 11 +++++++++++
4 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
diff --git a/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
new file mode 100644
index 0000000..4cea7cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
@@ -0,0 +1,5 @@
+* HW spinlock on OMAP4 platform:
+
+Required properties:
+- compatible : Must be "ti,omap4-spinlock";
+- ti,hwmods : "spinlock"
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..7a7f31e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -99,5 +99,10 @@
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
};
+
+ spinlock {
+ compatible = "ti,omap4-spinlock";
+ ti,hwmods = "spinlock";
+ };
};
};
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
index 36e2109..80fc18f 100644
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ b/arch/arm/mach-omap2/hwspinlock.c
@@ -19,6 +19,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/err.h>
+#include <linux/of.h>
#include <plat/omap_hwmod.h>
#include <plat/omap_device.h>
@@ -31,6 +32,10 @@ int __init hwspinlocks_init(void)
const char *oh_name = "spinlock";
const char *dev_name = "omap_hwspinlock";
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
/*
* Hwmod lookup will fail in case our platform doesn't support the
* hardware spinlock module, so it is safe to run this initcall
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index a8f0273..8dfa730 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -203,11 +203,22 @@ static int omap_hwspinlock_remove(struct platform_device *pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id spinlock_match[] = {
+ {.compatible = "ti,omap4-spinlock", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, spinlock_match);
+#else
+#define spinlock_match NULL
+#endif
+
static struct platform_driver omap_hwspinlock_driver = {
.probe = omap_hwspinlock_probe,
.remove = omap_hwspinlock_remove,
.driver = {
.name = "omap_hwspinlock",
+ .of_match_table = spinlock_match,
},
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson, Charulatha V,
Tarun Kanti DebBarma
Adapt the GPIO driver to retrieve information from a DT file.
Note that since the driver is currently under cleanup, some hacks
will have to be removed after.
Add documentation for GPIO properties specific to OMAP.
Remove an un-needed whitespace.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Charulatha V <charu@ti.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
---
.../devicetree/bindings/gpio/gpio-omap.txt | 33 ++++++
drivers/gpio/gpio-omap.c | 108 ++++++++++++++++++--
2 files changed, 132 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
new file mode 100644
index 0000000..bdd63de
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -0,0 +1,33 @@
+OMAP GPIO controller
+
+Required properties:
+- compatible:
+ - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
+ - "ti,omap4-gpio" for OMAP4 controller
+- #gpio-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the GPIO
+- id: 32 bits to identify the id (1 based index)
+- bank-width: number of pin supported by the controller (16 or 32)
+- debounce: set if the controller support the debouce funtionnality
+- bank-count: number of controller support by the SoC. This is a temporary
+ hack until the bank_count is removed from the driver.
+
+
+Example:
+
+gpio4: gpio4 {
+ compatible = "ti,omap4-gpio", "ti,omap-gpio";
+ ti,hwmods = "gpio4";
+ id = <4>;
+ bank-width = <32>;
+ debounce;
+ no_idle_on_suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+};
+
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0599854..f878fa4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -21,6 +21,8 @@
#include <linux/io.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include <mach/hardware.h>
#include <asm/irq.h>
@@ -521,7 +523,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
unsigned long flags;
if (bank->non_wakeup_gpios & gpio_bit) {
- dev_err(bank->dev,
+ dev_err(bank->dev,
"Unable to modify wakeup on non-wakeup GPIO%d\n", gpio);
return -EINVAL;
}
@@ -1150,6 +1152,8 @@ static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
irq_set_handler_data(bank->irq, bank);
}
+static const struct of_device_id omap_gpio_match[];
+
static int __devinit omap_gpio_probe(struct platform_device *pdev)
{
static int gpio_init_done;
@@ -1157,11 +1161,31 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
struct resource *res;
int id;
struct gpio_bank *bank;
+ struct device_node *node = pdev->dev.of_node;
+ const struct of_device_id *match;
+
+ match = of_match_device(omap_gpio_match, &pdev->dev);
+ if (match) {
+ pdata = match->data;
+ /* XXX: big hack until the bank_count is removed */
+ of_property_read_u32(node, "bank-count", &gpio_bank_count);
+ if (of_property_read_u32(node, "id", &id))
+ return -EINVAL;
+ /*
+ * In an ideal world, the id should not be needed, but since
+ * the OMAP TRM consider the multiple GPIO controllers as
+ * multiple banks, the GPIO number is based on the whole set
+ * of banks. Hence the need to provide an id in order to
+ * respect the order and the correct GPIO number.
+ */
+ id -= 1;
+ } else {
+ if (!pdev->dev.platform_data)
+ return -EINVAL;
- if (!pdev->dev.platform_data)
- return -EINVAL;
-
- pdata = pdev->dev.platform_data;
+ pdata = pdev->dev.platform_data;
+ id = pdev->id;
+ }
if (!gpio_init_done) {
int ret;
@@ -1171,7 +1195,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
return ret;
}
- id = pdev->id;
bank = &gpio_bank[id];
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -1181,12 +1204,19 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
}
bank->irq = res->start;
- bank->virtual_irq_start = pdata->virtual_irq_start;
bank->method = pdata->bank_type;
bank->dev = &pdev->dev;
- bank->dbck_flag = pdata->dbck_flag;
bank->stride = pdata->bank_stride;
- bank->width = pdata->bank_width;
+ if (match) {
+ of_property_read_u32(node, "bank-width", &bank->width);
+ if (of_get_property(node, "debounce", NULL))
+ bank->dbck_flag = true;
+ bank->virtual_irq_start = IH_GPIO_BASE + 32 * id;
+ } else {
+ bank->width = pdata->bank_width;
+ bank->dbck_flag = pdata->dbck_flag;
+ bank->virtual_irq_start = pdata->virtual_irq_start;
+ }
bank->regs = pdata->regs;
@@ -1559,10 +1589,70 @@ void omap_gpio_restore_context(void)
}
#endif
+#if defined(CONFIG_OF)
+static struct omap_gpio_reg_offs omap2_gpio_regs = {
+ .revision = OMAP24XX_GPIO_REVISION,
+ .direction = OMAP24XX_GPIO_OE,
+ .datain = OMAP24XX_GPIO_DATAIN,
+ .dataout = OMAP24XX_GPIO_DATAOUT,
+ .set_dataout = OMAP24XX_GPIO_SETDATAOUT,
+ .clr_dataout = OMAP24XX_GPIO_CLEARDATAOUT,
+ .irqstatus = OMAP24XX_GPIO_IRQSTATUS1,
+ .irqstatus2 = OMAP24XX_GPIO_IRQSTATUS2,
+ .irqenable = OMAP24XX_GPIO_IRQENABLE1,
+ .set_irqenable = OMAP24XX_GPIO_SETIRQENABLE1,
+ .clr_irqenable = OMAP24XX_GPIO_CLEARIRQENABLE1,
+ .debounce = OMAP24XX_GPIO_DEBOUNCE_VAL,
+ .debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN,
+};
+
+static struct omap_gpio_platform_data omap2_pdata = {
+ .bank_type = METHOD_GPIO_24XX,
+ .regs = &omap2_gpio_regs,
+};
+
+static struct omap_gpio_reg_offs omap4_gpio_regs = {
+ .revision = OMAP4_GPIO_REVISION,
+ .direction = OMAP4_GPIO_OE,
+ .datain = OMAP4_GPIO_DATAIN,
+ .dataout = OMAP4_GPIO_DATAOUT,
+ .set_dataout = OMAP4_GPIO_SETDATAOUT,
+ .clr_dataout = OMAP4_GPIO_CLEARDATAOUT,
+ .irqstatus = OMAP4_GPIO_IRQSTATUS1,
+ .irqstatus2 = OMAP4_GPIO_IRQSTATUS2,
+ .irqenable = OMAP4_GPIO_IRQENABLE1,
+ .set_irqenable = OMAP4_GPIO_SETIRQENABLE1,
+ .clr_irqenable = OMAP4_GPIO_CLEARIRQENABLE1,
+ .debounce = OMAP4_GPIO_DEBOUNCINGTIME,
+ .debounce_en = OMAP4_GPIO_DEBOUNCENABLE,
+};
+
+static struct omap_gpio_platform_data omap4_pdata = {
+ .bank_type = METHOD_GPIO_44XX,
+ .regs = &omap4_gpio_regs,
+};
+
+static const struct of_device_id omap_gpio_match[] = {
+ {
+ .compatible = "ti,omap4-gpio",
+ .data = &omap4_pdata,
+ },
+ {
+ .compatible = "ti,omap2-gpio",
+ .data = &omap2_pdata,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_gpio_match);
+#else
+#define omap_gpio_match NULL
+#endif
+
static struct platform_driver omap_gpio_driver = {
.probe = omap_gpio_probe,
.driver = {
.name = "omap_gpio",
+ .of_match_table = omap_gpio_match,
},
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Adapt the GPIO driver to retrieve information from a DT file.
Note that since the driver is currently under cleanup, some hacks
will have to be removed after.
Add documentation for GPIO properties specific to OMAP.
Remove an un-needed whitespace.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Charulatha V <charu@ti.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
---
.../devicetree/bindings/gpio/gpio-omap.txt | 33 ++++++
drivers/gpio/gpio-omap.c | 108 ++++++++++++++++++--
2 files changed, 132 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
new file mode 100644
index 0000000..bdd63de
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -0,0 +1,33 @@
+OMAP GPIO controller
+
+Required properties:
+- compatible:
+ - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
+ - "ti,omap4-gpio" for OMAP4 controller
+- #gpio-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the GPIO
+- id: 32 bits to identify the id (1 based index)
+- bank-width: number of pin supported by the controller (16 or 32)
+- debounce: set if the controller support the debouce funtionnality
+- bank-count: number of controller support by the SoC. This is a temporary
+ hack until the bank_count is removed from the driver.
+
+
+Example:
+
+gpio4: gpio4 {
+ compatible = "ti,omap4-gpio", "ti,omap-gpio";
+ ti,hwmods = "gpio4";
+ id = <4>;
+ bank-width = <32>;
+ debounce;
+ no_idle_on_suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+};
+
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0599854..f878fa4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -21,6 +21,8 @@
#include <linux/io.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include <mach/hardware.h>
#include <asm/irq.h>
@@ -521,7 +523,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
unsigned long flags;
if (bank->non_wakeup_gpios & gpio_bit) {
- dev_err(bank->dev,
+ dev_err(bank->dev,
"Unable to modify wakeup on non-wakeup GPIO%d\n", gpio);
return -EINVAL;
}
@@ -1150,6 +1152,8 @@ static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
irq_set_handler_data(bank->irq, bank);
}
+static const struct of_device_id omap_gpio_match[];
+
static int __devinit omap_gpio_probe(struct platform_device *pdev)
{
static int gpio_init_done;
@@ -1157,11 +1161,31 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
struct resource *res;
int id;
struct gpio_bank *bank;
+ struct device_node *node = pdev->dev.of_node;
+ const struct of_device_id *match;
+
+ match = of_match_device(omap_gpio_match, &pdev->dev);
+ if (match) {
+ pdata = match->data;
+ /* XXX: big hack until the bank_count is removed */
+ of_property_read_u32(node, "bank-count", &gpio_bank_count);
+ if (of_property_read_u32(node, "id", &id))
+ return -EINVAL;
+ /*
+ * In an ideal world, the id should not be needed, but since
+ * the OMAP TRM consider the multiple GPIO controllers as
+ * multiple banks, the GPIO number is based on the whole set
+ * of banks. Hence the need to provide an id in order to
+ * respect the order and the correct GPIO number.
+ */
+ id -= 1;
+ } else {
+ if (!pdev->dev.platform_data)
+ return -EINVAL;
- if (!pdev->dev.platform_data)
- return -EINVAL;
-
- pdata = pdev->dev.platform_data;
+ pdata = pdev->dev.platform_data;
+ id = pdev->id;
+ }
if (!gpio_init_done) {
int ret;
@@ -1171,7 +1195,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
return ret;
}
- id = pdev->id;
bank = &gpio_bank[id];
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -1181,12 +1204,19 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
}
bank->irq = res->start;
- bank->virtual_irq_start = pdata->virtual_irq_start;
bank->method = pdata->bank_type;
bank->dev = &pdev->dev;
- bank->dbck_flag = pdata->dbck_flag;
bank->stride = pdata->bank_stride;
- bank->width = pdata->bank_width;
+ if (match) {
+ of_property_read_u32(node, "bank-width", &bank->width);
+ if (of_get_property(node, "debounce", NULL))
+ bank->dbck_flag = true;
+ bank->virtual_irq_start = IH_GPIO_BASE + 32 * id;
+ } else {
+ bank->width = pdata->bank_width;
+ bank->dbck_flag = pdata->dbck_flag;
+ bank->virtual_irq_start = pdata->virtual_irq_start;
+ }
bank->regs = pdata->regs;
@@ -1559,10 +1589,70 @@ void omap_gpio_restore_context(void)
}
#endif
+#if defined(CONFIG_OF)
+static struct omap_gpio_reg_offs omap2_gpio_regs = {
+ .revision = OMAP24XX_GPIO_REVISION,
+ .direction = OMAP24XX_GPIO_OE,
+ .datain = OMAP24XX_GPIO_DATAIN,
+ .dataout = OMAP24XX_GPIO_DATAOUT,
+ .set_dataout = OMAP24XX_GPIO_SETDATAOUT,
+ .clr_dataout = OMAP24XX_GPIO_CLEARDATAOUT,
+ .irqstatus = OMAP24XX_GPIO_IRQSTATUS1,
+ .irqstatus2 = OMAP24XX_GPIO_IRQSTATUS2,
+ .irqenable = OMAP24XX_GPIO_IRQENABLE1,
+ .set_irqenable = OMAP24XX_GPIO_SETIRQENABLE1,
+ .clr_irqenable = OMAP24XX_GPIO_CLEARIRQENABLE1,
+ .debounce = OMAP24XX_GPIO_DEBOUNCE_VAL,
+ .debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN,
+};
+
+static struct omap_gpio_platform_data omap2_pdata = {
+ .bank_type = METHOD_GPIO_24XX,
+ .regs = &omap2_gpio_regs,
+};
+
+static struct omap_gpio_reg_offs omap4_gpio_regs = {
+ .revision = OMAP4_GPIO_REVISION,
+ .direction = OMAP4_GPIO_OE,
+ .datain = OMAP4_GPIO_DATAIN,
+ .dataout = OMAP4_GPIO_DATAOUT,
+ .set_dataout = OMAP4_GPIO_SETDATAOUT,
+ .clr_dataout = OMAP4_GPIO_CLEARDATAOUT,
+ .irqstatus = OMAP4_GPIO_IRQSTATUS1,
+ .irqstatus2 = OMAP4_GPIO_IRQSTATUS2,
+ .irqenable = OMAP4_GPIO_IRQENABLE1,
+ .set_irqenable = OMAP4_GPIO_SETIRQENABLE1,
+ .clr_irqenable = OMAP4_GPIO_CLEARIRQENABLE1,
+ .debounce = OMAP4_GPIO_DEBOUNCINGTIME,
+ .debounce_en = OMAP4_GPIO_DEBOUNCENABLE,
+};
+
+static struct omap_gpio_platform_data omap4_pdata = {
+ .bank_type = METHOD_GPIO_44XX,
+ .regs = &omap4_gpio_regs,
+};
+
+static const struct of_device_id omap_gpio_match[] = {
+ {
+ .compatible = "ti,omap4-gpio",
+ .data = &omap4_pdata,
+ },
+ {
+ .compatible = "ti,omap2-gpio",
+ .data = &omap2_pdata,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_gpio_match);
+#else
+#define omap_gpio_match NULL
+#endif
+
static struct platform_driver omap_gpio_driver = {
.probe = omap_gpio_probe,
.driver = {
.name = "omap_gpio",
+ .of_match_table = omap_gpio_match,
},
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 03/13] arm/dts: OMAP4: Add gpio nodes
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ, grant.likely-s3s/WqlpOiPyB63q8FvJNQ
Cc: khilman-l0cyMroinI0, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Charulatha V
Add the 6 GPIOs controller nodes.
Since the GPIO driver is still under cleanup, a couple of temp
hacks are needed. They will be removed as soon as the driver will
be cleaned.
Remove gpio static device initialisation if DT is populated.
Remove un-needed LF.
Signed-off-by: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Charulatha V <charu-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/omap4.dtsi | 69 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/gpio.c | 8 ++++-
2 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7a7f31e..bb19bca 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -104,5 +104,74 @@
compatible = "ti,omap4-spinlock";
ti,hwmods = "spinlock";
};
+
+ gpio1: gpio@1 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio1";
+ /* id should not be needed with a global GPIO parent */
+ id = <1>;
+ bank-width = <32>;
+ debounce;
+ /* XXX: big hack until the bank_count is removed */
+ bank-count = <6>;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio2: gpio@2 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio2";
+ id = <2>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio3: gpio@3 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio3";
+ id = <3>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio4: gpio@4 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio4";
+ id = <4>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio5: gpio@5 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio5";
+ id = <5>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio6: gpio@6 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio6";
+ id = <6>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
};
};
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 8cbfbc2..8412746 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -20,6 +20,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/interrupt.h>
+#include <linux/of.h>
#include <plat/omap_hwmod.h>
#include <plat/omap_device.h>
@@ -122,7 +123,10 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
*/
static int __init omap2_gpio_init(void)
{
- return omap_hwmod_for_each_by_class("gpio", omap2_gpio_dev_init,
- NULL);
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
+ return omap_hwmod_for_each_by_class("gpio", omap2_gpio_dev_init, NULL);
}
postcore_initcall(omap2_gpio_init);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 03/13] arm/dts: OMAP4: Add gpio nodes
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Add the 6 GPIOs controller nodes.
Since the GPIO driver is still under cleanup, a couple of temp
hacks are needed. They will be removed as soon as the driver will
be cleaned.
Remove gpio static device initialisation if DT is populated.
Remove un-needed LF.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Charulatha V <charu@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 69 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/gpio.c | 8 ++++-
2 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7a7f31e..bb19bca 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -104,5 +104,74 @@
compatible = "ti,omap4-spinlock";
ti,hwmods = "spinlock";
};
+
+ gpio1: gpio at 1 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio1";
+ /* id should not be needed with a global GPIO parent */
+ id = <1>;
+ bank-width = <32>;
+ debounce;
+ /* XXX: big hack until the bank_count is removed */
+ bank-count = <6>;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio2: gpio at 2 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio2";
+ id = <2>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio3: gpio at 3 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio3";
+ id = <3>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio4: gpio at 4 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio4";
+ id = <4>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio5: gpio at 5 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio5";
+ id = <5>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio6: gpio at 6 {
+ compatible = "ti,omap4-gpio";
+ ti,hwmods = "gpio6";
+ id = <6>;
+ bank-width = <32>;
+ debounce;
+ ti,no-idle-on-suspend;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
};
};
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 8cbfbc2..8412746 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -20,6 +20,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/interrupt.h>
+#include <linux/of.h>
#include <plat/omap_hwmod.h>
#include <plat/omap_device.h>
@@ -122,7 +123,10 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
*/
static int __init omap2_gpio_init(void)
{
- return omap_hwmod_for_each_by_class("gpio", omap2_gpio_dev_init,
- NULL);
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
+ return omap_hwmod_for_each_by_class("gpio", omap2_gpio_dev_init, NULL);
}
postcore_initcall(omap2_gpio_init);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 04/13] irq: Add stub for none DT build in irqdomain.h
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson
Add an empty funtion to allow building a file without
adding some #ifdef CONFIG_OF around of APIs.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Grant Likely <grant.likely@secretlab.ca>
---
include/linux/irqdomain.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index e807ad6..6fa08ab 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -84,6 +84,8 @@ extern void irq_domain_add_simple(struct device_node *controller, int irq_base);
extern void irq_domain_generate_simple(const struct of_device_id *match,
u64 phys_base, unsigned int irq_start);
#else /* CONFIG_IRQ_DOMAIN && CONFIG_OF_IRQ */
+static inline void irq_domain_add_simple(struct device_node *controller,
+ int irq_base) { }
static inline void irq_domain_generate_simple(const struct of_device_id *match,
u64 phys_base, unsigned int irq_start) { }
#endif /* CONFIG_IRQ_DOMAIN && CONFIG_OF_IRQ */
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 04/13] irq: Add stub for none DT build in irqdomain.h
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Add an empty funtion to allow building a file without
adding some #ifdef CONFIG_OF around of APIs.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Grant Likely <grant.likely@secretlab.ca>
---
include/linux/irqdomain.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index e807ad6..6fa08ab 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -84,6 +84,8 @@ extern void irq_domain_add_simple(struct device_node *controller, int irq_base);
extern void irq_domain_generate_simple(const struct of_device_id *match,
u64 phys_base, unsigned int irq_start);
#else /* CONFIG_IRQ_DOMAIN && CONFIG_OF_IRQ */
+static inline void irq_domain_add_simple(struct device_node *controller,
+ int irq_base) { }
static inline void irq_domain_generate_simple(const struct of_device_id *match,
u64 phys_base, unsigned int irq_start) { }
#endif /* CONFIG_IRQ_DOMAIN && CONFIG_OF_IRQ */
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 05/13] i2c: OMAP: Add DT support for i2c controller
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson, Ben Dooks, G,
Manjunath Kondaiah
Add initial DT support to retrieve the frequency using a
DT attribute instead of the pdata pointer if of_node exist.
Add documentation for omap i2c controller binding.
Based on original patches from Manju and Grant.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++++++++++++++++++++
drivers/i2c/busses/i2c-omap.c | 26 +++++++++++++++--
2 files changed, 53 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt
diff --git a/Documentation/devicetree/bindings/i2c/omap-i2c.txt b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
new file mode 100644
index 0000000..d21f4d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
@@ -0,0 +1,30 @@
+I2C for OMAP platforms
+
+Required properties :
+- compatible : Must be "ti,omap3-i2c"
+- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Recommended properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
+ the default 100 kHz frequency will be used.
+
+Optional properties:
+- Child nodes conforming to i2c bus binding
+
+Note: Current implementation will fetch base address, irq and dma
+from omap hwmod data base during device registration.
+Future plan is to migrate hwmod data base contents into device tree
+blob so that, all the required data will be used from device tree dts
+file.
+
+Examples :
+
+i2c1: i2c@0 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ clock-frequency = <400000>;
+};
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 155b32f..aee5bfa 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -37,6 +37,8 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/io.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
#include <linux/slab.h>
#include <linux/i2c-omap.h>
#include <linux/pm_runtime.h>
@@ -969,6 +971,16 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_i2c_of_match[] = {
+ {.compatible = "ti,omap3-i2c", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
+#else
+#define omap_i2c_of_match NULL
+#endif
+
static int __devinit
omap_i2c_probe(struct platform_device *pdev)
{
@@ -1005,12 +1017,16 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_release_region;
}
+ speed = 100; /* Default speed */
if (pdata != NULL) {
speed = pdata->clkrate;
dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat;
- } else {
- speed = 100; /* Default speed */
- dev->set_mpu_wkup_lat = NULL;
+ } else if (pdev->dev.of_node) {
+ u32 prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+ &prop))
+ /* convert DT value in Hz into kHz */
+ speed = prop / 1000;
}
dev->speed = speed;
@@ -1093,6 +1109,7 @@ omap_i2c_probe(struct platform_device *pdev)
strlcpy(adap->name, "OMAP I2C adapter", sizeof(adap->name));
adap->algo = &omap_i2c_algo;
adap->dev.parent = &pdev->dev;
+ adap->dev.of_node = pdev->dev.of_node;
/* i2c device drivers may be active on return from add_adapter() */
adap->nr = pdev->id;
@@ -1102,6 +1119,8 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_free_irq;
}
+ of_i2c_register_devices(adap);
+
return 0;
err_free_irq:
@@ -1143,6 +1162,7 @@ static struct platform_driver omap_i2c_driver = {
.driver = {
.name = "omap_i2c",
.owner = THIS_MODULE,
+ .of_match_table = omap_i2c_of_match,
},
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 05/13] i2c: OMAP: Add DT support for i2c controller
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Add initial DT support to retrieve the frequency using a
DT attribute instead of the pdata pointer if of_node exist.
Add documentation for omap i2c controller binding.
Based on original patches from Manju and Grant.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++++++++++++++++++++
drivers/i2c/busses/i2c-omap.c | 26 +++++++++++++++--
2 files changed, 53 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt
diff --git a/Documentation/devicetree/bindings/i2c/omap-i2c.txt b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
new file mode 100644
index 0000000..d21f4d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
@@ -0,0 +1,30 @@
+I2C for OMAP platforms
+
+Required properties :
+- compatible : Must be "ti,omap3-i2c"
+- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Recommended properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
+ the default 100 kHz frequency will be used.
+
+Optional properties:
+- Child nodes conforming to i2c bus binding
+
+Note: Current implementation will fetch base address, irq and dma
+from omap hwmod data base during device registration.
+Future plan is to migrate hwmod data base contents into device tree
+blob so that, all the required data will be used from device tree dts
+file.
+
+Examples :
+
+i2c1: i2c at 0 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ clock-frequency = <400000>;
+};
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 155b32f..aee5bfa 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -37,6 +37,8 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/io.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
#include <linux/slab.h>
#include <linux/i2c-omap.h>
#include <linux/pm_runtime.h>
@@ -969,6 +971,16 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_i2c_of_match[] = {
+ {.compatible = "ti,omap3-i2c", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
+#else
+#define omap_i2c_of_match NULL
+#endif
+
static int __devinit
omap_i2c_probe(struct platform_device *pdev)
{
@@ -1005,12 +1017,16 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_release_region;
}
+ speed = 100; /* Default speed */
if (pdata != NULL) {
speed = pdata->clkrate;
dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat;
- } else {
- speed = 100; /* Default speed */
- dev->set_mpu_wkup_lat = NULL;
+ } else if (pdev->dev.of_node) {
+ u32 prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+ &prop))
+ /* convert DT value in Hz into kHz */
+ speed = prop / 1000;
}
dev->speed = speed;
@@ -1093,6 +1109,7 @@ omap_i2c_probe(struct platform_device *pdev)
strlcpy(adap->name, "OMAP I2C adapter", sizeof(adap->name));
adap->algo = &omap_i2c_algo;
adap->dev.parent = &pdev->dev;
+ adap->dev.of_node = pdev->dev.of_node;
/* i2c device drivers may be active on return from add_adapter() */
adap->nr = pdev->id;
@@ -1102,6 +1119,8 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_free_irq;
}
+ of_i2c_register_devices(adap);
+
return 0;
err_free_irq:
@@ -1143,6 +1162,7 @@ static struct platform_driver omap_i2c_driver = {
.driver = {
.name = "omap_i2c",
.owner = THIS_MODULE,
+ .of_match_table = omap_i2c_of_match,
},
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 06/13] mfd: twl-core: Add initial DT support for twl4030/twl6030
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson, Balaji T K, Graeme Gregory,
Samuel Ortiz
Add initial device-tree support for twl familly chips.
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
platform_data information can be initialized properly.
Add documentation for the Texas Instruments TWL Integrated Chip.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Balaji T K <balajitk@ti.com>
Cc: Graeme Gregory <gg@slimlogic.co.uk>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
.../devicetree/bindings/mfd/twl-familly.txt | 47 +++++++++++++++++
drivers/mfd/twl-core.c | 53 ++++++++++++++++++--
2 files changed, 96 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt b/Documentation/devicetree/bindings/mfd/twl-familly.txt
new file mode 100644
index 0000000..ff4cacd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt
@@ -0,0 +1,47 @@
+Texas Instruments TWL family
+
+The TWLs are Integrated Power Management Chips.
+Some version might contain much more analog function like
+USB transceiver or Audio amplifier.
+These chips are connected to an i2c bus.
+
+
+Required properties:
+- compatible : Must be "ti,twl4030";
+ For Integrated power-management/audio CODEC device used in OMAP3
+ based boards
+- compatible : Must be "ti,twl6030";
+ For Integrated power-management used in OMAP4 based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the twl support several interrupts internally,
+ it is considered as an interrupt controller cascaded to the SoC one.
+- #interrupt-cells = <1>;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the twl. The twl family is made of severals variants
+ that support a different number of features.
+ The children nodes will thus depend of the capabilty of the variant.
+
+
+Example:
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+twl@48 {
+ compatible = "ti,twl6030";
+ reg = <0x48>;
+ interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ twl_rtc {
+ compatible = "ti,twl_rtc";
+ interrupts = <11>;
+ reg = <0>;
+ };
+};
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 01ecfee..3ef0b43 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -33,6 +33,10 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/irqdomain.h>
#include <linux/regulator/machine.h>
@@ -1182,22 +1186,53 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
int status;
unsigned i;
struct twl4030_platform_data *pdata = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
u8 temp;
int ret = 0;
+ if (node && !pdata) {
+ /*
+ * XXX: Temporary fake pdata until the information
+ * is correctly retrieved by every TWL modules from DT.
+ */
+ pdata = kzalloc(sizeof(struct twl4030_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ status = -ENOMEM;
+ goto exit;
+ }
+
+ /*
+ * XXX: For the moment the IRQs for TWL seems to be encoded in
+ * the global OMAP space. That should be cleaned to allow
+ * dynamically adding a new IRQ controller.
+ */
+ if ((id->driver_data) & TWL6030_CLASS) {
+ pdata->irq_base = TWL6030_IRQ_BASE;
+ pdata->irq_end = pdata->irq_base + TWL6030_BASE_NR_IRQS;
+ } else {
+ pdata->irq_base = TWL4030_IRQ_BASE;
+ pdata->irq_end = pdata->irq_base + TWL4030_BASE_NR_IRQS;
+ }
+ irq_domain_add_simple(node, pdata->irq_base);
+ }
+
if (!pdata) {
dev_dbg(&client->dev, "no platform data?\n");
- return -EINVAL;
+ status = -EINVAL;
+ goto fail_free;
}
if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
dev_dbg(&client->dev, "can't talk I2C?\n");
- return -EIO;
+ status = -EIO;
+ goto fail_free;
}
if (inuse) {
dev_dbg(&client->dev, "driver is already in use\n");
- return -EBUSY;
+ status = -EBUSY;
+ goto fail_free;
}
for (i = 0; i < TWL_NUM_SLAVES; i++) {
@@ -1269,10 +1304,20 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
}
- status = add_children(pdata, id->driver_data);
+#ifdef CONFIG_OF_DEVICE
+ if (node)
+ status = of_platform_populate(node, NULL, NULL, &client->dev);
+ else
+#endif
+ status = add_children(pdata, id->driver_data);
+
fail:
if (status < 0)
twl_remove(client);
+fail_free:
+ if (node)
+ kfree(pdata);
+exit:
return status;
}
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 06/13] mfd: twl-core: Add initial DT support for twl4030/twl6030
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Add initial device-tree support for twl familly chips.
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
platform_data information can be initialized properly.
Add documentation for the Texas Instruments TWL Integrated Chip.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Balaji T K <balajitk@ti.com>
Cc: Graeme Gregory <gg@slimlogic.co.uk>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
.../devicetree/bindings/mfd/twl-familly.txt | 47 +++++++++++++++++
drivers/mfd/twl-core.c | 53 ++++++++++++++++++--
2 files changed, 96 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt b/Documentation/devicetree/bindings/mfd/twl-familly.txt
new file mode 100644
index 0000000..ff4cacd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt
@@ -0,0 +1,47 @@
+Texas Instruments TWL family
+
+The TWLs are Integrated Power Management Chips.
+Some version might contain much more analog function like
+USB transceiver or Audio amplifier.
+These chips are connected to an i2c bus.
+
+
+Required properties:
+- compatible : Must be "ti,twl4030";
+ For Integrated power-management/audio CODEC device used in OMAP3
+ based boards
+- compatible : Must be "ti,twl6030";
+ For Integrated power-management used in OMAP4 based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the twl support several interrupts internally,
+ it is considered as an interrupt controller cascaded to the SoC one.
+- #interrupt-cells = <1>;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the twl. The twl family is made of severals variants
+ that support a different number of features.
+ The children nodes will thus depend of the capabilty of the variant.
+
+
+Example:
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+twl at 48 {
+ compatible = "ti,twl6030";
+ reg = <0x48>;
+ interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ twl_rtc {
+ compatible = "ti,twl_rtc";
+ interrupts = <11>;
+ reg = <0>;
+ };
+};
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 01ecfee..3ef0b43 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -33,6 +33,10 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/irqdomain.h>
#include <linux/regulator/machine.h>
@@ -1182,22 +1186,53 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
int status;
unsigned i;
struct twl4030_platform_data *pdata = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
u8 temp;
int ret = 0;
+ if (node && !pdata) {
+ /*
+ * XXX: Temporary fake pdata until the information
+ * is correctly retrieved by every TWL modules from DT.
+ */
+ pdata = kzalloc(sizeof(struct twl4030_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ status = -ENOMEM;
+ goto exit;
+ }
+
+ /*
+ * XXX: For the moment the IRQs for TWL seems to be encoded in
+ * the global OMAP space. That should be cleaned to allow
+ * dynamically adding a new IRQ controller.
+ */
+ if ((id->driver_data) & TWL6030_CLASS) {
+ pdata->irq_base = TWL6030_IRQ_BASE;
+ pdata->irq_end = pdata->irq_base + TWL6030_BASE_NR_IRQS;
+ } else {
+ pdata->irq_base = TWL4030_IRQ_BASE;
+ pdata->irq_end = pdata->irq_base + TWL4030_BASE_NR_IRQS;
+ }
+ irq_domain_add_simple(node, pdata->irq_base);
+ }
+
if (!pdata) {
dev_dbg(&client->dev, "no platform data?\n");
- return -EINVAL;
+ status = -EINVAL;
+ goto fail_free;
}
if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
dev_dbg(&client->dev, "can't talk I2C?\n");
- return -EIO;
+ status = -EIO;
+ goto fail_free;
}
if (inuse) {
dev_dbg(&client->dev, "driver is already in use\n");
- return -EBUSY;
+ status = -EBUSY;
+ goto fail_free;
}
for (i = 0; i < TWL_NUM_SLAVES; i++) {
@@ -1269,10 +1304,20 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
}
- status = add_children(pdata, id->driver_data);
+#ifdef CONFIG_OF_DEVICE
+ if (node)
+ status = of_platform_populate(node, NULL, NULL, &client->dev);
+ else
+#endif
+ status = add_children(pdata, id->driver_data);
+
fail:
if (status < 0)
twl_remove(client);
+fail_free:
+ if (node)
+ kfree(pdata);
+exit:
return status;
}
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 07/13] rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Alessandro Zummo <a.zummo@towertech.it>
---
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12 ++++++++++++
drivers/rtc/rtc-twl.c | 10 ++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
new file mode 100644
index 0000000..596e0c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
@@ -0,0 +1,12 @@
+* TI twl RTC
+
+The TWL family (twl4030/6030) contains a RTC.
+
+Required properties:
+- compatible : Should be twl4030-rtc
+
+Examples:
+
+rtc@0 {
+ compatible = "ti,twl4030-rtc";
+};
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 20687d5..d43b4f6 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -550,6 +550,11 @@ static int twl_rtc_resume(struct platform_device *pdev)
#define twl_rtc_resume NULL
#endif
+static const struct of_device_id twl_rtc_of_match[] = {
+ {.compatible = "ti,twl4030-rtc", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, twl_rtc_of_match);
MODULE_ALIAS("platform:twl_rtc");
static struct platform_driver twl4030rtc_driver = {
@@ -559,8 +564,9 @@ static struct platform_driver twl4030rtc_driver = {
.suspend = twl_rtc_suspend,
.resume = twl_rtc_resume,
.driver = {
- .owner = THIS_MODULE,
- .name = "twl_rtc",
+ .owner = THIS_MODULE,
+ .name = "twl_rtc",
+ .of_match_table = twl_rtc_of_match,
},
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 07/13] rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Alessandro Zummo <a.zummo@towertech.it>
---
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12 ++++++++++++
drivers/rtc/rtc-twl.c | 10 ++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
new file mode 100644
index 0000000..596e0c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
@@ -0,0 +1,12 @@
+* TI twl RTC
+
+The TWL family (twl4030/6030) contains a RTC.
+
+Required properties:
+- compatible : Should be twl4030-rtc
+
+Examples:
+
+rtc at 0 {
+ compatible = "ti,twl4030-rtc";
+};
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 20687d5..d43b4f6 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -550,6 +550,11 @@ static int twl_rtc_resume(struct platform_device *pdev)
#define twl_rtc_resume NULL
#endif
+static const struct of_device_id twl_rtc_of_match[] = {
+ {.compatible = "ti,twl4030-rtc", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, twl_rtc_of_match);
MODULE_ALIAS("platform:twl_rtc");
static struct platform_driver twl4030rtc_driver = {
@@ -559,8 +564,9 @@ static struct platform_driver twl4030rtc_driver = {
.suspend = twl_rtc_suspend,
.resume = twl_rtc_resume,
.driver = {
- .owner = THIS_MODULE,
- .name = "twl_rtc",
+ .owner = THIS_MODULE,
+ .name = "twl_rtc",
+ .of_match_table = twl_rtc_of_match,
},
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 08/13] arm/dts: OMAP4: Add i2c controller nodes
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson, G, Manjunath Kondaiah
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bb19bca..447f482 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -21,6 +21,10 @@
interrupt-parent = <&gic>;
aliases {
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
};
cpus {
@@ -173,5 +177,33 @@
#gpio-cells = <2>;
gpio-controller;
};
+
+ i2c1: i2c@1 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ };
+
+ i2c2: i2c@2 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c2";
+ };
+
+ i2c3: i2c@3 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c3";
+ };
+
+ i2c4: i2c@4 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c4";
+ };
};
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 08/13] arm/dts: OMAP4: Add i2c controller nodes
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bb19bca..447f482 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -21,6 +21,10 @@
interrupt-parent = <&gic>;
aliases {
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
};
cpus {
@@ -173,5 +177,33 @@
#gpio-cells = <2>;
gpio-controller;
};
+
+ i2c1: i2c at 1 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ };
+
+ i2c2: i2c at 2 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c2";
+ };
+
+ i2c3: i2c at 3 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c3";
+ };
+
+ i2c4: i2c at 4 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c4";
+ };
};
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 09/13] arm/dts: OMAP3: Add i2c controller nodes
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson, G, Manjunath Kondaiah
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..8ff794f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,12 @@
/ {
compatible = "ti,omap3430", "ti,omap3";
+ aliases {
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ };
+
cpus {
cpu@0 {
compatible = "arm,cortex-a8";
@@ -59,5 +65,26 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+ i2c1: i2c@1 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ };
+
+ i2c2: i2c@2 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c2";
+ };
+
+ i2c3: i2c@3 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c3";
+ };
};
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 09/13] arm/dts: OMAP3: Add i2c controller nodes
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..8ff794f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,12 @@
/ {
compatible = "ti,omap3430", "ti,omap3";
+ aliases {
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ };
+
cpus {
cpu at 0 {
compatible = "arm,cortex-a8";
@@ -59,5 +65,26 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+ i2c1: i2c at 1 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ };
+
+ i2c2: i2c at 2 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c2";
+ };
+
+ i2c3: i2c at 3 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c3";
+ };
};
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 10/13] arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson
Update pandaboard dts file with required clock frequencies
for the i2c client devices existing on pandaboard.
Add the twl6030 node in i2c1 controller.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add a generic i2c EEPROM entry.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
arch/arm/boot/dts/omap4-panda.dts | 44 +++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index c702657..2c6ce2b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -27,3 +27,47 @@
reg = <0x80000000 0x40000000>; /* 1 GB */
};
};
+
+&i2c1 {
+ clock-frequency = <400000>;
+
+ /*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+ twl@48 {
+ compatible = "ti,twl6030";
+ reg = <0x48>;
+ interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ /* twl is a MFD, so it will contain a bunch of sub-ips */
+ twl_rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+
+ /*
+ * Display monitor features are burnt in their EEPROM as EDID data.
+ * The EEPROM is connected as I2C slave device.
+ */
+ eeprom@50 {
+ compatible = "ti,eeprom";
+ reg = <0x50>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 10/13] arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Update pandaboard dts file with required clock frequencies
for the i2c client devices existing on pandaboard.
Add the twl6030 node in i2c1 controller.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add a generic i2c EEPROM entry.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
arch/arm/boot/dts/omap4-panda.dts | 44 +++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index c702657..2c6ce2b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -27,3 +27,47 @@
reg = <0x80000000 0x40000000>; /* 1 GB */
};
};
+
+&i2c1 {
+ clock-frequency = <400000>;
+
+ /*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+ twl at 48 {
+ compatible = "ti,twl6030";
+ reg = <0x48>;
+ interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ /* twl is a MFD, so it will contain a bunch of sub-ips */
+ twl_rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+
+ /*
+ * Display monitor features are burnt in their EEPROM as EDID data.
+ * The EEPROM is connected as I2C slave device.
+ */
+ eeprom at 50 {
+ compatible = "ti,eeprom";
+ reg = <0x50>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 11/13] arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson
Update DTS file with required clock frequencies
for the i2c client devices existing on sdp4430.
Add the twl6030 node inside the i2c1 controller node.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add the RTC submodule inside the twl node.
Add tmp105 temperature sensor in i2c3
Add bh1780 Ambient Light Sensor in i2c3
Add hmc5843 3-Axis Digital Compass in i2c4
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
arch/arm/boot/dts/omap4-sdp.dts | 62 +++++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..2990841 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -27,3 +27,65 @@
reg = <0x80000000 0x40000000>; /* 1 GB */
};
};
+
+&i2c1 {
+ clock-frequency = <400000>;
+
+ /*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+ twl@48 {
+ compatible = "ti,twl6030";
+ reg = <0x48>;
+ interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ /* twl is a MFD, so it will contain a bunch of sub-ips */
+ twl_rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+};
+
+&i2c3 {
+ clock-frequency = <400000>;
+
+ /*
+ * Temperature Sensor
+ * http://www.ti.com/lit/ds/symlink/tmp105.pdf
+ */
+ tmp105@48 {
+ compatible = "ti,tmp105";
+ reg = <0x48>;
+ };
+
+ /*
+ * Ambient Light Sensor
+ * http://www.rohm.com/products/databook/sensor/pdf/bh1780gli-e.pdf
+ */
+ bh1780@29 {
+ compatible = "rohm,bh1780";
+ reg = <0x29>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+
+ /*
+ * 3-Axis Digital Compass
+ * http://www.sparkfun.com/datasheets/Sensors/Magneto/HMC5843.pdf
+ */
+ hmc5843@1e {
+ compatible = "honeywell,hmc5843";
+ reg = <0x1e>;
+ };
+};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 11/13] arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Update DTS file with required clock frequencies
for the i2c client devices existing on sdp4430.
Add the twl6030 node inside the i2c1 controller node.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add the RTC submodule inside the twl node.
Add tmp105 temperature sensor in i2c3
Add bh1780 Ambient Light Sensor in i2c3
Add hmc5843 3-Axis Digital Compass in i2c4
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
arch/arm/boot/dts/omap4-sdp.dts | 62 +++++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..2990841 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -27,3 +27,65 @@
reg = <0x80000000 0x40000000>; /* 1 GB */
};
};
+
+&i2c1 {
+ clock-frequency = <400000>;
+
+ /*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+ twl at 48 {
+ compatible = "ti,twl6030";
+ reg = <0x48>;
+ interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ /* twl is a MFD, so it will contain a bunch of sub-ips */
+ twl_rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+};
+
+&i2c3 {
+ clock-frequency = <400000>;
+
+ /*
+ * Temperature Sensor
+ * http://www.ti.com/lit/ds/symlink/tmp105.pdf
+ */
+ tmp105 at 48 {
+ compatible = "ti,tmp105";
+ reg = <0x48>;
+ };
+
+ /*
+ * Ambient Light Sensor
+ * http://www.rohm.com/products/databook/sensor/pdf/bh1780gli-e.pdf
+ */
+ bh1780 at 29 {
+ compatible = "rohm,bh1780";
+ reg = <0x29>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+
+ /*
+ * 3-Axis Digital Compass
+ * http://www.sparkfun.com/datasheets/Sensors/Magneto/HMC5843.pdf
+ */
+ hmc5843 at 1e {
+ compatible = "honeywell,hmc5843";
+ reg = <0x1e>;
+ };
+};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 12/13] arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson, G, Manjunath Kondaiah
Add required clock frequencies for the i2c client devices existing
on beagle board.
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap3-beagle.dts | 38 ++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..a65f39d 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,3 +27,41 @@
reg = <0x80000000 0x20000000>; /* 512 MB */
};
};
+
+&i2c1 {
+ clock-frequency = <2600000>;
+
+ /*
+ * Integrated Power Management Chip
+ */
+ twl@48 {
+ compatible = "ti,twl4030";
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&intc>;
+
+ twl_rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+
+ /*
+ * Display monitor features are burnt in the EEPROM
+ * as EDID data.
+ */
+ eeprom@50 {
+ compatible = "ti,eeprom";
+ reg = <0x50>;
+ };
+};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 12/13] arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Add required clock frequencies for the i2c client devices existing
on beagle board.
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap3-beagle.dts | 38 ++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..a65f39d 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,3 +27,41 @@
reg = <0x80000000 0x20000000>; /* 512 MB */
};
};
+
+&i2c1 {
+ clock-frequency = <2600000>;
+
+ /*
+ * Integrated Power Management Chip
+ */
+ twl at 48 {
+ compatible = "ti,twl4030";
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&intc>;
+
+ twl_rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+
+ /*
+ * Display monitor features are burnt in the EEPROM
+ * as EDID data.
+ */
+ eeprom at 50 {
+ compatible = "ti,eeprom";
+ reg = <0x50>;
+ };
+};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 13/13] OMAP2+: board-generic: Remove i2c static init
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-26 16:50 ` Benoit Cousson
-1 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: tony, grant.likely
Cc: paul, khilman, rnayak, linux-omap, linux-arm-kernel,
devicetree-discuss, Benoit Cousson
This mainly reverts the commit that was adding the i2c static init.
Since the i2c and twl nodes are now present, there is no need
for the static initialization anymore.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-generic.c | 41 +---------------------------------
1 files changed, 2 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 1186a76..dcbd64c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -11,7 +11,6 @@
#include <linux/io.h>
#include <linux/of_platform.h>
#include <linux/irqdomain.h>
-#include <linux/i2c/twl.h>
#include <mach/hardware.h>
#include <asm/mach/arch.h>
@@ -19,31 +18,7 @@
#include <plat/board.h>
#include <plat/common.h>
#include <mach/omap4-common.h>
-#include "common-board-devices.h"
-/*
- * XXX: Still needed to boot until the i2c & twl driver is adapted to
- * device-tree
- */
-static struct twl4030_platform_data sdp4430_twldata = {
- .irq_base = TWL6030_IRQ_BASE,
- .irq_end = TWL6030_IRQ_END,
-};
-
-static void __init omap4_i2c_init(void)
-{
- omap4_pmic_init("twl6030", &sdp4430_twldata);
-}
-
-static struct twl4030_platform_data beagle_twldata = {
- .irq_base = TWL4030_IRQ_BASE,
- .irq_end = TWL4030_IRQ_END,
-};
-
-static void __init omap3_i2c_init(void)
-{
- omap3_pmic_init("twl4030", &beagle_twldata);
-}
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = "simple-bus", },
@@ -69,18 +44,6 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
-static void __init omap4_init(void)
-{
- omap4_i2c_init();
- omap_generic_init();
-}
-
-static void __init omap3_init(void)
-{
- omap3_i2c_init();
- omap_generic_init();
-}
-
#if defined(CONFIG_SOC_OMAP2420)
static const char *omap242x_boards_compat[] __initdata = {
"ti,omap2420",
@@ -126,7 +89,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device Tree)")
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
.init_irq = omap3_init_irq,
- .init_machine = omap3_init,
+ .init_machine = omap_generic_init,
.timer = &omap3_timer,
.dt_compat = omap3_boards_compat,
MACHINE_END
@@ -143,7 +106,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device Tree)")
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
.init_irq = gic_init_irq,
- .init_machine = omap4_init,
+ .init_machine = omap_generic_init,
.timer = &omap4_timer,
.dt_compat = omap4_boards_compat,
MACHINE_END
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 13/13] OMAP2+: board-generic: Remove i2c static init
@ 2011-09-26 16:50 ` Benoit Cousson
0 siblings, 0 replies; 52+ messages in thread
From: Benoit Cousson @ 2011-09-26 16:50 UTC (permalink / raw)
To: linux-arm-kernel
This mainly reverts the commit that was adding the i2c static init.
Since the i2c and twl nodes are now present, there is no need
for the static initialization anymore.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-generic.c | 41 +---------------------------------
1 files changed, 2 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 1186a76..dcbd64c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -11,7 +11,6 @@
#include <linux/io.h>
#include <linux/of_platform.h>
#include <linux/irqdomain.h>
-#include <linux/i2c/twl.h>
#include <mach/hardware.h>
#include <asm/mach/arch.h>
@@ -19,31 +18,7 @@
#include <plat/board.h>
#include <plat/common.h>
#include <mach/omap4-common.h>
-#include "common-board-devices.h"
-/*
- * XXX: Still needed to boot until the i2c & twl driver is adapted to
- * device-tree
- */
-static struct twl4030_platform_data sdp4430_twldata = {
- .irq_base = TWL6030_IRQ_BASE,
- .irq_end = TWL6030_IRQ_END,
-};
-
-static void __init omap4_i2c_init(void)
-{
- omap4_pmic_init("twl6030", &sdp4430_twldata);
-}
-
-static struct twl4030_platform_data beagle_twldata = {
- .irq_base = TWL4030_IRQ_BASE,
- .irq_end = TWL4030_IRQ_END,
-};
-
-static void __init omap3_i2c_init(void)
-{
- omap3_pmic_init("twl4030", &beagle_twldata);
-}
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = "simple-bus", },
@@ -69,18 +44,6 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
-static void __init omap4_init(void)
-{
- omap4_i2c_init();
- omap_generic_init();
-}
-
-static void __init omap3_init(void)
-{
- omap3_i2c_init();
- omap_generic_init();
-}
-
#if defined(CONFIG_SOC_OMAP2420)
static const char *omap242x_boards_compat[] __initdata = {
"ti,omap2420",
@@ -126,7 +89,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device Tree)")
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
.init_irq = omap3_init_irq,
- .init_machine = omap3_init,
+ .init_machine = omap_generic_init,
.timer = &omap3_timer,
.dt_compat = omap3_boards_compat,
MACHINE_END
@@ -143,7 +106,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device Tree)")
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
.init_irq = gic_init_irq,
- .init_machine = omap4_init,
+ .init_machine = omap_generic_init,
.timer = &omap4_timer,
.dt_compat = omap4_boards_compat,
MACHINE_END
--
1.7.0.4
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-27 5:40 ` Rajendra Nayak
-1 siblings, 0 replies; 52+ messages in thread
From: Rajendra Nayak @ 2011-09-27 5:40 UTC (permalink / raw)
To: Benoit Cousson
Cc: khilman-l0cyMroinI0, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Tarun Kanti DebBarma,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Charulatha V
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
> Adapt the GPIO driver to retrieve information from a DT file.
> Note that since the driver is currently under cleanup, some hacks
> will have to be removed after.
>
> Add documentation for GPIO properties specific to OMAP.
>
> Remove an un-needed whitespace.
>
> Signed-off-by: Benoit Cousson<b-cousson-l0cyMroinI0@public.gmane.org>
> Cc: Grant Likely<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Cc: Charulatha V<charu-l0cyMroinI0@public.gmane.org>
> Cc: Tarun Kanti DebBarma<tarun.kanti-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/gpio/gpio-omap.txt | 33 ++++++
> drivers/gpio/gpio-omap.c | 108 ++++++++++++++++++--
> 2 files changed, 132 insertions(+), 9 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
> new file mode 100644
> index 0000000..bdd63de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
> @@ -0,0 +1,33 @@
> +OMAP GPIO controller
> +
> +Required properties:
> +- compatible:
> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
Would it be more readable to have
"ti,omap2-gpio" for OMAP2 controllers and
"ti,omap3-gpio" for OMAP3 controllers?
> + - "ti,omap4-gpio" for OMAP4 controller
> +- #gpio-cells : Should be two.
> + - first cell is the pin number
> + - second cell is used to specify optional parameters (unused)
> +- gpio-controller : Marks the device node as a GPIO controller.
> +
> +OMAP specific properties:
> +- ti,hwmods: Name of the hwmod associated to the GPIO
> +- id: 32 bits to identify the id (1 based index)
> +- bank-width: number of pin supported by the controller (16 or 32)
> +- debounce: set if the controller support the debouce funtionnality
> +- bank-count: number of controller support by the SoC. This is a temporary
> + hack until the bank_count is removed from the driver.
Is there a general rule to be followed as to when to use
"ti,<prop-name>" and when to use just "<prop-name>".
Since all these are OMAP specific properties, shouldn't all
of them be "ti,<prop-name>"?
> +
> +
> +Example:
> +
> +gpio4: gpio4 {
> + compatible = "ti,omap4-gpio", "ti,omap-gpio";
> + ti,hwmods = "gpio4";
> + id =<4>;
> + bank-width =<32>;
> + debounce;
> + no_idle_on_suspend;
> + #gpio-cells =<2>;
> + gpio-controller;
> +};
> +
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 0599854..f878fa4 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -21,6 +21,8 @@
> #include<linux/io.h>
> #include<linux/slab.h>
> #include<linux/pm_runtime.h>
> +#include<linux/of.h>
> +#include<linux/of_device.h>
>
> #include<mach/hardware.h>
> #include<asm/irq.h>
> @@ -521,7 +523,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
> unsigned long flags;
>
> if (bank->non_wakeup_gpios& gpio_bit) {
> - dev_err(bank->dev,
> + dev_err(bank->dev,
Stray change?
> "Unable to modify wakeup on non-wakeup GPIO%d\n", gpio);
> return -EINVAL;
> }
> @@ -1150,6 +1152,8 @@ static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
> irq_set_handler_data(bank->irq, bank);
> }
>
> +static const struct of_device_id omap_gpio_match[];
> +
> static int __devinit omap_gpio_probe(struct platform_device *pdev)
> {
> static int gpio_init_done;
> @@ -1157,11 +1161,31 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
> struct resource *res;
> int id;
> struct gpio_bank *bank;
> + struct device_node *node = pdev->dev.of_node;
> + const struct of_device_id *match;
> +
> + match = of_match_device(omap_gpio_match,&pdev->dev);
> + if (match) {
> + pdata = match->data;
> + /* XXX: big hack until the bank_count is removed */
> + of_property_read_u32(node, "bank-count",&gpio_bank_count);
> + if (of_property_read_u32(node, "id",&id))
id should be u32.
> + return -EINVAL;
> + /*
> + * In an ideal world, the id should not be needed, but since
> + * the OMAP TRM consider the multiple GPIO controllers as
> + * multiple banks, the GPIO number is based on the whole set
> + * of banks. Hence the need to provide an id in order to
> + * respect the order and the correct GPIO number.
> + */
> + id -= 1;
> + } else {
> + if (!pdev->dev.platform_data)
> + return -EINVAL;
>
> - if (!pdev->dev.platform_data)
> - return -EINVAL;
> -
> - pdata = pdev->dev.platform_data;
> + pdata = pdev->dev.platform_data;
> + id = pdev->id;
> + }
>
> if (!gpio_init_done) {
> int ret;
> @@ -1171,7 +1195,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
> return ret;
> }
>
> - id = pdev->id;
> bank =&gpio_bank[id];
>
> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> @@ -1181,12 +1204,19 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
> }
>
> bank->irq = res->start;
> - bank->virtual_irq_start = pdata->virtual_irq_start;
> bank->method = pdata->bank_type;
> bank->dev =&pdev->dev;
> - bank->dbck_flag = pdata->dbck_flag;
> bank->stride = pdata->bank_stride;
> - bank->width = pdata->bank_width;
> + if (match) {
> + of_property_read_u32(node, "bank-width",&bank->width);
Bank width should be u32.
> + if (of_get_property(node, "debounce", NULL))
of_find_property() should suffice.
regards,
Rajendra
> + bank->dbck_flag = true;
> + bank->virtual_irq_start = IH_GPIO_BASE + 32 * id;
> + } else {
> + bank->width = pdata->bank_width;
> + bank->dbck_flag = pdata->dbck_flag;
> + bank->virtual_irq_start = pdata->virtual_irq_start;
> + }
>
> bank->regs = pdata->regs;
>
> @@ -1559,10 +1589,70 @@ void omap_gpio_restore_context(void)
> }
> #endif
>
> +#if defined(CONFIG_OF)
> +static struct omap_gpio_reg_offs omap2_gpio_regs = {
> + .revision = OMAP24XX_GPIO_REVISION,
> + .direction = OMAP24XX_GPIO_OE,
> + .datain = OMAP24XX_GPIO_DATAIN,
> + .dataout = OMAP24XX_GPIO_DATAOUT,
> + .set_dataout = OMAP24XX_GPIO_SETDATAOUT,
> + .clr_dataout = OMAP24XX_GPIO_CLEARDATAOUT,
> + .irqstatus = OMAP24XX_GPIO_IRQSTATUS1,
> + .irqstatus2 = OMAP24XX_GPIO_IRQSTATUS2,
> + .irqenable = OMAP24XX_GPIO_IRQENABLE1,
> + .set_irqenable = OMAP24XX_GPIO_SETIRQENABLE1,
> + .clr_irqenable = OMAP24XX_GPIO_CLEARIRQENABLE1,
> + .debounce = OMAP24XX_GPIO_DEBOUNCE_VAL,
> + .debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN,
> +};
> +
> +static struct omap_gpio_platform_data omap2_pdata = {
> + .bank_type = METHOD_GPIO_24XX,
> + .regs =&omap2_gpio_regs,
> +};
> +
> +static struct omap_gpio_reg_offs omap4_gpio_regs = {
> + .revision = OMAP4_GPIO_REVISION,
> + .direction = OMAP4_GPIO_OE,
> + .datain = OMAP4_GPIO_DATAIN,
> + .dataout = OMAP4_GPIO_DATAOUT,
> + .set_dataout = OMAP4_GPIO_SETDATAOUT,
> + .clr_dataout = OMAP4_GPIO_CLEARDATAOUT,
> + .irqstatus = OMAP4_GPIO_IRQSTATUS1,
> + .irqstatus2 = OMAP4_GPIO_IRQSTATUS2,
> + .irqenable = OMAP4_GPIO_IRQENABLE1,
> + .set_irqenable = OMAP4_GPIO_SETIRQENABLE1,
> + .clr_irqenable = OMAP4_GPIO_CLEARIRQENABLE1,
> + .debounce = OMAP4_GPIO_DEBOUNCINGTIME,
> + .debounce_en = OMAP4_GPIO_DEBOUNCENABLE,
> +};
> +
> +static struct omap_gpio_platform_data omap4_pdata = {
> + .bank_type = METHOD_GPIO_44XX,
> + .regs =&omap4_gpio_regs,
> +};
> +
> +static const struct of_device_id omap_gpio_match[] = {
> + {
> + .compatible = "ti,omap4-gpio",
> + .data =&omap4_pdata,
> + },
> + {
> + .compatible = "ti,omap2-gpio",
> + .data =&omap2_pdata,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, omap_gpio_match);
> +#else
> +#define omap_gpio_match NULL
> +#endif
> +
> static struct platform_driver omap_gpio_driver = {
> .probe = omap_gpio_probe,
> .driver = {
> .name = "omap_gpio",
> + .of_match_table = omap_gpio_match,
> },
> };
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
@ 2011-09-27 5:40 ` Rajendra Nayak
0 siblings, 0 replies; 52+ messages in thread
From: Rajendra Nayak @ 2011-09-27 5:40 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
> Adapt the GPIO driver to retrieve information from a DT file.
> Note that since the driver is currently under cleanup, some hacks
> will have to be removed after.
>
> Add documentation for GPIO properties specific to OMAP.
>
> Remove an un-needed whitespace.
>
> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
> Cc: Grant Likely<grant.likely@secretlab.ca>
> Cc: Charulatha V<charu@ti.com>
> Cc: Tarun Kanti DebBarma<tarun.kanti@ti.com>
> ---
> .../devicetree/bindings/gpio/gpio-omap.txt | 33 ++++++
> drivers/gpio/gpio-omap.c | 108 ++++++++++++++++++--
> 2 files changed, 132 insertions(+), 9 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
> new file mode 100644
> index 0000000..bdd63de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
> @@ -0,0 +1,33 @@
> +OMAP GPIO controller
> +
> +Required properties:
> +- compatible:
> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
Would it be more readable to have
"ti,omap2-gpio" for OMAP2 controllers and
"ti,omap3-gpio" for OMAP3 controllers?
> + - "ti,omap4-gpio" for OMAP4 controller
> +- #gpio-cells : Should be two.
> + - first cell is the pin number
> + - second cell is used to specify optional parameters (unused)
> +- gpio-controller : Marks the device node as a GPIO controller.
> +
> +OMAP specific properties:
> +- ti,hwmods: Name of the hwmod associated to the GPIO
> +- id: 32 bits to identify the id (1 based index)
> +- bank-width: number of pin supported by the controller (16 or 32)
> +- debounce: set if the controller support the debouce funtionnality
> +- bank-count: number of controller support by the SoC. This is a temporary
> + hack until the bank_count is removed from the driver.
Is there a general rule to be followed as to when to use
"ti,<prop-name>" and when to use just "<prop-name>".
Since all these are OMAP specific properties, shouldn't all
of them be "ti,<prop-name>"?
> +
> +
> +Example:
> +
> +gpio4: gpio4 {
> + compatible = "ti,omap4-gpio", "ti,omap-gpio";
> + ti,hwmods = "gpio4";
> + id =<4>;
> + bank-width =<32>;
> + debounce;
> + no_idle_on_suspend;
> + #gpio-cells =<2>;
> + gpio-controller;
> +};
> +
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 0599854..f878fa4 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -21,6 +21,8 @@
> #include<linux/io.h>
> #include<linux/slab.h>
> #include<linux/pm_runtime.h>
> +#include<linux/of.h>
> +#include<linux/of_device.h>
>
> #include<mach/hardware.h>
> #include<asm/irq.h>
> @@ -521,7 +523,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
> unsigned long flags;
>
> if (bank->non_wakeup_gpios& gpio_bit) {
> - dev_err(bank->dev,
> + dev_err(bank->dev,
Stray change?
> "Unable to modify wakeup on non-wakeup GPIO%d\n", gpio);
> return -EINVAL;
> }
> @@ -1150,6 +1152,8 @@ static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
> irq_set_handler_data(bank->irq, bank);
> }
>
> +static const struct of_device_id omap_gpio_match[];
> +
> static int __devinit omap_gpio_probe(struct platform_device *pdev)
> {
> static int gpio_init_done;
> @@ -1157,11 +1161,31 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
> struct resource *res;
> int id;
> struct gpio_bank *bank;
> + struct device_node *node = pdev->dev.of_node;
> + const struct of_device_id *match;
> +
> + match = of_match_device(omap_gpio_match,&pdev->dev);
> + if (match) {
> + pdata = match->data;
> + /* XXX: big hack until the bank_count is removed */
> + of_property_read_u32(node, "bank-count",&gpio_bank_count);
> + if (of_property_read_u32(node, "id",&id))
id should be u32.
> + return -EINVAL;
> + /*
> + * In an ideal world, the id should not be needed, but since
> + * the OMAP TRM consider the multiple GPIO controllers as
> + * multiple banks, the GPIO number is based on the whole set
> + * of banks. Hence the need to provide an id in order to
> + * respect the order and the correct GPIO number.
> + */
> + id -= 1;
> + } else {
> + if (!pdev->dev.platform_data)
> + return -EINVAL;
>
> - if (!pdev->dev.platform_data)
> - return -EINVAL;
> -
> - pdata = pdev->dev.platform_data;
> + pdata = pdev->dev.platform_data;
> + id = pdev->id;
> + }
>
> if (!gpio_init_done) {
> int ret;
> @@ -1171,7 +1195,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
> return ret;
> }
>
> - id = pdev->id;
> bank =&gpio_bank[id];
>
> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> @@ -1181,12 +1204,19 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
> }
>
> bank->irq = res->start;
> - bank->virtual_irq_start = pdata->virtual_irq_start;
> bank->method = pdata->bank_type;
> bank->dev =&pdev->dev;
> - bank->dbck_flag = pdata->dbck_flag;
> bank->stride = pdata->bank_stride;
> - bank->width = pdata->bank_width;
> + if (match) {
> + of_property_read_u32(node, "bank-width",&bank->width);
Bank width should be u32.
> + if (of_get_property(node, "debounce", NULL))
of_find_property() should suffice.
regards,
Rajendra
> + bank->dbck_flag = true;
> + bank->virtual_irq_start = IH_GPIO_BASE + 32 * id;
> + } else {
> + bank->width = pdata->bank_width;
> + bank->dbck_flag = pdata->dbck_flag;
> + bank->virtual_irq_start = pdata->virtual_irq_start;
> + }
>
> bank->regs = pdata->regs;
>
> @@ -1559,10 +1589,70 @@ void omap_gpio_restore_context(void)
> }
> #endif
>
> +#if defined(CONFIG_OF)
> +static struct omap_gpio_reg_offs omap2_gpio_regs = {
> + .revision = OMAP24XX_GPIO_REVISION,
> + .direction = OMAP24XX_GPIO_OE,
> + .datain = OMAP24XX_GPIO_DATAIN,
> + .dataout = OMAP24XX_GPIO_DATAOUT,
> + .set_dataout = OMAP24XX_GPIO_SETDATAOUT,
> + .clr_dataout = OMAP24XX_GPIO_CLEARDATAOUT,
> + .irqstatus = OMAP24XX_GPIO_IRQSTATUS1,
> + .irqstatus2 = OMAP24XX_GPIO_IRQSTATUS2,
> + .irqenable = OMAP24XX_GPIO_IRQENABLE1,
> + .set_irqenable = OMAP24XX_GPIO_SETIRQENABLE1,
> + .clr_irqenable = OMAP24XX_GPIO_CLEARIRQENABLE1,
> + .debounce = OMAP24XX_GPIO_DEBOUNCE_VAL,
> + .debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN,
> +};
> +
> +static struct omap_gpio_platform_data omap2_pdata = {
> + .bank_type = METHOD_GPIO_24XX,
> + .regs =&omap2_gpio_regs,
> +};
> +
> +static struct omap_gpio_reg_offs omap4_gpio_regs = {
> + .revision = OMAP4_GPIO_REVISION,
> + .direction = OMAP4_GPIO_OE,
> + .datain = OMAP4_GPIO_DATAIN,
> + .dataout = OMAP4_GPIO_DATAOUT,
> + .set_dataout = OMAP4_GPIO_SETDATAOUT,
> + .clr_dataout = OMAP4_GPIO_CLEARDATAOUT,
> + .irqstatus = OMAP4_GPIO_IRQSTATUS1,
> + .irqstatus2 = OMAP4_GPIO_IRQSTATUS2,
> + .irqenable = OMAP4_GPIO_IRQENABLE1,
> + .set_irqenable = OMAP4_GPIO_SETIRQENABLE1,
> + .clr_irqenable = OMAP4_GPIO_CLEARIRQENABLE1,
> + .debounce = OMAP4_GPIO_DEBOUNCINGTIME,
> + .debounce_en = OMAP4_GPIO_DEBOUNCENABLE,
> +};
> +
> +static struct omap_gpio_platform_data omap4_pdata = {
> + .bank_type = METHOD_GPIO_44XX,
> + .regs =&omap4_gpio_regs,
> +};
> +
> +static const struct of_device_id omap_gpio_match[] = {
> + {
> + .compatible = "ti,omap4-gpio",
> + .data =&omap4_pdata,
> + },
> + {
> + .compatible = "ti,omap2-gpio",
> + .data =&omap2_pdata,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, omap_gpio_match);
> +#else
> +#define omap_gpio_match NULL
> +#endif
> +
> static struct platform_driver omap_gpio_driver = {
> .probe = omap_gpio_probe,
> .driver = {
> .name = "omap_gpio",
> + .of_match_table = omap_gpio_match,
> },
> };
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 06/13] mfd: twl-core: Add initial DT support for twl4030/twl6030
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-27 5:42 ` Rajendra Nayak
-1 siblings, 0 replies; 52+ messages in thread
From: Rajendra Nayak @ 2011-09-27 5:42 UTC (permalink / raw)
To: Benoit Cousson
Cc: tony, grant.likely, paul, khilman, linux-omap, linux-arm-kernel,
devicetree-discuss, Balaji T K, Graeme Gregory, Samuel Ortiz
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
> Add initial device-tree support for twl familly chips.
s/familly/family
> The current version is missing the regulator entries due
> to the lack of DT regulator bindings for the moment.
> Only the simple sub-modules that do not depend on
> platform_data information can be initialized properly.
>
> Add documentation for the Texas Instruments TWL Integrated Chip.
>
> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
> Cc: Balaji T K<balajitk@ti.com>
> Cc: Graeme Gregory<gg@slimlogic.co.uk>
> Cc: Samuel Ortiz<sameo@linux.intel.com>
> ---
> .../devicetree/bindings/mfd/twl-familly.txt | 47 +++++++++++++++++
> drivers/mfd/twl-core.c | 53 ++++++++++++++++++--
> 2 files changed, 96 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
s/familly.txt/family.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt b/Documentation/devicetree/bindings/mfd/twl-familly.txt
> new file mode 100644
> index 0000000..ff4cacd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt
> @@ -0,0 +1,47 @@
> +Texas Instruments TWL family
> +
> +The TWLs are Integrated Power Management Chips.
> +Some version might contain much more analog function like
> +USB transceiver or Audio amplifier.
> +These chips are connected to an i2c bus.
> +
> +
> +Required properties:
> +- compatible : Must be "ti,twl4030";
> + For Integrated power-management/audio CODEC device used in OMAP3
> + based boards
> +- compatible : Must be "ti,twl6030";
> + For Integrated power-management used in OMAP4 based boards
> +- interrupts : This i2c device has an IRQ line connected to the main SoC
> +- interrupt-controller : Since the twl support several interrupts internally,
> + it is considered as an interrupt controller cascaded to the SoC one.
> +- #interrupt-cells =<1>;
> +- interrupt-parent : The parent interrupt controller.
> +
> +Optional node:
> +- Child nodes contain in the twl. The twl family is made of severals variants
> + that support a different number of features.
> + The children nodes will thus depend of the capabilty of the variant.
> +
> +
> +Example:
> +/*
> + * Integrated Power Management Chip
> + * http://www.ti.com/lit/ds/symlink/twl6030.pdf
> + */
> +twl@48 {
> + compatible = "ti,twl6030";
> + reg =<0x48>;
What does the 'reg' property signify here for twl?
> + interrupts =<39>; /* IRQ_SYS_1N cascaded to gic */
> + interrupt-controller;
> + #interrupt-cells =<1>;
> + interrupt-parent =<&gic>;
> + #address-cells =<1>;
> + #size-cells =<0>;
> +
> + twl_rtc {
> + compatible = "ti,twl_rtc";
> + interrupts =<11>;
> + reg =<0>;
Does the 'reg' property need to be faked for
every twl child node, even if it does not have
any?
> + };
> +};
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index 01ecfee..3ef0b43 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -33,6 +33,10 @@
> #include<linux/platform_device.h>
> #include<linux/clk.h>
> #include<linux/err.h>
> +#include<linux/slab.h>
> +#include<linux/of_irq.h>
> +#include<linux/of_platform.h>
> +#include<linux/irqdomain.h>
>
> #include<linux/regulator/machine.h>
>
> @@ -1182,22 +1186,53 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> int status;
> unsigned i;
> struct twl4030_platform_data *pdata = client->dev.platform_data;
> + struct device_node *node = client->dev.of_node;
> u8 temp;
> int ret = 0;
>
> + if (node&& !pdata) {
> + /*
> + * XXX: Temporary fake pdata until the information
> + * is correctly retrieved by every TWL modules from DT.
> + */
> + pdata = kzalloc(sizeof(struct twl4030_platform_data),
> + GFP_KERNEL);
devm_kzalloc instead?
> + if (!pdata) {
> + status = -ENOMEM;
> + goto exit;
> + }
> +
> + /*
> + * XXX: For the moment the IRQs for TWL seems to be encoded in
> + * the global OMAP space. That should be cleaned to allow
> + * dynamically adding a new IRQ controller.
> + */
> + if ((id->driver_data)& TWL6030_CLASS) {
> + pdata->irq_base = TWL6030_IRQ_BASE;
> + pdata->irq_end = pdata->irq_base + TWL6030_BASE_NR_IRQS;
> + } else {
> + pdata->irq_base = TWL4030_IRQ_BASE;
> + pdata->irq_end = pdata->irq_base + TWL4030_BASE_NR_IRQS;
> + }
> + irq_domain_add_simple(node, pdata->irq_base);
> + }
> +
> if (!pdata) {
> dev_dbg(&client->dev, "no platform data?\n");
> - return -EINVAL;
> + status = -EINVAL;
> + goto fail_free;
> }
>
> if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
> dev_dbg(&client->dev, "can't talk I2C?\n");
> - return -EIO;
> + status = -EIO;
> + goto fail_free;
> }
>
> if (inuse) {
> dev_dbg(&client->dev, "driver is already in use\n");
> - return -EBUSY;
> + status = -EBUSY;
> + goto fail_free;
> }
>
> for (i = 0; i< TWL_NUM_SLAVES; i++) {
> @@ -1269,10 +1304,20 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
> }
>
> - status = add_children(pdata, id->driver_data);
> +#ifdef CONFIG_OF_DEVICE
is the #ifdef really needed?
> + if (node)
> + status = of_platform_populate(node, NULL, NULL,&client->dev);
> + else
> +#endif
> + status = add_children(pdata, id->driver_data);
> +
> fail:
> if (status< 0)
> twl_remove(client);
> +fail_free:
> + if (node)
> + kfree(pdata);
> +exit:
> return status;
> }
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 06/13] mfd: twl-core: Add initial DT support for twl4030/twl6030
@ 2011-09-27 5:42 ` Rajendra Nayak
0 siblings, 0 replies; 52+ messages in thread
From: Rajendra Nayak @ 2011-09-27 5:42 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
> Add initial device-tree support for twl familly chips.
s/familly/family
> The current version is missing the regulator entries due
> to the lack of DT regulator bindings for the moment.
> Only the simple sub-modules that do not depend on
> platform_data information can be initialized properly.
>
> Add documentation for the Texas Instruments TWL Integrated Chip.
>
> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
> Cc: Balaji T K<balajitk@ti.com>
> Cc: Graeme Gregory<gg@slimlogic.co.uk>
> Cc: Samuel Ortiz<sameo@linux.intel.com>
> ---
> .../devicetree/bindings/mfd/twl-familly.txt | 47 +++++++++++++++++
> drivers/mfd/twl-core.c | 53 ++++++++++++++++++--
> 2 files changed, 96 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
s/familly.txt/family.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt b/Documentation/devicetree/bindings/mfd/twl-familly.txt
> new file mode 100644
> index 0000000..ff4cacd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt
> @@ -0,0 +1,47 @@
> +Texas Instruments TWL family
> +
> +The TWLs are Integrated Power Management Chips.
> +Some version might contain much more analog function like
> +USB transceiver or Audio amplifier.
> +These chips are connected to an i2c bus.
> +
> +
> +Required properties:
> +- compatible : Must be "ti,twl4030";
> + For Integrated power-management/audio CODEC device used in OMAP3
> + based boards
> +- compatible : Must be "ti,twl6030";
> + For Integrated power-management used in OMAP4 based boards
> +- interrupts : This i2c device has an IRQ line connected to the main SoC
> +- interrupt-controller : Since the twl support several interrupts internally,
> + it is considered as an interrupt controller cascaded to the SoC one.
> +- #interrupt-cells =<1>;
> +- interrupt-parent : The parent interrupt controller.
> +
> +Optional node:
> +- Child nodes contain in the twl. The twl family is made of severals variants
> + that support a different number of features.
> + The children nodes will thus depend of the capabilty of the variant.
> +
> +
> +Example:
> +/*
> + * Integrated Power Management Chip
> + * http://www.ti.com/lit/ds/symlink/twl6030.pdf
> + */
> +twl at 48 {
> + compatible = "ti,twl6030";
> + reg =<0x48>;
What does the 'reg' property signify here for twl?
> + interrupts =<39>; /* IRQ_SYS_1N cascaded to gic */
> + interrupt-controller;
> + #interrupt-cells =<1>;
> + interrupt-parent =<&gic>;
> + #address-cells =<1>;
> + #size-cells =<0>;
> +
> + twl_rtc {
> + compatible = "ti,twl_rtc";
> + interrupts =<11>;
> + reg =<0>;
Does the 'reg' property need to be faked for
every twl child node, even if it does not have
any?
> + };
> +};
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index 01ecfee..3ef0b43 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -33,6 +33,10 @@
> #include<linux/platform_device.h>
> #include<linux/clk.h>
> #include<linux/err.h>
> +#include<linux/slab.h>
> +#include<linux/of_irq.h>
> +#include<linux/of_platform.h>
> +#include<linux/irqdomain.h>
>
> #include<linux/regulator/machine.h>
>
> @@ -1182,22 +1186,53 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> int status;
> unsigned i;
> struct twl4030_platform_data *pdata = client->dev.platform_data;
> + struct device_node *node = client->dev.of_node;
> u8 temp;
> int ret = 0;
>
> + if (node&& !pdata) {
> + /*
> + * XXX: Temporary fake pdata until the information
> + * is correctly retrieved by every TWL modules from DT.
> + */
> + pdata = kzalloc(sizeof(struct twl4030_platform_data),
> + GFP_KERNEL);
devm_kzalloc instead?
> + if (!pdata) {
> + status = -ENOMEM;
> + goto exit;
> + }
> +
> + /*
> + * XXX: For the moment the IRQs for TWL seems to be encoded in
> + * the global OMAP space. That should be cleaned to allow
> + * dynamically adding a new IRQ controller.
> + */
> + if ((id->driver_data)& TWL6030_CLASS) {
> + pdata->irq_base = TWL6030_IRQ_BASE;
> + pdata->irq_end = pdata->irq_base + TWL6030_BASE_NR_IRQS;
> + } else {
> + pdata->irq_base = TWL4030_IRQ_BASE;
> + pdata->irq_end = pdata->irq_base + TWL4030_BASE_NR_IRQS;
> + }
> + irq_domain_add_simple(node, pdata->irq_base);
> + }
> +
> if (!pdata) {
> dev_dbg(&client->dev, "no platform data?\n");
> - return -EINVAL;
> + status = -EINVAL;
> + goto fail_free;
> }
>
> if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
> dev_dbg(&client->dev, "can't talk I2C?\n");
> - return -EIO;
> + status = -EIO;
> + goto fail_free;
> }
>
> if (inuse) {
> dev_dbg(&client->dev, "driver is already in use\n");
> - return -EBUSY;
> + status = -EBUSY;
> + goto fail_free;
> }
>
> for (i = 0; i< TWL_NUM_SLAVES; i++) {
> @@ -1269,10 +1304,20 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
> }
>
> - status = add_children(pdata, id->driver_data);
> +#ifdef CONFIG_OF_DEVICE
is the #ifdef really needed?
> + if (node)
> + status = of_platform_populate(node, NULL, NULL,&client->dev);
> + else
> +#endif
> + status = add_children(pdata, id->driver_data);
> +
> fail:
> if (status< 0)
> twl_remove(client);
> +fail_free:
> + if (node)
> + kfree(pdata);
> +exit:
> return status;
> }
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 08/13] arm/dts: OMAP4: Add i2c controller nodes
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-27 5:42 ` Rajendra Nayak
-1 siblings, 0 replies; 52+ messages in thread
From: Rajendra Nayak @ 2011-09-27 5:42 UTC (permalink / raw)
To: Benoit Cousson
Cc: tony, grant.likely, paul, khilman, linux-omap, linux-arm-kernel,
devicetree-discuss, G, Manjunath Kondaiah
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
> Add i2c controllers nodes into the main ocp bus.
>
> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
> Cc: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
> arch/arm/boot/dts/omap4.dtsi | 32 ++++++++++++++++++++++++++++++++
> 1 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index bb19bca..447f482 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -21,6 +21,10 @@
> interrupt-parent =<&gic>;
>
> aliases {
> + i2c1 =&i2c1;
> + i2c2 =&i2c2;
> + i2c3 =&i2c3;
> + i2c4 =&i2c4;
> };
>
> cpus {
> @@ -173,5 +177,33 @@
> #gpio-cells =<2>;
> gpio-controller;
> };
> +
> + i2c1: i2c@1 {
> + compatible = "ti,omap3-i2c";
This is a little confusing as omap4.dtsi has
compatible "ti,omap3-i2c" nodes in it.
> + #address-cells =<1>;
> + #size-cells =<0>;
> + ti,hwmods = "i2c1";
> + };
> +
> + i2c2: i2c@2 {
> + compatible = "ti,omap3-i2c";
> + #address-cells =<1>;
> + #size-cells =<0>;
> + ti,hwmods = "i2c2";
> + };
> +
> + i2c3: i2c@3 {
> + compatible = "ti,omap3-i2c";
> + #address-cells =<1>;
> + #size-cells =<0>;
> + ti,hwmods = "i2c3";
> + };
> +
> + i2c4: i2c@4 {
> + compatible = "ti,omap3-i2c";
> + #address-cells =<1>;
> + #size-cells =<0>;
> + ti,hwmods = "i2c4";
> + };
> };
> };
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 08/13] arm/dts: OMAP4: Add i2c controller nodes
@ 2011-09-27 5:42 ` Rajendra Nayak
0 siblings, 0 replies; 52+ messages in thread
From: Rajendra Nayak @ 2011-09-27 5:42 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
> Add i2c controllers nodes into the main ocp bus.
>
> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
> Cc: G, Manjunath Kondaiah<manjugk@ti.com>
> ---
> arch/arm/boot/dts/omap4.dtsi | 32 ++++++++++++++++++++++++++++++++
> 1 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index bb19bca..447f482 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -21,6 +21,10 @@
> interrupt-parent =<&gic>;
>
> aliases {
> + i2c1 =&i2c1;
> + i2c2 =&i2c2;
> + i2c3 =&i2c3;
> + i2c4 =&i2c4;
> };
>
> cpus {
> @@ -173,5 +177,33 @@
> #gpio-cells =<2>;
> gpio-controller;
> };
> +
> + i2c1: i2c at 1 {
> + compatible = "ti,omap3-i2c";
This is a little confusing as omap4.dtsi has
compatible "ti,omap3-i2c" nodes in it.
> + #address-cells =<1>;
> + #size-cells =<0>;
> + ti,hwmods = "i2c1";
> + };
> +
> + i2c2: i2c at 2 {
> + compatible = "ti,omap3-i2c";
> + #address-cells =<1>;
> + #size-cells =<0>;
> + ti,hwmods = "i2c2";
> + };
> +
> + i2c3: i2c at 3 {
> + compatible = "ti,omap3-i2c";
> + #address-cells =<1>;
> + #size-cells =<0>;
> + ti,hwmods = "i2c3";
> + };
> +
> + i2c4: i2c at 4 {
> + compatible = "ti,omap3-i2c";
> + #address-cells =<1>;
> + #size-cells =<0>;
> + ti,hwmods = "i2c4";
> + };
> };
> };
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
2011-09-27 5:40 ` Rajendra Nayak
@ 2011-09-28 8:15 ` Cousson, Benoit
-1 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:15 UTC (permalink / raw)
To: Nayak, Rajendra
Cc: Hilman, Kevin, paul, tony, devicetree-discuss, grant.likely,
linux-omap, DebBarma, Tarun Kanti, linux-arm-kernel, Varadarajan,
Charulatha
Hi Rajendra,
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
>> Adapt the GPIO driver to retrieve information from a DT file.
>> Note that since the driver is currently under cleanup, some hacks
>> will have to be removed after.
>>
>> Add documentation for GPIO properties specific to OMAP.
>>
>> Remove an un-needed whitespace.
>>
>> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
>> Cc: Grant Likely<grant.likely@secretlab.ca>
>> Cc: Charulatha V<charu@ti.com>
>> Cc: Tarun Kanti DebBarma<tarun.kanti@ti.com>
>> ---
>> .../devicetree/bindings/gpio/gpio-omap.txt | 33 ++++++
>> drivers/gpio/gpio-omap.c | 108 ++++++++++++++++++--
>> 2 files changed, 132 insertions(+), 9 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>> new file mode 100644
>> index 0000000..bdd63de
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>> @@ -0,0 +1,33 @@
>> +OMAP GPIO controller
>> +
>> +Required properties:
>> +- compatible:
>> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
>
> Would it be more readable to have
> "ti,omap2-gpio" for OMAP2 controllers and
> "ti,omap3-gpio" for OMAP3 controllers?
>
>> + - "ti,omap4-gpio" for OMAP4 controller
>> +- #gpio-cells : Should be two.
>> + - first cell is the pin number
>> + - second cell is used to specify optional parameters (unused)
>> +- gpio-controller : Marks the device node as a GPIO controller.
>> +
>> +OMAP specific properties:
>> +- ti,hwmods: Name of the hwmod associated to the GPIO
>> +- id: 32 bits to identify the id (1 based index)
>> +- bank-width: number of pin supported by the controller (16 or 32)
>> +- debounce: set if the controller support the debouce funtionnality
>> +- bank-count: number of controller support by the SoC. This is a temporary
>> + hack until the bank_count is removed from the driver.
>
> Is there a general rule to be followed as to when to use
> "ti,<prop-name>" and when to use just"<prop-name>".
> Since all these are OMAP specific properties, shouldn't all
> of them be "ti,<prop-name>"?
To be honest, I was wondering as well about this rule.
I think that a property that is not purely OMAP specific and that
represents some standard HW information does not have to be prefixed by
"ti,XXX".
So hwmods must be "ti,hwmods", but bank-witdh and bank-count seems to me
quite generic.
>> +Example:
>> +
>> +gpio4: gpio4 {
>> + compatible = "ti,omap4-gpio", "ti,omap-gpio";
>> + ti,hwmods = "gpio4";
>> + id =<4>;
>> + bank-width =<32>;
>> + debounce;
>> + no_idle_on_suspend;
>> + #gpio-cells =<2>;
>> + gpio-controller;
>> +};
>> +
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 0599854..f878fa4 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -21,6 +21,8 @@
>> #include<linux/io.h>
>> #include<linux/slab.h>
>> #include<linux/pm_runtime.h>
>> +#include<linux/of.h>
>> +#include<linux/of_device.h>
>>
>> #include<mach/hardware.h>
>> #include<asm/irq.h>
>> @@ -521,7 +523,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
>> unsigned long flags;
>>
>> if (bank->non_wakeup_gpios& gpio_bit) {
>> - dev_err(bank->dev,
>> + dev_err(bank->dev,
>
> Stray change?
Not anymore, it is part of the changelog :-)
>
>> "Unable to modify wakeup on non-wakeup GPIO%d\n", gpio);
>> return -EINVAL;
>> }
>> @@ -1150,6 +1152,8 @@ static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
>> irq_set_handler_data(bank->irq, bank);
>> }
>>
>> +static const struct of_device_id omap_gpio_match[];
>> +
>> static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> {
>> static int gpio_init_done;
>> @@ -1157,11 +1161,31 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> struct resource *res;
>> int id;
>> struct gpio_bank *bank;
>> + struct device_node *node = pdev->dev.of_node;
>> + const struct of_device_id *match;
>> +
>> + match = of_match_device(omap_gpio_match,&pdev->dev);
>> + if (match) {
>> + pdata = match->data;
>> + /* XXX: big hack until the bank_count is removed */
>> + of_property_read_u32(node, "bank-count",&gpio_bank_count);
>> + if (of_property_read_u32(node, "id",&id))
>
> id should be u32.
Oops, good point.
>
>> + return -EINVAL;
>> + /*
>> + * In an ideal world, the id should not be needed, but since
>> + * the OMAP TRM consider the multiple GPIO controllers as
>> + * multiple banks, the GPIO number is based on the whole set
>> + * of banks. Hence the need to provide an id in order to
>> + * respect the order and the correct GPIO number.
>> + */
>> + id -= 1;
>> + } else {
>> + if (!pdev->dev.platform_data)
>> + return -EINVAL;
>>
>> - if (!pdev->dev.platform_data)
>> - return -EINVAL;
>> -
>> - pdata = pdev->dev.platform_data;
>> + pdata = pdev->dev.platform_data;
>> + id = pdev->id;
>> + }
>>
>> if (!gpio_init_done) {
>> int ret;
>> @@ -1171,7 +1195,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> return ret;
>> }
>>
>> - id = pdev->id;
>> bank =&gpio_bank[id];
>>
>> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> @@ -1181,12 +1204,19 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> }
>>
>> bank->irq = res->start;
>> - bank->virtual_irq_start = pdata->virtual_irq_start;
>> bank->method = pdata->bank_type;
>> bank->dev =&pdev->dev;
>> - bank->dbck_flag = pdata->dbck_flag;
>> bank->stride = pdata->bank_stride;
>> - bank->width = pdata->bank_width;
>> + if (match) {
>> + of_property_read_u32(node, "bank-width",&bank->width);
>
> Bank width should be u32.
>
>> + if (of_get_property(node, "debounce", NULL))
>
> of_find_property() should suffice.
Yes, indeed.
Thanks,
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
@ 2011-09-28 8:15 ` Cousson, Benoit
0 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rajendra,
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
>> Adapt the GPIO driver to retrieve information from a DT file.
>> Note that since the driver is currently under cleanup, some hacks
>> will have to be removed after.
>>
>> Add documentation for GPIO properties specific to OMAP.
>>
>> Remove an un-needed whitespace.
>>
>> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
>> Cc: Grant Likely<grant.likely@secretlab.ca>
>> Cc: Charulatha V<charu@ti.com>
>> Cc: Tarun Kanti DebBarma<tarun.kanti@ti.com>
>> ---
>> .../devicetree/bindings/gpio/gpio-omap.txt | 33 ++++++
>> drivers/gpio/gpio-omap.c | 108 ++++++++++++++++++--
>> 2 files changed, 132 insertions(+), 9 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>> new file mode 100644
>> index 0000000..bdd63de
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>> @@ -0,0 +1,33 @@
>> +OMAP GPIO controller
>> +
>> +Required properties:
>> +- compatible:
>> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
>
> Would it be more readable to have
> "ti,omap2-gpio" for OMAP2 controllers and
> "ti,omap3-gpio" for OMAP3 controllers?
>
>> + - "ti,omap4-gpio" for OMAP4 controller
>> +- #gpio-cells : Should be two.
>> + - first cell is the pin number
>> + - second cell is used to specify optional parameters (unused)
>> +- gpio-controller : Marks the device node as a GPIO controller.
>> +
>> +OMAP specific properties:
>> +- ti,hwmods: Name of the hwmod associated to the GPIO
>> +- id: 32 bits to identify the id (1 based index)
>> +- bank-width: number of pin supported by the controller (16 or 32)
>> +- debounce: set if the controller support the debouce funtionnality
>> +- bank-count: number of controller support by the SoC. This is a temporary
>> + hack until the bank_count is removed from the driver.
>
> Is there a general rule to be followed as to when to use
> "ti,<prop-name>" and when to use just"<prop-name>".
> Since all these are OMAP specific properties, shouldn't all
> of them be "ti,<prop-name>"?
To be honest, I was wondering as well about this rule.
I think that a property that is not purely OMAP specific and that
represents some standard HW information does not have to be prefixed by
"ti,XXX".
So hwmods must be "ti,hwmods", but bank-witdh and bank-count seems to me
quite generic.
>> +Example:
>> +
>> +gpio4: gpio4 {
>> + compatible = "ti,omap4-gpio", "ti,omap-gpio";
>> + ti,hwmods = "gpio4";
>> + id =<4>;
>> + bank-width =<32>;
>> + debounce;
>> + no_idle_on_suspend;
>> + #gpio-cells =<2>;
>> + gpio-controller;
>> +};
>> +
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 0599854..f878fa4 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -21,6 +21,8 @@
>> #include<linux/io.h>
>> #include<linux/slab.h>
>> #include<linux/pm_runtime.h>
>> +#include<linux/of.h>
>> +#include<linux/of_device.h>
>>
>> #include<mach/hardware.h>
>> #include<asm/irq.h>
>> @@ -521,7 +523,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
>> unsigned long flags;
>>
>> if (bank->non_wakeup_gpios& gpio_bit) {
>> - dev_err(bank->dev,
>> + dev_err(bank->dev,
>
> Stray change?
Not anymore, it is part of the changelog :-)
>
>> "Unable to modify wakeup on non-wakeup GPIO%d\n", gpio);
>> return -EINVAL;
>> }
>> @@ -1150,6 +1152,8 @@ static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
>> irq_set_handler_data(bank->irq, bank);
>> }
>>
>> +static const struct of_device_id omap_gpio_match[];
>> +
>> static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> {
>> static int gpio_init_done;
>> @@ -1157,11 +1161,31 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> struct resource *res;
>> int id;
>> struct gpio_bank *bank;
>> + struct device_node *node = pdev->dev.of_node;
>> + const struct of_device_id *match;
>> +
>> + match = of_match_device(omap_gpio_match,&pdev->dev);
>> + if (match) {
>> + pdata = match->data;
>> + /* XXX: big hack until the bank_count is removed */
>> + of_property_read_u32(node, "bank-count",&gpio_bank_count);
>> + if (of_property_read_u32(node, "id",&id))
>
> id should be u32.
Oops, good point.
>
>> + return -EINVAL;
>> + /*
>> + * In an ideal world, the id should not be needed, but since
>> + * the OMAP TRM consider the multiple GPIO controllers as
>> + * multiple banks, the GPIO number is based on the whole set
>> + * of banks. Hence the need to provide an id in order to
>> + * respect the order and the correct GPIO number.
>> + */
>> + id -= 1;
>> + } else {
>> + if (!pdev->dev.platform_data)
>> + return -EINVAL;
>>
>> - if (!pdev->dev.platform_data)
>> - return -EINVAL;
>> -
>> - pdata = pdev->dev.platform_data;
>> + pdata = pdev->dev.platform_data;
>> + id = pdev->id;
>> + }
>>
>> if (!gpio_init_done) {
>> int ret;
>> @@ -1171,7 +1195,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> return ret;
>> }
>>
>> - id = pdev->id;
>> bank =&gpio_bank[id];
>>
>> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> @@ -1181,12 +1204,19 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>> }
>>
>> bank->irq = res->start;
>> - bank->virtual_irq_start = pdata->virtual_irq_start;
>> bank->method = pdata->bank_type;
>> bank->dev =&pdev->dev;
>> - bank->dbck_flag = pdata->dbck_flag;
>> bank->stride = pdata->bank_stride;
>> - bank->width = pdata->bank_width;
>> + if (match) {
>> + of_property_read_u32(node, "bank-width",&bank->width);
>
> Bank width should be u32.
>
>> + if (of_get_property(node, "debounce", NULL))
>
> of_find_property() should suffice.
Yes, indeed.
Thanks,
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
2011-09-27 5:40 ` Rajendra Nayak
@ 2011-09-28 8:20 ` Cousson, Benoit
-1 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:20 UTC (permalink / raw)
To: Nayak, Rajendra
Cc: Hilman, Kevin, paul, tony, devicetree-discuss, grant.likely,
linux-omap, DebBarma, Tarun Kanti, linux-arm-kernel, Varadarajan,
Charulatha
I missed one comment...
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
[...]
>> +Required properties:
>> +- compatible:
>> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
>
> Would it be more readable to have
> "ti,omap2-gpio" for OMAP2 controllers and
> "ti,omap3-gpio" for OMAP3 controllers?
The point here is to identify the IP version used in various OMAPs.
Since OMAP3 and OMAP2 are using the same IP version, there is no point
to differentiate the OMAP3 version.
What is doable is to put both "ti,omap3-gpio", "ti,omap2-gpio" to avoid
modifying the driver for no reason and still being able to identify the
OMAP3 version.
But I'm not sure we should do that if there is not real difference.
regards,
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
@ 2011-09-28 8:20 ` Cousson, Benoit
0 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:20 UTC (permalink / raw)
To: linux-arm-kernel
I missed one comment...
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
[...]
>> +Required properties:
>> +- compatible:
>> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
>
> Would it be more readable to have
> "ti,omap2-gpio" for OMAP2 controllers and
> "ti,omap3-gpio" for OMAP3 controllers?
The point here is to identify the IP version used in various OMAPs.
Since OMAP3 and OMAP2 are using the same IP version, there is no point
to differentiate the OMAP3 version.
What is doable is to put both "ti,omap3-gpio", "ti,omap2-gpio" to avoid
modifying the driver for no reason and still being able to identify the
OMAP3 version.
But I'm not sure we should do that if there is not real difference.
regards,
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 06/13] mfd: twl-core: Add initial DT support for twl4030/twl6030
2011-09-27 5:42 ` Rajendra Nayak
@ 2011-09-28 8:52 ` Cousson, Benoit
-1 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:52 UTC (permalink / raw)
To: Nayak, Rajendra
Cc: Hilman, Kevin, paul, Krishnamoorthy, Balaji T, tony,
devicetree-discuss, grant.likely, Graeme Gregory, linux-omap,
linux-arm-kernel, Samuel Ortiz
On 9/27/2011 7:42 AM, Nayak, Rajendra wrote:
> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
>> Add initial device-tree support for twl familly chips.
>
> s/familly/family
Oops.
>> The current version is missing the regulator entries due
>> to the lack of DT regulator bindings for the moment.
>> Only the simple sub-modules that do not depend on
>> platform_data information can be initialized properly.
>>
>> Add documentation for the Texas Instruments TWL Integrated Chip.
>>
>> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
>> Cc: Balaji T K<balajitk@ti.com>
>> Cc: Graeme Gregory<gg@slimlogic.co.uk>
>> Cc: Samuel Ortiz<sameo@linux.intel.com>
>> ---
>> .../devicetree/bindings/mfd/twl-familly.txt | 47 +++++++++++++++++
>> drivers/mfd/twl-core.c | 53 ++++++++++++++++++--
>> 2 files changed, 96 insertions(+), 4 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
>
> s/familly.txt/family.txt
At least I am consistent in my typos ;-)
>> diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt b/Documentation/devicetree/bindings/mfd/twl-familly.txt
>> new file mode 100644
>> index 0000000..ff4cacd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt
>> @@ -0,0 +1,47 @@
>> +Texas Instruments TWL family
>> +
>> +The TWLs are Integrated Power Management Chips.
>> +Some version might contain much more analog function like
>> +USB transceiver or Audio amplifier.
>> +These chips are connected to an i2c bus.
>> +
>> +
>> +Required properties:
>> +- compatible : Must be "ti,twl4030";
>> + For Integrated power-management/audio CODEC device used in OMAP3
>> + based boards
>> +- compatible : Must be "ti,twl6030";
>> + For Integrated power-management used in OMAP4 based boards
>> +- interrupts : This i2c device has an IRQ line connected to the main SoC
>> +- interrupt-controller : Since the twl support several interrupts internally,
>> + it is considered as an interrupt controller cascaded to the SoC one.
>> +- #interrupt-cells =<1>;
>> +- interrupt-parent : The parent interrupt controller.
>> +
>> +Optional node:
>> +- Child nodes contain in the twl. The twl family is made of severals variants
>> + that support a different number of features.
>> + The children nodes will thus depend of the capabilty of the variant.
>> +
>> +
>> +Example:
>> +/*
>> + * Integrated Power Management Chip
>> + * http://www.ti.com/lit/ds/symlink/twl6030.pdf
>> + */
>> +twl@48 {
>> + compatible = "ti,twl6030";
>> + reg =<0x48>;
>
> What does the 'reg' property signify here for twl?
The i2c slave address.
>> + interrupts =<39>; /* IRQ_SYS_1N cascaded to gic */
>> + interrupt-controller;
>> + #interrupt-cells =<1>;
>> + interrupt-parent =<&gic>;
>> + #address-cells =<1>;
>> + #size-cells =<0>;
>> +
>> + twl_rtc {
>> + compatible = "ti,twl_rtc";
>> + interrupts =<11>;
>> + reg =<0>;
>
> Does the 'reg' property need to be faked for
> every twl child node, even if it does not have
> any?
No, it was even removed from the DTS. But I forgot to update the
documentation:-(
>> + };
>> +};
>> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
>> index 01ecfee..3ef0b43 100644
>> --- a/drivers/mfd/twl-core.c
>> +++ b/drivers/mfd/twl-core.c
>> @@ -33,6 +33,10 @@
>> #include<linux/platform_device.h>
>> #include<linux/clk.h>
>> #include<linux/err.h>
>> +#include<linux/slab.h>
>> +#include<linux/of_irq.h>
>> +#include<linux/of_platform.h>
>> +#include<linux/irqdomain.h>
>>
>> #include<linux/regulator/machine.h>
>>
>> @@ -1182,22 +1186,53 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
>> int status;
>> unsigned i;
>> struct twl4030_platform_data *pdata = client->dev.platform_data;
>> + struct device_node *node = client->dev.of_node;
>> u8 temp;
>> int ret = 0;
>>
>> + if (node&& !pdata) {
>> + /*
>> + * XXX: Temporary fake pdata until the information
>> + * is correctly retrieved by every TWL modules from DT.
>> + */
>> + pdata = kzalloc(sizeof(struct twl4030_platform_data),
>> + GFP_KERNEL);
>
> devm_kzalloc instead?
Good point.
>> + if (!pdata) {
>> + status = -ENOMEM;
>> + goto exit;
>> + }
>> +
>> + /*
>> + * XXX: For the moment the IRQs for TWL seems to be encoded in
>> + * the global OMAP space. That should be cleaned to allow
>> + * dynamically adding a new IRQ controller.
>> + */
>> + if ((id->driver_data)& TWL6030_CLASS) {
>> + pdata->irq_base = TWL6030_IRQ_BASE;
>> + pdata->irq_end = pdata->irq_base + TWL6030_BASE_NR_IRQS;
>> + } else {
>> + pdata->irq_base = TWL4030_IRQ_BASE;
>> + pdata->irq_end = pdata->irq_base + TWL4030_BASE_NR_IRQS;
>> + }
>> + irq_domain_add_simple(node, pdata->irq_base);
>> + }
>> +
>> if (!pdata) {
>> dev_dbg(&client->dev, "no platform data?\n");
>> - return -EINVAL;
>> + status = -EINVAL;
>> + goto fail_free;
>> }
>>
>> if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
>> dev_dbg(&client->dev, "can't talk I2C?\n");
>> - return -EIO;
>> + status = -EIO;
>> + goto fail_free;
>> }
>>
>> if (inuse) {
>> dev_dbg(&client->dev, "driver is already in use\n");
>> - return -EBUSY;
>> + status = -EBUSY;
>> + goto fail_free;
>> }
>>
>> for (i = 0; i< TWL_NUM_SLAVES; i++) {
>> @@ -1269,10 +1304,20 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
>> twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
>> }
>>
>> - status = add_children(pdata, id->driver_data);
>> +#ifdef CONFIG_OF_DEVICE
>
> is the #ifdef really needed?
Yes, because the of_platform_populate does not have a stub in case of
none DT build... But I agree, it is ugly and the of_platform.h should
maybe be fixed instead.
I was too lazy to fix it :-)
Thanks,
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 06/13] mfd: twl-core: Add initial DT support for twl4030/twl6030
@ 2011-09-28 8:52 ` Cousson, Benoit
0 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:52 UTC (permalink / raw)
To: linux-arm-kernel
On 9/27/2011 7:42 AM, Nayak, Rajendra wrote:
> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
>> Add initial device-tree support for twl familly chips.
>
> s/familly/family
Oops.
>> The current version is missing the regulator entries due
>> to the lack of DT regulator bindings for the moment.
>> Only the simple sub-modules that do not depend on
>> platform_data information can be initialized properly.
>>
>> Add documentation for the Texas Instruments TWL Integrated Chip.
>>
>> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
>> Cc: Balaji T K<balajitk@ti.com>
>> Cc: Graeme Gregory<gg@slimlogic.co.uk>
>> Cc: Samuel Ortiz<sameo@linux.intel.com>
>> ---
>> .../devicetree/bindings/mfd/twl-familly.txt | 47 +++++++++++++++++
>> drivers/mfd/twl-core.c | 53 ++++++++++++++++++--
>> 2 files changed, 96 insertions(+), 4 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
>
> s/familly.txt/family.txt
At least I am consistent in my typos ;-)
>> diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt b/Documentation/devicetree/bindings/mfd/twl-familly.txt
>> new file mode 100644
>> index 0000000..ff4cacd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt
>> @@ -0,0 +1,47 @@
>> +Texas Instruments TWL family
>> +
>> +The TWLs are Integrated Power Management Chips.
>> +Some version might contain much more analog function like
>> +USB transceiver or Audio amplifier.
>> +These chips are connected to an i2c bus.
>> +
>> +
>> +Required properties:
>> +- compatible : Must be "ti,twl4030";
>> + For Integrated power-management/audio CODEC device used in OMAP3
>> + based boards
>> +- compatible : Must be "ti,twl6030";
>> + For Integrated power-management used in OMAP4 based boards
>> +- interrupts : This i2c device has an IRQ line connected to the main SoC
>> +- interrupt-controller : Since the twl support several interrupts internally,
>> + it is considered as an interrupt controller cascaded to the SoC one.
>> +- #interrupt-cells =<1>;
>> +- interrupt-parent : The parent interrupt controller.
>> +
>> +Optional node:
>> +- Child nodes contain in the twl. The twl family is made of severals variants
>> + that support a different number of features.
>> + The children nodes will thus depend of the capabilty of the variant.
>> +
>> +
>> +Example:
>> +/*
>> + * Integrated Power Management Chip
>> + * http://www.ti.com/lit/ds/symlink/twl6030.pdf
>> + */
>> +twl at 48 {
>> + compatible = "ti,twl6030";
>> + reg =<0x48>;
>
> What does the 'reg' property signify here for twl?
The i2c slave address.
>> + interrupts =<39>; /* IRQ_SYS_1N cascaded to gic */
>> + interrupt-controller;
>> + #interrupt-cells =<1>;
>> + interrupt-parent =<&gic>;
>> + #address-cells =<1>;
>> + #size-cells =<0>;
>> +
>> + twl_rtc {
>> + compatible = "ti,twl_rtc";
>> + interrupts =<11>;
>> + reg =<0>;
>
> Does the 'reg' property need to be faked for
> every twl child node, even if it does not have
> any?
No, it was even removed from the DTS. But I forgot to update the
documentation:-(
>> + };
>> +};
>> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
>> index 01ecfee..3ef0b43 100644
>> --- a/drivers/mfd/twl-core.c
>> +++ b/drivers/mfd/twl-core.c
>> @@ -33,6 +33,10 @@
>> #include<linux/platform_device.h>
>> #include<linux/clk.h>
>> #include<linux/err.h>
>> +#include<linux/slab.h>
>> +#include<linux/of_irq.h>
>> +#include<linux/of_platform.h>
>> +#include<linux/irqdomain.h>
>>
>> #include<linux/regulator/machine.h>
>>
>> @@ -1182,22 +1186,53 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
>> int status;
>> unsigned i;
>> struct twl4030_platform_data *pdata = client->dev.platform_data;
>> + struct device_node *node = client->dev.of_node;
>> u8 temp;
>> int ret = 0;
>>
>> + if (node&& !pdata) {
>> + /*
>> + * XXX: Temporary fake pdata until the information
>> + * is correctly retrieved by every TWL modules from DT.
>> + */
>> + pdata = kzalloc(sizeof(struct twl4030_platform_data),
>> + GFP_KERNEL);
>
> devm_kzalloc instead?
Good point.
>> + if (!pdata) {
>> + status = -ENOMEM;
>> + goto exit;
>> + }
>> +
>> + /*
>> + * XXX: For the moment the IRQs for TWL seems to be encoded in
>> + * the global OMAP space. That should be cleaned to allow
>> + * dynamically adding a new IRQ controller.
>> + */
>> + if ((id->driver_data)& TWL6030_CLASS) {
>> + pdata->irq_base = TWL6030_IRQ_BASE;
>> + pdata->irq_end = pdata->irq_base + TWL6030_BASE_NR_IRQS;
>> + } else {
>> + pdata->irq_base = TWL4030_IRQ_BASE;
>> + pdata->irq_end = pdata->irq_base + TWL4030_BASE_NR_IRQS;
>> + }
>> + irq_domain_add_simple(node, pdata->irq_base);
>> + }
>> +
>> if (!pdata) {
>> dev_dbg(&client->dev, "no platform data?\n");
>> - return -EINVAL;
>> + status = -EINVAL;
>> + goto fail_free;
>> }
>>
>> if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
>> dev_dbg(&client->dev, "can't talk I2C?\n");
>> - return -EIO;
>> + status = -EIO;
>> + goto fail_free;
>> }
>>
>> if (inuse) {
>> dev_dbg(&client->dev, "driver is already in use\n");
>> - return -EBUSY;
>> + status = -EBUSY;
>> + goto fail_free;
>> }
>>
>> for (i = 0; i< TWL_NUM_SLAVES; i++) {
>> @@ -1269,10 +1304,20 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
>> twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
>> }
>>
>> - status = add_children(pdata, id->driver_data);
>> +#ifdef CONFIG_OF_DEVICE
>
> is the #ifdef really needed?
Yes, because the of_platform_populate does not have a stub in case of
none DT build... But I agree, it is ugly and the of_platform.h should
maybe be fixed instead.
I was too lazy to fix it :-)
Thanks,
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
2011-09-28 8:15 ` Cousson, Benoit
@ 2011-09-28 18:23 ` Scott Wood
-1 siblings, 0 replies; 52+ messages in thread
From: Scott Wood @ 2011-09-28 18:23 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Nayak, Rajendra, Hilman, Kevin, tony, devicetree-discuss,
linux-omap, DebBarma, Tarun Kanti, linux-arm-kernel, Varadarajan,
Charulatha
On 09/28/2011 03:15 AM, Cousson, Benoit wrote:
> On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
>> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
>>> +Required properties:
>>> +- compatible:
>>> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
>>
>> Would it be more readable to have
>> "ti,omap2-gpio" for OMAP2 controllers and
>> "ti,omap3-gpio" for OMAP3 controllers?
Or have OMAP3 say this if it's fully backwards compatible:
compatible = "ti,omap3-gpio", "ti,omap2-gpio";
>>> + - "ti,omap4-gpio" for OMAP4 controller
>>> +- #gpio-cells : Should be two.
>>> + - first cell is the pin number
>>> + - second cell is used to specify optional parameters (unused)
>>> +- gpio-controller : Marks the device node as a GPIO controller.
>>> +
>>> +OMAP specific properties:
>>> +- ti,hwmods: Name of the hwmod associated to the GPIO
>>> +- id: 32 bits to identify the id (1 based index)
What does "the id" mean, in relation to the actual hardware?
Some existing bindings have such a thing (often called "cell-index"),
but it should be well-defined what it refers to. Often aliases would be
a better approach, if it just refers to what the manual calls the device.
>>> +- bank-width: number of pin supported by the controller (16 or 32)
>>> +- debounce: set if the controller support the debouce funtionnality
>>> +- bank-count: number of controller support by the SoC. This is a
>>> temporary
>>> + hack until the bank_count is removed from the driver.
>>
>> Is there a general rule to be followed as to when to use
>> "ti,<prop-name>" and when to use just"<prop-name>".
>> Since all these are OMAP specific properties, shouldn't all
>> of them be "ti,<prop-name>"?
>
> To be honest, I was wondering as well about this rule.
> I think that a property that is not purely OMAP specific and that
> represents some standard HW information does not have to be prefixed by
> "ti,XXX".
> So hwmods must be "ti,hwmods", but bank-witdh and bank-count seems to me
> quite generic.
It's about where the property is documented. Suppose you use an
un-prefixed bank-width but define it in the TI-specific binding to mean
width in bits. Later, someone wants something similar for another
driver, doesn't look at the TI binding, but says, "This is generic, I'll
define something in the main gpio binding," but defines it as width in
bytes (ignore the (de)merits of defining it that way in this case). If
you had a namespace prefix, it would be clear which binding a node is
referring to.
As for bank-count, the description "this is a temporary hack until the
bank_count is removed from the driver" suggests it shouldn't be there at
all, much less be part of the generic binding.
-Scott
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
@ 2011-09-28 18:23 ` Scott Wood
0 siblings, 0 replies; 52+ messages in thread
From: Scott Wood @ 2011-09-28 18:23 UTC (permalink / raw)
To: linux-arm-kernel
On 09/28/2011 03:15 AM, Cousson, Benoit wrote:
> On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
>> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
>>> +Required properties:
>>> +- compatible:
>>> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
>>
>> Would it be more readable to have
>> "ti,omap2-gpio" for OMAP2 controllers and
>> "ti,omap3-gpio" for OMAP3 controllers?
Or have OMAP3 say this if it's fully backwards compatible:
compatible = "ti,omap3-gpio", "ti,omap2-gpio";
>>> + - "ti,omap4-gpio" for OMAP4 controller
>>> +- #gpio-cells : Should be two.
>>> + - first cell is the pin number
>>> + - second cell is used to specify optional parameters (unused)
>>> +- gpio-controller : Marks the device node as a GPIO controller.
>>> +
>>> +OMAP specific properties:
>>> +- ti,hwmods: Name of the hwmod associated to the GPIO
>>> +- id: 32 bits to identify the id (1 based index)
What does "the id" mean, in relation to the actual hardware?
Some existing bindings have such a thing (often called "cell-index"),
but it should be well-defined what it refers to. Often aliases would be
a better approach, if it just refers to what the manual calls the device.
>>> +- bank-width: number of pin supported by the controller (16 or 32)
>>> +- debounce: set if the controller support the debouce funtionnality
>>> +- bank-count: number of controller support by the SoC. This is a
>>> temporary
>>> + hack until the bank_count is removed from the driver.
>>
>> Is there a general rule to be followed as to when to use
>> "ti,<prop-name>" and when to use just"<prop-name>".
>> Since all these are OMAP specific properties, shouldn't all
>> of them be "ti,<prop-name>"?
>
> To be honest, I was wondering as well about this rule.
> I think that a property that is not purely OMAP specific and that
> represents some standard HW information does not have to be prefixed by
> "ti,XXX".
> So hwmods must be "ti,hwmods", but bank-witdh and bank-count seems to me
> quite generic.
It's about where the property is documented. Suppose you use an
un-prefixed bank-width but define it in the TI-specific binding to mean
width in bits. Later, someone wants something similar for another
driver, doesn't look at the TI binding, but says, "This is generic, I'll
define something in the main gpio binding," but defines it as width in
bytes (ignore the (de)merits of defining it that way in this case). If
you had a namespace prefix, it would be clear which binding a node is
referring to.
As for bank-count, the description "this is a temporary hack until the
bank_count is removed from the driver" suggests it shouldn't be there at
all, much less be part of the generic binding.
-Scott
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
2011-09-28 18:23 ` Scott Wood
@ 2011-09-28 20:57 ` Cousson, Benoit
-1 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-28 20:57 UTC (permalink / raw)
To: Scott Wood
Cc: Hilman, Kevin, tony, devicetree-discuss, Nayak, Rajendra,
linux-omap, DebBarma, Tarun Kanti, linux-arm-kernel, Varadarajan,
Charulatha
On 9/28/2011 8:23 PM, Scott Wood wrote:
> On 09/28/2011 03:15 AM, Cousson, Benoit wrote:
>> On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
>>> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
>>>> +Required properties:
>>>> +- compatible:
>>>> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
>>>
>>> Would it be more readable to have
>>> "ti,omap2-gpio" for OMAP2 controllers and
>>> "ti,omap3-gpio" for OMAP3 controllers?
>
> Or have OMAP3 say this if it's fully backwards compatible:
>
> compatible = "ti,omap3-gpio", "ti,omap2-gpio";
I saw that several time for other platform, but was wondering if this
was a strong rule or not. In that case, the IP is the same, so should we
still identify it with a different compatible value?
>>>> + - "ti,omap4-gpio" for OMAP4 controller
>>>> +- #gpio-cells : Should be two.
>>>> + - first cell is the pin number
>>>> + - second cell is used to specify optional parameters (unused)
>>>> +- gpio-controller : Marks the device node as a GPIO controller.
>>>> +
>>>> +OMAP specific properties:
>>>> +- ti,hwmods: Name of the hwmod associated to the GPIO
>>>> +- id: 32 bits to identify the id (1 based index)
>
> What does "the id" mean, in relation to the actual hardware?
It's true that the description is not super meaningful...
This is the HW instance number. We have 6 gpios, named gpio1 to gpio6,
but the pin numbering is global, meaning from 1 to 192, sine only the
global number is referenced in the pinmuxing control, we have to
maintain the order to ensure the right number.
I still do not know how to use that with the way gpio binding is
working. Because in theory each gpio controller should be referenced
with the local number, not the global one. And converting that global
number from HW spec to a gpio instance + local number seems to me very
error prone.
> Some existing bindings have such a thing (often called "cell-index"),
> but it should be well-defined what it refers to. Often aliases would be
> a better approach, if it just refers to what the manual calls the device.
The issue is that the manual refer to a global gpio controller.
>>>> +- bank-width: number of pin supported by the controller (16 or 32)
>>>> +- debounce: set if the controller support the debouce funtionnality
>>>> +- bank-count: number of controller support by the SoC. This is a
>>>> temporary
>>>> + hack until the bank_count is removed from the driver.
>>>
>>> Is there a general rule to be followed as to when to use
>>> "ti,<prop-name>" and when to use just"<prop-name>".
>>> Since all these are OMAP specific properties, shouldn't all
>>> of them be "ti,<prop-name>"?
>>
>> To be honest, I was wondering as well about this rule.
>> I think that a property that is not purely OMAP specific and that
>> represents some standard HW information does not have to be prefixed by
>> "ti,XXX".
>> So hwmods must be "ti,hwmods", but bank-witdh and bank-count seems to me
>> quite generic.
>
> It's about where the property is documented. Suppose you use an
> un-prefixed bank-width but define it in the TI-specific binding to mean
> width in bits. Later, someone wants something similar for another
> driver, doesn't look at the TI binding, but says, "This is generic, I'll
> define something in the main gpio binding," but defines it as width in
> bytes (ignore the (de)merits of defining it that way in this case). If
> you had a namespace prefix, it would be clear which binding a node is
> referring to.
Good to know, and that makes sense. So the recommendation is to add that
into the generic gpio as much as possible if this can be reused by
someone else.
> As for bank-count, the description "this is a temporary hack until the
> bank_count is removed from the driver" suggests it shouldn't be there at
> all, much less be part of the generic binding.
That one sucks and will be removed soon since the driver cleanup was
posted and waiting for upstream acceptance.
Thanks for the detailed explanations.
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
@ 2011-09-28 20:57 ` Cousson, Benoit
0 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-28 20:57 UTC (permalink / raw)
To: linux-arm-kernel
On 9/28/2011 8:23 PM, Scott Wood wrote:
> On 09/28/2011 03:15 AM, Cousson, Benoit wrote:
>> On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
>>> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
>>>> +Required properties:
>>>> +- compatible:
>>>> + - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
>>>
>>> Would it be more readable to have
>>> "ti,omap2-gpio" for OMAP2 controllers and
>>> "ti,omap3-gpio" for OMAP3 controllers?
>
> Or have OMAP3 say this if it's fully backwards compatible:
>
> compatible = "ti,omap3-gpio", "ti,omap2-gpio";
I saw that several time for other platform, but was wondering if this
was a strong rule or not. In that case, the IP is the same, so should we
still identify it with a different compatible value?
>>>> + - "ti,omap4-gpio" for OMAP4 controller
>>>> +- #gpio-cells : Should be two.
>>>> + - first cell is the pin number
>>>> + - second cell is used to specify optional parameters (unused)
>>>> +- gpio-controller : Marks the device node as a GPIO controller.
>>>> +
>>>> +OMAP specific properties:
>>>> +- ti,hwmods: Name of the hwmod associated to the GPIO
>>>> +- id: 32 bits to identify the id (1 based index)
>
> What does "the id" mean, in relation to the actual hardware?
It's true that the description is not super meaningful...
This is the HW instance number. We have 6 gpios, named gpio1 to gpio6,
but the pin numbering is global, meaning from 1 to 192, sine only the
global number is referenced in the pinmuxing control, we have to
maintain the order to ensure the right number.
I still do not know how to use that with the way gpio binding is
working. Because in theory each gpio controller should be referenced
with the local number, not the global one. And converting that global
number from HW spec to a gpio instance + local number seems to me very
error prone.
> Some existing bindings have such a thing (often called "cell-index"),
> but it should be well-defined what it refers to. Often aliases would be
> a better approach, if it just refers to what the manual calls the device.
The issue is that the manual refer to a global gpio controller.
>>>> +- bank-width: number of pin supported by the controller (16 or 32)
>>>> +- debounce: set if the controller support the debouce funtionnality
>>>> +- bank-count: number of controller support by the SoC. This is a
>>>> temporary
>>>> + hack until the bank_count is removed from the driver.
>>>
>>> Is there a general rule to be followed as to when to use
>>> "ti,<prop-name>" and when to use just"<prop-name>".
>>> Since all these are OMAP specific properties, shouldn't all
>>> of them be "ti,<prop-name>"?
>>
>> To be honest, I was wondering as well about this rule.
>> I think that a property that is not purely OMAP specific and that
>> represents some standard HW information does not have to be prefixed by
>> "ti,XXX".
>> So hwmods must be "ti,hwmods", but bank-witdh and bank-count seems to me
>> quite generic.
>
> It's about where the property is documented. Suppose you use an
> un-prefixed bank-width but define it in the TI-specific binding to mean
> width in bits. Later, someone wants something similar for another
> driver, doesn't look at the TI binding, but says, "This is generic, I'll
> define something in the main gpio binding," but defines it as width in
> bytes (ignore the (de)merits of defining it that way in this case). If
> you had a namespace prefix, it would be clear which binding a node is
> referring to.
Good to know, and that makes sense. So the recommendation is to add that
into the generic gpio as much as possible if this can be reused by
someone else.
> As for bank-count, the description "this is a temporary hack until the
> bank_count is removed from the driver" suggests it shouldn't be there at
> all, much less be part of the generic binding.
That one sucks and will be removed soon since the driver cleanup was
posted and waiting for upstream acceptance.
Thanks for the detailed explanations.
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
2011-09-28 20:57 ` Cousson, Benoit
@ 2011-09-28 21:32 ` Scott Wood
-1 siblings, 0 replies; 52+ messages in thread
From: Scott Wood @ 2011-09-28 21:32 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Nayak, Rajendra, Hilman, Kevin, tony, devicetree-discuss,
linux-omap, DebBarma, Tarun Kanti, linux-arm-kernel, Varadarajan,
Charulatha
On 09/28/2011 03:57 PM, Cousson, Benoit wrote:
> On 9/28/2011 8:23 PM, Scott Wood wrote:
>> What does "the id" mean, in relation to the actual hardware?
>
> It's true that the description is not super meaningful...
> This is the HW instance number. We have 6 gpios, named gpio1 to gpio6,
> but the pin numbering is global, meaning from 1 to 192, sine only the
> global number is referenced in the pinmuxing control, we have to
> maintain the order to ensure the right number.
I'd either have one node that handles all the banks (with multiple "reg"
resources in the order that they should be mapped to the numberspace),
or avoid using that global numberspace and reference things by
bank/offset (with the bank identified by alias or phandle).
> I still do not know how to use that with the way gpio binding is
> working. Because in theory each gpio controller should be referenced
> with the local number, not the global one. And converting that global
> number from HW spec to a gpio instance + local number seems to me very
> error prone.
You could say the same thing about a chip whose manual is written
assuming a global IRQ numberspace with a certain encoding scheme.
Or in the other direction, Freescale's manuals split up MPIC interrupts
into external/internal/MSI, while they really just map to different
regions of the openpic (hardware standard that Freescale's MPIC is an
instance of) interrupt space. The device trees use the raw openpic
interrupt numbers.
There's certainly potential for confusion, but at least the device tree
representation is internally consistent and doesn't make assumptions
about the overall system.
-Scott
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
@ 2011-09-28 21:32 ` Scott Wood
0 siblings, 0 replies; 52+ messages in thread
From: Scott Wood @ 2011-09-28 21:32 UTC (permalink / raw)
To: linux-arm-kernel
On 09/28/2011 03:57 PM, Cousson, Benoit wrote:
> On 9/28/2011 8:23 PM, Scott Wood wrote:
>> What does "the id" mean, in relation to the actual hardware?
>
> It's true that the description is not super meaningful...
> This is the HW instance number. We have 6 gpios, named gpio1 to gpio6,
> but the pin numbering is global, meaning from 1 to 192, sine only the
> global number is referenced in the pinmuxing control, we have to
> maintain the order to ensure the right number.
I'd either have one node that handles all the banks (with multiple "reg"
resources in the order that they should be mapped to the numberspace),
or avoid using that global numberspace and reference things by
bank/offset (with the bank identified by alias or phandle).
> I still do not know how to use that with the way gpio binding is
> working. Because in theory each gpio controller should be referenced
> with the local number, not the global one. And converting that global
> number from HW spec to a gpio instance + local number seems to me very
> error prone.
You could say the same thing about a chip whose manual is written
assuming a global IRQ numberspace with a certain encoding scheme.
Or in the other direction, Freescale's manuals split up MPIC interrupts
into external/internal/MSI, while they really just map to different
regions of the openpic (hardware standard that Freescale's MPIC is an
instance of) interrupt space. The device trees use the raw openpic
interrupt numbers.
There's certainly potential for confusion, but at least the device tree
representation is internally consistent and doesn't make assumptions
about the overall system.
-Scott
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 12/13] arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
2011-09-26 16:50 ` Benoit Cousson
@ 2011-09-29 17:25 ` Grant Likely
-1 siblings, 0 replies; 52+ messages in thread
From: Grant Likely @ 2011-09-29 17:25 UTC (permalink / raw)
To: Benoit Cousson
Cc: khilman-l0cyMroinI0, tony-4v6yS6AI5VpBDgjK7y7TUQ, G,
Manjunath Kondaiah, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Mon, Sep 26, 2011 at 06:50:20PM +0200, Benoit Cousson wrote:
> Add required clock frequencies for the i2c client devices existing
> on beagle board.
>
> Add the twl4030 basic description with only the twl_rtc module.
>
> Add the EEPROM node.
>
> Based on original patch from Manju:
> http://www.spinics.net/lists/linux-omap/msg55831.html
>
> Signed-off-by: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
> Cc: G, Manjunath Kondaiah <manjugk-l0cyMroinI0@public.gmane.org>
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 38 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> index 9486be6..a65f39d 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -27,3 +27,41 @@
> reg = <0x80000000 0x20000000>; /* 512 MB */
> };
> };
> +
> +&i2c1 {
> + clock-frequency = <2600000>;
> +
> + /*
> + * Integrated Power Management Chip
> + */
> + twl@48 {
> + compatible = "ti,twl4030";
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + interrupt-parent = <&intc>;
> +
> + twl_rtc {
Nit: use the generic names recommended practise for node names (in
this case, simply 'rtc' sounds appropriate, and don't use underscores
(it's not forbidden, just doesn't match the style.
> + compatible = "ti,twl4030-rtc";
> + interrupts = <11>;
> + };
> + };
> +};
> +
> +&i2c2 {
> + clock-frequency = <400000>;
> +};
> +
> +&i2c3 {
> + clock-frequency = <100000>;
> +
> + /*
> + * Display monitor features are burnt in the EEPROM
> + * as EDID data.
> + */
> + eeprom@50 {
> + compatible = "ti,eeprom";
> + reg = <0x50>;
> + };
> +};
> --
> 1.7.0.4
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 12/13] arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
@ 2011-09-29 17:25 ` Grant Likely
0 siblings, 0 replies; 52+ messages in thread
From: Grant Likely @ 2011-09-29 17:25 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 26, 2011 at 06:50:20PM +0200, Benoit Cousson wrote:
> Add required clock frequencies for the i2c client devices existing
> on beagle board.
>
> Add the twl4030 basic description with only the twl_rtc module.
>
> Add the EEPROM node.
>
> Based on original patch from Manju:
> http://www.spinics.net/lists/linux-omap/msg55831.html
>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 38 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> index 9486be6..a65f39d 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -27,3 +27,41 @@
> reg = <0x80000000 0x20000000>; /* 512 MB */
> };
> };
> +
> +&i2c1 {
> + clock-frequency = <2600000>;
> +
> + /*
> + * Integrated Power Management Chip
> + */
> + twl at 48 {
> + compatible = "ti,twl4030";
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + interrupt-parent = <&intc>;
> +
> + twl_rtc {
Nit: use the generic names recommended practise for node names (in
this case, simply 'rtc' sounds appropriate, and don't use underscores
(it's not forbidden, just doesn't match the style.
> + compatible = "ti,twl4030-rtc";
> + interrupts = <11>;
> + };
> + };
> +};
> +
> +&i2c2 {
> + clock-frequency = <400000>;
> +};
> +
> +&i2c3 {
> + clock-frequency = <100000>;
> +
> + /*
> + * Display monitor features are burnt in the EEPROM
> + * as EDID data.
> + */
> + eeprom at 50 {
> + compatible = "ti,eeprom";
> + reg = <0x50>;
> + };
> +};
> --
> 1.7.0.4
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
2011-09-27 5:40 ` Rajendra Nayak
@ 2011-09-30 11:53 ` Cousson, Benoit
-1 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-30 11:53 UTC (permalink / raw)
To: Nayak, Rajendra
Cc: Hilman, Kevin, paul, tony, devicetree-discuss, grant.likely,
linux-omap, DebBarma, Tarun Kanti, linux-arm-kernel, Varadarajan,
Charulatha
Second thought... I was too fast to say OK :-)
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
[...]
>> + if (match) {
>> + of_property_read_u32(node, "bank-width",&bank->width);
>
> Bank width should be u32.
I guess you meant bank->width, and it appears that bank->width is
already a u32.
Regards,
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
@ 2011-09-30 11:53 ` Cousson, Benoit
0 siblings, 0 replies; 52+ messages in thread
From: Cousson, Benoit @ 2011-09-30 11:53 UTC (permalink / raw)
To: linux-arm-kernel
Second thought... I was too fast to say OK :-)
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
[...]
>> + if (match) {
>> + of_property_read_u32(node, "bank-width",&bank->width);
>
> Bank width should be u32.
I guess you meant bank->width, and it appears that bank->width is
already a u32.
Regards,
Benoit
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 01/13] hwspinlock: OMAP4: Add spinlock support in DT
2011-09-26 16:50 ` Benoit Cousson
@ 2011-10-10 12:49 ` Ohad Ben-Cohen
-1 siblings, 0 replies; 52+ messages in thread
From: Ohad Ben-Cohen @ 2011-10-10 12:49 UTC (permalink / raw)
To: Benoit Cousson
Cc: tony, grant.likely, paul, khilman, rnayak, linux-omap,
linux-arm-kernel, devicetree-discuss
Hi Benoit,
On Mon, Sep 26, 2011 at 7:50 PM, Benoit Cousson <b-cousson@ti.com> wrote:
> +++ b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
> @@ -0,0 +1,5 @@
> +* HW spinlock on OMAP4 platform:
> +
> +Required properties:
> +- compatible : Must be "ti,omap4-spinlock";
> +- ti,hwmods : "spinlock"
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 4c61c82..7a7f31e 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -99,5 +99,10 @@
> reg = <0x48241000 0x1000>,
> <0x48240100 0x0100>;
> };
> +
> + spinlock {
> + compatible = "ti,omap4-spinlock";
> + ti,hwmods = "spinlock";
> + };
I think it'd be nice to add the 'baseid' property as we discussed for
dynamic allocation of hwspinlocks.
The patch that adds the hwspinlock groundwork for this is in
linux-next and will hopefully get into 3.2 if everything works out
well:
https://lkml.org/lkml/2011/9/12/194
Of course, as we discussed with Arnd, we will use phandles to the
hwspinlock controller when we'll get to static allocations of
hwspinlock instances.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 01/13] hwspinlock: OMAP4: Add spinlock support in DT
@ 2011-10-10 12:49 ` Ohad Ben-Cohen
0 siblings, 0 replies; 52+ messages in thread
From: Ohad Ben-Cohen @ 2011-10-10 12:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Benoit,
On Mon, Sep 26, 2011 at 7:50 PM, Benoit Cousson <b-cousson@ti.com> wrote:
> +++ b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
> @@ -0,0 +1,5 @@
> +* HW spinlock on OMAP4 platform:
> +
> +Required properties:
> +- compatible : Must be "ti,omap4-spinlock";
> +- ti,hwmods : "spinlock"
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 4c61c82..7a7f31e 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -99,5 +99,10 @@
> ? ? ? ? ? ? ? ? ? ? ? ?reg = <0x48241000 0x1000>,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?<0x48240100 0x0100>;
> ? ? ? ? ? ? ? ?};
> +
> + ? ? ? ? ? ? ? spinlock {
> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-spinlock";
> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "spinlock";
> + ? ? ? ? ? ? ? };
I think it'd be nice to add the 'baseid' property as we discussed for
dynamic allocation of hwspinlocks.
The patch that adds the hwspinlock groundwork for this is in
linux-next and will hopefully get into 3.2 if everything works out
well:
https://lkml.org/lkml/2011/9/12/194
Of course, as we discussed with Arnd, we will use phandles to the
hwspinlock controller when we'll get to static allocations of
hwspinlock instances.
Thanks,
Ohad.
^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2011-10-10 12:49 UTC | newest]
Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-26 16:50 [PATCH 00/13] OMAP3+: Add DT support for early devices and i2c / twl6030 Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-26 16:50 ` [PATCH 01/13] hwspinlock: OMAP4: Add spinlock support in DT Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-10-10 12:49 ` Ohad Ben-Cohen
2011-10-10 12:49 ` Ohad Ben-Cohen
2011-09-26 16:50 ` [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
[not found] ` <1317055821-20652-3-git-send-email-b-cousson-l0cyMroinI0@public.gmane.org>
2011-09-27 5:40 ` Rajendra Nayak
2011-09-27 5:40 ` Rajendra Nayak
2011-09-28 8:15 ` Cousson, Benoit
2011-09-28 8:15 ` Cousson, Benoit
2011-09-28 18:23 ` Scott Wood
2011-09-28 18:23 ` Scott Wood
2011-09-28 20:57 ` Cousson, Benoit
2011-09-28 20:57 ` Cousson, Benoit
2011-09-28 21:32 ` Scott Wood
2011-09-28 21:32 ` Scott Wood
2011-09-28 8:20 ` Cousson, Benoit
2011-09-28 8:20 ` Cousson, Benoit
2011-09-30 11:53 ` Cousson, Benoit
2011-09-30 11:53 ` Cousson, Benoit
[not found] ` <1317055821-20652-1-git-send-email-b-cousson-l0cyMroinI0@public.gmane.org>
2011-09-26 16:50 ` [PATCH 03/13] arm/dts: OMAP4: Add gpio nodes Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-26 16:50 ` [PATCH 04/13] irq: Add stub for none DT build in irqdomain.h Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-26 16:50 ` [PATCH 05/13] i2c: OMAP: Add DT support for i2c controller Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-26 16:50 ` [PATCH 06/13] mfd: twl-core: Add initial DT support for twl4030/twl6030 Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-27 5:42 ` Rajendra Nayak
2011-09-27 5:42 ` Rajendra Nayak
2011-09-28 8:52 ` Cousson, Benoit
2011-09-28 8:52 ` Cousson, Benoit
2011-09-26 16:50 ` [PATCH 07/13] rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030 Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-26 16:50 ` [PATCH 08/13] arm/dts: OMAP4: Add i2c controller nodes Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-27 5:42 ` Rajendra Nayak
2011-09-27 5:42 ` Rajendra Nayak
2011-09-26 16:50 ` [PATCH 09/13] arm/dts: OMAP3: " Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-26 16:50 ` [PATCH 10/13] arm/dts: omap4-panda: Add twl6030 and i2c EEPROM Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-26 16:50 ` [PATCH 11/13] arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
2011-09-26 16:50 ` [PATCH 12/13] arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
[not found] ` <1317055821-20652-13-git-send-email-b-cousson-l0cyMroinI0@public.gmane.org>
2011-09-29 17:25 ` Grant Likely
2011-09-29 17:25 ` Grant Likely
2011-09-26 16:50 ` [PATCH 13/13] OMAP2+: board-generic: Remove i2c static init Benoit Cousson
2011-09-26 16:50 ` Benoit Cousson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.