From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v6 06/36] nds32: Kernel booting and initialization Date: Mon, 22 Jan 2018 10:53:07 +0100 Message-ID: References: <5930d2df872116555cc553284b6c111dce29e298.1515766253.git.green.hu@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Greentime Hu Cc: Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , Vincent Chen , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren List-Id: linux-arch.vger.kernel.org On Mon, Jan 22, 2018 at 10:49 AM, Greentime Hu wrote: > 2018-01-20 0:41 GMT+08:00 Arnd Bergmann : >>> This implementation is referenced from openrisc. >>> https://lkml.org/lkml/2017/11/17/228 >> >> It's correct on openrisc, because that has a reliable cycle counter, >> and that gets used in its delay function: >> >> void __delay(unsigned long cycles) >> { >> cycles_t start = get_cycles(); >> while ((get_cycles() - start) < cycles) >> cpu_relax(); >> } >> >> In my review comment that you cited, I assumed that nds32 had similar >> hardware. >> >> However, as you explained earlier, the nds32 architecture does not provide >> a cycle counter and the clocksource resolution is not high enough to >> be a good replacement, so you have to use the traditional delay >> calibration. >> > > Hi, Arnd: > > Thank you for your explanation. > Will it be ok if I code it like this? > > config GENERIC_CALIBRATE_DELAY > def_bool y Yes, I think that should be sufficient. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f68.google.com ([209.85.218.68]:44272 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbeAVJxK (ORCPT ); Mon, 22 Jan 2018 04:53:10 -0500 MIME-Version: 1.0 In-Reply-To: References: <5930d2df872116555cc553284b6c111dce29e298.1515766253.git.green.hu@gmail.com> From: Arnd Bergmann Date: Mon, 22 Jan 2018 10:53:07 +0100 Message-ID: Subject: Re: [PATCH v6 06/36] nds32: Kernel booting and initialization Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Greentime Hu Cc: Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , Vincent Chen , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren , Randy Dunlap , David Miller , Jonas Bonn , Stefan Kristiansson , Stafford Horne , Vincent Chen Message-ID: <20180122095307.ffe2BU1SCv89EToHOhcELqwEII4R5ZeWqK_bGbMiFVE@z> On Mon, Jan 22, 2018 at 10:49 AM, Greentime Hu wrote: > 2018-01-20 0:41 GMT+08:00 Arnd Bergmann : >>> This implementation is referenced from openrisc. >>> https://lkml.org/lkml/2017/11/17/228 >> >> It's correct on openrisc, because that has a reliable cycle counter, >> and that gets used in its delay function: >> >> void __delay(unsigned long cycles) >> { >> cycles_t start = get_cycles(); >> while ((get_cycles() - start) < cycles) >> cpu_relax(); >> } >> >> In my review comment that you cited, I assumed that nds32 had similar >> hardware. >> >> However, as you explained earlier, the nds32 architecture does not provide >> a cycle counter and the clocksource resolution is not high enough to >> be a good replacement, so you have to use the traditional delay >> calibration. >> > > Hi, Arnd: > > Thank you for your explanation. > Will it be ok if I code it like this? > > config GENERIC_CALIBRATE_DELAY > def_bool y Yes, I think that should be sufficient. Arnd