OMAP serial device tree support
Subsystems (5)
cover OMAP serial device tree support
This series adds minimal device tree support for OMAP-serial driver, and is based on top of the latest runtime-PM changes from Govind[1] posted here[2].
The series passes minimal data that allows serial console boot, with UART's initialised from device tree. However some of low power support for UART and remote wakeup needs more work.
Boot tested on OMAP4 panda and OMAP4 sdp boards.
[1] git://gitorious.org/runtime_3-0/runtime_3-0.git 3.2-rc1_uart_runtime
[2] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg58486.html
Rajendra Nayak (3):
ARM: omap_device: handle first time activation of console device
omap-serial: Add minimal device tree support
ARM: omap: pass minimal SoC/board data for UART from dt
.../devicetree/bindings/arm/omap/omap.txt | 1 + .../devicetree/bindings/serial/omap_serial.txt | 8 ++++ arch/arm/boot/dts/omap3-beagle.dts | 17 +++++++++ arch/arm/boot/dts/omap3.dtsi | 27 ++++++++++++++ arch/arm/boot/dts/omap4-panda.dts | 17 +++++++++ arch/arm/boot/dts/omap4-sdp.dts | 17 +++++++++ arch/arm/boot/dts/omap4.dtsi | 24 +++++++++++++ arch/arm/mach-omap2/board-generic.c | 1 - arch/arm/plat-omap/omap_device.c | 33 +++++++++++++++++- drivers/tty/serial/omap-serial.c | 37 +++++++++++++++++++- 10 files changed, 179 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
PATCH 1/3 ARM: omap_device: handle first time activation of console device
console device on OMAP is never reset or idled by hwmod post initial setup, early during boot, for obvious reasons not to break early debug prints thrown on console.
This leaves the console device enabled at boot and the first activation of it using hwmod needs to be handled in such a way that a disable is called followed by an enable of the hwmod, the subsequent activations can then use the default activation technique.
To handle this add a new binding to identify a hwmod which is used as the console device.
This patch is based on the what is done in serial.c for non-DT builds.
--- .../devicetree/bindings/arm/omap/omap.txt | 1 + arch/arm/plat-omap/omap_device.c | 33 +++++++++++++++++++- 2 files changed, 33 insertions(+), 1 deletions(-)
Documentation/devicetree/bindings/arm/omap/omap.txt +1 -0
@@ -21,6 +21,7 @@ Required properties: Optional properties: - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module during suspend. +- ti,console_hwmod: boolean, identifies the hwmod used as console device Example:
arch/arm/plat-omap/omap_device.c +32 -1
@@ -88,6 +88,7 @@#include <linux/pm_runtime.h> #include <linux/of.h> #include <linux/notifier.h> +#include <linux/console.h> #include <plat/omap_device.h> #include <plat/omap_hwmod.h>
@@ -114,6 +115,32 @@ static struct omap_device_pm_latency omap_default_latency[] = { } }; +static int omap_console_hwmod_enable (struct omap_device *od) +{ +console_lock (); +/* +* For early console we prevented hwmod reset and idle +* So before we enable the uart clocks idle the console +* uart clocks, then enable back the console uart hwmod. +*/ +omap_hwmod_idle (od->hwmods[0 ]); +omap_hwmod_enable (od->hwmods[0 ]); +console_unlock (); +/* +* Restore the default activate/deactivate funcs, +* since now we have set the hwmod state machine right +* with the idle/enable for console uart +*/ + od->pm_lats = omap_default_latency; +return 0 ; +} + +static struct omap_device_pm_latency omap_console_latency[] = { + { + .activate_func = omap_console_hwmod_enable, + }, +}; +/* Private functions */ /**
@@ -342,6 +369,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)struct omap_hwmod **hwmods;struct omap_device *od;struct omap_hwmod *oh; +struct omap_device_pm_latency *pm_lat =NULL ;struct device_node *node = pdev->dev.of_node;const char *oh_name;int oh_cnt, i, ret =0 ;
@@ -370,7 +398,10 @@ static int omap_device_build_from_dt(struct platform_device *pdev) hwmods[i] = oh; } - od =omap_device_alloc (pdev, hwmods, oh_cnt,NULL ,0 ); +if (of_find_property (node,"ti,console_hwmod" ,NULL )) + pm_lat = omap_console_latency; + + od =omap_device_alloc (pdev, hwmods, oh_cnt, pm_lat,0 );if (!od) {dev_err (&pdev->dev,"Cannot allocate omap_device for :%s\n" , oh_name);
Signature · 1 line
1.7.1
PATCH 1/3 ARM: omap_device: handle first time activation of console device
Quoted 24 lines · Rajendra Nayak
console device on OMAP is never reset or idled by hwmod post initial setup, early during boot, for obvious reasons not to break early debug prints thrown on console.
This leaves the console device enabled at boot and the first activation of it using hwmod needs to be handled in such a way that a disable is called followed by an enable of the hwmod, the subsequent activations can then use the default activation technique.To handle this add a new binding to identify a hwmod which is used as the console device.
This patch is based on the what is done in
serial.cfor non-DT builds.Signed-off-by Rajendra Nayak <[email protected]>--- .../devicetree/bindings/arm/omap/omap.txt | 1 + arch/arm/plat-omap/omap_device.c | 33 +++++++++++++++++++- 2 files changed, 33 insertions(+), 1 deletions(-)Documentation/devicetree/bindings/arm/omap/omap.txt +0
-0
Documentation/devicetree/bindings/arm/omap/omap.txt Required properties: · line 25
Quoted 5 lines
Documentation/devicetree/bindings/arm/omap/omap.txt +1
-0@@ -21,6 +21,7 @@ Required properties: Optional properties: - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module during suspend. +- ti,console_hwmod: boolean, identifies the hwmod used as console device
This doesn't seem right. Which console is not a h/w property. Why can't you use aliases like other platforms are doing?
Also, it's not clear in the documentation where this (and ti,no_idle_on_suspend) should go in the DT. Both seem like they should be kernel cmdline params.
Rob
PATCH 1/3 ARM: omap_device: handle first time activation of console device
Hi Rob,
Quoted 34 lines · Rob Herring
Quoted 24 lines · Rajendra Nayak
console device on OMAP is never reset or idled by hwmod post initial setup, early during boot, for obvious reasons not to break early debug prints thrown on console.
This leaves the console device enabled at boot and the first activation of it using hwmod needs to be handled in such a way that a disable is called followed by an enable of the hwmod, the subsequent activations can then use the default activation technique.To handle this add a new binding to identify a hwmod which is used as the console device.
This patch is based on the what is done in
serial.cfor non-DT builds.Signed-off-by Rajendra Nayak<[email protected]>--- .../devicetree/bindings/arm/omap/omap.txt | 1 + arch/arm/plat-omap/omap_device.c | 33 +++++++++++++++++++- 2 files changed, 33 insertions(+), 1 deletions(-)Documentation/devicetree/bindings/arm/omap/omap.txt +0
-0Documentation/devicetree/bindings/arm/omap/omap.txt Required properties: · line 25
Quoted 5 lines
Documentation/devicetree/bindings/arm/omap/omap.txt +1
-0@@ -21,6 +21,7 @@ Required properties: Optional properties: - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module during suspend. +- ti,console_hwmod: boolean, identifies the hwmod used as console deviceThis doesn't seem right. Which console is not a h/w property. Why can't you use aliases like other platforms are doing?
Quoted 3 lines
Also, it's not clear in the documentation where this (and ti,no_idle_on_suspend) should go in the DT. Both seem like they should be kernel cmdline params.
That raise the question about using DT to pass linux specific parameter. We already discuss that on the mailing list, but never get a clear answer. It seems that DT is already used to provide some OS specific information using the "linux," prefix for example.
There are clearly a couple of parameters that can be provided by the bootloader, but that does not reflect a HW property.
So what is the guideline for that, should we stick to cmdline params for that?
Quoting Grant's documentation, runtime configuration is supported:
"Runtime configuration
In most cases, a DT will be the sole method of communicating data from firmware to the kernel, so also gets used to pass in runtime and configuration data like the kernel parameters string and the location of an initrd image.
Most of this data is contained in the /chosen node, and when booting Linux it will look something like this:
chosen {
bootargs = "console=ttyS0,115200 loglevel=8";
initrd-start = <0xc8000000>;
initrd-end = <0xc8200000>;
};The bootargs property contains the kernel arguments, and the initrd-* properties define the address and size of an initrd blob. The chosen node may also optionally contain an arbitrary number of additional properties for platform-specific configuration data."
Does that mean that this is supported only if the bootloader does not support cmdline?
Thanks,
Benoit
PATCH 1/3 ARM: omap_device: handle first time activation of console device
Benoit,
Quoted 41 lines · Benoit
Hi Rob,
Quoted 38 lines · Rob Herring
Quoted 28 lines · Rajendra Nayak
console device on OMAP is never reset or idled by hwmod post initial setup, early during boot, for obvious reasons not to break early debug prints thrown on console.
This leaves the console device enabled at boot and the first activation of it using hwmod needs to be handled in such a way that a disable is called followed by an enable of the hwmod, the subsequent activations can then use the default activation technique.To handle this add a new binding to identify a hwmod which is used as the console device.
This patch is based on the what is done in
serial.cfor non-DT builds.Signed-off-by Rajendra Nayak<[email protected]>--- .../devicetree/bindings/arm/omap/omap.txt | 1 + arch/arm/plat-omap/omap_device.c | 33 +++++++++++++++++++- 2 files changed, 33 insertions(+), 1 deletions(-)Documentation/devicetree/bindings/arm/omap/omap.txt +0
-0@@ -21,6 +21,7 @@ Required properties: Optional properties: - ti,no_idle_on_suspend: When present, it prevents the PM to idleQuoted 5 lines
the module
during suspend.
+- ti,console_hwmod: boolean, identifies the hwmod used as console deviceThis doesn't seem right. Which console is not a h/w property. Why can't you use aliases like other platforms are doing?
Quoted 8 lines
Quoted 3 lines
Also, it's not clear in the documentation where this (and ti,no_idle_on_suspend) should go in the DT. Both seem like they should be kernel cmdline params.
That raise the question about using DT to pass linux specific parameter. We already discuss that on the mailing list, but never get a clear answer. It seems that DT is already used to provide some OS specific information using the "linux," prefix for example.
True, but "linux," properties will always face resistance and scrutiny.
Quoted 6 lines
There are clearly a couple of parameters that can be provided by the bootloader, but that does not reflect a HW property.
So what is the guideline for that, should we stick to cmdline params for that?
I would say that if the setting does not depend on something in the DT, then the cmdline is the right place. If you have a property that references a phandle, then it can't be on the cmdline. For console selection, there is already a defined way to select it with console=blah. And there is an agreed way to define indexes in the DT with aliases.
How were these properties set without DT?
Quoted 18 lines
Quoting Grant's documentation, runtime configuration is supported:
"Runtime configuration
In most cases, a DT will be the sole method of communicating data from firmware to the kernel, so also gets used to pass in runtime and configuration data like the kernel parameters string and the location of an initrd image.
Most of this data is contained in the /chosen node, and when booting Linux it will look something like this:
chosen { bootargs = "console=ttyS0,115200 loglevel=8"; initrd-start = <0xc8000000>; initrd-end = <0xc8200000>; };
Quoted 8 lines
The bootargs property contains the kernel arguments, and the initrd-* properties define the address and size of an initrd blob. The chosen node may also optionally contain an arbitrary number of additional properties for platform-specific configuration data."
Does that mean that this is supported only if the bootloader does not support cmdline?
No. I think it means chosen can be extended. However, how many other chosen properties are defined? Not very many. Clearly, it's not a place for adding whatever random property you want. chosen is really the boot interface between the bootloader and kernel as it is ATAG type data.
Rob
PATCH 1/3 ARM: omap_device: handle first time activation of console device
Quoted 48 lines · Rob Herring
Benoit,
Quoted 45 lines · Benoit
Hi Rob,
Quoted 41 lines · Rob Herring
Quoted 28 lines · Rajendra Nayak
console device on OMAP is never reset or idled by hwmod post initial setup, early during boot, for obvious reasons not to break early debug prints thrown on console.
This leaves the console device enabled at boot and the first activation of it using hwmod needs to be handled in such a way that a disable is called followed by an enable of the hwmod, the subsequent activations can then use the default activation technique.To handle this add a new binding to identify a hwmod which is used as the console device.
This patch is based on the what is done in
serial.cfor non-DT builds.Signed-off-by Rajendra Nayak<[email protected]>--- .../devicetree/bindings/arm/omap/omap.txt | 1 + arch/arm/plat-omap/omap_device.c | 33 +++++++++++++++++++- 2 files changed, 33 insertions(+), 1 deletions(-)Documentation/devicetree/bindings/arm/omap/omap.txt +0
-0@@ -21,6 +21,7 @@ Required properties: Optional properties: - ti,no_idle_on_suspend: When present, it prevents the PM to idleQuoted 5 lines
the module
during suspend.
+- ti,console_hwmod: boolean, identifies the hwmod used as console deviceThis doesn't seem right. Which console is not a h/w property. Why can't you use aliases like other platforms are doing?
Also, it's not clear in the documentation where this (and ti,no_idle_on_suspend) should go in the DT. Both seem like they should be kernel cmdline params.
Quoted 6 lines
Quoted 4 lines
That raise the question about using DT to pass linux specific parameter. We already discuss that on the mailing list, but never get a clear answer. It seems that DT is already used to provide some OS specific information using the "linux," prefix for example.
True, but "linux," properties will always face resistance and scrutiny.
OK, that's good to know. So we should avoid abusing that kind of prefix.
Quoted 7 lines
Quoted 6 lines
There are clearly a couple of parameters that can be provided by the bootloader, but that does not reflect a HW property.
So what is the guideline for that, should we stick to cmdline params for that?
Quoted 6 lines
I would say that if the setting does not depend on something in the DT, then the cmdline is the right place. If you have a property that references a phandle, then it can't be on the cmdline. For console selection, there is already a defined way to select it with console=blah. And there is an agreed way to define indexes in the DT with aliases.
OK, I saw that in some DT adapted serial driver, we can retrieve the index from the string "serial<x>" and thus can get the console from the ttyS number.
Quoted 1 line
How were these properties set without DT?
From the board file most of the time. Or using some dirty hacks here
and there :-)
Quoted 24 lines
Quoted 24 lines
Quoting Grant's documentation, runtime configuration is supported:
"Runtime configuration
In most cases, a DT will be the sole method of communicating data from firmware to the kernel, so also gets used to pass in runtime and configuration data like the kernel parameters string and the location of an initrd image.
Most of this data is contained in the /chosen node, and when booting Linux it will look something like this:
chosen { bootargs = "console=ttyS0,115200 loglevel=8"; initrd-start =<0xc8000000>; initrd-end =<0xc8200000>; };The bootargs property contains the kernel arguments, and the initrd-* properties define the address and size of an initrd blob. The chosen node may also optionally contain an arbitrary number of additional properties for platform-specific configuration data."
Quoted 7 lines
Quoted 2 lines
Does that mean that this is supported only if the bootloader does not support cmdline?
No. I think it means chosen can be extended. However, how many other chosen properties are defined? Not very many. Clearly, it's not a place for adding whatever random property you want. chosen is really the boot interface between the bootloader and kernel as it is ATAG type data.
OK, thanks for the clarification.
Regards,
Benoit
PATCH 1/3 ARM: omap_device: handle first time activation of console device
In reply to Rob HerringHi Rob,
On Wednesday 16 November 2011 08:20 PM, Rob Herring wrote:
[]...
Quoted 14 lines
Documentation/devicetree/bindings/arm/omap/omap.txt Required properties: · line 25
Quoted 11 lines
Documentation/devicetree/bindings/arm/omap/omap.txt +1
-0@@ -21,6 +21,7 @@ Required properties: Optional properties: - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module during suspend. +- ti,console_hwmod: boolean, identifies the hwmod used as console deviceThis doesn't seem right. Which console is not a h/w property. Why can't you use aliases like other platforms are doing?
After thinking of this some more, I figured its more of a hwmod problem to be solved, than with being able to identify which console. Will post a separate patch to fix it up in hmwod and drop this from the DT series.
Thanks for the review.
regards,
Rajendra
Quoted 6 lines
Also, it's not clear in the documentation where this (and ti,no_idle_on_suspend) should go in the DT. Both seem like they should be kernel cmdline params.
Rob
PATCH 1/3 ARM: omap_device: handle first time activation of console device
In reply to Rajendra NayakHi Rajendra,
Quoted 24 lines · Rajendra Nayak
console device on OMAP is never reset or idled by hwmod post initial setup, early during boot, for obvious reasons not to break early debug prints thrown on console.
This leaves the console device enabled at boot and the first activation of it using hwmod needs to be handled in such a way that a disable is called followed by an enable of the hwmod, the subsequent activations can then use the default activation technique.To handle this add a new binding to identify a hwmod which is used as the console device.
This patch is based on the what is done in
serial.cfor non-DT builds.Signed-off-by Rajendra Nayak<[email protected]>--- .../devicetree/bindings/arm/omap/omap.txt | 1 + arch/arm/plat-omap/omap_device.c | 33 +++++++++++++++++++- 2 files changed, 33 insertions(+), 1 deletions(-)Documentation/devicetree/bindings/arm/omap/omap.txt +0
-0
Documentation/devicetree/bindings/arm/omap/omap.txt Required properties: · line 24
Quoted 4 lines
Documentation/devicetree/bindings/arm/omap/omap.txt +1
-0@@ -21,6 +21,7 @@ Required properties: Optional properties: - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module during suspend. +- ti,console_hwmod: boolean, identifies the hwmod used as console device
This is not directly hwmod related,
Quoted 14 lines
Documentation/devicetree/bindings/arm/omap/omap.txt +0
-0Example:arch/arm/plat-omap/omap_device.c +1
-0@@ -88,6 +88,7 @@#include <linux/pm_runtime.h> #include <linux/of.h> #include <linux/notifier.h> +#include <linux/console.h> #include <plat/omap_device.h> #include <plat/omap_hwmod.h>
arch/arm/plat-omap/omap_device.c static struct omap_device_pm_latency omap_default_latency[] = { · line 122
Quoted 8 lines
arch/arm/plat-omap/omap_device.c +5
-0@@ -114,6 +115,32 @@ static struct omap_device_pm_latency omap_default_latency[] = { } }; +static int omap_console_hwmod_enable (struct omap_device *od) +{ +console_lock (); +/* +* For early console we prevented hwmod reset and idle
A period is missing. Or maybe it should a comma with not capital letter.
arch/arm/plat-omap/omap_device.c static struct omap_device_pm_latency omap_default_latency[] = { · line 127
Quoted 5 lines
arch/arm/plat-omap/omap_device.c +5
-0+* So before we enable the uart clocks idle the console +* uart clocks, then enable back the console uart hwmod. +*/ +omap_hwmod_idle (od->hwmods[0 ]); +omap_hwmod_enable (od->hwmods[0 ]);
Why do we have to idle -> enable? The module is already enabled, isn't it? The comment is not super clear for me :-)
Is the goal is to reset the IP?
arch/arm/plat-omap/omap_device.c static struct omap_device_pm_latency omap_default_latency[] = { · line 134
Quoted 7 lines
arch/arm/plat-omap/omap_device.c +7
-0+console_unlock (); +/* +* Restore the default activate/deactivate funcs, +* since now we have set the hwmod state machine right +* with the idle/enable for console uart +*/ + od->pm_lats = omap_default_latency;
I do not understand that part to?
This is not the default, but instead a specific one only for the serial driver.
It looks to me that you are overwriting the default one with a specific one.
Quoted 21 lines
arch/arm/plat-omap/omap_device.c +10
-0+return 0 ; +} + +static struct omap_device_pm_latency omap_console_latency[] = { + { + .activate_func = omap_console_hwmod_enable, + }, +}; +/* Private functions */ /** @@ -342,6 +369,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)struct omap_hwmod **hwmods;struct omap_device *od;struct omap_hwmod *oh; +struct omap_device_pm_latency *pm_lat =NULL ;struct device_node *node = pdev->dev.of_node;const char *oh_name;int oh_cnt, i, ret =0 ;
arch/arm/plat-omap/omap_device.c static int omap_device_build_from_dt(struct platform_device *pdev) · line 402
Quoted 6 lines
arch/arm/plat-omap/omap_device.c +2
-1@@ -370,7 +398,10 @@ static int omap_device_build_from_dt(struct platform_device *pdev) hwmods[i] = oh; } - od =omap_device_alloc (pdev, hwmods, oh_cnt,NULL ,0 ); +if (of_find_property (node,"ti,console_hwmod" ,NULL )) + pm_lat = omap_console_latency;
That's looks like a hack to me to add that specific serial hooks into the core code. But I'm not sure to have any better idea, since the issue is the lack of function pointer in DT :-)
arch/arm/plat-omap/omap_device.c static int omap_device_build_from_dt(struct platform_device *pdev) · line 404
Quoted 1 line
arch/arm/plat-omap/omap_device.c +1
-0+ od =omap_device_alloc (pdev, hwmods, oh_cnt, pm_lat,0 );
It should not be 0 but the size of the array here: ARRAY_SIZE(omap_console_latency).
I'm wondering how it can work with zero since the code is doing that in omap_device_alloc:
od->pm_lats = kmemdup(pm_lats,
sizeof(struct omap_device_pm_latency) * pm_lats_cnt, GFP_KERNEL);
Regards,
Benoit
PATCH 1/3 ARM: omap_device: handle first time activation of console device
[...]
Quoted 8 lines
arch/arm/plat-omap/omap_device.c static struct omap_device_pm_latency omap_default_latency[] = { · line 122
Quoted 5 lines
arch/arm/plat-omap/omap_device.c +5
-0+static int omap_console_hwmod_enable (struct omap_device *od) +{ +console_lock (); +/* +* For early console we prevented hwmod reset and idle A period is missing. Or maybe it should a comma with not capital letter.
Quoted 9 lines
arch/arm/plat-omap/omap_device.c static struct omap_device_pm_latency omap_default_latency[] = { · line 127
Quoted 5 lines
arch/arm/plat-omap/omap_device.c +5
-0+* So before we enable the uart clocks idle the console +* uart clocks, then enable back the console uart hwmod. +*/ +omap_hwmod_idle (od->hwmods[0 ]); +omap_hwmod_enable (od->hwmods[0 ]);Why do we have to idle -> enable? The module is already enabled, isn't it? The comment is not super clear for me :-)
Is the goal is to reset the IP?
Yes, now that I read it, it does sound confusing. I should have at-least read it once before I picked it from serial.c
But anyway, here's what the problem is.
I feel its partly to do with the inability of hwmod to handle some modules which are left enabled post a setup, due to the 'HWMOD_INIT_NO_IDLE' flag set.
Such modules end up with a hwmod state as '_HWMOD_STATE_ENABLED' post a setup. Now when a driver for such devices/modules tries to enable the module the first time, hwmod throws up a big WARN stating the hwmod is already in an enabled state.
[uart used as console is one such module, which cannot be idled post a setup by hwmod]
If hwmod could be made in some way intelligent enough to know that the module is in enabled state because of the 'HWMOD_INIT_NO_IDLE' itself, a lot of this hackery might not be needed at all.
Simplest way to do it could be to just add another intermediate state, something like '_HWMOD_STATE_ENABLED_AT_INIT'.
I will post a patch for this, see if you like it being handled that way.
The other part of the problem is also with the inability to hook up 'custom' omap_device_pm_latency for omap devices created from DT. Maybe a lot of such cases which need custom activate/deactivate functions might have to be handled in some way in the framework itself like the one above.
PATCH 1/3 ARM: omap_device: handle first time activation of console device
Hi Rajendra,
Quoted 25 lines · Rajendra Nayak
[...]
Quoted 14 lines
arch/arm/plat-omap/omap_device.c static struct omap_device_pm_latency omap_default_latency[] = { · line 122
Quoted 5 lines
arch/arm/plat-omap/omap_device.c +5
-0+static int omap_console_hwmod_enable (struct omap_device *od) +{ +console_lock (); +/* +* For early console we prevented hwmod reset and idle A period is missing. Or maybe it should a comma with not capital letter.
Quoted 5 lines
+ * So before we enable the uart clocks idle the console
+ * uart clocks, then enable back the console uart hwmod.
+ */
+omap_hwmod_idle(od->hwmods[0]);
+omap_hwmod_enable(od->hwmods[0]);Quoted 4 lines
Why do we have to idle -> enable? The module is already enabled, isn't it?
The comment is not super clear for me :-)
Is the goal is to reset the IP?Yes, now that I read it, it does sound confusing. I should have at-least read it once before I picked it from
serial.cBut anyway, here's what the problem is.
Quoted 7 lines
I feel its partly to do with the inability of hwmod to handle some modules which are left enabled post a setup, due to the '
HWMOD_INIT_NO_IDLE' flag set.
Such modules end up with a hwmod state as '_HWMOD_STATE_ENABLED' post a setup. Now when a driver for such devices/modules tries to enable the module the first time, hwmod throws up a big WARN stating the hwmod is already in an enabled state.
OK, now, that makes sense :-)
We have hwmod in ENABLE state whereas the omap_device is still in IDLE or even DISABLE.
Quoted 6 lines
[uart used as console is one such module, which cannot be idled post a setup by hwmod]
If hwmod could be made in some way intelligent enough to know that the module is in enabled state because of the '
HWMOD_INIT_NO_IDLE' itself, a lot of this hackery might not be needed at all.
Fully agree, the fmwk should handle that.
Quoted 3 lines
Simplest way to do it could be to just add another intermediate state, something like '
_HWMOD_STATE_ENABLED_AT_INIT'.
I will post a patch for this, see if you like it being handled that way.
That seems to be good. I'm just wondering if we need to introduce a new state for that or use a dedicated flag.
My concern is just that we will have two flavors of HWMOD_STATE_ENABLED that we will have to check in various places in the hwmod core code.
Maybe that's not such a big deal. Go ahead, and we will see how it looks like.
Quoted 5 lines
The other part of the problem is also with the inability to hook up 'custom'
omap_device_pm_latencyfor omap devices created from DT. Maybe a lot of such cases which need custom activate/deactivate functions might have to be handled in some way in the framework itself like the one above.
For the moment, it looks like only the serial is requiring such custom stuff, but anyway, we should have a mechanism to allow that...
Thanks,
Benoit
PATCH 1/3 ARM: omap_device: handle first time activation of console device
[]...
Quoted 19 lines
Quoted 11 lines
Quoted 5 lines
Why do we have to idle -> enable? The module is already enabled, isn't it?
The comment is not super clear for me :-)
Is the goal is to reset the IP?Yes, now that I read it, it does sound confusing. I should have at-least read it once before I picked it from
serial.cBut anyway, here's what the problem is.
Quoted 7 lines
I feel its partly to do with the inability of hwmod to handle some modules which are left enabled post a setup, due to the '
HWMOD_INIT_NO_IDLE' flag set.
Such modules end up with a hwmod state as '_HWMOD_STATE_ENABLED' post a setup. Now when a driver for such devices/modules tries to enable the module the first time, hwmod throws up a big WARN stating the hwmod is already in an enabled state.
Quoted 3 lines
OK, now, that makes sense :-)
We have hwmod in ENABLE state whereas theomap_deviceis still in IDLE or even DISABLE.
Right.
Quoted 14 lines
Quoted 7 lines
[uart used as console is one such module, which cannot be idled post a setup by hwmod]
If hwmod could be made in some way intelligent enough to know that the module is in enabled state because of the '
HWMOD_INIT_NO_IDLE' itself, a lot of this hackery might not be needed at all.Fully agree, the fmwk should handle that.
Quoted 3 lines
Simplest way to do it could be to just add another intermediate state, something like '
_HWMOD_STATE_ENABLED_AT_INIT'.
I will post a patch for this, see if you like it being handled that way.
Quoted 7 lines
That seems to be good. I'm just wondering if we need to introduce a new state for that or use a dedicated flag.
My concern is just that we will have two flavors ofHWMOD_STATE_ENABLEDthat we will have to check in various places in the hwmod core code.Maybe that's not such a big deal. Go ahead, and we will see how it looks like.
I initially thought I could do that using the existing flag itself, but the key is that its needed only the first time a enable is done on the hwmod. The rest of the state handling remains the same.
I just posted the patch, so that should make it more clear.
Quoted 8 lines
Quoted 6 lines
The other part of the problem is also with the inability to hook up 'custom'
omap_device_pm_latencyfor omap devices created from DT. Maybe a lot of such cases which need custom activate/deactivate functions might have to be handled in some way in the framework itself like the one above.For the moment, it looks like only the serial is requiring such custom
yes.
Quoted 5 lines
stuff, but anyway, we should have a mechanism to allow that...
Thanks,
Benoit
PATCH 2/3 omap-serial: Add minimal device tree support
In reply to Rajendra NayakAdapt the driver to device tree and pass minimal platform data from device tree needed for console boot. No power management features will be suppported for now since it requires more tweaks around OCP settings to toggle forceidle/noidle/smaridle bits and handling remote wakeup and dynamic muxing.
--- .../devicetree/bindings/serial/omap_serial.txt | 9 +++++ drivers/tty/serial/omap-serial.c | 37 +++++++++++++++++++- 2 files changed, 45 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
Documentation/devicetree/bindings/serial/omap_serial.txt new file +9 -0
@@ -0,0 +1,9 @@ +OMAP UART controller + +Required properties: +- compatible : should be "ti,omap-uart" +- ti,hwmods : Must be "uart<n>", n being the instance number (1-based) + +Optional properties: +- clock-frequency : frequency of the clock input to the UART +- ti,console_hwmod : boolean, UART used as debug console
drivers/tty/serial/omap-serial.c +36 -1
@@ -38,6 +38,7 @@#include <linux/serial_core.h> #include <linux/irq.h> #include <linux/pm_runtime.h> +#include <linux/of.h> #include <plat/dma.h> #include <plat/dmtimer.h>
@@ -1322,6 +1323,22 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, void *data)return ; } +static struct omap_uart_port_info *of_get_uart_port_info (struct device *dev) +{ +struct omap_uart_port_info *omap_up_info; + + omap_up_info =devm_kzalloc (dev,sizeof (*omap_up_info),GFP_KERNEL ); +if (!omap_up_info) +return NULL ;/* out of memory */ + +of_property_read_u32 (dev->of_node,"clock-frequency" , + &(*omap_up_info).uartclk); + +return omap_up_info; +} + +static atomic_t omap_uart_next_id =ATOMIC_INIT (0 ); +static int serial_omap_probe (struct platform_device *pdev) {struct uart_omap_port *up;
@@ -1329,6 +1346,11 @@ static int serial_omap_probe(struct platform_device *pdev)struct omap_uart_port_info *omap_up_info = pdev->dev.platform_data;int ret = -ENOSPC ; +if (pdev->dev.of_node) { + omap_up_info =of_get_uart_port_info (&pdev->dev); + pdev->id =atomic_inc_return (&omap_uart_next_id) -1 ; + } + mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 );if (!mem) {dev_err (&pdev->dev,"no mem resource?\n" );
@@ -1523,7 +1545,7 @@ static int serial_omap_runtime_suspend(struct device *dev)if (!up)return -EINVAL ; -if (!pdata->enable_wakeup) +if (!pdata || !pdata->enable_wakeup)return 0 ;if (pdata->get_context_loss_count)
@@ -1582,12 +1604,25 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = { serial_omap_runtime_resume, NULL) }; +#if defined(CONFIG_OF ) +static const struct of_device_id omap_serial_of_match[] = { + { + .compatible ="ti,omap-uart" , + }, + {}, +}; +MODULE_DEVICE_TABLE (of, omap_serial_of_match); +#else +#define omap_serial_of_match NULL +#endif +static struct platform_driver serial_omap_driver = { .probe = serial_omap_probe, .remove = serial_omap_remove, .driver = { .name =DRIVER_NAME , .pm = &serial_omap_dev_pm_ops, + .of_match_table = omap_serial_of_match, }, };
Signature · 1 line
1.7.1
PATCH 2/3 omap-serial: Add minimal device tree support
Quoted 20 lines · Rajendra Nayak
Adapt the driver to device tree and pass minimal platform data from device tree needed for console boot. No power management features will be suppported for now since it requires more tweaks around OCP settings to toggle forceidle/noidle/smaridle bits and handling remote wakeup and dynamic muxing.
Signed-off-by Rajendra Nayak <[email protected]>--- .../devicetree/bindings/serial/omap_serial.txt | 9 +++++ drivers/tty/serial/omap-serial.c | 37 +++++++++++++++++++- 2 files changed, 45 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txtDocumentation/devicetree/bindings/serial/omap_serial.txt new file +0
-0
Documentation/devicetree/bindings/serial/omap_serial.txt line 4
Quoted 4 lines
Documentation/devicetree/bindings/serial/omap_serial.txt new file +4
-0@@ -0,0 +1,9 @@ +OMAP UART controller + +Required properties: +- compatible : should be "ti,omap-uart"
This seems too generic. There are no h/w differences in the uart since the 1st OMAP1 device?
Quoted 21 lines
Documentation/devicetree/bindings/serial/omap_serial.txt new file +5
-0+- ti,hwmods : Must be "uart<n>", n being the instance number (1-based) + +Optional properties: +- clock-frequency : frequency of the clock input to the UART +- ti,console_hwmod : boolean, UART used as debug consoledrivers/tty/serial/omap-serial.c +1
-0@@ -38,6 +38,7 @@#include <linux/serial_core.h> #include <linux/irq.h> #include <linux/pm_runtime.h> +#include <linux/of.h> #include <plat/dma.h> #include <plat/dmtimer.h> @@ -1322,6 +1323,22 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, void *data)return ; }
drivers/tty/serial/omap-serial.c static void uart_tx_dma_callback(int lch, u16 ch_status, void *data) · line 1335
Quoted 10 lines
drivers/tty/serial/omap-serial.c +10
-0+static struct omap_uart_port_info *of_get_uart_port_info (struct device *dev) +{ +struct omap_uart_port_info *omap_up_info; + + omap_up_info =devm_kzalloc (dev,sizeof (*omap_up_info),GFP_KERNEL ); +if (!omap_up_info) +return NULL ;/* out of memory */ + +of_property_read_u32 (dev->of_node,"clock-frequency" , + &(*omap_up_info).uartclk);
&omap_up_info->uartclk
You want 0 to be the default freq?
Quoted 10 lines
drivers/tty/serial/omap-serial.c +6
-0+ +return omap_up_info; +} + +static atomic_t omap_uart_next_id =ATOMIC_INIT (0 ); +static int serial_omap_probe (struct platform_device *pdev) {struct uart_omap_port *up;
drivers/tty/serial/omap-serial.c static int serial_omap_probe(struct platform_device *pdev) · line 1351
Quoted 6 lines
drivers/tty/serial/omap-serial.c +3
-0@@ -1329,6 +1346,11 @@ static int serial_omap_probe(struct platform_device *pdev)struct omap_uart_port_info *omap_up_info = pdev->dev.platform_data;int ret = -ENOSPC ; +if (pdev->dev.of_node) { + omap_up_info =of_get_uart_port_info (&pdev->dev); + pdev->id =atomic_inc_return (&omap_uart_next_id) -1 ;
I don't think a driver changing this value is a good idea. Look at other serial drivers like iMX for how they use aliases.
Quoted 27 lines
drivers/tty/serial/omap-serial.c +12
-1+ } + mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 );if (!mem) {dev_err (&pdev->dev,"no mem resource?\n" );@@ -1523,7 +1545,7 @@ static int serial_omap_runtime_suspend(struct device *dev)if (!up)return -EINVAL ; -if (!pdata->enable_wakeup) +if (!pdata || !pdata->enable_wakeup)return 0 ;if (pdata->get_context_loss_count)@@ -1582,12 +1604,25 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = { serial_omap_runtime_resume, NULL) }; +#if defined(CONFIG_OF ) +static const struct of_device_id omap_serial_of_match[] = { + { + .compatible ="ti,omap-uart" , + }, + {}, +}; +MODULE_DEVICE_TABLE (of, omap_serial_of_match); +#else
drivers/tty/serial/omap-serial.c static const struct dev_pm_ops serial_omap_dev_pm_ops = { · line 1625
Quoted 10 lines
drivers/tty/serial/omap-serial.c +4
-0+#define omap_serial_of_match NULL +#endif +static struct platform_driver serial_omap_driver = { .probe = serial_omap_probe, .remove = serial_omap_remove, .driver = { .name =DRIVER_NAME , .pm = &serial_omap_dev_pm_ops, + .of_match_table = omap_serial_of_match,
Use of_match_ptr and get rid of the #else
Rob
PATCH 2/3 omap-serial: Add minimal device tree support
Quoted 15 lines · Rob Herring
Quoted 14 lines · Rajendra Nayak
Adapt the driver to device tree and pass minimal platform data from device tree needed for console boot. No power management features will be suppported for now since it requires more tweaks around OCP settings to toggle forceidle/noidle/smaridle bits and handling remote wakeup and dynamic muxing.
Signed-off-by Rajendra Nayak<[email protected]>--- .../devicetree/bindings/serial/omap_serial.txt | 9 +++++ drivers/tty/serial/omap-serial.c | 37 +++++++++++++++++++- 2 files changed, 45 insertions(+), 1 deletions(-)create mode 100644
Documentation/devicetree/bindings/serial/omap_serial.txt
Quoted 13 lines
Documentation/devicetree/bindings/serial/omap_serial.txt line 4
Quoted 10 lines
Documentation/devicetree/bindings/serial/omap_serial.txt new file +4
-0@@ -0,0 +1,9 @@ +OMAP UART controller + +Required properties: +- compatible : should be "ti,omap-uart"This seems too generic. There are no h/w differences in the uart since the 1st OMAP1 device?
This driver supports only OMAP2+ devices, and there doesn't seem to be really much difference. But I might have to re-look, in case I need to handle some silicon errata.
Quoted 35 lines
Quoted 22 lines
Documentation/devicetree/bindings/serial/omap_serial.txt new file +5
-0+- ti,hwmods : Must be "uart<n>", n being the instance number (1-based) + +Optional properties: +- clock-frequency : frequency of the clock input to the UART +- ti,console_hwmod : boolean, UART used as debug consoledrivers/tty/serial/omap-serial.c +1
-0@@ -38,6 +38,7 @@#include <linux/serial_core.h> #include <linux/irq.h> #include <linux/pm_runtime.h> +#include <linux/of.h> #include <plat/dma.h> #include <plat/dmtimer.h> @@ -1322,6 +1323,22 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, void *data)return ; }drivers/tty/serial/omap-serial.c static void uart_tx_dma_callback(int lch, u16 ch_status, void *data) · line 1335
Quoted 10 lines
drivers/tty/serial/omap-serial.c +10
-0+static struct omap_uart_port_info *of_get_uart_port_info (struct device *dev) +{ +struct omap_uart_port_info *omap_up_info; + + omap_up_info =devm_kzalloc (dev,sizeof (*omap_up_info),GFP_KERNEL ); +if (!omap_up_info) +return NULL ;/* out of memory */ + +of_property_read_u32 (dev->of_node,"clock-frequency" , + &(*omap_up_info).uartclk);
&omap_up_info->uartclk
Quoted 1 line
You want 0 to be the default freq?
good point, I need to handle this better.
Quoted 14 lines
Quoted 14 lines
drivers/tty/serial/omap-serial.c +6
-0+ +return omap_up_info; +} + +static atomic_t omap_uart_next_id =ATOMIC_INIT (0 ); +static int serial_omap_probe (struct platform_device *pdev) {struct uart_omap_port *up;@@ -1329,6 +1346,11 @@ static int serial_omap_probe(struct platform_device *pdev)struct omap_uart_port_info *omap_up_info = pdev->dev.platform_data;int ret = -ENOSPC ;
Quoted 6 lines
drivers/tty/serial/omap-serial.c static int serial_omap_probe(struct platform_device *pdev) · line 1351
Quoted 3 lines
drivers/tty/serial/omap-serial.c +3
-0+if (pdev->dev.of_node) { + omap_up_info =of_get_uart_port_info (&pdev->dev); + pdev->id =atomic_inc_return (&omap_uart_next_id) -1 ;I don't think a driver changing this value is a good idea. Look at other serial drivers like iMX for how they use aliases.
Well, I did lookup, but maybe the wrong one. I looked up the msm serial which added DT support not too long ago and does the exact same thing.
Quoted 32 lines
Quoted 32 lines
drivers/tty/serial/omap-serial.c +15
-1+ } + mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 );if (!mem) {dev_err (&pdev->dev,"no mem resource?\n" );@@ -1523,7 +1545,7 @@ static int serial_omap_runtime_suspend(struct device *dev)if (!up)return -EINVAL ; -if (!pdata->enable_wakeup) +if (!pdata || !pdata->enable_wakeup)return 0 ;if (pdata->get_context_loss_count)@@ -1582,12 +1604,25 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = { serial_omap_runtime_resume, NULL) }; +#if defined(CONFIG_OF ) +static const struct of_device_id omap_serial_of_match[] = { + { + .compatible ="ti,omap-uart" , + }, + {}, +}; +MODULE_DEVICE_TABLE (of, omap_serial_of_match); +#else +#define omap_serial_of_match NULL +#endif +static struct platform_driver serial_omap_driver = {
Quoted 8 lines
drivers/tty/serial/omap-serial.c static const struct dev_pm_ops serial_omap_dev_pm_ops = { · line 1625
Quoted 6 lines
drivers/tty/serial/omap-serial.c +1
-0.probe = serial_omap_probe, .remove = serial_omap_remove, .driver = { .name = DRIVER_NAME, .pm =&serial_omap_dev_pm_ops, + .of_match_table = omap_serial_of_match,Use
of_match_ptrand get rid of the #else
Ok, thanks.
Rajendra
Quoted 2 lines
Rob
PATCH 3/3 ARM: omap: pass minimal SoC/board data for UART from dt
In reply to Rajendra NayakPass minimal data needed for console boot, from dt, for OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the static initialization from generic board file.
--- arch/arm/boot/dts/omap3-beagle.dts | 17 +++++++++++++++++ arch/arm/boot/dts/omap3.dtsi | 27 +++++++++++++++++++++++++++ arch/arm/boot/dts/omap4-panda.dts | 17 +++++++++++++++++ arch/arm/boot/dts/omap4-sdp.dts | 17 +++++++++++++++++ arch/arm/boot/dts/omap4.dtsi | 24 ++++++++++++++++++++++++ arch/arm/mach-omap2/board-generic.c | 1 - 6 files changed, 102 insertions(+), 1 deletions(-)
arch/arm/boot/dts/omap3-beagle.dts +17 -0
@@ -27,3 +27,20 @@ reg = <0x80000000 0x20000000>; /* 512 MB */ }; }; + +&uart1 { + clock-frequency = <48000000>; +}; + +&uart2 { + clock-frequency = <48000000>; +}; + +&uart3 { + ti,console_hwmod; + clock-frequency = <48000000>; +}; + +&uart4 { + clock-frequency = <48000000>; +};
arch/arm/boot/dts/omap3.dtsi +27 -0
@@ -13,6 +13,13 @@ / { compatible = "ti,omap3430", "ti,omap3"; + aliases { + uart1 = &uart1; + uart2 = &uart2; + uart3 = &uart3; + uart4 = &uart4; + }; + cpus { cpu at 0 { compatible = "arm,cortex-a8";
@@ -59,5 +66,25 @@ interrupt-controller; #interrupt-cells = <1>; }; + + uart1: uart at 1 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart1"; + }; + + uart2: uart at 2 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart2"; + }; + + uart3: uart at 3 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart3"; + }; + + uart4: uart at 4 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart4"; + }; }; };
arch/arm/boot/dts/omap4-panda.dts +17 -0
@@ -27,3 +27,20 @@ reg = <0x80000000 0x40000000>; /* 1 GB */ }; }; + +&uart1 { + clock-frequency = <48000000>; +}; + +&uart2 { + clock-frequency = <48000000>; +}; + +&uart3 { + ti,console_hwmod; + clock-frequency = <48000000>; +}; + +&uart4 { + clock-frequency = <48000000>; +};
arch/arm/boot/dts/omap4-sdp.dts +17 -0
@@ -27,3 +27,20 @@ reg = <0x80000000 0x40000000>; /* 1 GB */ }; }; + +&uart1 { + clock-frequency = <48000000>; +}; + +&uart2 { + clock-frequency = <48000000>; +}; + +&uart3 { + ti,console_hwmod; + clock-frequency = <48000000>; +}; + +&uart4 { + clock-frequency = <48000000>; +};
arch/arm/boot/dts/omap4.dtsi +24 -0
@@ -21,6 +21,10 @@ interrupt-parent = <&gic>; aliases { + uart1 = &uart1; + uart2 = &uart2; + uart3 = &uart3; + uart4 = &uart4; }; cpus {
@@ -99,5 +103,25 @@ reg = <0x48241000 0x1000>, <0x48240100 0x0100>; }; + + uart1: uart at 1 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart1"; + }; + + uart2: uart at 2 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart2"; + }; + + uart3: uart at 3 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart3"; + }; + + uart4: uart at 4 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart4"; + }; }; };
arch/arm/mach-omap2/board-generic.c +0 -1
@@ -70,7 +70,6 @@ static void __init omap_generic_init(void)if (node)irq_domain_add_simple (node,0 ); -omap_serial_init ();omap_sdrc_init (NULL ,NULL );of_platform_populate (NULL , omap_dt_match_table,NULL ,NULL );
Signature · 1 line
1.7.1
PATCH 3/3 ARM: omap: pass minimal SoC/board data for UART from dt
Quoted 58 lines · Rajendra Nayak
Pass minimal data needed for console boot, from dt, for OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the static initialization from generic board file.
Signed-off-by Rajendra Nayak <[email protected]>--- arch/arm/boot/dts/omap3-beagle.dts | 17 +++++++++++++++++ arch/arm/boot/dts/omap3.dtsi | 27 +++++++++++++++++++++++++++ arch/arm/boot/dts/omap4-panda.dts | 17 +++++++++++++++++ arch/arm/boot/dts/omap4-sdp.dts | 17 +++++++++++++++++ arch/arm/boot/dts/omap4.dtsi | 24 ++++++++++++++++++++++++ arch/arm/mach-omap2/board-generic.c | 1 - 6 files changed, 102 insertions(+), 1 deletions(-)arch/arm/boot/dts/omap3-beagle.dts +17
-0@@ -27,3 +27,20 @@ reg = <0x80000000 0x20000000>; /* 512 MB */ }; }; + +&uart1 { + clock-frequency = <48000000>; +}; + +&uart2 { + clock-frequency = <48000000>; +}; + +&uart3 { + ti,console_hwmod; + clock-frequency = <48000000>; +}; + +&uart4 { + clock-frequency = <48000000>; +};arch/arm/boot/dts/omap3.dtsi +7
-0@@ -13,6 +13,13 @@ / { compatible = "ti,omap3430", "ti,omap3"; + aliases { + uart1 = &uart1; + uart2 = &uart2; + uart3 = &uart3; + uart4 = &uart4; + }; + cpus { cpu at 0 { compatible = "arm,cortex-a8";
arch/arm/boot/dts/omap3.dtsi line 70
Quoted 5 lines
arch/arm/boot/dts/omap3.dtsi +2
-0@@ -59,5 +66,25 @@ interrupt-controller; #interrupt-cells = <1>; }; + + uart1: uart at 1 {
Use the generic name serial and the address: uart1: serial at 1234abcd
Quoted 59 lines
arch/arm/boot/dts/omap3.dtsi +18
-0+ compatible = "ti,omap-uart"; + ti,hwmods = "uart1"; + }; + + uart2: uart at 2 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart2"; + }; + + uart3: uart at 3 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart3"; + }; + + uart4: uart at 4 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart4"; + }; }; };arch/arm/boot/dts/omap4-panda.dts +17
-0@@ -27,3 +27,20 @@ reg = <0x80000000 0x40000000>; /* 1 GB */ }; }; + +&uart1 { + clock-frequency = <48000000>; +}; + +&uart2 { + clock-frequency = <48000000>; +}; + +&uart3 { + ti,console_hwmod; + clock-frequency = <48000000>; +}; + +&uart4 { + clock-frequency = <48000000>; +};arch/arm/boot/dts/omap4-sdp.dts +6
-0@@ -27,3 +27,20 @@ reg = <0x80000000 0x40000000>; /* 1 GB */ }; }; + +&uart1 { + clock-frequency = <48000000>; +}; + +&uart2 {
arch/arm/boot/dts/omap4-sdp.dts line 45
Quoted 10 lines
arch/arm/boot/dts/omap4-sdp.dts +10
-0+ clock-frequency = <48000000>; +}; + +&uart3 { + ti,console_hwmod; + clock-frequency = <48000000>; +}; + +&uart4 { + clock-frequency = <48000000>;
It doesn't seem that this frequency ever varies and is likely to be replaced with clock bindings, so maybe just put it in the dtsi files.
Rob
PATCH 3/3 ARM: omap: pass minimal SoC/board data for UART from dt
Quoted 58 lines · Rob Herring
Quoted 57 lines · Rajendra Nayak
Pass minimal data needed for console boot, from dt, for OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the static initialization from generic board file.
Signed-off-by Rajendra Nayak<[email protected]>--- arch/arm/boot/dts/omap3-beagle.dts | 17 +++++++++++++++++ arch/arm/boot/dts/omap3.dtsi | 27 +++++++++++++++++++++++++++ arch/arm/boot/dts/omap4-panda.dts | 17 +++++++++++++++++ arch/arm/boot/dts/omap4-sdp.dts | 17 +++++++++++++++++ arch/arm/boot/dts/omap4.dtsi | 24 ++++++++++++++++++++++++ arch/arm/mach-omap2/board-generic.c | 1 - 6 files changed, 102 insertions(+), 1 deletions(-)arch/arm/boot/dts/omap3-beagle.dts +17
-0@@ -27,3 +27,20 @@ reg =<0x80000000 0x20000000>; /* 512 MB */ }; }; + +&uart1 { + clock-frequency =<48000000>; +}; + +&uart2 { + clock-frequency =<48000000>; +}; + +&uart3 { + ti,console_hwmod; + clock-frequency =<48000000>; +}; + +&uart4 { + clock-frequency =<48000000>; +};arch/arm/boot/dts/omap3.dtsi +7
-0@@ -13,6 +13,13 @@ / { compatible = "ti,omap3430", "ti,omap3"; + aliases { + uart1 =&uart1; + uart2 =&uart2; + uart3 =&uart3; + uart4 =&uart4; + }; + cpus { cpu at 0 { compatible = "arm,cortex-a8";
Quoted 8 lines
arch/arm/boot/dts/omap3.dtsi line 70
Quoted 6 lines
arch/arm/boot/dts/omap3.dtsi +2
-0@@ -59,5 +66,25 @@ interrupt-controller; #interrupt-cells =<1>; }; + + uart1: uart at 1 {Use the generic name serial and the address: uart1: serial at
1234abcd
ok.
Quoted 65 lines
Quoted 65 lines
arch/arm/boot/dts/omap3.dtsi +18
-0+ compatible = "ti,omap-uart"; + ti,hwmods = "uart1"; + }; + + uart2: uart at 2 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart2"; + }; + + uart3: uart at 3 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart3"; + }; + + uart4: uart at 4 { + compatible = "ti,omap-uart"; + ti,hwmods = "uart4"; + }; }; };arch/arm/boot/dts/omap4-panda.dts +17
-0@@ -27,3 +27,20 @@ reg =<0x80000000 0x40000000>; /* 1 GB */ }; }; + +&uart1 { + clock-frequency =<48000000>; +}; + +&uart2 { + clock-frequency =<48000000>; +}; + +&uart3 { + ti,console_hwmod; + clock-frequency =<48000000>; +}; + +&uart4 { + clock-frequency =<48000000>; +};arch/arm/boot/dts/omap4-sdp.dts +11
-0@@ -27,3 +27,20 @@ reg =<0x80000000 0x40000000>; /* 1 GB */ }; }; + +&uart1 { + clock-frequency =<48000000>; +}; + +&uart2 { + clock-frequency =<48000000>; +}; + +&uart3 { + ti,console_hwmod;
Quoted 8 lines
arch/arm/boot/dts/omap4-sdp.dts line 45
Quoted 5 lines
arch/arm/boot/dts/omap4-sdp.dts +5
-0+ clock-frequency =<48000000>; +}; + +&uart4 { + clock-frequency =<48000000>;It doesn't seem that this frequency ever varies and is likely to be replaced with clock bindings, so maybe just put it in the dtsi files.
sure, will do.
regards,
Rajendra
Quoted 3 lines
Rob