From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Icenowy Zheng <icenowy@aosc.io>
Cc: Chen-Yu Tsai <wens@csie.org>,
Russell King <linux@armlinux.org.uk>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Linus Walleij <linus.walleij@linaro.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-sunxi@googlegroups.com
Subject: Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC
Date: Mon, 22 Jan 2018 13:14:35 +0100 [thread overview]
Message-ID: <20180122121435.bpayxk4uzfqbhqse@flea.lan> (raw)
In-Reply-To: <20180119231735.61504-1-icenowy@aosc.io>
[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]
On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
>
> The same die is packaged differently, come with different co-packaged
> DRAM or shipped with different SDK; and then made many model names: F23,
> F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> share a common feature set and are packaged similarly (eLQFP128 for SoCs
> without co-packaged DRAM, QFN88 for with DRAM). As their's no
> functionality hidden on the QFN88 models (except DRAM interface not
> exported), it's not clever to differentiate them. So I will use suniv as
> common name of all these SoCs.
Where is that suniv prefix coming from?
And you need to have a SoC in all your compatibles. This isn't about
being clever or not, this is just a matter of being able to accurately
read in a crystal ball. Or maybe it's just the same, in which case,
I'd really like to have a course :)
You should really answer two questions here:
- Are you able to predict whether you'll find an SoC part of that
family in the future that derives a bit and will need a compatible
of its own?
- Are you able to predict which quirks we'll need along the way to
support all the SoCs you've listed there?
If you can't answer yes to both these questions, with a 100%
certainty, then you'll need a SoC name in the compatible.
Which doesn't prevent you from sharing as much as possible the DT like
we did between the A10s and the A13 for example.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-01-22 12:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-19 23:17 [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC Icenowy Zheng
2018-01-19 23:17 ` [RFC PATCH 1/9] ARM: add CONFIG_ARCH_SUNXI_V7 for differentiate ARMv5/v7 Allwinner SoCs Icenowy Zheng
2018-01-20 3:04 ` [linux-sunxi] " Julian Calaby
2018-01-19 23:17 ` [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs Icenowy Zheng
2018-01-20 3:06 ` [linux-sunxi] " Julian Calaby
2018-01-20 3:10 ` Icenowy Zheng
2018-01-20 3:22 ` Julian Calaby
2018-01-22 12:15 ` Maxime Ripard
2018-01-19 23:17 ` [RFC PATCH 3/9] irqchip/sun4i: add support for suniv interrupt controller Icenowy Zheng
2018-01-19 23:17 ` [RFC PATCH 4/9] clocksource: sun4i: add a compatible for suniv Icenowy Zheng
2018-01-19 23:17 ` [RFC PATCH 5/9] clocksource/drivers/sun4i: register as sched_clock on suniv Icenowy Zheng
2018-01-19 23:17 ` [RFC PATCH 6/9] pinctrl: sunxi: add support for suniv (newer F-series SoCs) Icenowy Zheng
2018-01-19 23:17 ` [RFC PATCH 7/9] clk: sunxi-ng: add support for suniv SoC Icenowy Zheng
2018-01-19 23:17 ` [RFC PATCH 8/9] ARM: dts: suniv: add initial DTSI file for suniv and F1C100s Icenowy Zheng
2018-01-21 11:03 ` Rask Ingemann Lambertsen
2018-01-19 23:17 ` [RFC PATCH 9/9] ARM: suniv: f1c100s: add device tree for Lichee Pi Nano Icenowy Zheng
2018-01-22 12:14 ` Maxime Ripard [this message]
2018-01-24 13:10 ` [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC Icenowy Zheng
2018-01-25 15:35 ` Maxime Ripard
2018-01-25 15:38 ` Icenowy Zheng
2018-01-26 14:43 ` Maxime Ripard
2018-01-26 20:57 ` Icenowy Zheng
2018-01-29 19:48 ` Rob Herring
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=20180122121435.bpayxk4uzfqbhqse@flea.lan \
--to=maxime.ripard@free-electrons.com \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=icenowy@aosc.io \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=linux@armlinux.org.uk \
--cc=marc.zyngier@arm.com \
--cc=wens@csie.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).