[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2093191.gujNGSl66k@wuerfel>
Date: Fri, 27 Feb 2015 10:14:22 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Scott Branden <sbranden@...adcom.com>
Cc: bcm-kernel-feedback-list@...adcom.com,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Matt Mackall <mpm@...enic.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Grant Likely <grant.likely@...aro.org>,
Ray Jui <rjui@...adcom.com>,
Jonathan Richardson <jonathar@...adcom.com>,
Dmitry Torokhov <dtor@...gle.com>,
Anatol Pomazao <anatol@...gle.com>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver
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.
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists