Re: ANN: New Wiki Theme
On Tue, Nov 15, 2011 at 02:28:57PM -0600, Andy Doan wrote: We just updated wiki.linare.org with a new default theme. In addition we've created a new front page to the wiki that is intended to make some of most important links more discoverable. Most people should just press refresh to see the changes. However, if you've updated your wiki account with the non-default theme, you won't see the changes. You'll need to go to Settings-Preferences and set the theme to either default or linaro-narrow. While this is mostly cosmetic, we had a session at Connect where we outlined many other work items to help make other more substantial improvements. = Details of Changes (if you are interested) 1. The wiki now uses a maximum width for its page content so that text doesn't get really wide when you try to read. So now, unless your browser is set really narrow, you'll see a border around the sides of the page content. 2. The standard banner for links to other websites now shows up on the top of the page. 3. The table-of-contents macro now renders correctly when you try and embed it in a table that floats on the right. That's certainly much less cluttered than the previous page -- it looks like a good improvement. I think for the table of links we do need an explanation of what each item is, though this should literally just be a few words. There are also some things there which would be fairly incomprehensible to a newcomer. What is Cycles, for example? People also won't be able to guess what Connect refers to without laboriously reading the other text. I would vote for removing all the links from the introductory paragraph -- the precence of links disrupts the readability of the text unnecessarily IMHO, and putting all the links into the table. Could we also experiment with ordering the links so that the stuff for newcomers appears first, and the resources for developers come afterwards, perhaps in a separate table? We need to give newcomers a bit of extra help, because they're the people who will need it. On a more frivolous note, could we change the title to something like Welcome to the Linaro Wiki? This is friendlier, and helps to suggest that the site is for non-experts too. In practice, the wiki isn't just for developers, after all. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device
On 11/16/2011 05:02 AM, Rajendra Nayak wrote: 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. Signed-off-by: Rajendra Nayak rna...@ti.com --- .../devicetree/bindings/arm/omap/omap.txt |1 + arch/arm/plat-omap/omap_device.c | 33 +++- 2 files changed, 33 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index dbdab40..46ffd41 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/3] omap-serial: Add minimal device tree support
On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
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 rna...@ti.com
---
.../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
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 000..bf6d631
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -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?
+- ti,hwmods : Must be uartn, 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
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index e1c8527..e3419c6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -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);
omap_up_info-uartclk
You want 0 to be the default freq?
+
+ 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;
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.
+ }
+
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,
Use of_match_ptr and get rid of the #else
Rob
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device
Benoit,
On 11/16/2011 09:14 AM, Cousson, Benoit wrote:
Hi Rob,
On 11/16/2011 3:50 PM, Rob Herring wrote:
On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
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.
Signed-off-by: Rajendra Nayakrna...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |1 +
arch/arm/plat-omap/omap_device.c | 33
+++-
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index dbdab40..46ffd41 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -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.
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.
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?
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 = 0xc800;
initrd-end = 0xc820;
};
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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ANN: New Wiki Theme
On 11/16/2011 11:00 AM, Joey STANFORD wrote: Howdy All, Somehow OCTO is missed from the main page. is it possible to have a link to OfficeofCTO? I can add it, is there a list of icons I could select from? I'm looking into this today. We are also missing a link to the TSC. These pages don't receive a lot of traffic so I want to make sure we add things like this in a way that don't detract from our most important items. In the same vein the Project Managers are not there. We took a stance at Connect that only things that a developer wants should be presented on the front page of the developer wiki (which is what this is). If you don't do this, the page just grows into a website (and we have one of those already). Therefore the TSC, PMs, and OCTO were not added. We want the wiki to be focused on development functions, not teams (even though in our case they are the same). I've been thinking about compromises because the three pages don't really get linked to from anywhere else and thus become orphaned. I'm thinking about adding a new link to the table called Administrative. This would link to a new page that would then enumerate these links as well as links to stuff like Process. Thoughts? -andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ANN: New Wiki Theme
Hmm, I'm not sure what category TSC and OCTO comes under, but NOT Administrative! Dave On 16 Nov 2011, at 17:49, Joey STANFORD wrote: I've been thinking about compromises because the three pages don't really get linked to from anywhere else and thus become orphaned. I'm thinking about adding a new link to the table called Administrative. This would link to a new page that would then enumerate these links as well as links to stuff like Process. Thoughts? I like it. We need to run it through Steve T's framework filter to make sure it doesn't break anything. I don't want us to expand out the front page again to be a website. More content in this case hampers discoverability . ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device
On 11/16/2011 4:41 PM, Rob Herring wrote:
Benoit,
On 11/16/2011 09:14 AM, Cousson, Benoit wrote:
Hi Rob,
On 11/16/2011 3:50 PM, Rob Herring wrote:
On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
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.
Signed-off-by: Rajendra Nayakrna...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |1 +
arch/arm/plat-omap/omap_device.c | 33
+++-
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index dbdab40..46ffd41 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -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.
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.
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.
OK, I saw that in some DT adapted serial driver, we can retrieve the
index from the string serialx and thus can get the console from the
ttyS number.
How were these properties set without DT?
From the board file most of the time. Or using some dirty hacks here
and there :-)
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 =0xc800;
initrd-end =0xc820;
};
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.
OK, thanks for the clarification.
Regards,
Benoit
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ANN: New Wiki Theme
On Wed, Nov 16, 2011 at 05:55:54PM +, David Rusling wrote: Hmm, I'm not sure what category TSC and OCTO comes under, but NOT Administrative! Steering? Though I think the real fix is to reorganize the website to make it clear how Linaro actually works, and then the frontpage of the wiki becomes less important. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Request
Kishore, Yeah, could you tell me a little more? On 15 November 2011 02:22, KISHORE CHORNOOR kishore...@samsung.com wrote: We are developing UFS driver on Poseidon Board and we would like to release this to Linaro, can you please help us regarding how do we submit the UFS driver patch? -rgds ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Graphics WG weekly status report for wk45.2011 (20111107-20111111)
Status report in more detail https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Wk45 weekly meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-11-09 = Highlights = * Unity/NUX/compiz: we expect to get nux updated packages and possibly also compiz. FYI code merges for upstream should be ready for the alpha1 milestone of 12.04, note that this is on December 1st. * For compiz: the code has been reviewed upstream and testing is pending on the DX side. For reference here are the branches set by the maintainer lp:~compiz-team/compiz-core/compiz-core.gles2 and lp:~compiz-team/compiz-core/compiz-core.crack * glmark2 is ready for 11.11 release * glcompbench, glproxy, libmatrix, glew: no changes since 11.10 release * Memory management: No new versions of CMA or dma-mapping patches for some time, progress for v4l2 as a dma-buf user. Also work has progressed on getting an amendment to xorg to support dri2video - the work includes, in addition to patches for the core protocol support in xorg server, support for xf86-video-nouveau driver implemented as reference. Best regards, -- Ilias Biris ilias.bi...@linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 3/3] ARM: omap: pass minimal SoC/board data for UART from dt
On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
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 rna...@ti.com
---
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(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..4c8f11e 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,3 +27,20 @@
reg = 0x8000 0x2000; /* 512 MB */
};
};
+
+uart1 {
+ clock-frequency = 4800;
+};
+
+uart2 {
+ clock-frequency = 4800;
+};
+
+uart3 {
+ ti,console_hwmod;
+ clock-frequency = 4800;
+};
+
+uart4 {
+ clock-frequency = 4800;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..ea591c5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,13 @@
/ {
compatible = ti,omap3430, ti,omap3;
+ aliases {
+ uart1 = uart1;
+ uart2 = uart2;
+ uart3 = uart3;
+ uart4 = uart4;
+ };
+
cpus {
cpu@0 {
compatible = arm,cortex-a8;
@@ -59,5 +66,25 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ uart1: uart@1 {
Use the generic name serial and the address: uart1: serial@1234abcd
+ compatible = ti,omap-uart;
+ ti,hwmods = uart1;
+ };
+
+ uart2: uart@2 {
+ compatible = ti,omap-uart;
+ ti,hwmods = uart2;
+ };
+
+ uart3: uart@3 {
+ compatible = ti,omap-uart;
+ ti,hwmods = uart3;
+ };
+
+ uart4: uart@4 {
+ compatible = ti,omap-uart;
+ ti,hwmods = uart4;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index c702657..aa65449 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -27,3 +27,20 @@
reg = 0x8000 0x4000; /* 1 GB */
};
};
+
+uart1 {
+ clock-frequency = 4800;
+};
+
+uart2 {
+ clock-frequency = 4800;
+};
+
+uart3 {
+ ti,console_hwmod;
+ clock-frequency = 4800;
+};
+
+uart4 {
+ clock-frequency = 4800;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..524f5bf 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -27,3 +27,20 @@
reg = 0x8000 0x4000; /* 1 GB */
};
};
+
+uart1 {
+ clock-frequency = 4800;
+};
+
+uart2 {
+ clock-frequency = 4800;
+};
+
+uart3 {
+ ti,console_hwmod;
+ clock-frequency = 4800;
+};
+
+uart4 {
+ clock-frequency = 4800;
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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
lava-deployment-tool
As part of an effort to streamline deployment of LAVA, and allow for a more continuous testing and deployment process, the Linaro Validation Team has been working on a tool to assist with deployment of LAVA components. The intent is to create something that is suitable for production deployments as well as development/evaluation environments, and even allow for separate instances running on the same machine. Not everything is implemented just yet, but we're interested in putting this out there for wider testing and feedback. Because this is a very new tool, and needs to do things like add configuration to apache and add databases to your system, we highly recommend using a VM or cloud instance to test this. To get started you'll need to get the source from bzr and start by checking out the readme: bzr branch lp:lava-deployment-tool Special thanks to Zygmunt Krynicki for getting this started, and Michael Hudson-Doyle for being an early guinea pig. Thanks, Paul Larson ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] S5PC2XX: Rename S5pc2XX to exynos4
As per new conventions Samsung SoC's are named as Exynos.
Cortex-A9 based Soc's are named as exynos4. s5pc2xx is cortex-A9
based, hence renamed to exynos4. This is done as per kernel
naming convetions.
Similerly rename the s5p-common to exynos-common and
libs5p-common to libexynos-common.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Makefile |6 +++---
.../armv7/{s5p-common = exynos-common}/Makefile |2 +-
.../armv7/{s5p-common = exynos-common}/cpu_info.c |0
.../cpu/armv7/{s5p-common = exynos-common}/pwm.c |0
.../armv7/{s5p-common = exynos-common}/sromc.c|0
.../armv7/{s5p-common = exynos-common}/timer.c|0
arch/arm/cpu/armv7/{s5pc2xx = exynos4}/Makefile |0
arch/arm/cpu/armv7/{s5pc2xx = exynos4}/clock.c|0
arch/arm/cpu/armv7/{s5pc2xx = exynos4}/soc.c |0
.../asm/{arch-s5pc2xx = arch-exynos4}/adc.h |0
.../asm/{arch-s5pc2xx = arch-exynos4}/clk.h |0
.../asm/{arch-s5pc2xx = arch-exynos4}/clock.h |0
.../asm/{arch-s5pc2xx = arch-exynos4}/cpu.h |0
.../asm/{arch-s5pc2xx = arch-exynos4}/gpio.h |0
.../asm/{arch-s5pc2xx = arch-exynos4}/mmc.h |0
.../asm/{arch-s5pc2xx = arch-exynos4}/pwm.h |0
.../asm/{arch-s5pc2xx = arch-exynos4}/sromc.h |0
.../asm/{arch-s5pc2xx = arch-exynos4}/sys_proto.h |0
.../asm/{arch-s5pc2xx = arch-exynos4}/uart.h |0
boards.cfg |6 +++---
20 files changed, 7 insertions(+), 7 deletions(-)
rename arch/arm/cpu/armv7/{s5p-common = exynos-common}/Makefile (97%)
rename arch/arm/cpu/armv7/{s5p-common = exynos-common}/cpu_info.c (100%)
rename arch/arm/cpu/armv7/{s5p-common = exynos-common}/pwm.c (100%)
rename arch/arm/cpu/armv7/{s5p-common = exynos-common}/sromc.c (100%)
rename arch/arm/cpu/armv7/{s5p-common = exynos-common}/timer.c (100%)
rename arch/arm/cpu/armv7/{s5pc2xx = exynos4}/Makefile (100%)
rename arch/arm/cpu/armv7/{s5pc2xx = exynos4}/clock.c (100%)
rename arch/arm/cpu/armv7/{s5pc2xx = exynos4}/soc.c (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/adc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/clk.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/clock.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/cpu.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/gpio.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/mmc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/pwm.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/sromc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/sys_proto.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos4}/uart.h (100%)
diff --git a/Makefile b/Makefile
index 294c762..1d7721c 100644
--- a/Makefile
+++ b/Makefile
@@ -301,10 +301,10 @@ LIBS += $(CPUDIR)/omap-common/libomap-common.o
endif
ifeq ($(SOC),s5pc1xx)
-LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
+LIBS += $(CPUDIR)/exynos-common/libexynos-common.o
endif
-ifeq ($(SOC),s5pc2xx)
-LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
+ifeq ($(SOC),exynos4)
+LIBS += $(CPUDIR)/exynos-common/libexynos-common.o
endif
LIBS := $(addprefix $(obj),$(sort $(LIBS)))
diff --git a/arch/arm/cpu/armv7/s5p-common/Makefile
b/arch/arm/cpu/armv7/exynos-common/Makefile
similarity index 97%
rename from arch/arm/cpu/armv7/s5p-common/Makefile
rename to arch/arm/cpu/armv7/exynos-common/Makefile
index 1705399..3c2aef8 100644
--- a/arch/arm/cpu/armv7/s5p-common/Makefile
+++ b/arch/arm/cpu/armv7/exynos-common/Makefile
@@ -23,7 +23,7 @@
include $(TOPDIR)/config.mk
-LIB= $(obj)libs5p-common.o
+LIB= $(obj)libexynos-common.o
COBJS-y+= cpu_info.o
COBJS-y+= timer.o
diff --git a/arch/arm/cpu/armv7/s5p-common/cpu_info.c
b/arch/arm/cpu/armv7/exynos-common/cpu_info.c
similarity index 100%
rename from arch/arm/cpu/armv7/s5p-common/cpu_info.c
rename to arch/arm/cpu/armv7/exynos-common/cpu_info.c
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/exynos-common/pwm.c
similarity index 100%
rename from arch/arm/cpu/armv7/s5p-common/pwm.c
rename to arch/arm/cpu/armv7/exynos-common/pwm.c
diff --git a/arch/arm/cpu/armv7/s5p-common/sromc.c
b/arch/arm/cpu/armv7/exynos-common/sromc.c
similarity index 100%
rename from arch/arm/cpu/armv7/s5p-common/sromc.c
rename to arch/arm/cpu/armv7/exynos-common/sromc.c
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/exynos-common/timer.c
similarity index 100%
rename from arch/arm/cpu/armv7/s5p-common/timer.c
rename to arch/arm/cpu/armv7/exynos-common/timer.c
diff --git a/arch/arm/cpu/armv7/s5pc2xx/Makefile
b/arch/arm/cpu/armv7/exynos4/Makefile
similarity index 100%
rename from arch/arm/cpu/armv7/s5pc2xx/Makefile
rename to arch/arm/cpu/armv7/exynos4/Makefile
diff --git
Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device
[...]
+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.
+* 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.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device
Hi Rob, On Wednesday 16 November 2011 08:20 PM, Rob Herring wrote: []... diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index dbdab40..46ffd41 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -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? 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 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
