All of lore.kernel.org
 help / color / mirror / Atom feed
From: john.stultz@linaro.org (John Stultz)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL]: clocksource: new material for 3.13
Date: Mon, 30 Sep 2013 10:49:32 -0700	[thread overview]
Message-ID: <5249B9AC.8050209@linaro.org> (raw)
In-Reply-To: <5249B7E2.5060201@linaro.org>

On 09/30/2013 10:41 AM, Daniel Lezcano wrote:
>
> Hi Thomas,
>
> this pull request is based on 3.12-rc3 with the following content:
>
>  - Miroslav improved the RTC update by increasing the interval
> acceptable for an update in the sync_cmos_clock workqueue callback
>
>  - Prarit added a missing function declaration to fix a compilation
> issue on x86. Please *note*, this patch is coming from a pull from
> John's tree, it would make sense to cherry-pick this fix into
> timers/urgent
>
>  - Soren added FEAT_PERCPU to a clock device when it is local per cpu.
> This feature prevents the clock framework to choose a per cpu timer as
> a broadcast timer. This problem arised when the ARM global timer is
> used which is the case now on Xillinx.
>
>  - Stephen extended the generic sched_clock code to support 64bit
> counters and removes the setup_sched_clock deprecation, as that causes
> lots of warnings since there's still users in the arch/arm tree.
>
>  - Will and Sudeep implemented the event stream for architected timer.
> The event streams can be used to impose a timeout on a wfe, to
> safeguard against any programming error in case an expected event is
> not generated or even to implement wfe-based timeouts for userspace
> locking implementations.
>
>  - Zoran prevents to enter suspend mode if there are pending RTC
> timers to be handled, avoiding these ones to be delayed as well as the
> subsequent possible time critical code tied with them.
>


Hey Daniel,
    So this looks like a strange pull request. You based it on 3.12-rc3
instead of the current tip/timers/core (which is what your submitting
this to). Unfortunately since the branch you pulled from me was based on
tip/timers/core, this pull request seems to be submitting items that are
already in tip/timers/core (like the changes from Prarit, Miroslav and
Zoran).

Does any of the changes here actually depend on 3.12-rc3? If not you
might just re-generate the branch against tip/timers/core, and you'll
end up with a much cleaner pull request.

thanks
-john

WARNING: multiple messages have this Message-ID (diff)
From: John Stultz <john.stultz@linaro.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>,
	mlichvar@redhat.com, prarit@redhat.com,
	Soren Brinkmann <soren.brinkmann@xilinx.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	zoran markovic <zoran.markovic@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [GIT PULL]: clocksource: new material for 3.13
Date: Mon, 30 Sep 2013 10:49:32 -0700	[thread overview]
Message-ID: <5249B9AC.8050209@linaro.org> (raw)
In-Reply-To: <5249B7E2.5060201@linaro.org>

On 09/30/2013 10:41 AM, Daniel Lezcano wrote:
>
> Hi Thomas,
>
> this pull request is based on 3.12-rc3 with the following content:
>
>  - Miroslav improved the RTC update by increasing the interval
> acceptable for an update in the sync_cmos_clock workqueue callback
>
>  - Prarit added a missing function declaration to fix a compilation
> issue on x86. Please *note*, this patch is coming from a pull from
> John's tree, it would make sense to cherry-pick this fix into
> timers/urgent
>
>  - Soren added FEAT_PERCPU to a clock device when it is local per cpu.
> This feature prevents the clock framework to choose a per cpu timer as
> a broadcast timer. This problem arised when the ARM global timer is
> used which is the case now on Xillinx.
>
>  - Stephen extended the generic sched_clock code to support 64bit
> counters and removes the setup_sched_clock deprecation, as that causes
> lots of warnings since there's still users in the arch/arm tree.
>
>  - Will and Sudeep implemented the event stream for architected timer.
> The event streams can be used to impose a timeout on a wfe, to
> safeguard against any programming error in case an expected event is
> not generated or even to implement wfe-based timeouts for userspace
> locking implementations.
>
>  - Zoran prevents to enter suspend mode if there are pending RTC
> timers to be handled, avoiding these ones to be delayed as well as the
> subsequent possible time critical code tied with them.
>


Hey Daniel,
    So this looks like a strange pull request. You based it on 3.12-rc3
instead of the current tip/timers/core (which is what your submitting
this to). Unfortunately since the branch you pulled from me was based on
tip/timers/core, this pull request seems to be submitting items that are
already in tip/timers/core (like the changes from Prarit, Miroslav and
Zoran).

Does any of the changes here actually depend on 3.12-rc3? If not you
might just re-generate the branch against tip/timers/core, and you'll
end up with a much cleaner pull request.

thanks
-john


  reply	other threads:[~2013-09-30 17:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-30 17:41 [GIT PULL]: clocksource: new material for 3.13 Daniel Lezcano
2013-09-30 17:41 ` Daniel Lezcano
2013-09-30 17:49 ` John Stultz [this message]
2013-09-30 17:49   ` John Stultz
2013-09-30 18:09   ` Daniel Lezcano
2013-09-30 18:09     ` Daniel Lezcano
2013-09-30 18:18     ` John Stultz
2013-09-30 18:18       ` John Stultz

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=5249B9AC.8050209@linaro.org \
    --to=john.stultz@linaro.org \
    --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.