Hi,
I was wondering if there were any comments to this patch or if it was
picked up somewhere?
Thanks,
Dave
On Wed, May 14, 2014 at 3:30 PM, David Riley <[email protected]> wrote:
> This change adds a module and a script that makes use of it to
> validate that udelay delays for at least as long as requested
> (as compared to ktime).
>
> Changes since v1:
> - allow udelay() to be 0.5% faster than requested as per feedback
>
> David Riley (2):
> kernel: time: Add udelay_test module to validate udelay
> tools: add script to test udelay
>
> kernel/time/Kconfig | 7 ++
> kernel/time/Makefile | 1 +
> kernel/time/udelay_test.c | 169 +++++++++++++++++++++++++++++++++++++++++++++
> tools/time/udelay_test.sh | 66 ++++++++++++++++++
> 4 files changed, 243 insertions(+)
> create mode 100644 kernel/time/udelay_test.c
> create mode 100644 tools/time/udelay_test.sh
>
> --
> 1.7.9.5
>
On Mon, Jun 9, 2014 at 4:41 PM, David Riley <[email protected]> wrote:
> Hi,
>
> I was wondering if there were any comments to this patch or if it was
> picked up somewhere?
So I guess it got left in a bit of an ambiguous spot. The basic point
of this test is to verify there is a sane counter time-based delay on
freq shifting systems. You've addressed my only false positive
concern, and so I'm not opposed to including it.
However, there was the following discussion of why this test was
wanted, and that was due to a system that didn't have a counter time
based delay (instead using the loop delay) which was running into
problems with cpufreq changes. That discussion wandered a bit, but the
consensus was "don't do that".
I sort of mixed the messages and associated that feedback with this
patch as well, so my apologies.
Just to be clear, it might be good to more clearly target this test as
a validation to ensure systems don't use those bad configs. So If you
want to resend with that extra context in the commit message, I'll go
ahead and queue it (looking at 3.17)
thanks
-john