From: Rob Herring <robherring2@gmail.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: linux-serial@vger.kernel.org, linux-omap@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org, khilman@ti.com,
linaro-dev@lists.linaro.org, tony@atomide.com,
govindraj.raja@ti.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device
Date: Wed, 16 Nov 2011 08:50:44 -0600 [thread overview]
Message-ID: <4EC3CDC4.7000108@gmail.com> (raw)
In-Reply-To: <1321441346-19591-2-git-send-email-rnayak@ti.com>
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 <rnayak@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
WARNING: multiple messages have this Message-ID (diff)
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] ARM: omap_device: handle first time activation of console device
Date: Wed, 16 Nov 2011 08:50:44 -0600 [thread overview]
Message-ID: <4EC3CDC4.7000108@gmail.com> (raw)
In-Reply-To: <1321441346-19591-2-git-send-email-rnayak@ti.com>
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 <rnayak@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
next prev parent reply other threads:[~2011-11-16 14:50 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 11:02 [PATCH 0/3] OMAP serial device tree support Rajendra Nayak
2011-11-16 11:02 ` Rajendra Nayak
2011-11-16 11:02 ` [PATCH 1/3] ARM: omap_device: handle first time activation of console device Rajendra Nayak
2011-11-16 11:02 ` Rajendra Nayak
2011-11-16 14:50 ` Rob Herring [this message]
2011-11-16 14:50 ` Rob Herring
2011-11-16 15:14 ` Cousson, Benoit
2011-11-16 15:14 ` Cousson, Benoit
2011-11-16 15:41 ` Rob Herring
2011-11-16 15:41 ` Rob Herring
2011-11-16 18:18 ` Cousson, Benoit
2011-11-16 18:18 ` Cousson, Benoit
2011-11-17 7:31 ` Rajendra Nayak
2011-11-17 7:31 ` Rajendra Nayak
2011-11-16 15:01 ` Cousson, Benoit
2011-11-16 15:01 ` Cousson, Benoit
2011-11-17 7:19 ` Rajendra Nayak
2011-11-17 7:19 ` Rajendra Nayak
2011-11-17 9:52 ` Cousson, Benoit
2011-11-17 9:52 ` Cousson, Benoit
2011-11-17 10:16 ` Rajendra Nayak
2011-11-17 10:16 ` Rajendra Nayak
2011-11-16 11:02 ` [PATCH 2/3] omap-serial: Add minimal device tree support Rajendra Nayak
2011-11-16 11:02 ` Rajendra Nayak
2011-11-16 14:59 ` Rob Herring
2011-11-16 14:59 ` Rob Herring
2011-11-17 8:39 ` Rajendra Nayak
2011-11-17 8:39 ` Rajendra Nayak
2011-11-16 11:02 ` [PATCH 3/3] ARM: omap: pass minimal SoC/board data for UART from dt Rajendra Nayak
2011-11-16 11:02 ` Rajendra Nayak
2011-11-17 1:04 ` Rob Herring
2011-11-17 1:04 ` Rob Herring
2011-11-17 8:42 ` Rajendra Nayak
2011-11-17 8:42 ` Rajendra Nayak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EC3CDC4.7000108@gmail.com \
--to=robherring2@gmail.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=govindraj.raja@ti.com \
--cc=khilman@ti.com \
--cc=linaro-dev@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=rnayak@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.