From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc
Date: Wed, 09 Dec 2015 16:32:11 +0100 [thread overview]
Message-ID: <4297924.YW2IR8MmHA@wuerfel> (raw)
In-Reply-To: <56664878.8040805@huawei.com>
On Tuesday 08 December 2015 11:03:20 xuejiancheng wrote:
> >>
> >> 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.
>
>
Do you mean you want to remove the other options as well?
We should do this consistently at least within the Kconfig file.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: xuejiancheng <xuejiancheng@huawei.com>
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
Subject: Re: [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc
Date: Wed, 09 Dec 2015 16:32:11 +0100 [thread overview]
Message-ID: <4297924.YW2IR8MmHA@wuerfel> (raw)
In-Reply-To: <56664878.8040805@huawei.com>
On Tuesday 08 December 2015 11:03:20 xuejiancheng wrote:
> >>
> >> 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.
>
>
Do you mean you want to remove the other options as well?
We should do this consistently at least within the Kconfig file.
Arnd
next prev parent reply other threads:[~2015-12-09 15:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 2:42 [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc Jiancheng Xue
2015-12-03 2:42 ` Jiancheng Xue
2015-12-03 9:40 ` Arnd Bergmann
2015-12-03 9:40 ` Arnd Bergmann
2015-12-04 4:07 ` xuejiancheng
2015-12-04 4:07 ` xuejiancheng
2015-12-04 21:54 ` Arnd Bergmann
2015-12-04 21:54 ` Arnd Bergmann
2015-12-07 6:58 ` xuejiancheng
2015-12-07 6:58 ` xuejiancheng
2015-12-07 9:46 ` Arnd Bergmann
2015-12-07 9:46 ` Arnd Bergmann
2015-12-08 1:55 ` xuejiancheng
2015-12-08 1:55 ` xuejiancheng
2015-12-08 3:03 ` xuejiancheng
2015-12-08 3:03 ` xuejiancheng
2015-12-09 15:32 ` Arnd Bergmann [this message]
2015-12-09 15:32 ` Arnd Bergmann
2015-12-10 6:13 ` xuejiancheng
2015-12-10 6:13 ` xuejiancheng
2015-12-10 8:25 ` Arnd Bergmann
2015-12-10 8:25 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4297924.YW2IR8MmHA@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.