From: mingo@kernel.org (Ingo Molnar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] clockevents: Manage device's state separately for core
Date: Tue, 10 Mar 2015 14:05:41 +0100 [thread overview]
Message-ID: <20150310130541.GA26185@gmail.com> (raw)
In-Reply-To: <CAKohpok+bfVVm-6fW5+tJCOKQA+dY=8zHykdyJEcUNbgGQyrcQ@mail.gmail.com>
* Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 27 February 2015 at 17:21, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > Hi Thomas/Ingo,
> >
> > This is in response to the suggestions Ingo gave [1] on the shortcomings of
> > clockevents core's state machine.
> >
> > This first separates out the RESUME functionality from other states as its a
> > special case. Then it defines a new enum to map possible states of a clockevent
> > device.
> >
> > Ideally it should only be available for the core, but as bL switcher is using it
> > today, it is exposed in clockchips.h. That dependency will go away after
> > applying the Thomas's work (Sent out be Peter) and then we can move this enum to
> > somewhere in kernel/time/.
> >
> > The last patch moves the legacy check to the legacy code.
> >
> > Please see if this meets your expectation or if you have some suggestions on it.
> >
> > Rebased of tip/master as there were some dependencies:
> > 575daeea39a3 Merge branch 'tools/kvm'
> >
> > This along with migration of few clockevents drivers is pushed here:
> > git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git clkevt/manage-state
> >
> > --
> > Viresh
> >
> > [1] https://lkml.org/lkml/2015/2/20/107
> >
> > Viresh Kumar (3):
> > clockevents: Handle tick device's resume separately
> > clockevents: Manage device's state separately for the core
> > clockevents: Don't validate dev->mode against CLOCK_EVT_MODE_UNUSED
> > for new interface
>
> Ingo,
>
> Gentle reminder ping...
Yeah, so I'd like PeterZ to ACK/NAK this approach before I move
forward with the patches - but he's on the road right now, so it
will take a week I suspect.
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
Kevin Hilman <khilman@linaro.org>,
Preeti U Murthy <preeti@linux.vnet.ibm.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Linaro Networking <linaro-networking@linaro.org>
Subject: Re: [PATCH 0/3] clockevents: Manage device's state separately for core
Date: Tue, 10 Mar 2015 14:05:41 +0100 [thread overview]
Message-ID: <20150310130541.GA26185@gmail.com> (raw)
In-Reply-To: <CAKohpok+bfVVm-6fW5+tJCOKQA+dY=8zHykdyJEcUNbgGQyrcQ@mail.gmail.com>
* Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 27 February 2015 at 17:21, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > Hi Thomas/Ingo,
> >
> > This is in response to the suggestions Ingo gave [1] on the shortcomings of
> > clockevents core's state machine.
> >
> > This first separates out the RESUME functionality from other states as its a
> > special case. Then it defines a new enum to map possible states of a clockevent
> > device.
> >
> > Ideally it should only be available for the core, but as bL switcher is using it
> > today, it is exposed in clockchips.h. That dependency will go away after
> > applying the Thomas's work (Sent out be Peter) and then we can move this enum to
> > somewhere in kernel/time/.
> >
> > The last patch moves the legacy check to the legacy code.
> >
> > Please see if this meets your expectation or if you have some suggestions on it.
> >
> > Rebased of tip/master as there were some dependencies:
> > 575daeea39a3 Merge branch 'tools/kvm'
> >
> > This along with migration of few clockevents drivers is pushed here:
> > git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git clkevt/manage-state
> >
> > --
> > Viresh
> >
> > [1] https://lkml.org/lkml/2015/2/20/107
> >
> > Viresh Kumar (3):
> > clockevents: Handle tick device's resume separately
> > clockevents: Manage device's state separately for the core
> > clockevents: Don't validate dev->mode against CLOCK_EVT_MODE_UNUSED
> > for new interface
>
> Ingo,
>
> Gentle reminder ping...
Yeah, so I'd like PeterZ to ACK/NAK this approach before I move
forward with the patches - but he's on the road right now, so it
will take a week I suspect.
Thanks,
Ingo
next prev parent reply other threads:[~2015-03-10 13:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 11:51 [PATCH 0/3] clockevents: Manage device's state separately for core Viresh Kumar
2015-02-27 11:51 ` Viresh Kumar
2015-02-27 11:51 ` [PATCH 1/3] clockevents: Handle tick device's resume separately Viresh Kumar
2015-02-27 11:51 ` Viresh Kumar
2015-03-27 11:48 ` [tip:timers/core] clockevents: Handle tick device' s " tip-bot for Viresh Kumar
2015-02-27 11:51 ` [PATCH 2/3] clockevents: Manage device's state separately for the core Viresh Kumar
2015-02-27 11:51 ` Viresh Kumar
2015-03-27 11:48 ` [tip:timers/core] clockevents: Manage device' s " tip-bot for Viresh Kumar
2015-02-27 11:51 ` [PATCH 3/3] clockevents: Don't validate dev->mode against CLOCK_EVT_MODE_UNUSED for new interface Viresh Kumar
2015-02-27 11:51 ` Viresh Kumar
2015-03-27 11:49 ` [tip:timers/core] clockevents: Don't validate dev-> mode " tip-bot for Viresh Kumar
2015-03-10 10:34 ` [PATCH 0/3] clockevents: Manage device's state separately for core Viresh Kumar
2015-03-10 10:34 ` Viresh Kumar
2015-03-10 13:05 ` Ingo Molnar [this message]
2015-03-10 13:05 ` Ingo Molnar
2015-03-10 17:12 ` Peter Zijlstra
2015-03-10 17:12 ` Peter Zijlstra
2015-03-16 9:14 ` Viresh Kumar
2015-03-16 9:14 ` Viresh Kumar
2015-03-26 11:59 ` Viresh Kumar
2015-03-26 11:59 ` Viresh Kumar
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=20150310130541.GA26185@gmail.com \
--to=mingo@kernel.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.