2017-11-29 19:57 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: > On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu <green.hu@xxxxxxxxx> wrote: >> 2017-11-29 17:25 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: >>> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven >>> <geert@xxxxxxxxxxxxxx> wrote: >>>> Hi Arnd, >>>> >>>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >>>>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@xxxxxxxxx> wrote: >>>>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: >>>>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@xxxxxxxxx> wrote: >>>>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu >>>>>>>> +config CPU_CACHE_NONALIASING >>>>>>>> + bool "Non-aliasing cache" >>>>>>>> + help >>>>>>>> + If this CPU is using VIPT data cache and its cache way size is larger >>>>>>>> + than page size, say N. If it is using PIPT data cache, say Y. >>>>>>>> + >>>>>>>> + If unsure, say Y. >>>>>>> >>>>>>> Can you determine this from the CPU type? >>>>>> >>>>>> There is no cpu register to determine it. It also depeneds on page >>>>>> size and way size however page size is configurable by software. >>>>>> These codes are determined at compile time will be benefit to code >>>>>> size and performance. >>>>>> IMHO, I think it would be better to be determined here. >>>>> >>>>> I meant determining it at compile time from other Kconfig symbols, >>>>> if that's possible. Do the CPU cores each have a fixed way-size? >>>>> If they do, it could be done like >>>>> >>>>> menu "CPU selection" >>>>> >>>>> config CPU_N15 >>>>> bool "AndesCore N15" >>>>> select CPU_CACHE_NONALIASING >>>>> >>>>> config CPU_N13 >>>>> bool "AndesCore N15" >>>>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K >>>>> >>>>> ... >>>>> >>>>> endmenu >>>>> >>>>> and then you can use the same CPU_... symbols to make other decisions >>>>> as well, e.g. CPU specific compiler optimizations. >>>> >>>> Do you want to support multiple CPU types in a single kernel image >>>> (I see no "choice" statement above)? >>>> If yes, you may have a mix of aliasing and non-aliasing caches, so >>>> you may want to invert the logic, and select CPU_CACHE_ALIASING >>>> instead. >>> >>> Right, my mistake. >>> >> >> Thanks to Arnd and Geert! >> >> How about this? >> >> choice >> prompt "CPU type" >> default CPU_N13 >> config CPU_N15 >> bool "AndesCore N15" >> select CPU_CACHE_NONALIASING >> config CPU_N13 >> bool "AndesCore N13" >> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB >> config CPU_N10 >> bool "AndesCore N10" >> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB >> config CPU_D15 >> bool "AndesCore D15" >> select CPU_CACHE_NONALIASING >> select HWZOL >> config CPU_D10 >> bool "AndesCore D10" >> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB >> endchoice > > With a 'choice' statement this works, but I would consider that > suboptimal for another reason: now you cannot build a kernel that > works on e.g. both N13 and N15. > > This is what we had on ARM a long time ago and on MIPS not so long > ago, but it's really a burden for testing and distribution once you get > support for more than a handful of machines supported in the mainline > kernel: If each CPU core is mutually incompatible with the other ones, > this means you likely end up having one defconfig per CPU core, > or even one defconfig per SoC or board. > > I would always try to get the largest amount of hardware to work > in the same kernel concurrently. > > One way of of this would be to define the "CPU type" as the minimum > supported CPU, e.g. selecting D15 would result in a kernel that > only works on D15, while selecting N15 would work on both N15 and > D15, and selecting D10 would work on both D10 and D15. > Hi, Arnd: Maybe we should keep the original implementation for this reason. The default value of CPU_CACHE_NONALIASING and ANDES_PAGE_SIZE_8KB is available for all CPU types for now. User can use these configs built kernel to boot on almost all nds32 CPUs. It might be a little bit weird if we config CPU_N10 but run on a N13 CPU. This might confuse our users. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
