From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-1458762-1516614613-2-4107850462816944271 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, FREEMAIL_FROM 0.001, RCVD_IN_DNSWL_NONE -0.0001, RCVD_IN_MSPIKE_H3 -0.01, RCVD_IN_MSPIKE_WL -0.01, SPF_PASS -0.001, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.85.217.194', Host='mail-ua0-f194.google.com', Country='US', FromHeader='com', MailFrom='com' X-Spam-charsets: plain='UTF-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: green.hu@gmail.com ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516614613; b=QLjZlbnpNvB9/d0NWMU6z6J+d0nz463OLc4XQh1rb5aGWzd O6gzRndxfhVL1gn+Y32jELWwN/97TxpqEw2LIgba61HBBMAs2FjFuCBoVJIBkuCd O325SXedZEKjNSK1HYoRWjFmCykVgBAs2ZtzaD9S3DOeQbssITL3fUcrwhL3FQE4 UrVh5bPai4CnT+uYpujR3b2no47LGhfk7wGMTrBay761PbE4xaTkgWurFU0pC6rW OUk/0gLnP+uLPOYum+ABD2ecx4mlsPhiONOtld456YchRT5AQoEamGKPPp6EaGVS K0yJGhe2lZVRSDG0C+BpihuB1wrKvtL1ArBxF4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=mime-version:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; s=arctest; t= 1516614613; bh=AsT5ULeTkvAhbpr6mVKfzhAbxzlqt77kqchHj3kh1j0=; b=N gbPvS+O5iQXdXHkjjZtPOPaLrILhUZdYau8dm9LikYE/Vz+/NkW3gK8LuFeAdPLo 0B1n91SwgRE0C0LFhu61pB+qSjOh1wdAN1455+ivicbL0u0WPZNKayILA34twlaF iOk0HmjRmZj+zhYBBrKyLTU3wKUQqYR8veXn80ZiACwLXElrn1Pq1ROHtOUD2J5K M7qnBAWe8N8+GIIEy9vJJpVX6FlUHpye0zMPp9hUlIw58RpDfky/moz+0L7AAsST hSYV6EQJ4y6kEGORzLIVjMqAwrYonNbgvQM+5b0ko+dcchW/IdlagC77hCKT864J n03eeU+SEdGDB7hHq20Fg== ARC-Authentication-Results: i=1; mx2.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=LGA1Wm+g x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,d=none) header.from=gmail.com; iprev=pass policy.iprev=209.85.217.194 (mail-ua0-f194.google.com); spf=pass smtp.mailfrom=green.hu@gmail.com smtp.helo=mail-ua0-f194.google.com; x-aligned-from=pass; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=XztchWeA; x-ptr=pass x-ptr-helo=mail-ua0-f194.google.com x-ptr-lookup=mail-ua0-f194.google.com; x-return-mx=pass smtp.domain=gmail.com smtp.result=pass smtp_is_org_domain=yes header.domain=gmail.com header.result=pass header_is_org_domain=yes; x-tls=pass version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 Authentication-Results: mx2.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=LGA1Wm+g x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,d=none) header.from=gmail.com; iprev=pass policy.iprev=209.85.217.194 (mail-ua0-f194.google.com); spf=pass smtp.mailfrom=green.hu@gmail.com smtp.helo=mail-ua0-f194.google.com; x-aligned-from=pass; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=XztchWeA; x-ptr=pass x-ptr-helo=mail-ua0-f194.google.com x-ptr-lookup=mail-ua0-f194.google.com; x-return-mx=pass smtp.domain=gmail.com smtp.result=pass smtp_is_org_domain=yes header.domain=gmail.com header.result=pass header_is_org_domain=yes; x-tls=pass version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 X-Google-Smtp-Source: AH8x227EniR6tLF/H2voCu5p8cHTx9a+/RWdWvH2Vk2vttTDUvoCe3mZCYsJLm7v8t/fodLAGjENg5mODZ/S5USJETc= MIME-Version: 1.0 In-Reply-To: References: <5930d2df872116555cc553284b6c111dce29e298.1515766253.git.green.hu@gmail.com> From: Greentime Hu Date: Mon, 22 Jan 2018 17:49:30 +0800 Message-ID: Subject: Re: [PATCH v6 06/36] nds32: Kernel booting and initialization To: Arnd Bergmann 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 Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 2018-01-20 0:41 GMT+08:00 Arnd Bergmann : > On Fri, Jan 19, 2018 at 5:34 PM, Greentime Hu wrote: >> Hi, Arnd: >> >> 2018-01-18 18:11 GMT+08:00 Arnd Bergmann : >>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu wrote: >>> >>> I had not looked at this patch in enough detail earlier, sorry about >>> that. It should be >>> easy enough to fix though. >>> >>>> +#ifdef CONFIG_VGA_CONSOLE >>>> +struct screen_info screen_info; >>>> +#endif >>> >>> I would assume that you can't ever have a VGA console. Just drop all >>> the references >>> here and instead send a patch to the fbdev maintainer to add the dependency >>> at CONFIG_VGA_CONSOLE to prevent selecting it with nds32. >> >> I found it can be built pass for now because we disable it in defconfig. >> Should I send the patch in v7 series? > > yes, I think that would be best. > >>>> + >>>> +extern void __init early_init_devtree(void *params); >>>> +extern void __init early_trap_init(void); >>> >>> similarly, these are declared in include/linux/of_fdt.h >>> >> >> early_trap_init is a nds32 function. I will move it to nds32.h > > Right, makes sense. > >>>> +void calibrate_delay(void) >>>> +{ >>>> + const int *val; >>>> + struct device_node *cpu = NULL; >>>> + cpu = of_find_compatible_node(NULL, NULL, "andestech,nds32v3"); >>>> + val = of_get_property(cpu, "clock-frequency", NULL); >>>> + if (!val || !*val) >>>> + panic("no cpu 'clock-frequency' parameter in device tree"); >>>> + loops_per_jiffy = be32_to_cpup(val) / HZ; >>>> + pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n", >>>> + loops_per_jiffy / (500000 / HZ), >>>> + (loops_per_jiffy / (5000 / HZ)) % 100, loops_per_jiffy); >>>> +} >>> >>> This seems very odd to me: The 'clock-frequency' property in the >>> cpu node should refer to the actual frequency it is running at, but that >>> tends to be different from the bogomips as needed by the ndelay() >>> function. Can you explain what is going on here? >>> >> >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greentime Hu Subject: Re: [PATCH v6 06/36] nds32: Kernel booting and initialization Date: Mon, 22 Jan 2018 17:49:30 +0800 Message-ID: References: <5930d2df872116555cc553284b6c111dce29e298.1515766253.git.green.hu@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org 2018-01-20 0:41 GMT+08:00 Arnd Bergmann : > On Fri, Jan 19, 2018 at 5:34 PM, Greentime Hu wrote: >> Hi, Arnd: >> >> 2018-01-18 18:11 GMT+08:00 Arnd Bergmann : >>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu wrote: >>> >>> I had not looked at this patch in enough detail earlier, sorry about >>> that. It should be >>> easy enough to fix though. >>> >>>> +#ifdef CONFIG_VGA_CONSOLE >>>> +struct screen_info screen_info; >>>> +#endif >>> >>> I would assume that you can't ever have a VGA console. Just drop all >>> the references >>> here and instead send a patch to the fbdev maintainer to add the dependency >>> at CONFIG_VGA_CONSOLE to prevent selecting it with nds32. >> >> I found it can be built pass for now because we disable it in defconfig. >> Should I send the patch in v7 series? > > yes, I think that would be best. > >>>> + >>>> +extern void __init early_init_devtree(void *params); >>>> +extern void __init early_trap_init(void); >>> >>> similarly, these are declared in include/linux/of_fdt.h >>> >> >> early_trap_init is a nds32 function. I will move it to nds32.h > > Right, makes sense. > >>>> +void calibrate_delay(void) >>>> +{ >>>> + const int *val; >>>> + struct device_node *cpu = NULL; >>>> + cpu = of_find_compatible_node(NULL, NULL, "andestech,nds32v3"); >>>> + val = of_get_property(cpu, "clock-frequency", NULL); >>>> + if (!val || !*val) >>>> + panic("no cpu 'clock-frequency' parameter in device tree"); >>>> + loops_per_jiffy = be32_to_cpup(val) / HZ; >>>> + pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n", >>>> + loops_per_jiffy / (500000 / HZ), >>>> + (loops_per_jiffy / (5000 / HZ)) % 100, loops_per_jiffy); >>>> +} >>> >>> This seems very odd to me: The 'clock-frequency' property in the >>> cpu node should refer to the actual frequency it is running at, but that >>> tends to be different from the bogomips as needed by the ndelay() >>> function. Can you explain what is going on here? >>> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greentime Hu Subject: Re: [PATCH v6 06/36] nds32: Kernel booting and initialization Date: Mon, 22 Jan 2018 17:49:30 +0800 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: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Arnd Bergmann 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren List-Id: devicetree@vger.kernel.org 2018-01-20 0:41 GMT+08:00 Arnd Bergmann : > On Fri, Jan 19, 2018 at 5:34 PM, Greentime Hu wrote: >> Hi, Arnd: >> >> 2018-01-18 18:11 GMT+08:00 Arnd Bergmann : >>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu wrote: >>> >>> I had not looked at this patch in enough detail earlier, sorry about >>> that. It should be >>> easy enough to fix though. >>> >>>> +#ifdef CONFIG_VGA_CONSOLE >>>> +struct screen_info screen_info; >>>> +#endif >>> >>> I would assume that you can't ever have a VGA console. Just drop all >>> the references >>> here and instead send a patch to the fbdev maintainer to add the dependency >>> at CONFIG_VGA_CONSOLE to prevent selecting it with nds32. >> >> I found it can be built pass for now because we disable it in defconfig. >> Should I send the patch in v7 series? > > yes, I think that would be best. > >>>> + >>>> +extern void __init early_init_devtree(void *params); >>>> +extern void __init early_trap_init(void); >>> >>> similarly, these are declared in include/linux/of_fdt.h >>> >> >> early_trap_init is a nds32 function. I will move it to nds32.h > > Right, makes sense. > >>>> +void calibrate_delay(void) >>>> +{ >>>> + const int *val; >>>> + struct device_node *cpu = NULL; >>>> + cpu = of_find_compatible_node(NULL, NULL, "andestech,nds32v3"); >>>> + val = of_get_property(cpu, "clock-frequency", NULL); >>>> + if (!val || !*val) >>>> + panic("no cpu 'clock-frequency' parameter in device tree"); >>>> + loops_per_jiffy = be32_to_cpup(val) / HZ; >>>> + pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n", >>>> + loops_per_jiffy / (500000 / HZ), >>>> + (loops_per_jiffy / (5000 / HZ)) % 100, loops_per_jiffy); >>>> +} >>> >>> This seems very odd to me: The 'clock-frequency' property in the >>> cpu node should refer to the actual frequency it is running at, but that >>> tends to be different from the bogomips as needed by the ndelay() >>> function. Can you explain what is going on here? >>> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html