All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Govindraj.R" <govindraj.raja@ti.com>
Cc: linux-omap@vger.kernel.org
Subject: Re: [pm-wip/uart][PATCH v3] Serial: Avoid using hwmod lookup using  name string
Date: Thu, 24 Jun 2010 15:33:29 -0700	[thread overview]
Message-ID: <87zkykxdqe.fsf@deeprootsystems.com> (raw)
In-Reply-To: <61551.192.168.10.88.1277384156.squirrel@dbdmail.itg.ti.com> (Govindraj R.'s message of "Thu, 24 Jun 2010 18:25:56 +0530 (IST)")

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

> Avoid using hwmod lookup using name string rather
> retreive port info using the hwmod class interface.
> Aviod populating uart_list in early init phase,
> leave the uart_list empty and keep the omap hwmod info
> in a seperate uart_oh list and if board file calls
> serial init use this uart_oh list info to fill uart_list.
>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
> ---
>  arch/arm/mach-omap2/serial.c |   90 ++++++++++++++++++++---------------------
>  1 files changed, 44 insertions(+), 46 deletions(-)

Hi Govindraj,

Thanks for this update.

> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 38a74d0..68cbd16 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -55,8 +55,6 @@
>   */
>  #define DEFAULT_TIMEOUT 0
>
> -#define MAX_UART_HWMOD_NAME_LEN		16
> -
>  struct omap_uart_state {
>  	int num;
>  	int can_sleep;
> @@ -96,6 +94,12 @@ struct omap_uart_state {
>  #endif
>  };
>
> +struct uart_oh {
> +	struct list_head node;
> +	struct omap_hwmod *oh;
> +};
> +
> +static LIST_HEAD(uart_oh_list);
>  static LIST_HEAD(uart_list);
>  static u8 num_uarts;
>
> @@ -568,52 +572,37 @@ static void serial_out_override(struct uart_port *up, int offset, int value)
>  }
>  #endif
>
> -void __init omap_serial_early_init(void)
> +static int omap_serial_port_init(struct omap_hwmod *oh, void *user)
>  {
> -	int i = 0;
> -
> -	do {
> -		char oh_name[MAX_UART_HWMOD_NAME_LEN];
> -		struct omap_hwmod *oh;
> -		struct omap_uart_state *uart;
> -
> -		snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN,
> -			 "uart%d", i + 1);
> -		oh = omap_hwmod_lookup(oh_name);
> -		if (!oh)
> -			break;
> -
> -		uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
> -		if (WARN_ON(!uart))
> -			return;
> -
> -		uart->oh = oh;
> -		uart->num = i++;
> -		list_add_tail(&uart->node, &uart_list);
> -		num_uarts++;
> -
> -		/*
> -		 * NOTE: omap_hwmod_init() has not yet been called,
> -		 *       so no hwmod functions will work yet.
> -		 */
> +	struct uart_oh *uoh;
>
> -		/*
> -		 * 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
> -		 */
> -		uart->oh->flags |= HWMOD_INIT_NO_IDLE;

Minor issue... in the current pm-wip/uart (just changed today), this
part has been removed, so please refresh this against current
pm-wip/uart. 

> -
> -		/*
> -		 * Since UART hwmod is idle/enabled inside the
> -		 * idle loop, interrupts are already disabled and
> -		 * thus no locking is needed.  Since the mutex-based
> -		 * locking in hwmod might sleep, allowing locking
> -		 * may introduce problems.
> -		 */
> -		uart->oh->flags |= HWMOD_NO_IDLE_LOCKING;
> +	uoh = kzalloc(sizeof(struct uart_oh), GFP_KERNEL);
> +	if (WARN_ON(!uoh))
> +		return -ENOMEM;
> +	/*
> +	 * 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
> +	 */
> +	oh->flags |= HWMOD_INIT_NO_IDLE;
> +	/*
> +	 * Since UART hwmod is idle/enabled inside the
> +	 * idle loop, interrupts are already disabled and
> +	 * thus no locking is needed.  Since the mutex-based
> +	 * locking in hwmod might sleep, allowing locking
> +	 * may introduce problems.
> +	 */
> +	oh->flags |= HWMOD_NO_IDLE_LOCKING;
> +	list_add_tail(&uoh->node, &uart_oh_list);
> +	uoh->oh = oh;
> +	num_uarts++;
> +	return 0;
> +}
>
> -	} while (1);
> +void __init omap_serial_early_init(void)
> +{
> +	omap_hwmod_for_each_by_class("uart",
> +		omap_serial_port_init, NULL);
>  }
>
>  /**
> @@ -769,7 +758,16 @@ void __init omap_serial_init_port(int port)
>  void __init omap_serial_init(void)
>  {
>  	struct omap_uart_state *uart;
> +	struct uart_oh *uoh;
> +	int i = 0;
>
> -	list_for_each_entry(uart, &uart_list, node)
> +	list_for_each_entry(uoh, &uart_oh_list, node) {
> +		uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
> +		if (WARN_ON(!uart))
> +			return;
> +		list_add_tail(&uart->node, &uart_list);
> +		uart->num = i++;
> +		uart->oh = uoh->oh;
>  		omap_serial_init_port(uart->num);
> +	}
>  }

This works if a board calls omap_serial_init(), but doesn't work if a
board only wants to init a single UART and calls omap_serial_init_port()
directly.

I think you have to move the kzalloc, list_add etc. into
omap_serial_init_port()

Then, you'll have to add a 'num' field to the 'struct uart_oh' so you
can call omap_serial_init_port() with a valid number.

If we have to add a number to 'struct uart_oh', then it makes more sense
(to me) to just keep the hwmod lookup by name, since knowing the UART
number is rather important in this case.

So maybe just leave the hwmod lookup by name, but fix the problems with
empty lists that this patch also addresses.

Kevin


  reply	other threads:[~2010-06-24 22:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-24 12:55 [pm-wip/uart][PATCH v3] Serial: Avoid using hwmod lookup using name string Govindraj.R
2010-06-24 22:33 ` Kevin Hilman [this message]
2010-06-25 13:41   ` [pm-wip/uart][PATCH] Serial: Avoid populating uart_list in early init phase Govindraj.R
2010-06-25 16:23     ` Kevin Hilman
2010-06-30 14:43       ` Govindraj
2010-06-26 16:08     ` DebBarma, Tarun Kanti
2010-06-28 12:18       ` Govindraj

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=87zkykxdqe.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=govindraj.raja@ti.com \
    --cc=linux-omap@vger.kernel.org \
    /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.