[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEbi=3dNwRU0aVqDdHDmmQD=RHCcnOcf2+kik80ZnvrGJ8x-kg@mail.gmail.com>
Date: Fri, 17 Nov 2017 20:39:33 +0800
From: Greentime Hu <green.hu@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Greentime <greentime@...estech.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Marc Zyngier <marc.zyngier@....com>,
Rob Herring <robh+dt@...nel.org>,
Networking <netdev@...r.kernel.org>,
Vincent Chen <vincentc@...estech.com>
Subject: Re: [PATCH 26/31] nds32: Build infrastructure
2017-11-10 16:26 GMT+08:00 Greentime Hu <green.hu@...il.com>:
> 2017-11-09 18:33 GMT+08:00 Arnd Bergmann <arnd@...db.de>:
>> On Thu, Nov 9, 2017 at 10:02 AM, Greentime Hu <green.hu@...il.com> wrote:
>>> 2017-11-08 18:16 GMT+08:00 Arnd Bergmann <arnd@...db.de>:
>>>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@...il.com> wrote:
>>
>>>>> +config GENERIC_CALIBRATE_DELAY
>>>>> + def_bool y
>>>>
>>>> It's better to avoid the delay loop completely and skip the calibration,
>>>> if your hardware allows.
>>>
>>> Thanks.
>>> Do you mean that this config should be def_bool n?
>>> why? Almost all arch enable it.
>>
>> It depends on what your hardware can do. If you have a way to see how much
>> time has passed that is guaranteed to be reliable on all machines, then
>> use that instead.
>>
>> On a lot of architectures, it's not possible, so they have to fall back to using
>> the delay loop.
>
> I get it. I will discuss it with our HW colleagues.
> We may get these informations in some registers.
Hi, Arnd:
I think I can't set it to default n because it will be called in start_kernel.
start_kernel() -> calibrate_delay()
If I don't enable this config, it will link error because it didn't
build init/calibrate.c
Powered by blists - more mailing lists