Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751837AbbB0JPQ (ORCPT ); Fri, 27 Feb 2015 04:15:16 -0500 Received: from mout.kundenserver.de ([212.227.126.187]:58480 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750752AbbB0JPM (ORCPT ); Fri, 27 Feb 2015 04:15:12 -0500 From: Arnd Bergmann To: Scott Branden Cc: bcm-kernel-feedback-list@broadcom.com, Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Matt Mackall , Herbert Xu , Grant Likely , Ray Jui , Jonathan Richardson , Dmitry Torokhov , Anatol Pomazao , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver Date: Fri, 27 Feb 2015 10:14:22 +0100 Message-ID: <2093191.gujNGSl66k@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <54EF9D7A.3090707@broadcom.com> References: <1424888184-22180-3-git-send-email-sbranden@broadcom.com> <4488852.TuVxKbAYde@wuerfel> <54EF9D7A.3090707@broadcom.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:esWaoqlmZczVw7mo8WFQQzZ9SAplOcD0VOyPJc4oi/eeI98CQFM z7ZypRu+KMwKOe+nbUITJZhk2ntdbtbnUNpMYnSEo0aou1zY1hF45tpMHb/B2ZxqwsACqYY RHUs5XU/nKTOKEZWXmMjyXKAX+DNxHwchGpXoTODsZo1uIAQwM8QCV14IH6twwA0vYkt+WL lohAkeTwEwsR683p4XcfA== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1740 Lines: 39 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/