All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: "Govindraj.R" <govindraj.raja@ti.com>
Cc: linux-omap@vger.kernel.org, linux-serial@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Tony Lindgren <tony@atomide.com>, Partha Basak <p-basak2@ti.com>,
	Vishwanath Sripathy <vishwanath.bs@ti.com>,
	Rajendra Nayak <rnayak@ti.com>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>
Subject: Re: [PATCH v6 15/16] OMAP2+: UART: Enable back uart clocks with runtime API for early console
Date: Tue, 11 Oct 2011 14:06:16 -0700	[thread overview]
Message-ID: <87pqi3z19z.fsf@ti.com> (raw)
In-Reply-To: <1317380561-661-6-git-send-email-govindraj.raja@ti.com> (Govindraj R.'s message of "Fri, 30 Sep 2011 16:32:40 +0530")

"Govindraj.R" <govindraj.raja@ti.com> writes:

> For the early console probing we had avoided hwmod reset and idling
> and uart was idled using hwmod API and enabled back using omap_device API
> after omap_device registration.
>
> Now since we are using runtime API's to enable back uart, move hwmod
> idling and use runtime API to enable back UART.
>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>

Now that the driver is using runtime PM.  Why do we still need
HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET?

The comment in the code says:

		/*
		 * During UART early init, device need to be probed
		 * to determine SoC specific init before omap_device
		 * is ready.  Therefore, don't allow idle here
		 */

This was true when using the 8250 driver because it was not using
runtime PM so could not know how to (re)enable the device.

However, since the driver is now runtime PM adapted, any device access
should be contained within a runtime PM get/put block, so there should
no longer be a reason not allow the IP blocks to be reset during boot.

Kevin


WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 15/16] OMAP2+: UART: Enable back uart clocks with runtime API for early console
Date: Tue, 11 Oct 2011 14:06:16 -0700	[thread overview]
Message-ID: <87pqi3z19z.fsf@ti.com> (raw)
In-Reply-To: <1317380561-661-6-git-send-email-govindraj.raja@ti.com> (Govindraj R.'s message of "Fri, 30 Sep 2011 16:32:40 +0530")

"Govindraj.R" <govindraj.raja@ti.com> writes:

> For the early console probing we had avoided hwmod reset and idling
> and uart was idled using hwmod API and enabled back using omap_device API
> after omap_device registration.
>
> Now since we are using runtime API's to enable back uart, move hwmod
> idling and use runtime API to enable back UART.
>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>

Now that the driver is using runtime PM.  Why do we still need
HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET?

The comment in the code says:

		/*
		 * During UART early init, device need to be probed
		 * to determine SoC specific init before omap_device
		 * is ready.  Therefore, don't allow idle here
		 */

This was true when using the 8250 driver because it was not using
runtime PM so could not know how to (re)enable the device.

However, since the driver is now runtime PM adapted, any device access
should be contained within a runtime PM get/put block, so there should
no longer be a reason not allow the IP blocks to be reset during boot.

Kevin

  reply	other threads:[~2011-10-11 21:06 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-30 11:02 [PATCH v6 10/16] OMAP2+: UART: Modify omap_uart_can_sleep function Govindraj.R
2011-09-30 11:02 ` Govindraj.R
2011-09-30 11:02 ` [PATCH v6 11/16] OMAP2+: UART: Move errata handling from serial.c to omap-serial Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 21:01   ` Kevin Hilman
2011-10-11 21:01     ` Kevin Hilman
2011-10-12 10:43     ` Govindraj
2011-10-12 10:43       ` Govindraj
2011-09-30 11:02 ` [PATCH v6 12/16] OMAP2+: UART: Allow UART parameters to be configured from board file Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 18:53   ` Kevin Hilman
2011-10-11 18:53     ` Kevin Hilman
2011-10-12 10:44     ` Govindraj
2011-10-12 10:44       ` Govindraj
2011-09-30 11:02 ` [PATCH v6 13/16] OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-09-30 11:02 ` [PATCH v6 14/16] OMAP2+: UART: Take console_lock in suspend path if not taken Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 19:01   ` Kevin Hilman
2011-10-11 19:01     ` Kevin Hilman
2011-10-12 11:23     ` Govindraj
2011-10-12 11:23       ` Govindraj
2011-10-12 23:47       ` Kevin Hilman
2011-10-12 23:47         ` Kevin Hilman
2011-10-13  1:11         ` Govindraj
2011-10-13  1:11           ` Govindraj
2011-09-30 11:02 ` [PATCH v6 15/16] OMAP2+: UART: Enable back uart clocks with runtime API for early console Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 21:06   ` Kevin Hilman [this message]
2011-10-11 21:06     ` Kevin Hilman
2011-10-12 14:04     ` Govindraj
2011-10-12 14:04       ` Govindraj
2011-10-13  0:00       ` Kevin Hilman
2011-10-13  0:00         ` Kevin Hilman
2011-10-13  1:22         ` Govindraj
2011-10-13  1:22           ` Govindraj
2011-10-13 21:01           ` Kevin Hilman
2011-10-13 21:01             ` Kevin Hilman
2011-10-14 14:18             ` Govindraj
2011-10-14 14:18               ` Govindraj
2011-10-14 17:12               ` Kevin Hilman
2011-10-14 17:12                 ` Kevin Hilman
2011-09-30 11:02 ` [PATCH v6 16/16] OMAP2+: UART: Do not gate uart clocks if used for debug_prints Govindraj.R
2011-09-30 11:02   ` Govindraj.R
2011-10-11 18:24 ` [PATCH v6 10/16] OMAP2+: UART: Modify omap_uart_can_sleep function Kevin Hilman
2011-10-11 18:24   ` Kevin Hilman
2011-10-12 13:38   ` Govindraj
2011-10-12 13:38     ` Govindraj
2011-10-12 19:41     ` Kevin Hilman
2011-10-12 19:41       ` Kevin Hilman
2011-10-13  1:09       ` Govindraj
2011-10-13  1:09         ` Govindraj
2011-10-13  6:59         ` Jean Pihet
2011-10-13  6:59           ` Jean Pihet

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=87pqi3z19z.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=govindraj.raja@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=p-basak2@ti.com \
    --cc=rnayak@ti.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=tony@atomide.com \
    --cc=vishwanath.bs@ti.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.