[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210527115530.GC22019@willie-the-truck>
Date: Thu, 27 May 2021 12:55:30 +0100
From: Will Deacon <will@...nel.org>
To: Xin Hao <xhao@...ux.alibaba.com>
Cc: fweisbec@...il.com, john.stultz@...aro.org,
kernel-team@...roid.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, lorenzo@...gle.com, maz@...nel.org,
mika.penttila@...tfour.com, sboyd@...nel.org, tglx@...utronix.de
Subject: Re: [PATCH v2 2/5] tick/broadcast: Split
__tick_broadcast_oneshot_control() into a helper
On Thu, May 27, 2021 at 07:35:03PM +0800, Xin Hao wrote:
>
> 在 2021/5/27 下午4:22, Will Deacon 写道:
> > On Thu, May 27, 2021 at 03:23:06PM +0800, Xin Hao wrote:
> > > I had backport you tick/broadcast: Prefer per-cpu relatives patches,
> > >
> > > but i did not get the true result, the Wakeup Devices are all null, why?
> > Probably because you don't have any suitable per-cpu timers to act as a
> > wakeup. Do you have a per-cpu timer registered with CLOCK_EVT_FEAT_PERCPU
>
> Yes, you are right, but i want to know why the timer do not support
> CLOCK_EVT_FEAT_PERCPU.
I suspect there may be drivers with the feature missing simply because it
wasn't really used for much until now (I think it just prevented use for
broadcast). However, before adding that to a timer, you do need to make
sure that it really is banked per-cpu (or at least handles racing accesses)
as well as having the per-cpu irq.
Will
Powered by blists - more mailing lists