From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout
Date: Tue, 6 Oct 2015 21:51:22 +0100 [thread overview]
Message-ID: <20151006205122.GF17172@x1> (raw)
In-Reply-To: <20151006193757.GY21513@n2100.arm.linux.org.uk>
On Tue, 06 Oct 2015, Russell King - ARM Linux wrote:
> On Tue, Oct 06, 2015 at 03:44:00PM +0100, Lee Jones wrote:
> > Samples are documented to be available every 0.667us, so in theory
> > the 8 sample deep FIFO should take 5.336us to fill. However, during
> > thorough testing, it became apparent that filling the FIFO actually
> > takes closer to 12us.
>
> Is that measured?
I measured it using ktime. Hopefully that was adequate.
> > +/*
> > + * Samples are documented to be available every 0.667us, so in theory
> > + * the 8 sample deep FIFO should take 5.336us to fill. However, during
> > + * thorough testing, it became apparent that filling the FIFO actually
> > + * takes closer to 12us.
> > + */
> > +#define ST_RNG_FILL_FIFO_TIMEOUT 12
>
> I hope you're not using such a precise figure with udelay(). udelay()
> is not guaranteed to give exactly (or even at least) the delay you
> request. It's defined to give an approximate delay.
>
> Many people have a problem understanding that, so I won't explain why
> it is that way, just accept that it is and move on... it's not going
> to magically get "fixed" because someone has just learnt about this. :)
Thanks for the info. I did do testing, again using ktime, to make
sure and on our platform (is it platform specific?) I measured
udelay(1) to be ~1100ns. After moving to a 12us timeout and reading
many MBs of randomness I am yet to receive any more timeouts.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, peter@korsgaard.com,
kernel@stlinux.com, daniel.thompson@linaro.org,
pankaj.dev@st.com, festevam@gmail.com,
herbert@gondor.apana.org.au
Subject: Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout
Date: Tue, 6 Oct 2015 21:51:22 +0100 [thread overview]
Message-ID: <20151006205122.GF17172@x1> (raw)
In-Reply-To: <20151006193757.GY21513@n2100.arm.linux.org.uk>
On Tue, 06 Oct 2015, Russell King - ARM Linux wrote:
> On Tue, Oct 06, 2015 at 03:44:00PM +0100, Lee Jones wrote:
> > Samples are documented to be available every 0.667us, so in theory
> > the 8 sample deep FIFO should take 5.336us to fill. However, during
> > thorough testing, it became apparent that filling the FIFO actually
> > takes closer to 12us.
>
> Is that measured?
I measured it using ktime. Hopefully that was adequate.
> > +/*
> > + * Samples are documented to be available every 0.667us, so in theory
> > + * the 8 sample deep FIFO should take 5.336us to fill. However, during
> > + * thorough testing, it became apparent that filling the FIFO actually
> > + * takes closer to 12us.
> > + */
> > +#define ST_RNG_FILL_FIFO_TIMEOUT 12
>
> I hope you're not using such a precise figure with udelay(). udelay()
> is not guaranteed to give exactly (or even at least) the delay you
> request. It's defined to give an approximate delay.
>
> Many people have a problem understanding that, so I won't explain why
> it is that way, just accept that it is and move on... it's not going
> to magically get "fixed" because someone has just learnt about this. :)
Thanks for the info. I did do testing, again using ktime, to make
sure and on our platform (is it platform specific?) I measured
udelay(1) to be ~1100ns. After moving to a 12us timeout and reading
many MBs of randomness I am yet to receive any more timeouts.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2015-10-06 20:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-06 14:43 [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Lee Jones
2015-10-06 14:43 ` Lee Jones
2015-10-06 14:43 ` [PATCH 2/3] hwrng: st: Report correct FIFO size Lee Jones
2015-10-06 14:43 ` Lee Jones
2015-10-06 15:48 ` Daniel Thompson
2015-10-06 15:48 ` Daniel Thompson
2015-10-06 15:23 ` Lee Jones
2015-10-06 15:23 ` Lee Jones
2015-10-06 14:44 ` [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Lee Jones
2015-10-06 14:44 ` Lee Jones
2015-10-06 19:37 ` Russell King - ARM Linux
2015-10-06 19:37 ` Russell King - ARM Linux
2015-10-06 20:51 ` Lee Jones [this message]
2015-10-06 20:51 ` Lee Jones
2015-10-06 20:56 ` Russell King - ARM Linux
2015-10-06 20:56 ` Russell King - ARM Linux
2015-10-07 7:53 ` Lee Jones
2015-10-07 7:53 ` Lee Jones
2015-10-06 15:24 ` [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Herbert Xu
2015-10-06 15:24 ` Herbert Xu
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=20151006205122.GF17172@x1 \
--to=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.