Messages in this thread | | | Date | Fri, 21 Feb 2020 18:36:50 +0100 | From | Daniel Lezcano <> | Subject | Re: [PATCH v9 09/17] arm: tegra20: cpuidle: Handle case where secondary CPU hangs on entering LP2 |
| |
On Fri, Feb 21, 2020 at 07:56:51PM +0300, Dmitry Osipenko wrote: > Hello Daniel, > > 21.02.2020 18:43, Daniel Lezcano пишет: > > On Thu, Feb 13, 2020 at 02:51:26AM +0300, Dmitry Osipenko wrote: > >> It is possible that something may go wrong with the secondary CPU, in that > >> case it is much nicer to get a dump of the flow-controller state before > >> hanging machine. > >> > >> Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> > >> Tested-by: Peter Geis <pgwipeout@gmail.com> > >> Tested-by: Jasper Korten <jja2000@gmail.com> > >> Tested-by: David Heidelberg <david@ixit.cz> > >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > >> ---
[ ... ]
> >> +static int tegra20_wait_for_secondary_cpu_parking(void) > >> +{ > >> + unsigned int retries = 3; > >> + > >> + while (retries--) { > >> + ktime_t timeout = ktime_add_ms(ktime_get(), 500); > > > > Oops I missed this one. Do not use ktime_get() in this code path, use jiffies. > > Could you please explain what benefits jiffies have over the ktime_get()?
ktime_get() is very slow, jiffies is updated every tick.
> >> + > >> + /* > >> + * The primary CPU0 core shall wait for the secondaries > >> + * shutdown in order to power-off CPU's cluster safely. > >> + * The timeout value depends on the current CPU frequency, > >> + * it takes about 40-150us in average and over 1000us in > >> + * a worst case scenario. > >> + */ > >> + do { > >> + if (tegra_cpu_rail_off_ready()) > >> + return 0; > >> + > >> + } while (ktime_before(ktime_get(), timeout)); > > > > So this loop will aggresively call tegra_cpu_rail_off_ready() and retry 3 > > times. The tegra_cpu_rail_off_ready() function can be called thoushand of times > > here but the function will hang 1.5s :/ > > > > I suggest something like: > > > > while (retries--i && !tegra_cpu_rail_off_ready()) > > udelay(100); > > > > So <retries> calls to tegra_cpu_rail_off_ready() and 100us x <retries> maximum > > impact. > But udelay() also results into CPU spinning in a busy-loop, and thus, > what's the difference?
busy looping instead of register reads with all the hardware things involved behind.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
| |