On 15-02-27 01:14 AM, Arnd Bergmann wrote:
On Thursday 26 February 2015 14:26:02 Scott Branden wrote:
On 15-02-26 12:15 PM, Arnd Bergmann wrote:
On 15-02-25 11:17 AM, Arnd Bergmann wrote:
On Wednesday 25 February 2015 10:16:24 Scott Branden wrote:
This code was following examples of other open source drivers - bcm2835
and exynos both use cpu_relax. I'll have to look into this more to
understand.
The majority of the driver apparently use udelay(10) to wait, which is
not much better but at least consistent. The cpu_relax() call probably
gives better throughput.
I don't understand why none of the drivers actually attempts to
msleep(), but that may be because the delay is much too long.
Can you find out what the expected latency is for new data to
become available on your hardware?
RNG generates at a nominal 1 Mbps. So to generate 32 bits of data takes
approximately 32 us.
The udelay(10) that the other drivers have seems about appropriate then,
and we can independently think of a way to refine the interface.
Please add a comment that explains the rate. Also, is there some kind
of FIFO present in the hwrng device? If it can store close to 1ms work
of data (1000 bits), you can just use an msleep(1) to wait for the
pool to recover.
FIFO is 512 bits. I will look as to whether we can live with 1/2
throughput.
Another option would be to use usleep_range() with the exact amount
of time to wait for, the lower bound being the minimum number of
bytes asked for and the fifo size, the upper bound being the fifo
size.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
