* [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement
2012-04-05 9:55 [0/7] Next round of DT enablement for ux500/Snowball Lee Jones
@ 2012-04-05 9:55 ` Lee Jones
2012-04-10 9:03 ` Linus Walleij
2012-04-05 9:55 ` [PATCH 2/7] ARM: ux500: New DT:ed u8500_init_devices " Lee Jones
` (5 subsequent siblings)
6 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-05 9:55 UTC (permalink / raw)
To: linux-arm-kernel
During Device Tree enablement it is necessary to remove
snowball_<device>* platform_data segments one at at time,
as and when particular devices are DT enabled. This patch
provides a temporary solution. Once this new struct is
empty it will be removed again.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 77d03c1..29e0ade 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -609,6 +609,13 @@ static struct platform_device *snowball_platform_devs[] __initdata = {
&ab8500_device,
};
+static struct platform_device *snowball_of_platform_devs[] __initdata = {
+ &snowball_led_dev,
+ &snowball_key_dev,
+ &snowball_sbnet_dev,
+ &ab8500_device,
+};
+
static void __init mop500_init_machine(void)
{
struct device *parent = NULL;
@@ -786,8 +793,15 @@ static void __init u8500_init_machine(void)
mop500_sdi_init(parent);
} else if (of_machine_is_compatible("calaosystems,snowball-a9500")) {
snowball_pins_init();
- platform_add_devices(snowball_platform_devs,
- ARRAY_SIZE(snowball_platform_devs));
+
+ /* Devices to be DT:ed:
+ snowball_led_dev = todo
+ snowball_key_dev = todo
+ snowball_sbnet_dev = todo
+ ab8500_device = todo
+ */
+ platform_add_devices(snowball_of_platform_devs,
+ ARRAY_SIZE(snowball_of_platform_devs));
snowball_sdi_init(parent);
} else if (of_machine_is_compatible("st-ericsson,hrefv60+")) {
--
1.7.9.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement
2012-04-05 9:55 ` [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement Lee Jones
@ 2012-04-10 9:03 ` Linus Walleij
2012-04-10 9:26 ` Lee Jones
0 siblings, 1 reply; 31+ messages in thread
From: Linus Walleij @ 2012-04-10 9:03 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones <lee.jones@linaro.org> wrote:
> During Device Tree enablement it is necessary to remove
> snowball_<device>* platform_data segments one at at time,
> as and when particular devices are DT enabled. This patch
> provides a temporary solution. Once this new struct is
> empty it will be removed again.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This is not exactly elegant and I cannot quite see how the pieces
fit together.
> ---
> ?arch/arm/mach-ux500/board-mop500.c | ? 18 ++++++++++++++++--
> ?1 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
> index 77d03c1..29e0ade 100644
> --- a/arch/arm/mach-ux500/board-mop500.c
> +++ b/arch/arm/mach-ux500/board-mop500.c
> @@ -609,6 +609,13 @@ static struct platform_device *snowball_platform_devs[] __initdata = {
> ? ? ? ?&ab8500_device,
> ?};
>
> +static struct platform_device *snowball_of_platform_devs[] __initdata = {
> + ? ? ? &snowball_led_dev,
> + ? ? ? &snowball_key_dev,
> + ? ? ? &snowball_sbnet_dev,
> + ? ? ? &ab8500_device,
> +};
So above this array is an identical array which is going to become
unused, then why
not just rename the other array with _of_ or just skip the whole
business altogether?
> +
> ?static void __init mop500_init_machine(void)
> ?{
> ? ? ? ?struct device *parent = NULL;
> @@ -786,8 +793,15 @@ static void __init u8500_init_machine(void)
> ? ? ? ? ? ? ? ?mop500_sdi_init(parent);
> ? ? ? ?} else if (of_machine_is_compatible("calaosystems,snowball-a9500")) {
> ? ? ? ? ? ? ? ?snowball_pins_init();
> - ? ? ? ? ? ? ? platform_add_devices(snowball_platform_devs,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ARRAY_SIZE(snowball_platform_devs));
So first you remove ths use of that array...
> +
> + ? ? ? ? ? ? ? /* Devices to be DT:ed:
> + ? ? ? ? ? ? ? ? ? ?snowball_led_dev ? = todo
> + ? ? ? ? ? ? ? ? ? ?snowball_key_dev ? = todo
> + ? ? ? ? ? ? ? ? ? ?snowball_sbnet_dev = todo
> + ? ? ? ? ? ? ? ? ? ?ab8500_device ? ? ?= todo
> + ? ? ? ? ? ? ? */
/*
* Comment style
*/
> + ? ? ? ? ? ? ? platform_add_devices(snowball_of_platform_devs,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ARRAY_SIZE(snowball_of_platform_devs));
And insert an identical array?
The only change is that you now have an *unused* array with all it's
parents set and then an array with all parents set to NULL which you
use. I don't get it ...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement
2012-04-10 9:03 ` Linus Walleij
@ 2012-04-10 9:26 ` Lee Jones
2012-04-10 11:02 ` Linus Walleij
0 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-10 9:26 UTC (permalink / raw)
To: linux-arm-kernel
On 10/04/12 10:03, Linus Walleij wrote:
> On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones<lee.jones@linaro.org> wrote:
>
>> During Device Tree enablement it is necessary to remove
>> snowball_<device>* platform_data segments one at at time,
>> as and when particular devices are DT enabled. This patch
>> provides a temporary solution. Once this new struct is
>> empty it will be removed again.
>>
>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
>
> This is not exactly elegant and I cannot quite see how the pieces
> fit together.
>
>> ---
>> arch/arm/mach-ux500/board-mop500.c | 18 ++++++++++++++++--
>> 1 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
>> index 77d03c1..29e0ade 100644
>> --- a/arch/arm/mach-ux500/board-mop500.c
>> +++ b/arch/arm/mach-ux500/board-mop500.c
>> @@ -609,6 +609,13 @@ static struct platform_device *snowball_platform_devs[] __initdata = {
>> &ab8500_device,
>> };
>>
>> +static struct platform_device *snowball_of_platform_devs[] __initdata = {
>> +&snowball_led_dev,
>> +&snowball_key_dev,
>> +&snowball_sbnet_dev,
>> +&ab8500_device,
>> +};
>
> So above this array is an identical array which is going to become
> unused, then why
> not just rename the other array with _of_ or just skip the whole
> business altogether?
Eh? No, that won't help. The other array needs to be kept fully intact
for non-DT boots. The idea is that each element from the DT array will
be removed sequentially as they are DT enabled. For instance, I already
have a patch with enables the SMSC911x chip, which also removes the
&snowball_sbnet_dev entry. After that something else will be enabled and
its cohort will be subsequently removed too. Only when all these devices
have been DT enabled can the struct be removed.
>> +
>> static void __init mop500_init_machine(void)
>> {
>> struct device *parent = NULL;
>> @@ -786,8 +793,15 @@ static void __init u8500_init_machine(void)
>> mop500_sdi_init(parent);
>> } else if (of_machine_is_compatible("calaosystems,snowball-a9500")) {
>> snowball_pins_init();
>> - platform_add_devices(snowball_platform_devs,
>> - ARRAY_SIZE(snowball_platform_devs));
>
> So first you remove ths use of that array...
>
>> +
>> + /* Devices to be DT:ed:
>> + snowball_led_dev = todo
>> + snowball_key_dev = todo
>> + snowball_sbnet_dev = todo
>> + ab8500_device = todo
>> + */
>
> /*
> * Comment style
> */
No problem, I'll fix that.
>> + platform_add_devices(snowball_of_platform_devs,
>> + ARRAY_SIZE(snowball_of_platform_devs));
>
> And insert an identical array?
>
> The only change is that you now have an *unused* array with all it's
> parents set and then an array with all parents set to NULL which you
> use. I don't get it ...
Nothing is unused. When DT is disabled snowball_platform_devs will be
used to add the platform devices. This is, and will remain fully
populated for non-DT boots. The DT'ed version will decrease in size
until the final element is removed along with the definition.
I have ran this past Arnd, who thought this was a good idea. It's only a
temporary solution which well aide us in enabling devices spanned over
multiple submissions, rather than attempting to enable everything in a
single patch-set - which isn't going to happen.
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement
2012-04-10 9:26 ` Lee Jones
@ 2012-04-10 11:02 ` Linus Walleij
2012-04-10 11:15 ` Lee Jones
0 siblings, 1 reply; 31+ messages in thread
From: Linus Walleij @ 2012-04-10 11:02 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 10, 2012 at 11:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
> Nothing is unused. When DT is disabled snowball_platform_devs will be used
> to add the platform devices. This is, and will remain fully populated for
> non-DT boots. The DT'ed version will decrease in size until the final
> element is removed along with the definition.
OK then..
> I have ran this past Arnd, who thought this was a good idea. It's only a
> temporary solution which well aide us in enabling devices spanned over
> multiple submissions, rather than attempting to enable everything in a
> single patch-set - which isn't going to happen.
Sure so let's say that I add this patch immediately before the first patch
removing atleast *one* of the entries, because until then it is certainly
not needed.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement
2012-04-10 11:02 ` Linus Walleij
@ 2012-04-10 11:15 ` Lee Jones
0 siblings, 0 replies; 31+ messages in thread
From: Lee Jones @ 2012-04-10 11:15 UTC (permalink / raw)
To: linux-arm-kernel
On 10/04/12 12:02, Linus Walleij wrote:
> On Tue, Apr 10, 2012 at 11:26 AM, Lee Jones<lee.jones@linaro.org> wrote:
>
>> Nothing is unused. When DT is disabled snowball_platform_devs will be used
>> to add the platform devices. This is, and will remain fully populated for
>> non-DT boots. The DT'ed version will decrease in size until the final
>> element is removed along with the definition.
>
> OK then..
>
>> I have ran this past Arnd, who thought this was a good idea. It's only a
>> temporary solution which well aide us in enabling devices spanned over
>> multiple submissions, rather than attempting to enable everything in a
>> single patch-set - which isn't going to happen.
>
> Sure so let's say that I add this patch immediately before the first patch
> removing atleast *one* of the entries, because until then it is certainly
> not needed.
Sounds sensible, thanks.
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 2/7] ARM: ux500: New DT:ed u8500_init_devices for one-by-one device enablement
2012-04-05 9:55 [0/7] Next round of DT enablement for ux500/Snowball Lee Jones
2012-04-05 9:55 ` [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement Lee Jones
@ 2012-04-05 9:55 ` Lee Jones
2012-04-10 9:05 ` Linus Walleij
2012-04-05 9:55 ` [PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings Lee Jones
` (4 subsequent siblings)
6 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-05 9:55 UTC (permalink / raw)
To: linux-arm-kernel
During Device Tree enablement it is necessary to remove
<hw_component>_add_<device> calls one at at time, as and when
particular devices are DT enabled. This patch provides a
temporary solution. Once the new *of_init_devices function
has been fully unpopulated it will be removed again.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500.c | 2 +-
arch/arm/mach-ux500/cpu-db8500.c | 22 ++++++++++++++++++++++
arch/arm/mach-ux500/include/mach/setup.h | 3 +++
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 29e0ade..4d4aeda 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -772,7 +772,7 @@ static void __init u8500_init_machine(void)
int i2c0_devs;
int i;
- parent = u8500_init_devices();
+ parent = u8500_of_init_devices();
i2c0_devs = ARRAY_SIZE(mop500_i2c0_devices);
for (i = 0; i < ARRAY_SIZE(mop500_platform_devs); i++)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 9bd8163..c19c8b8 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -206,3 +206,25 @@ struct device * __init u8500_init_devices(void)
return parent;
}
+
+// TODO: Once all pieces are DT:ed, remove completely
+struct device * __init u8500_of_init_devices(void)
+{
+ struct device *parent;
+ int i;
+
+ parent = db8500_soc_device_init();
+
+ db8500_add_rtc(parent);
+ db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
+
+ platform_device_register_data(parent,
+ "cpufreq-u8500", -1, NULL, 0);
+
+ for (i = 0; i < ARRAY_SIZE(platform_devs); i++)
+ platform_devs[i]->dev.parent = parent;
+
+ platform_add_devices(platform_devs, ARRAY_SIZE(platform_devs));
+
+ return parent;
+}
diff --git a/arch/arm/mach-ux500/include/mach/setup.h b/arch/arm/mach-ux500/include/mach/setup.h
index 3dc00ff..a792c2a 100644
--- a/arch/arm/mach-ux500/include/mach/setup.h
+++ b/arch/arm/mach-ux500/include/mach/setup.h
@@ -21,6 +21,9 @@ extern void __init u8500_map_io(void);
extern struct device * __init u5500_init_devices(void);
extern struct device * __init u8500_init_devices(void);
+// TODO: Once all pieces are DT:ed, remove completely
+extern struct device * __init u8500_of_init_devices(void);
+
extern void __init ux500_init_irq(void);
extern void __init u5500_sdi_init(struct device *parent);
--
1.7.9.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings
2012-04-05 9:55 [0/7] Next round of DT enablement for ux500/Snowball Lee Jones
2012-04-05 9:55 ` [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement Lee Jones
2012-04-05 9:55 ` [PATCH 2/7] ARM: ux500: New DT:ed u8500_init_devices " Lee Jones
@ 2012-04-05 9:55 ` Lee Jones
2012-04-10 9:14 ` Linus Walleij
2012-04-05 9:55 ` [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for " Lee Jones
` (3 subsequent siblings)
6 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-05 9:55 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/db8500.dtsi | 18 +++++++++++++++
arch/arm/boot/dts/snowball.dts | 10 ++++----
arch/arm/mach-ux500/board-mop500.c | 12 ++++++++++
drivers/gpio/gpio-nomadik.c | 41 +++++++++++++++++++++++++++++++++--
4 files changed, 73 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/db8500.dtsi b/arch/arm/boot/dts/db8500.dtsi
index d73dce6..b8591fa 100644
--- a/arch/arm/boot/dts/db8500.dtsi
+++ b/arch/arm/boot/dts/db8500.dtsi
@@ -61,6 +61,8 @@
interrupts = <0 119 0x4>;
supports-sleepmode;
gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank = <0>;
};
gpio1: gpio at 8012e080 {
@@ -70,6 +72,8 @@
interrupts = <0 120 0x4>;
supports-sleepmode;
gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank = <1>;
};
gpio2: gpio at 8000e000 {
@@ -79,6 +83,8 @@
interrupts = <0 121 0x4>;
supports-sleepmode;
gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank = <2>;
};
gpio3: gpio at 8000e080 {
@@ -88,6 +94,8 @@
interrupts = <0 122 0x4>;
supports-sleepmode;
gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank = <3>;
};
gpio4: gpio at 8000e100 {
@@ -97,6 +105,8 @@
interrupts = <0 123 0x4>;
supports-sleepmode;
gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank = <4>;
};
gpio5: gpio at 8000e180 {
@@ -106,6 +116,8 @@
interrupts = <0 124 0x4>;
supports-sleepmode;
gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank = <5>;
};
gpio6: gpio at 8011e000 {
@@ -115,6 +127,8 @@
interrupts = <0 125 0x4>;
supports-sleepmode;
gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank = <6>;
};
gpio7: gpio at 8011e080 {
@@ -124,6 +138,8 @@
interrupts = <0 126 0x4>;
supports-sleepmode;
gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank = <7>;
};
gpio8: gpio at a03fe000 {
@@ -133,6 +149,8 @@
interrupts = <0 127 0x4>;
supports-sleepmode;
gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank = <8>;
};
usb at a03e0000 {
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 359c6d6..738959d 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -30,35 +30,35 @@
wakeup = <1>;
linux,code = <2>;
label = "userpb";
- gpios = <&gpio1 0>;
+ gpios = <&gpio1 0 0>;
};
button at 2 {
debounce_interval = <50>;
wakeup = <1>;
linux,code = <3>;
label = "userpb";
- gpios = <&gpio4 23>;
+ gpios = <&gpio4 23 0>;
};
button at 3 {
debounce_interval = <50>;
wakeup = <1>;
linux,code = <4>;
label = "userpb";
- gpios = <&gpio4 23>;
+ gpios = <&gpio4 24 0>;
};
button at 4 {
debounce_interval = <50>;
wakeup = <1>;
linux,code = <5>;
label = "userpb";
- gpios = <&gpio5 1>;
+ gpios = <&gpio5 1 0>;
};
button at 5 {
debounce_interval = <50>;
wakeup = <1>;
linux,code = <6>;
label = "userpb";
- gpios = <&gpio5 2>;
+ gpios = <&gpio5 2 0>;
};
};
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 4d4aeda..a47d6bd 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -753,10 +753,22 @@ MACHINE_END
#ifdef CONFIG_MACH_UX500_DT
struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
+ /* Requires DMA and call-back bindings. */
OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", &uart0_plat),
OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", &uart1_plat),
OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
+ /* Requires DMA bindings. */
OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
+ /* Requires clock name bindings. */
+ OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
+ OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
+ OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
+ OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e080, "gpio.3", NULL),
+ OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e100, "gpio.4", NULL),
+ OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e180, "gpio.5", NULL),
+ OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e000, "gpio.6", NULL),
+ OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e080, "gpio.7", NULL),
+ OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0xa03fe000, "gpio.8", NULL),
{},
};
diff --git a/drivers/gpio/gpio-nomadik.c b/drivers/gpio/gpio-nomadik.c
index 839624f..750a971 100644
--- a/drivers/gpio/gpio-nomadik.c
+++ b/drivers/gpio/gpio-nomadik.c
@@ -1071,6 +1071,7 @@ void nmk_gpio_read_pull(int gpio_bank, u32 *pull_up)
static int __devinit nmk_gpio_probe(struct platform_device *dev)
{
struct nmk_gpio_platform_data *pdata = dev->dev.platform_data;
+ struct device_node *np = dev->dev.of_node;
struct nmk_gpio_chip *nmk_chip;
struct gpio_chip *chip;
struct resource *res;
@@ -1079,8 +1080,28 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
int irq;
int ret;
- if (!pdata)
+ if (!pdata && !np) {
+ dev_err(&dev->dev, "No platform data or device tree found\n");
return -ENODEV;
+ }
+
+ if (np) {
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ if (of_get_property(np, "supports-sleepmode", NULL))
+ pdata->supports_sleepmode = true;
+
+ if (of_property_read_u32(np, "gpio-bank", &dev->id)) {
+ dev_err(&dev->dev, "gpio-bank property not found\n");
+ ret = -EINVAL;
+ goto out_dt;
+ }
+
+ pdata->first_gpio = dev->id * NMK_GPIO_PER_CHIP;
+ pdata->num_gpio = NMK_GPIO_PER_CHIP;
+ }
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
if (!res) {
@@ -1117,6 +1138,7 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
ret = -ENOMEM;
goto out_clk;
}
+
/*
* The virt address in nmk_chip->addr is in the nomadik register space,
* so we can simply convert the resource address, without remapping
@@ -1139,6 +1161,8 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
chip->dev = &dev->dev;
chip->owner = THIS_MODULE;
+ chip->of_node = np;
+
ret = gpiochip_add(&nmk_chip->chip);
if (ret)
goto out_free;
@@ -1146,12 +1170,13 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
BUG_ON(nmk_chip->bank >= ARRAY_SIZE(nmk_gpio_chips));
nmk_gpio_chips[nmk_chip->bank] = nmk_chip;
+
platform_set_drvdata(dev, nmk_chip);
nmk_gpio_init_irq(nmk_chip);
- dev_info(&dev->dev, "at address %p\n",
- nmk_chip->addr);
+ dev_info(&dev->dev, "at address %p\n", nmk_chip->addr);
+
return 0;
out_free:
@@ -1164,13 +1189,23 @@ out_release:
out:
dev_err(&dev->dev, "Failure %i for GPIO %i-%i\n", ret,
pdata->first_gpio, pdata->first_gpio+31);
+out_dt:
+ if (np)
+ kfree(pdata);
+
return ret;
}
+static const struct of_device_id nmk_gpio_match[] = {
+ { .compatible = "stmicroelectronics,nomadik-gpio", },
+ {}
+};
+
static struct platform_driver nmk_gpio_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "gpio",
+ .of_match_table = nmk_gpio_match,
},
.probe = nmk_gpio_probe,
};
--
1.7.9.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings
2012-04-05 9:55 ` [PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings Lee Jones
@ 2012-04-10 9:14 ` Linus Walleij
2012-04-10 9:19 ` Linus Walleij
0 siblings, 1 reply; 31+ messages in thread
From: Linus Walleij @ 2012-04-10 9:14 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones <lee.jones@linaro.org> wrote:
> + ? ? ? /* Requires clock name bindings. */
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e080, "gpio.3", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e100, "gpio.4", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e180, "gpio.5", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e000, "gpio.6", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e080, "gpio.7", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0xa03fe000, "gpio.8", NULL),
Needs updating to use the st,foo prefix I guess.
Please use the defined block offset addresses from <mach/db8500-regs.h>
U8500_GPIO0_BASE etc. instead of hardcoded values.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings
2012-04-10 9:14 ` Linus Walleij
@ 2012-04-10 9:19 ` Linus Walleij
0 siblings, 0 replies; 31+ messages in thread
From: Linus Walleij @ 2012-04-10 9:19 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 10, 2012 at 11:14 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
>> + ? ? ? /* Requires clock name bindings. */
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e080, "gpio.3", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e100, "gpio.4", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e180, "gpio.5", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e000, "gpio.6", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e080, "gpio.7", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0xa03fe000, "gpio.8", NULL),
>
> Needs updating to use the st,foo prefix I guess.
>
> Please use the defined block offset addresses from <mach/db8500-regs.h>
> U8500_GPIO0_BASE etc. instead of hardcoded values.
On second thought ignore that last thing. We already have the explicit
address in
other auxdata and the goal is to get rid of the register file anyway.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings
2012-04-05 9:55 [0/7] Next round of DT enablement for ux500/Snowball Lee Jones
` (2 preceding siblings ...)
2012-04-05 9:55 ` [PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings Lee Jones
@ 2012-04-05 9:55 ` Lee Jones
2012-04-06 4:20 ` Grant Likely
2012-04-05 9:55 ` [PATCH 5/7] ARM: ux500: Rename gpio_keys in the Device Tree file Lee Jones
` (2 subsequent siblings)
6 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-05 9:55 UTC (permalink / raw)
To: linux-arm-kernel
Add required documentation for specific gpio-nomadik DT bindings.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
.../devicetree/bindings/gpio/gpio-nmk.txt | 29 ++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-nmk.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
new file mode 100644
index 0000000..1555029
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
@@ -0,0 +1,29 @@
+Nomadik GPIO controller
+
+Required properties:
+- compatible : Should be "stmicroelectronics,nomadik-gpio".
+- reg : Physical base address and length of the controller's registers.
+- interrupts : The interrupt outputs from the controller.
+- #gpio-cells : Should be two:
+ The first cell is the pin number.
+ The second cell is used to specify optional parameters:
+ - bits[3:0] trigger type and level flags:
+ 1 = low-to-high edge triggered.
+ 2 = high-to-low edge triggered.
+ 4 = active high level-sensitive.
+ 8 = active low level-sensitive.
+- gpio-controller : Marks the device node as a GPIO controller.
+- supports-sleepmode : Specifies whether controller can sleep or not
+- gpio-bank : Specifies which bank a controller owns.
+
+Example:
+
+ gpio1: gpio at 8012e080 {
+ compatible = "stmicroelectronics,nomadik-gpio";
+ reg = <0x8012e080 0x80>;
+ interrupts = <0 120 0x4>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ supports-sleepmode;
+ gpio-bank = <1>;
+ };
--
1.7.9.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings
2012-04-05 9:55 ` [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for " Lee Jones
@ 2012-04-06 4:20 ` Grant Likely
2012-04-10 7:24 ` Lee Jones
0 siblings, 1 reply; 31+ messages in thread
From: Grant Likely @ 2012-04-06 4:20 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 5 Apr 2012 10:55:45 +0100, Lee Jones <lee.jones@linaro.org> wrote:
> Add required documentation for specific gpio-nomadik DT bindings.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/gpio/gpio-nmk.txt | 29 ++++++++++++++++++++
> 1 files changed, 29 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-nmk.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> new file mode 100644
> index 0000000..1555029
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> @@ -0,0 +1,29 @@
> +Nomadik GPIO controller
> +
> +Required properties:
> +- compatible : Should be "stmicroelectronics,nomadik-gpio".
"stmicroelectronics," is a really long prefix. You can use simply
"st," here since it has already been defined and documented in
Documentation/devicetree/bindings/vendor-prefixes.txt
> +- reg : Physical base address and length of the controller's registers.
> +- interrupts : The interrupt outputs from the controller.
> +- #gpio-cells : Should be two:
> + The first cell is the pin number.
> + The second cell is used to specify optional parameters:
> + - bits[3:0] trigger type and level flags:
> + 1 = low-to-high edge triggered.
> + 2 = high-to-low edge triggered.
> + 4 = active high level-sensitive.
> + 8 = active low level-sensitive.
Those look like interrupt flags, not gpio flags. If the gpio lines
can be used as generic irq input lines, then this node should also
declare itself as an interrupt controller.
> +- gpio-controller : Marks the device node as a GPIO controller.
> +- supports-sleepmode : Specifies whether controller can sleep or not
Typically, custom properites that are for a specific device should be
prefixed with the manufacturer name. So, something like:
"st,has-sleepmode".
> +- gpio-bank : Specifies which bank a controller owns.
What is this for (how is it used)? It shouldn't be needed to specify
a bank number.
> +
> +Example:
> +
> + gpio1: gpio at 8012e080 {
> + compatible = "stmicroelectronics,nomadik-gpio";
> + reg = <0x8012e080 0x80>;
> + interrupts = <0 120 0x4>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + supports-sleepmode;
> + gpio-bank = <1>;
> + };
> --
> 1.7.9.1
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings
2012-04-06 4:20 ` Grant Likely
@ 2012-04-10 7:24 ` Lee Jones
2012-05-11 19:12 ` Grant Likely
0 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-10 7:24 UTC (permalink / raw)
To: linux-arm-kernel
On 06/04/12 05:20, Grant Likely wrote:
> On Thu, 5 Apr 2012 10:55:45 +0100, Lee Jones<lee.jones@linaro.org> wrote:
>> Add required documentation for specific gpio-nomadik DT bindings.
>>
>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
>> ---
>> .../devicetree/bindings/gpio/gpio-nmk.txt | 29 ++++++++++++++++++++
>> 1 files changed, 29 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-nmk.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
>> new file mode 100644
>> index 0000000..1555029
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
>> @@ -0,0 +1,29 @@
>> +Nomadik GPIO controller
>> +
>> +Required properties:
>> +- compatible : Should be "stmicroelectronics,nomadik-gpio".
>
> "stmicroelectronics," is a really long prefix. You can use simply
> "st," here since it has already been defined and documented in
> Documentation/devicetree/bindings/vendor-prefixes.txt
Absolutely.
>> +- reg : Physical base address and length of the controller's registers.
>> +- interrupts : The interrupt outputs from the controller.
>> +- #gpio-cells : Should be two:
>> + The first cell is the pin number.
>> + The second cell is used to specify optional parameters:
>> + - bits[3:0] trigger type and level flags:
>> + 1 = low-to-high edge triggered.
>> + 2 = high-to-low edge triggered.
>> + 4 = active high level-sensitive.
>> + 8 = active low level-sensitive.
>
> Those look like interrupt flags, not gpio flags. If the gpio lines
> can be used as generic irq input lines, then this node should also
> declare itself as an interrupt controller.
They can and it will do in an up-coming patch.
>> +- gpio-controller : Marks the device node as a GPIO controller.
>> +- supports-sleepmode : Specifies whether controller can sleep or not
>
> Typically, custom properites that are for a specific device should be
> prefixed with the manufacturer name. So, something like:
> "st,has-sleepmode".
No problem.
>> +- gpio-bank : Specifies which bank a controller owns.
>
> What is this for (how is it used)? It shouldn't be needed to specify
> a bank number.
Briefly, it is used like this:
of_property_read_u32(np, "gpio-bank", &bank);
chip->base = bank * NMK_GPIO_PER_CHIP;
nmk_chip->bank = bank;
Is that wrong? If so, is there a better way to do it?
Thanks Grant.
Kind regards,
Lee
>> +
>> +Example:
>> +
>> + gpio1: gpio at 8012e080 {
>> + compatible = "stmicroelectronics,nomadik-gpio";
>> + reg =<0x8012e080 0x80>;
>> + interrupts =<0 120 0x4>;
>> + #gpio-cells =<2>;
>> + gpio-controller;
>> + supports-sleepmode;
>> + gpio-bank =<1>;
>> + };
>> --
>> 1.7.9.1
>>
>
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings
2012-04-10 7:24 ` Lee Jones
@ 2012-05-11 19:12 ` Grant Likely
2012-05-11 22:18 ` Linus Walleij
0 siblings, 1 reply; 31+ messages in thread
From: Grant Likely @ 2012-05-11 19:12 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 10 Apr 2012 08:24:49 +0100, Lee Jones <lee.jones@linaro.org> wrote:
> On 06/04/12 05:20, Grant Likely wrote:
> > On Thu, 5 Apr 2012 10:55:45 +0100, Lee Jones<lee.jones@linaro.org> wrote:
> >> Add required documentation for specific gpio-nomadik DT bindings.
> >>
> >> Signed-off-by: Lee Jones<lee.jones@linaro.org>
> >> ---
> >> .../devicetree/bindings/gpio/gpio-nmk.txt | 29 ++++++++++++++++++++
> >> 1 files changed, 29 insertions(+), 0 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> >> new file mode 100644
> >> index 0000000..1555029
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> >> @@ -0,0 +1,29 @@
> >> +Nomadik GPIO controller
> >> +
> >> +Required properties:
> >> +- compatible : Should be "stmicroelectronics,nomadik-gpio".
> >
> > "stmicroelectronics," is a really long prefix. You can use simply
> > "st," here since it has already been defined and documented in
> > Documentation/devicetree/bindings/vendor-prefixes.txt
>
> Absolutely.
>
> >> +- reg : Physical base address and length of the controller's registers.
> >> +- interrupts : The interrupt outputs from the controller.
> >> +- #gpio-cells : Should be two:
> >> + The first cell is the pin number.
> >> + The second cell is used to specify optional parameters:
> >> + - bits[3:0] trigger type and level flags:
> >> + 1 = low-to-high edge triggered.
> >> + 2 = high-to-low edge triggered.
> >> + 4 = active high level-sensitive.
> >> + 8 = active low level-sensitive.
> >
> > Those look like interrupt flags, not gpio flags. If the gpio lines
> > can be used as generic irq input lines, then this node should also
> > declare itself as an interrupt controller.
>
> They can and it will do in an up-coming patch.
>
> >> +- gpio-controller : Marks the device node as a GPIO controller.
> >> +- supports-sleepmode : Specifies whether controller can sleep or not
> >
> > Typically, custom properites that are for a specific device should be
> > prefixed with the manufacturer name. So, something like:
> > "st,has-sleepmode".
>
> No problem.
>
> >> +- gpio-bank : Specifies which bank a controller owns.
> >
> > What is this for (how is it used)? It shouldn't be needed to specify
> > a bank number.
>
> Briefly, it is used like this:
>
> of_property_read_u32(np, "gpio-bank", &bank);
> chip->base = bank * NMK_GPIO_PER_CHIP;
> nmk_chip->bank = bank;
>
> Is that wrong? If so, is there a better way to do it?
(sorry for the late reply on this, I've been tied up with other stuff.
I know you've posted updated patches, but I haven't looked at them
yet. This answer may be obsolete by now, but I'm sending it anyway
for background).
It's not strictly wrong, but it looks a lot like the "cell-index"
pattern which is appropriate sometimes, but always comes under
scrutiny first. It makes me wonder what the driver needs it for. ie.
Are the banks all part of a single GPIO device? If they are really
independent, the the bank number should be irrelevant because the base
address identifies how to control the device. Or, is there a shared
resource that needs the bank number to access correctly?
If they a single device then a better binding might be a single node
with #gpio-cells = <3> with the first cell specifying a bank and the
second specifying the gpio number. Or if the GPIOs appear in a flat
number space, then you could use the exact same numbering as found in
the user-manual for the chip.
g.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings
2012-05-11 19:12 ` Grant Likely
@ 2012-05-11 22:18 ` Linus Walleij
2012-05-11 22:24 ` Grant Likely
0 siblings, 1 reply; 31+ messages in thread
From: Linus Walleij @ 2012-05-11 22:18 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 11, 2012 at 9:12 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Are the banks all part of a single GPIO device?
No. The banks are individual pieces of silicon instance, so they
each have separate reset and clock lines for example.
Apart from that I just vaguely grasp what you're discussing here :-)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings
2012-05-11 22:18 ` Linus Walleij
@ 2012-05-11 22:24 ` Grant Likely
2012-05-14 8:33 ` Lee Jones
0 siblings, 1 reply; 31+ messages in thread
From: Grant Likely @ 2012-05-11 22:24 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 11, 2012 at 4:18 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, May 11, 2012 at 9:12 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> Are the banks all part of a single GPIO device?
>
> No. The banks are individual pieces of silicon instance, so they
> each have separate reset and clock lines for example.
>
> Apart from that I just vaguely grasp what you're discussing here :-)
Don't worry about it. After reading further, it looks okay.
g.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings
2012-05-11 22:24 ` Grant Likely
@ 2012-05-14 8:33 ` Lee Jones
0 siblings, 0 replies; 31+ messages in thread
From: Lee Jones @ 2012-05-14 8:33 UTC (permalink / raw)
To: linux-arm-kernel
On 11/05/12 23:24, Grant Likely wrote:
> On Fri, May 11, 2012 at 4:18 PM, Linus Walleij<linus.walleij@linaro.org> wrote:
>> On Fri, May 11, 2012 at 9:12 PM, Grant Likely<grant.likely@secretlab.ca> wrote:
>>
>>> Are the banks all part of a single GPIO device?
>>
>> No. The banks are individual pieces of silicon instance, so they
>> each have separate reset and clock lines for example.
>>
>> Apart from that I just vaguely grasp what you're discussing here :-)
>
> Don't worry about it. After reading further, it looks okay.
Great. Thanks for checking Grant.
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 5/7] ARM: ux500: Rename gpio_keys in the Device Tree file
2012-04-05 9:55 [0/7] Next round of DT enablement for ux500/Snowball Lee Jones
` (3 preceding siblings ...)
2012-04-05 9:55 ` [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for " Lee Jones
@ 2012-04-05 9:55 ` Lee Jones
2012-04-10 9:16 ` Linus Walleij
2012-04-05 9:55 ` [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants Lee Jones
2012-04-05 9:55 ` [PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings Lee Jones
6 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-05 9:55 UTC (permalink / raw)
To: linux-arm-kernel
Ensure each button is individually identifiable by using
their correct unique given device names.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/snowball.dts | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 738959d..0cec47b 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -36,28 +36,28 @@
debounce_interval = <50>;
wakeup = <1>;
linux,code = <3>;
- label = "userpb";
+ label = "extkb1";
gpios = <&gpio4 23 0>;
};
button at 3 {
debounce_interval = <50>;
wakeup = <1>;
linux,code = <4>;
- label = "userpb";
+ label = "extkb2";
gpios = <&gpio4 24 0>;
};
button at 4 {
debounce_interval = <50>;
wakeup = <1>;
linux,code = <5>;
- label = "userpb";
+ label = "extkb3";
gpios = <&gpio5 1 0>;
};
button at 5 {
debounce_interval = <50>;
wakeup = <1>;
linux,code = <6>;
- label = "userpb";
+ label = "extkb4";
gpios = <&gpio5 2 0>;
};
};
--
1.7.9.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants
2012-04-05 9:55 [0/7] Next round of DT enablement for ux500/Snowball Lee Jones
` (4 preceding siblings ...)
2012-04-05 9:55 ` [PATCH 5/7] ARM: ux500: Rename gpio_keys in the Device Tree file Lee Jones
@ 2012-04-05 9:55 ` Lee Jones
2012-04-05 12:36 ` Russell King - ARM Linux
2012-04-05 9:55 ` [PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings Lee Jones
6 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-05 9:55 UTC (permalink / raw)
To: linux-arm-kernel
Provide a means to collect attributes specific to ST-Ericsson's
ux500 variant series. This patch registers itself as the AMBA
driver to be called during the probe process. Once all
attributes and ux500 specifics are are collected the normal
mmci core probe is called.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/snowball.dts | 21 ++++++++++--
arch/arm/mach-ux500/board-mop500-sdi.c | 4 +-
arch/arm/mach-ux500/board-mop500.c | 3 +-
arch/arm/mach-ux500/board-mop500.h | 4 ++
drivers/mmc/host/mmci.c | 58 +++++++++++++++++++++++++++++--
5 files changed, 80 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 0cec47b..8e2a609 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -87,13 +87,28 @@
};
};
+ // External Micro SD slot
sdi at 80126000 {
- status = "enabled";
- cd-gpios = <&gpio6 26>;
+ arm,primecell-periphid = <0x10480180>;
+ clock-frequency = <50000000>;
+ bus-width = <8>;
+ mmc-cap-mmc-highspeed;
+
+ #gpio-cells = <1>;
+ cd-gpios = <&gpio6 26>; // 218
+ cd-inverted;
+
+ status = "okay";
};
+ // On-board eMMC
sdi at 80114000 {
- status = "enabled";
+ arm,primecell-periphid = <0x10480180>;
+ clock-frequency = <50000000>;
+ bus-width = <8>;
+ mmc-cap-mmc-highspeed;
+
+ status = "okay";
};
uart at 80120000 {
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 920251c..18ff781 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -80,7 +80,7 @@ static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
};
#endif
-static struct mmci_platform_data mop500_sdi0_data = {
+struct mmci_platform_data mop500_sdi0_data = {
.ios_handler = mop500_sdi0_ios_handler,
.ocr_mask = MMC_VDD_29_30,
.f_max = 50000000,
@@ -227,7 +227,7 @@ static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
};
#endif
-static struct mmci_platform_data mop500_sdi4_data = {
+struct mmci_platform_data mop500_sdi4_data = {
.ocr_mask = MMC_VDD_29_30,
.f_max = 50000000,
.capabilities = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA |
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index a47d6bd..d2c3a5c 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -759,6 +759,8 @@ struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
/* Requires DMA bindings. */
OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", &mop500_sdi0_data),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4", &mop500_sdi4_data),
/* Requires clock name bindings. */
OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
@@ -815,7 +817,6 @@ static void __init u8500_init_machine(void)
platform_add_devices(snowball_of_platform_devs,
ARRAY_SIZE(snowball_of_platform_devs));
- snowball_sdi_init(parent);
} else if (of_machine_is_compatible("st-ericsson,hrefv60+")) {
/*
* The HREFv60 board removed a GPIO expander and routed
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index fdcfa87..384baf7 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -7,6 +7,8 @@
#ifndef __BOARD_MOP500_H
#define __BOARD_MOP500_H
+#include <linux/amba/mmci.h>
+
/* Snowball specific GPIO assignments, this board has no GPIO expander */
#define SNOWBALL_ACCEL_INT1_GPIO 163
#define SNOWBALL_ACCEL_INT2_GPIO 164
@@ -74,6 +76,8 @@
#define SNOWBALL_EN_3V3_ETH_GPIO MOP500_AB8500_PIN_GPIO(26) /* GPIO26 */
struct i2c_board_info;
+extern struct mmci_platform_data mop500_sdi0_data;
+extern struct mmci_platform_data mop500_sdi4_data;
extern void mop500_sdi_init(struct device *parent);
extern void snowball_sdi_init(struct device *parent);
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 032b847..8538d55 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -15,6 +15,7 @@
#include <linux/device.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/highmem.h>
@@ -1196,21 +1197,70 @@ static const struct mmc_host_ops mmci_ops = {
.get_cd = mmci_get_cd,
};
+#ifdef CONFIG_OF
+static void mmci_dt_populate_generic_pdata(struct device_node *np,
+ struct mmci_platform_data *pdata)
+{
+ int bus_width = 0;
+
+ of_property_read_u32(np, "wp-gpios", &pdata->gpio_wp);
+ if (!pdata->gpio_wp)
+ pdata->gpio_wp = -1;
+
+ of_property_read_u32(np, "cd-gpios", &pdata->gpio_cd);
+ if (!pdata->gpio_cd)
+ pdata->gpio_cd = -1;
+
+ if (of_get_property(np, "cd-inverted", NULL))
+ pdata->cd_invert = true;
+ else
+ pdata->cd_invert = false;
+
+ of_property_read_u32(np, "clock-frequency", &pdata->f_max);
+ if (!pdata->f_max)
+ pr_warn("%s has no 'clock-frequency' property\n", np->full_name);
+
+ if (of_get_property(np, "mmc-cap-mmc-highspeed", NULL))
+ pdata->capabilities |= MMC_CAP_MMC_HIGHSPEED;
+ if (of_get_property(np, "mmc-cap-sd-highspeed", NULL))
+ pdata->capabilities |= MMC_CAP_SD_HIGHSPEED;
+
+ of_property_read_u32(np, "bus-width", &bus_width);
+ switch (bus_width) {
+ case 0 :
+ /* No bus-width supplied. */
+ break;
+ case 4 :
+ pdata->capabilities |= MMC_CAP_4_BIT_DATA;
+ break;
+ case 8 :
+ pdata->capabilities |= MMC_CAP_8_BIT_DATA;
+ break;
+ default :
+ pr_warn("%s: Unsupported bus width\n", np->full_name);
+ }
+}
+#endif
+
static int __devinit mmci_probe(struct amba_device *dev,
const struct amba_id *id)
{
struct mmci_platform_data *plat = dev->dev.platform_data;
+ struct device_node *np = dev->dev.of_node;
struct variant_data *variant = id->data;
struct mmci_host *host;
struct mmc_host *mmc;
int ret;
- /* must have platform data */
- if (!plat) {
- ret = -EINVAL;
- goto out;
+ /* Must have platform data or Device Tree. */
+ if (!plat && !np) {
+ dev_err(&dev->dev, "No plat data or DT found\n");
+ return -EINVAL;
}
+ if (np)
+ mmci_dt_populate_generic_pdata(np, plat);
+
ret = amba_request_regions(dev, DRIVER_NAME);
if (ret)
goto out;
--
1.7.9.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants
2012-04-05 9:55 ` [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants Lee Jones
@ 2012-04-05 12:36 ` Russell King - ARM Linux
2012-04-05 13:45 ` Lee Jones
0 siblings, 1 reply; 31+ messages in thread
From: Russell King - ARM Linux @ 2012-04-05 12:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 05, 2012 at 10:55:47AM +0100, Lee Jones wrote:
> + of_property_read_u32(np, "clock-frequency", &pdata->f_max);
> + if (!pdata->f_max)
> + pr_warn("%s has no 'clock-frequency' property\n", np->full_name);
To be anal about this (which is what we should be about DT bindings)
this is not a 'clock frequency' but a maximum clock frequency for the
bus. Or to put it another way, a clock frequency limit.
A 'clock-frequency' property suggests (at least to me) that it's
specifying the rate of the MCLK signal, which is not what it's doing.
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants
2012-04-05 12:36 ` Russell King - ARM Linux
@ 2012-04-05 13:45 ` Lee Jones
2012-04-06 4:14 ` Grant Likely
0 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-05 13:45 UTC (permalink / raw)
To: linux-arm-kernel
On 05/04/12 13:36, Russell King - ARM Linux wrote:
> On Thu, Apr 05, 2012 at 10:55:47AM +0100, Lee Jones wrote:
>> + of_property_read_u32(np, "clock-frequency",&pdata->f_max);
>> + if (!pdata->f_max)
>> + pr_warn("%s has no 'clock-frequency' property\n", np->full_name);
>
> To be anal about this (which is what we should be about DT bindings)
> this is not a 'clock frequency' but a maximum clock frequency for the
> bus. Or to put it another way, a clock frequency limit.
>
> A 'clock-frequency' property suggests (at least to me) that it's
> specifying the rate of the MCLK signal, which is not what it's doing.
Sounds sensible.
I initially had it as 'f-max', but was told to change it to
'clock-frequency'. I'm happy to take other suggestions however.
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants
2012-04-05 13:45 ` Lee Jones
@ 2012-04-06 4:14 ` Grant Likely
2012-04-09 14:27 ` Arnd Bergmann
0 siblings, 1 reply; 31+ messages in thread
From: Grant Likely @ 2012-04-06 4:14 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 05 Apr 2012 14:45:02 +0100, Lee Jones <lee.jones@linaro.org> wrote:
> On 05/04/12 13:36, Russell King - ARM Linux wrote:
> > On Thu, Apr 05, 2012 at 10:55:47AM +0100, Lee Jones wrote:
> >> + of_property_read_u32(np, "clock-frequency",&pdata->f_max);
> >> + if (!pdata->f_max)
> >> + pr_warn("%s has no 'clock-frequency' property\n", np->full_name);
> >
> > To be anal about this (which is what we should be about DT bindings)
> > this is not a 'clock frequency' but a maximum clock frequency for the
> > bus. Or to put it another way, a clock frequency limit.
> >
> > A 'clock-frequency' property suggests (at least to me) that it's
> > specifying the rate of the MCLK signal, which is not what it's doing.
>
> Sounds sensible.
>
> I initially had it as 'f-max', but was told to change it to
> 'clock-frequency'. I'm happy to take other suggestions however.
Yes, "clock-frequency" already has established usage as an exact clock
specification. If it is a maximum as you say then something like
"max-frequency" makes more sense.
Someone was working on a common MMC DT binding. Really all of the MMC
drivers should use the same binding for the common bits.
g.
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants
2012-04-06 4:14 ` Grant Likely
@ 2012-04-09 14:27 ` Arnd Bergmann
2012-04-09 14:41 ` Chris Ball
0 siblings, 1 reply; 31+ messages in thread
From: Arnd Bergmann @ 2012-04-09 14:27 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 06 April 2012, Grant Likely wrote:
> Yes, "clock-frequency" already has established usage as an exact clock
> specification. If it is a maximum as you say then something like
> "max-frequency" makes more sense.
>
> Someone was working on a common MMC DT binding. Really all of the MMC
> drivers should use the same binding for the common bits.
Agreed.
Should we use max-frequency or clock-frequency for sdhci though? It looks
like this is both the maximum frequency that it can use and the base frequency
that the actual clock rate is derived from (can be a fraction).
Arnd
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants
2012-04-09 14:27 ` Arnd Bergmann
@ 2012-04-09 14:41 ` Chris Ball
0 siblings, 0 replies; 31+ messages in thread
From: Chris Ball @ 2012-04-09 14:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Mon, Apr 09 2012, Arnd Bergmann wrote:
> Agreed.
>
> Should we use max-frequency or clock-frequency for sdhci though? It looks
> like this is both the maximum frequency that it can use and the base frequency
> that the actual clock rate is derived from (can be a fraction).
This is ultimately setting the "f_max" ("maximum operating frequency")
field in the MMC core, so I'm happy naming the property "max-frequency".
It's true that this doesn't explain the derivation to clock rate --
but we weren't doing that before the DT binding either, and I think that
having a discrepancy between the DT property and the core's naming would
lead to confusion/mistakes.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings
2012-04-05 9:55 [0/7] Next round of DT enablement for ux500/Snowball Lee Jones
` (5 preceding siblings ...)
2012-04-05 9:55 ` [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants Lee Jones
@ 2012-04-05 9:55 ` Lee Jones
2012-04-18 13:04 ` Arnd Bergmann
6 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-05 9:55 UTC (permalink / raw)
To: linux-arm-kernel
This provides full documentation detailing each compulsory,
optional and device (variant) specific properties available
for use within the MMCI Device Tree.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
Documentation/devicetree/bindings/mmc/mmci.txt | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmci.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
new file mode 100644
index 0000000..16502a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmci.txt
@@ -0,0 +1,19 @@
+* ARM PrimeCell MultiMedia Card Interface (MMCI) PL180/1
+
+The ARM PrimeCell MMCI PL180 and PL181 provides and interface for
+reading and writing to MultiMedia and SD cards alike.
+
+Required properties:
+- compatible : contains "arm,pl18x", "arm,primecell".
+- reg : contains pl18x registers and length.
+- interrupts : contains the device IRQ(s).
+- arm,primecell-periphid : contains the PrimeCell Peripheral ID.
+
+Optional properties:
+- wp-gpios : contains any write protect (ro) gpios
+- cd-gpios : contains any card detection gpios
+- cd-inverted : indicates whether the cd gpio is inverted
+- clock-frequency : contains the maximum operating frequency
+- bus-width : Number of data lines, can be <1>, <4>, or <8>
+- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable
+- mmc-cap-sd-highspeed : indicates whether SD is high speed capable
--
1.7.9.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings
2012-04-05 9:55 ` [PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings Lee Jones
@ 2012-04-18 13:04 ` Arnd Bergmann
2012-04-18 14:25 ` Pawel Moll
0 siblings, 1 reply; 31+ messages in thread
From: Arnd Bergmann @ 2012-04-18 13:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 05 April 2012, Lee Jones wrote:
> This provides full documentation detailing each compulsory,
> optional and device (variant) specific properties available
> for use within the MMCI Device Tree.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings
2012-04-18 13:04 ` Arnd Bergmann
@ 2012-04-18 14:25 ` Pawel Moll
2012-04-18 14:29 ` Lee Jones
0 siblings, 1 reply; 31+ messages in thread
From: Pawel Moll @ 2012-04-18 14:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
On Wed, 2012-04-18 at 13:04 +0000, Arnd Bergmann wrote:
> On Thursday 05 April 2012, Lee Jones wrote:
> > This provides full documentation detailing each compulsory,
> > optional and device (variant) specific properties available
> > for use within the MMCI Device Tree.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Did you really mean to ack this version or the newer one, with
"max-frequency" instead of "clock-frequency"?
Pawe?
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings
2012-04-18 14:25 ` Pawel Moll
@ 2012-04-18 14:29 ` Lee Jones
2012-04-18 16:32 ` Arnd Bergmann
0 siblings, 1 reply; 31+ messages in thread
From: Lee Jones @ 2012-04-18 14:29 UTC (permalink / raw)
To: linux-arm-kernel
On 18/04/12 15:25, Pawel Moll wrote:
> Hi Arnd,
>
> On Wed, 2012-04-18 at 13:04 +0000, Arnd Bergmann wrote:
>> On Thursday 05 April 2012, Lee Jones wrote:
>>> This provides full documentation detailing each compulsory,
>>> optional and device (variant) specific properties available
>>> for use within the MMCI Device Tree.
>>>
>>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
>>
>> Acked-by: Arnd Bergmann<arnd@arndb.de>
>
> Did you really mean to ack this version or the newer one, with
> "max-frequency" instead of "clock-frequency"?
He meant the newer one. :)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings
2012-04-18 14:29 ` Lee Jones
@ 2012-04-18 16:32 ` Arnd Bergmann
0 siblings, 0 replies; 31+ messages in thread
From: Arnd Bergmann @ 2012-04-18 16:32 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 18 April 2012, Lee Jones wrote:
> On 18/04/12 15:25, Pawel Moll wrote:
> > Hi Arnd,
> >
> > On Wed, 2012-04-18 at 13:04 +0000, Arnd Bergmann wrote:
> >> On Thursday 05 April 2012, Lee Jones wrote:
> >>> This provides full documentation detailing each compulsory,
> >>> optional and device (variant) specific properties available
> >>> for use within the MMCI Device Tree.
> >>>
> >>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
> >>
> >> Acked-by: Arnd Bergmann<arnd@arndb.de>
> >
> > Did you really mean to ack this version or the newer one, with
> > "max-frequency" instead of "clock-frequency"?
>
> He meant the newer one. :)
>
Yes, of course. Sorry for the confusion.
Arnd
^ permalink raw reply [flat|nested] 31+ messages in thread