From: Kevin Hilman <khilman@ti.com>
To: "Govindraj.R" <govindraj.raja@ti.com>
Cc: linux-omap@vger.kernel.org, Paul Walmsley <paul@pwsan.com>,
Tony Lindgren <tony@atomide.com>, Partha Basak <p-basak2@ti.com>,
linux-serial@vger.kernel.org,
Vishwanath Sripathy <vishwanath.bs@ti.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 04/11] OMAP2+: UART: Remove uart clock handling code from serial.c
Date: Thu, 08 Sep 2011 16:39:21 -0700 [thread overview]
Message-ID: <87pqja61ue.fsf@ti.com> (raw)
In-Reply-To: <1315400013-4849-5-git-send-email-govindraj.raja@ti.com> (Govindraj R.'s message of "Wed, 7 Sep 2011 18:23:26 +0530")
"Govindraj.R" <govindraj.raja@ti.com> writes:
> Cleanup serial.c file in preparation to addition of runtime API's in omap-serial
> file. Remove all clock handling mechanism as this will be taken care with
> pm runtime API's in omap-serial.c file itself.
>
> 1.) Remove omap-device enable and disable. We can can use get_sync/put_sync API's
> 2.) Remove context save/restore can be done with runtime_resume callback for
> get_sync call. No need to save context as all reg details available in
> uart_port structure can be used for restore, so add missing regs in
> uart port struct.
> 3.) Add func to identify console uart.
I don't see that as part of this patch.
> 4.) Erratum handling informed as flag to driver and func to handle erratum
> can be moved to omap-serial driver itself.
OK, but I see two erratum flags removed, but only flag added back.
Also, the erratum handling is completely removed here and not added to
the driver.
In general, this way of moving things makes it very difficult to review.
You remove a bunch of things in this patch (and the previous one) and
imply that some of it is added back to the driver. However, that's
really difficult to verify with patch review.
If code is being moved, it is customary to remove it and add it to the
new place in the same patch.
> Acked-by: Alan Cox <alan@linux.intel.com>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
> ---
> arch/arm/mach-omap2/serial.c | 742 ++-----------------------
> arch/arm/plat-omap/include/plat/omap-serial.h | 11 +-
> 2 files changed, 53 insertions(+), 700 deletions(-)
[...]
> -static DEVICE_ATTR(sleep_timeout, 0644, sleep_timeout_show,
> - sleep_timeout_store);
> -#define DEV_CREATE_FILE(dev, attr) WARN_ON(device_create_file(dev, attr))
> -#else
> -static inline void omap_uart_idle_init(struct omap_uart_state *uart) {}
> -static void omap_uart_block_sleep(struct omap_uart_state *uart)
> +struct omap_hwmod *omap_uart_hwmod_lookup(int num)
function should be static
[...]
> + for (i = 0; i < OMAP_MAX_HSUART_PORTS; i++) {
> + oh = omap_uart_hwmod_lookup(i);
> if (!oh)
> - break;
> -
> - uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
> - if (WARN_ON(!uart))
> - return -ENODEV;
> -
> - uart->oh = oh;
> - uart->num = i++;
> - list_add_tail(&uart->node, &uart_list);
> - num_uarts++;
> -
> - /*
> - * NOTE: omap_hwmod_setup*() has not yet been called,
> - * so no hwmod functions will work yet.
> - */
> -
> - /*
> - * 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 | HWMOD_INIT_NO_RESET;
> - } while (1);
> + continue;
>
> + oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
With proper runtime PM in the driver, I did not expect these to be
needed any longer by the end of the series, but I see they are still
there. Are they really needed?
[...]
> @@ -864,15 +213,14 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
> */
> void __init omap_serial_init(void)
> {
> - struct omap_uart_state *uart;
> struct omap_board_data bdata;
> + u8 i;
>
> - list_for_each_entry(uart, &uart_list, node) {
> - bdata.id = uart->num;
> + for (i = 0; i < OMAP_MAX_HSUART_PORTS; i++) {
This should probably use the hwmod class iterator.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 04/11] OMAP2+: UART: Remove uart clock handling code from serial.c
Date: Thu, 08 Sep 2011 16:39:21 -0700 [thread overview]
Message-ID: <87pqja61ue.fsf@ti.com> (raw)
In-Reply-To: <1315400013-4849-5-git-send-email-govindraj.raja@ti.com> (Govindraj R.'s message of "Wed, 7 Sep 2011 18:23:26 +0530")
"Govindraj.R" <govindraj.raja@ti.com> writes:
> Cleanup serial.c file in preparation to addition of runtime API's in omap-serial
> file. Remove all clock handling mechanism as this will be taken care with
> pm runtime API's in omap-serial.c file itself.
>
> 1.) Remove omap-device enable and disable. We can can use get_sync/put_sync API's
> 2.) Remove context save/restore can be done with runtime_resume callback for
> get_sync call. No need to save context as all reg details available in
> uart_port structure can be used for restore, so add missing regs in
> uart port struct.
> 3.) Add func to identify console uart.
I don't see that as part of this patch.
> 4.) Erratum handling informed as flag to driver and func to handle erratum
> can be moved to omap-serial driver itself.
OK, but I see two erratum flags removed, but only flag added back.
Also, the erratum handling is completely removed here and not added to
the driver.
In general, this way of moving things makes it very difficult to review.
You remove a bunch of things in this patch (and the previous one) and
imply that some of it is added back to the driver. However, that's
really difficult to verify with patch review.
If code is being moved, it is customary to remove it and add it to the
new place in the same patch.
> Acked-by: Alan Cox <alan@linux.intel.com>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
> ---
> arch/arm/mach-omap2/serial.c | 742 ++-----------------------
> arch/arm/plat-omap/include/plat/omap-serial.h | 11 +-
> 2 files changed, 53 insertions(+), 700 deletions(-)
[...]
> -static DEVICE_ATTR(sleep_timeout, 0644, sleep_timeout_show,
> - sleep_timeout_store);
> -#define DEV_CREATE_FILE(dev, attr) WARN_ON(device_create_file(dev, attr))
> -#else
> -static inline void omap_uart_idle_init(struct omap_uart_state *uart) {}
> -static void omap_uart_block_sleep(struct omap_uart_state *uart)
> +struct omap_hwmod *omap_uart_hwmod_lookup(int num)
function should be static
[...]
> + for (i = 0; i < OMAP_MAX_HSUART_PORTS; i++) {
> + oh = omap_uart_hwmod_lookup(i);
> if (!oh)
> - break;
> -
> - uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
> - if (WARN_ON(!uart))
> - return -ENODEV;
> -
> - uart->oh = oh;
> - uart->num = i++;
> - list_add_tail(&uart->node, &uart_list);
> - num_uarts++;
> -
> - /*
> - * NOTE: omap_hwmod_setup*() has not yet been called,
> - * so no hwmod functions will work yet.
> - */
> -
> - /*
> - * 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 | HWMOD_INIT_NO_RESET;
> - } while (1);
> + continue;
>
> + oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
With proper runtime PM in the driver, I did not expect these to be
needed any longer by the end of the series, but I see they are still
there. Are they really needed?
[...]
> @@ -864,15 +213,14 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
> */
> void __init omap_serial_init(void)
> {
> - struct omap_uart_state *uart;
> struct omap_board_data bdata;
> + u8 i;
>
> - list_for_each_entry(uart, &uart_list, node) {
> - bdata.id = uart->num;
> + for (i = 0; i < OMAP_MAX_HSUART_PORTS; i++) {
This should probably use the hwmod class iterator.
Kevin
next prev parent reply other threads:[~2011-09-08 23:39 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-07 12:53 [PATCH v4 00/11] OMAP2+: Serial: Runtime adaptation + cleanup Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-07 12:53 ` [PATCH v4 01/11] OMAP2+: hwmod: Add API to enable IO ring wakeup Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-07 12:53 ` [PATCH v4 02/11] OMAP2+: hwmod: Add API to check IO PAD wakeup status Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-07 12:53 ` [PATCH v4 03/11] OMAP2+: UART: cleanup + remove certain uart calls from pm code Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-07 12:53 ` [PATCH v4 04/11] OMAP2+: UART: Remove uart clock handling code from serial.c Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-08 23:39 ` Kevin Hilman [this message]
2011-09-08 23:39 ` Kevin Hilman
2011-09-09 5:22 ` Govindraj
2011-09-09 5:22 ` Govindraj
2011-09-07 12:53 ` [PATCH v4 05/11] OMAP2+: Serial: Add default mux for all uarts Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-07 12:53 ` [PATCH v4 06/11] Serial: OMAP: Store certain reg values to port structure Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-07 12:53 ` [PATCH v4 07/11] Serial: OMAP: Add runtime pm support for omap-serial driver Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-09 0:24 ` Kevin Hilman
2011-09-09 0:24 ` Kevin Hilman
2011-09-09 6:32 ` Govindraj
2011-09-09 6:32 ` Govindraj
2011-09-09 18:14 ` Kevin Hilman
2011-09-09 18:14 ` Kevin Hilman
2011-09-12 6:55 ` Govindraj
2011-09-12 6:55 ` Govindraj
2011-09-12 6:58 ` Govindraj
2011-09-12 6:58 ` Govindraj
2011-09-12 17:01 ` Kevin Hilman
2011-09-12 17:01 ` Kevin Hilman
2011-09-07 12:53 ` [PATCH v4 08/11] Serial: OMAP2+: Move erratum handling from serial.c Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-07 12:53 ` [PATCH v4 09/11] OMAP2+: Serial: Use prepare and resume calls to gate uart clocks Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-09 18:59 ` Kevin Hilman
2011-09-09 18:59 ` Kevin Hilman
2011-09-12 6:37 ` Govindraj
2011-09-12 6:37 ` Govindraj
2011-09-07 12:53 ` [PATCH v4 10/11] OMAP: Serial: Allow UART parameters to be configured from board file Govindraj.R
2011-09-07 12:53 ` Govindraj.R
2011-09-09 19:11 ` Kevin Hilman
2011-09-09 19:11 ` Kevin Hilman
2011-09-12 6:34 ` Govindraj
2011-09-12 6:34 ` Govindraj
2011-09-07 12:53 ` [PATCH v4 11/11] Serial: OMAP2+: Make the RX_TIMEOUT for DMA configurable for each UART Govindraj.R
2011-09-07 12:53 ` Govindraj.R
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=87pqja61ue.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=paul@pwsan.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.