Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1301393

Re: [PATCH v3 1/3] clocksource/vt8500: Increase the minimum delta

From Russell King - ARM Linux <linux@arm.linux.org.uk>
Newsgroups linux.kernel
Subject Re: [PATCH v3 1/3] clocksource/vt8500: Increase the minimum delta
Date 2016-01-05 11:10 +0100
Message-ID <qNwIX-Cq-23@gated-at.bofh.it> (permalink)
References <qM85Y-31n-7@gated-at.bofh.it> <qM85Y-31n-13@gated-at.bofh.it> <qNvMS-8om-5@gated-at.bofh.it> <qNwpA-eM-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Jan 05, 2016 at 12:42:42PM +0300, Roman Volkov wrote:
> Why multiply by two? Good question. Maybe there is a reserve for
> stability. The value passed by the system to the set_next_event() should
> be not lesser than this value, and theoretically, we should not
> multiply MIN_OSCR_DELTA by two. As I can see, in many drivers there is
> no such minimal values at all.

It's a speciality of the StrongARM/PXA hardware.  It takes a certain
number of OSCR cycles for the value written to hit the compare registers.
So, if a very small delta is written (eg, the compare register is written
with a value of OSCR + 1), the OSCR will have incremented past this value
before it hits the underlying hardware.  The result is, that you end up
waiting a very long time for the OSCR to wrap before the event fires.

So, we introduce a check in set_next_event() to detect this and return
-ETIME if the calculated delta is too small, which causes the generic
clockevents code to retry after adding the min_delta specified in
clockevents_config_and_register() to the current time value.

min_delta must be sufficient that we don't re-trip the -ETIME check - if
we do, we will return -ETIME, forward the next event time, try to set it,
return -ETIME again, and basically lock the system up.  So, min_delta
must be larger than the check inside set_next_event().  A factor of two
was chosen to ensure that this situation would never occur.

The PXA code worked on PXA systems for years, and I'd suggest no one
changes this mechanism without access to a wide range of PXA systems,
otherwise they're risking breakage.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v3 1/3] clocksource/vt8500: Increase the minimum delta Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-05 10:10 +0100
  Re: [PATCH v3 1/3] clocksource/vt8500: Increase the minimum delta Roman Volkov <v1ron@mail.ru> - 2016-01-05 10:50 +0100
    Re: [PATCH v3 1/3] clocksource/vt8500: Increase the minimum delta Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-01-05 11:10 +0100
      Re: [PATCH v3 1/3] clocksource/vt8500: Increase the minimum delta Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-05 11:40 +0100
        Re: [PATCH v3 1/3] clocksource/vt8500: Increase the minimum delta Roman Volkov <v1ron@mail.ru> - 2016-01-05 12:20 +0100
    Re: [PATCH v3 1/3] clocksource/vt8500: Increase the minimum delta Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-05 11:20 +0100

csiph-web