Subject: Re: [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc
To: Arnd Bergmann <arnd@arndb.de>
References: <1449110565-23590-1-git-send-email-xuejiancheng@huawei.com>
 <43938749.Z0h4RNddN6@wuerfel> <56652E06.10309@huawei.com>
 <2329688.AAaHl8K2Zb@wuerfel>
CC: <linux-arm-kernel@lists.infradead.org>, <linux@arm.linux.org.uk>,
        <khilman@linaro.org>, <olof@lixom.net>, <xuwei5@hisilicon.com>,
        <haojian.zhuang@linaro.org>, <zhangfei.gao@linaro.org>,
        <bintian.wang@huawei.com>, <suwenping@hisilicon.com>,
        <linux-kernel@vger.kernel.org>, <yanhaifeng@hisilicon.com>,
        <gaofei@hisilicon.com>, <ml.yang@hisilicon.com>,
        <yanghongwei@hisilicon.com>
From: xuejiancheng <xuejiancheng@huawei.com>
Message-ID: <56663897.7040901@huawei.com>
Date: Tue, 8 Dec 2015 09:55:35 +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: <2329688.AAaHl8K2Zb@wuerfel>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4322
Lines: 104


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.

> 
> 	Arnd
> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/