From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932474AbbLHDFQ (ORCPT ); Mon, 7 Dec 2015 22:05:16 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:11224 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932267AbbLHDFO (ORCPT ); Mon, 7 Dec 2015 22:05:14 -0500 Subject: Re: [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc To: Arnd Bergmann References: <1449110565-23590-1-git-send-email-xuejiancheng@huawei.com> <43938749.Z0h4RNddN6@wuerfel> <56652E06.10309@huawei.com> <2329688.AAaHl8K2Zb@wuerfel> <56663897.7040901@huawei.com> CC: , , , , , , , , , , , , , From: xuejiancheng Message-ID: <56664878.8040805@huawei.com> Date: Tue, 8 Dec 2015 11:03:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56663897.7040901@huawei.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.217.211] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.56664885.0087,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0446608e898c03ab887aef8e43d1ee2b Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/12/8 9:55, xuejiancheng wrote: > > > On 2015/12/7 17:46, Arnd Bergmann wrote: >> On Monday 07 December 2015 14:58:14 xuejiancheng wrote: >>> On 2015/12/5 5:54, Arnd Bergmann wrote: >>>> On Friday 04 December 2015 12:07:58 xuejiancheng wrote: >>>>> On 2015/12/3 17:40, Arnd Bergmann wrote: >>>>>> On Thursday 03 December 2015 10:42:45 Jiancheng Xue wrote: >>>>>>> --- a/arch/arm/mach-hisi/Kconfig >>>>>>> +++ b/arch/arm/mach-hisi/Kconfig >>>>>>> @@ -12,6 +12,14 @@ if ARCH_HISI >>>>>>> >>>>>>> menu "Hisilicon platform type" >>>>>>> >>>>>>> +config ARCH_HI3519 >>>>>>> + bool "Hisilicon Hi3519 Soc" if ARCH_MULTI_V7 >>>>>>> + select HAVE_ARM_ARCH_TIMER >>>>>>> + select ARCH_HAS_RESET_CONTROLLER >>>>>>> + >>>>>>> + help >>>>>>> + Support for Hisilicon Hi3519 Soc >>>>>>> + >>>>>>> config ARCH_HI3xxx >>>>>>> bool "Hisilicon Hi36xx family" if ARCH_MULTI_V7 >>>>>>> select CACHE_L2X0 >>>>>> >>>>>> Do those need to be separate? I would just extend the Hi36xx >>>>>> to cover all Hi3xxx, if nothing in the platform code really >>>>>> depends on this. >>>>> >>>>> For HI3519, there is really no special platform code. But HI35xx and HI36xx soc families >>>>> belong to different product lines in hisilicon. HI35xx family also composes of various >>>>> architectures socs(single core, smp and big-little). So I think it may be clear to have >>>>> separate arch definitions. >>>>> >>>>> Could you give me more suggestions about this? Thank you! >>>> >>>> For the most part, you already need to enable the device drivers for the >>>> specific components on each chip, and the per-soc top-level options here >>>> don't actually control the compilation of any particular code. >>>> >>>> This is slightly different for some of the older platforms that for historic >>>> reasons need fine-grained options. You could probably just make the device >>>> drivers depend on "ARCH_HISI || COMPILE_TEST" in general, but some level >>>> of classification is ok, in particular when the chips are not related at all. >>>> >>>> In this case, my impression is that while HI3519 and HI36xx are made >>>> by different business units, there is still a noticeable amount of shared >>>> IP in them (e.g. the "sysctrl" node that seems to be shared with some of >>>> the other chips as well), so grouping them together should make sense. >>> >>> HI35xx and HI36xx are designed totally independently, including IP selection. >>> The relation between HI35xx and HI36xx is just like the one between HI36xx >>> and HIP0x. In another word, HI35xx and HI36xx are not related except they all >>> belong to hisilicon. So I don't think it's proper to group them together. >>> >>> Is it OK if I drop ARCH_HI3519 and use ARCH_HISI directly? >> >> I think we should come up with a way to handle this in general for >> ARCH_HISI. It's not problem to have a couple of sub-options, but I'd >> rather not have one for each SoC because I'm sure that hisilicon has >> made dozens or possibly hundreds of ARM based SoCs that belong into >> a couple of families. > > Agree with you. > >> >> The individual selection of IP blocks is not that important, because >> those tend to just be generic device drivers that we can enable on >> any platform using the defconfig files. >> >> You said that ARCH_HI3519 and HIP04 have an identical system controller, >> but it's different for Hi36xx, correct? > > No. The system controller of HI3519 is also different from HIP04. Maybe I gave you > wrong descriptions. Sorry about that. > >> >> So maybe we can generalize the HIP04 option to include all chips with >> that system controller as they appear to share a common ancestry regardless >> of the target market? >> > > I agree that we generalize some options regardless of the product line and target market. > >> The Hi35xx family includes some rather older chips as well based on ARM9 >> etc, correct? Are they closely related to the new one as well, or do they >> just share the name? > > Yes. It's correct. They may share some IP blocks. But they may be very different > from the new one for the arch code. I also don't think it's a good idea to make > them share the same name. I will use ARCH_HISI instead of ARCH_HI3519. > >> >> Arnd >> >> . >>