From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752065AbcEQRms (ORCPT ); Tue, 17 May 2016 13:42:48 -0400 Received: from mail-bn1bon0114.outbound.protection.outlook.com ([157.56.111.114]:51662 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751918AbcEQRmq convert rfc822-to-8bit (ORCPT ); Tue, 17 May 2016 13:42:46 -0400 From: Hartley Sweeten To: Ian Abbott , "devel@driverdev.osuosl.org" CC: Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH 14/14] staging: comedi: daqboard2000: prefer usleep_range() Thread-Topic: [PATCH 14/14] staging: comedi: daqboard2000: prefer usleep_range() Thread-Index: AQHRsCH5yOuEWYFB4EW1HibJRB6UYp+9ZP4g Date: Tue, 17 May 2016 17:42:38 +0000 Message-ID: References: <1463478773-5916-1-git-send-email-abbotti@mev.co.uk> <1463478773-5916-15-git-send-email-abbotti@mev.co.uk> In-Reply-To: <1463478773-5916-15-git-send-email-abbotti@mev.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mev.co.uk; dkim=none (message not signed) header.d=none;mev.co.uk; dmarc=none action=none header.from=visionengravers.com; x-originating-ip: [184.183.19.121] x-ms-office365-filtering-correlation-id: 552477cd-64e9-44f6-60be-08d37e7aa3ac x-microsoft-exchange-diagnostics: 1;CO2PR01MB2086;5:OOC3/ltEkDOFkO9GapT0TKwTDSNbN9/qo8BdclAOLXwCG8fMZLHPpySbRRqAWqwNQCdWuc+Hs288tGRs0p4KWCGR2FQDShyEUrnn750S0sL2si9iP+EV4bGIAlT3Il8WDjl/WqV0/LXG1E20VbjEyw==;24:NrbAMTEvhF8Zd8ziIWMOJJiAG3aKJF/CBa7E4UWmP/Jb7JJCmLoDey7oO3ZDnlHlRLc1j/qY4KA+64kHmF/IMUG7arLoLgJOcDfQwRg4tlw=;7:D0tiaOggI9Wbd9rnf7ztHL0qTqpPudeuhlNFftk4gz7msytqDYTmf9jLvkV6UU5JiCSvbkYmPn5A+JKYZvsPeuzvU+XL8h6mOaBjB2X9W9eP3L02UXKie6SUlGm0txgVU2y1++FyeBr5JqXcOeYFam+j8d+/nTI2qVH/Jd9VeaGTertqZMSX8fcnByjp1eE/ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR01MB2086; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040130)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:CO2PR01MB2086;BCL:0;PCL:0;RULEID:;SRVR:CO2PR01MB2086; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(24454002)(377454003)(5004730100002)(2906002)(6116002)(3846002)(1220700001)(102836003)(66066001)(586003)(5008740100001)(4326007)(9686002)(87936001)(74316001)(11100500001)(106116001)(33656002)(2900100001)(86362001)(92566002)(5003600100002)(2950100001)(50986999)(54356999)(76176999)(122556002)(77096005)(81166006)(8676002)(189998001)(8936002)(80792005)(2501003)(5002640100001)(10400500002)(19580395003)(5001770100001);DIR:OUT;SFP:1102;SCL:1;SRVR:CO2PR01MB2086;H:CO2PR01MB2088.prod.exchangelabs.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: visionengravers.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 17:42:38.3964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d698601f-af92-4269-8099-fd6f11636477 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR01MB2086 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, May 17, 2016 2:53 AM, Ian Abbott wrote: > The checkpatch.pl warns about two `udelay(x)` calls, one of 100 > microseconds, and one of 10 microseconds. The 100 microseconds one is > used when waiting for FPGA to become ready to accept firmware, and is > not that critical, so replace it with a call to `usleep_range(100, > 1000)`. The 10 microseconds one is called as each 16-bit word of > firmware data is written. A longer sleep would slow down firmware > loading, so leave it alone. The firmware blob in comedi-nonfree-firmware/daqboard2000 is 41236 bytes or 20618 words. With the 10 microsecond delay for each word to total delay time is only 0.0206 seconds. I don't think a small usleep_range() would slow down the firmware loading by much. How about usleep_range(10, 20)? Regards, Hartley