All of lore.kernel.org
 help / color / mirror / Atom feed
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/5] clockevents: decouple broadcast mechanism from drivers
Date: Fri, 21 Dec 2012 15:38:02 +0530	[thread overview]
Message-ID: <50D43502.1070402@ti.com> (raw)
In-Reply-To: <1355832418-31692-1-git-send-email-mark.rutland@arm.com>

Mark,

On Tuesday 18 December 2012 05:36 PM, Mark Rutland wrote:
> In some SMP systems, cpu-local timers may stop delivering interrupts
> when in low power states, or not all CPUs may have local timers. To
> support these systems we have a mechanism for broadcasting timer ticks
> to other CPUs. This mechanism relies on the struct
> clock_event_device::broadcast function pointer, which is a
> driver-specific mechanism for broadcasting ticks to other CPUs.
>
> As the broadcast mechanism is architecture-specific, placing the
> broadcast function on struct clock_event_device ties each driver to a
> single architecture. Additionally the driver or architecture backend
> must handle the routing of broadcast ticks to the correct
> clock_event_device, leading to duplication of the list of active
> clock_event_devices.
>
> These patches introduce a generic mechanism for handling the receipt of
> timer broadcasts, and an optional architecture-specific broadcast
> function which allows drivers to be decoupled from a particular
> architecture will retaining support for timer tick broadcasts. These
> mechanisms are wired up for the arm port, and have been boot-tested on a
> pandaboard.
>
Apart from the relevant comments given against couple of patches and
Stephen's printk string comment, the series looks pretty good to me.

I have tested the series with CPUIdle where the broadcast is actually
used actively.

So feel free to add,
Reviewed-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: <linux-kernel@vger.kernel.org>, <linux@arm.linux.org.uk>,
	<nico@linaro.org>, <marc.zyngier@arm.com>, <will.deacon@arm.com>,
	<john.stultz@linaro.org>, <tglx@linutronix.de>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 0/5] clockevents: decouple broadcast mechanism from drivers
Date: Fri, 21 Dec 2012 15:38:02 +0530	[thread overview]
Message-ID: <50D43502.1070402@ti.com> (raw)
In-Reply-To: <1355832418-31692-1-git-send-email-mark.rutland@arm.com>

Mark,

On Tuesday 18 December 2012 05:36 PM, Mark Rutland wrote:
> In some SMP systems, cpu-local timers may stop delivering interrupts
> when in low power states, or not all CPUs may have local timers. To
> support these systems we have a mechanism for broadcasting timer ticks
> to other CPUs. This mechanism relies on the struct
> clock_event_device::broadcast function pointer, which is a
> driver-specific mechanism for broadcasting ticks to other CPUs.
>
> As the broadcast mechanism is architecture-specific, placing the
> broadcast function on struct clock_event_device ties each driver to a
> single architecture. Additionally the driver or architecture backend
> must handle the routing of broadcast ticks to the correct
> clock_event_device, leading to duplication of the list of active
> clock_event_devices.
>
> These patches introduce a generic mechanism for handling the receipt of
> timer broadcasts, and an optional architecture-specific broadcast
> function which allows drivers to be decoupled from a particular
> architecture will retaining support for timer tick broadcasts. These
> mechanisms are wired up for the arm port, and have been boot-tested on a
> pandaboard.
>
Apart from the relevant comments given against couple of patches and
Stephen's printk string comment, the series looks pretty good to me.

I have tested the series with CPUIdle where the broadcast is actually
used actively.

So feel free to add,
Reviewed-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>


  parent reply	other threads:[~2012-12-21 10:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-18 12:06 [RFC PATCH 0/5] clockevents: decouple broadcast mechanism from drivers Mark Rutland
2012-12-18 12:06 ` Mark Rutland
2012-12-18 12:06 ` [RFC PATCH 1/5] ARM: remove useless guard in smp.c Mark Rutland
2012-12-18 12:06   ` Mark Rutland
2012-12-18 18:47   ` Stephen Boyd
2012-12-18 18:47     ` Stephen Boyd
2012-12-19  9:40     ` Mark Rutland
2012-12-19  9:40       ` Mark Rutland
2012-12-21 10:02   ` Santosh Shilimkar
2012-12-21 10:02     ` Santosh Shilimkar
2013-01-02 11:14     ` Mark Rutland
2013-01-02 11:14       ` Mark Rutland
2012-12-18 12:06 ` [RFC PATCH 2/5] clockevents: Add generic timer broadcast receiver Mark Rutland
2012-12-18 12:06   ` Mark Rutland
2012-12-18 22:17   ` Stephen Boyd
2012-12-18 22:17     ` Stephen Boyd
2012-12-19 10:19     ` Mark Rutland
2012-12-19 10:19       ` Mark Rutland
2012-12-21 10:02   ` Santosh Shilimkar
2012-12-21 10:02     ` Santosh Shilimkar
2013-01-02 10:59     ` Mark Rutland
2013-01-02 10:59       ` Mark Rutland
2012-12-18 12:06 ` [RFC PATCH 3/5] ARM: Use generic timer broadcast receive Mark Rutland
2012-12-18 12:06   ` Mark Rutland
2012-12-18 12:06 ` [RFC PATCH 4/5] clockevents: Add generic timer broadcast function Mark Rutland
2012-12-18 12:06   ` Mark Rutland
2012-12-18 22:17   ` Stephen Boyd
2012-12-18 22:17     ` Stephen Boyd
2012-12-19 10:37     ` Mark Rutland
2012-12-19 10:37       ` Mark Rutland
2012-12-18 12:06 ` [RFC PATCH 5/5] ARM: Add generic timer broadcast support Mark Rutland
2012-12-18 12:06   ` Mark Rutland
2012-12-21 10:08 ` Santosh Shilimkar [this message]
2012-12-21 10:08   ` [RFC PATCH 0/5] clockevents: decouple broadcast mechanism from drivers Santosh Shilimkar
2013-01-02 11:41   ` Mark Rutland
2013-01-02 11:41     ` Mark Rutland

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=50D43502.1070402@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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.