Re: [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc

From: xuejiancheng
Date: Mon Dec 07 2015 - 22:06:03 EST




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
>>
>> .
>>

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