2017-11-17 20:50 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: > On Fri, Nov 17, 2017 at 1:39 PM, Greentime Hu <green.hu@xxxxxxxxx> wrote: >> 2017-11-10 16:26 GMT+08:00 Greentime Hu <green.hu@xxxxxxxxx>: >>> 2017-11-09 18:33 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: >>>> On Thu, Nov 9, 2017 at 10:02 AM, Greentime Hu <green.hu@xxxxxxxxx> wrote: >>>>> 2017-11-08 18:16 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: >>>>>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@xxxxxxxxx> 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 > > You will have to provide an architecture-specific implementation of > this function, please ahve a look at what others are doing, e.g. tile, > openrisc or > h8300. Thanks. I got you.
