LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: sudeep.holla@arm.com, tglx@linutronix.de
Cc: khilman@baylibre.com, linux-kernel@vger.kernel.org,
	fweisbec@gmail.com, arnd@arndb.de
Subject: Re: [PATCH] tick: prefer a lower rating device only if it's CPU local device
Date: Sun, 8 Jul 2018 22:59:13 +0200	[thread overview]
Message-ID: <CAFBinCBhBBK1TZnhH1bGrQP5SokaMNrk7C8OcMXaaTcR6_WOTg@mail.gmail.com> (raw)
In-Reply-To: <20180703164823.GB15335@e107155-lin>

Hi Thomas,

On Tue, Jul 3, 2018 at 6:48 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Hi Thomas,
>
> On Tue, Jul 03, 2018 at 06:08:19PM +0200, Thomas Gleixner wrote:
>
> [...]
>
> > > > / # cat /sys/devices/system/clockevents/broadcast/current_device
> > > > meson6_tick
> > >
> > > OK, it can support broadcast
> > >
> > > > / # cat /sys/devices/system/clockevents/clockevent0/current_device
> > > > dummy_timer
> > > > / # cat /sys/devices/system/clockevents/clockevent1/current_device
> > > > dummy_timer
> > > > / # cat /sys/devices/system/clockevents/clockevent2/current_device
> > > > dummy_timer
> > >
> > > But I can't understand why is dummy_timer the active event source and
> > > not meson6_tick. And you say this is working case ? Looks suspicious.
> >
> > Because if it switches to broadcast mode then the meson timer cannot longer
> > be used as per cpu timer. It's broadcasting to all CPUs via the dummy timer.
>
> Thanks for the explanation. I completely misread the sysfs entry and
> assume clockevent_register failed for meson6 and hence regarded as
> suspicious which is complete non-sense, my bad. Sorry for that.
> I think I now understand the issue.
>
> 1. Juno usecase for which $subject was added as fix:
>
> Two system wide timers(cpumask=possible cpus) with rating 300 and 400.
> When second one with 400 is added, timer with rating 300 is added to
> released list and again added back to main one. In this case both were
> chosen as preferred and that resulted in deadlock.
>
> 2. Meson6 usecase:
>
> When meson6_tick is added, it's set as preferred and dummy_timer is released.
> When it's being added back from the released list, it will be chosen as
> preferred as it's per_cpu resulting in deadlock.
>
> I am not sure how to fix this. Should the fix to my original problem have
> checks for both old and new for per-cpu  to prevent the issue reported on
> Meson6
could you please answer Sudeep's question?

in the meantime I checked Sudpeed's suggestion regarding the TWD
timer: it seems that the Meson8 (Cortex-A9) and Meson8b (Cortex-A5)
SoCs have the ARM TWD (timer watchdog) built-in - Carlo sent a patch
for this a long time ago: [0].
however, I figured out that this doesn't work out-of-the-box anymore:
the TWD seems to be supplied (according to my own tests) by CPU_CLK
div 16 and the interrupt should be IRQ_TYPE_EDGE_RISING
unfortunately we cannot simply add the TWD timer to Meson8 or Meson8b
because this would first require changes to the clock controller
driver (the are currently registered as platform driver, which is too
late for the TWD timer driver)

in other words: we cannot use the TWD timer on the Meson platform in
the v4.18 cycle, so I would prefer a fix of the timer/tick code


Regards
Martin


[0] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/391928.html

  reply	other threads:[~2018-07-08 20:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 16:02 Sudeep Holla
2018-05-13 13:09 ` [tip:timers/core] tick: Prefer " tip-bot for Sudeep Holla
2018-07-02 23:44 ` [PATCH] tick: prefer " Kevin Hilman
2018-07-03 10:53   ` Sudeep Holla
2018-07-03 15:04     ` Kevin Hilman
2018-07-03 15:44       ` Sudeep Holla
2018-07-03 16:08         ` Thomas Gleixner
2018-07-03 16:48           ` Sudeep Holla
2018-07-08 20:59             ` Martin Blumenstingl [this message]
2018-07-09 15:12               ` Sudeep Holla

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=CAFBinCBhBBK1TZnhH1bGrQP5SokaMNrk7C8OcMXaaTcR6_WOTg@mail.gmail.com \
    --to=martin.blumenstingl@googlemail.com \
    --cc=arnd@arndb.de \
    --cc=fweisbec@gmail.com \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH] tick: prefer a lower rating device only if it'\''s CPU local device' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).