On Mon, Sep 08, 2014 at 03:55:19PM +0200, Luc Verhaegen wrote:
> On Mon, Sep 08, 2014 at 01:37:23PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 08, 2014 at 01:01:11PM +0200, Luc Verhaegen wrote:
> > > Signed-off-by: Luc Verhaegen <l...@skynet.be>
> > > ---
> > >  meminfo.c |    4 ++--
> > >  1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/meminfo.c b/meminfo.c
> > > index 86b5c1e..24b4772 100644
> > > --- a/meminfo.c
> > > +++ b/meminfo.c
> > > @@ -60,8 +60,8 @@ enum sunxi_soc_version {
> > >   SUNXI_SOC_SUN6I = 0x1633, /* A31 */
> > >   SUNXI_SOC_SUN7I = 0x1651, /* A20 */
> > >   SUNXI_SOC_SUN8I = 0x1650, /* A23 */
> > > - SUNXI_SOC_SUN9I = 0x1667, /* A33 */
> > > - SUNXI_SOC_SUN10I = 0x1635, /* A80 */
> > > + SUNXI_SOC_SUN9I = 0x1635, /* A80 */
> > > + SUNXI_SOC_SUN10I = 0x1667, /* A33 */
> > 
> > A33 is actually part of the sun8i family.
> > 
> > Maxime
> 
> For those who do not know what Maxime is on about, here is the short 
> explanation: 
> http://linux-sunxi.org/Allwinner_SoC_Family#Naming_confusion
> 
> I do not buy the modern allwinner sunXi naming.
> 
> Retro-actively renaming half their line-up sun4i and the other half 
> sun8i, I have seen that before (cfr unichrome.sf.net). A few months in, 
> and that Vendor did another little pirouette. And again, and again.
> 
> Where Allwinner drew the naming line now is quite arbitrary: the type of 
> the ARM core in there. The one component which is mostly generic and 
> reasonably universal. Sun4i suddenly became all ARM Cortex A8, sun8i 
> became all ARM Cortex A7. Now that they stuck a few A15 in A80, they 
> named that sun9i.

Actually, I do find it consistent.

> If the sunXiwYpZ scheme actually had something to do with the majority 
> of SoC specific component lineage, i would've totally bought into it: 
> that would put A20 close to A10, and would put A31 somewhere else 
> altogether, with A23 and A33 close together...

Yeah, right, as if the sun4i/sun5i was in any way better....

> So no, this is purely a marketing driven decision, which will have 
> changed again in 6 months time. Where will Allwinners freshly announced 
> A83 land? Will they stick to their own naming scheme? What will happen 
> when Allwinner produces an ARMv8 chip, will they count beyond 9, or will 
> they rename everything sun7i/sun8i?
> 
> Sun[4567]i was chronological, and initially sun[89]i were too. So I say 
> we just keep on counting for ourselves.

A10s was released after A13, A31 and A20 at the same time. Not very
chronological if you ask me...

But I guess what it all boils down is this: do we want to keep
allwinner's naming and be consistent with it or not. We've been so
far, it's something I'd like to be kept. Especially since it's *very*
easy to support (basically, keep the sun6i and sun7i, introduce sun8i
for A23, A33, and whatever comes next, which should be the best if
following your "connection" argument), and have sun9i for the A80.

Introducing this sun10i out of nowhere, without any other
code/documentation referring to it, and with the only argument that
"some guy thought it was a better idea" is not that great. Especially
when the time where they will have a new design and come up with
sun10i chips.

> Another option is to completely switch to AW<chip id>, which would mimic 
> what i did for unichrome.
> 
> A10    = AW1623 (sun4i)
> A13/A10s = AW1625 (sun5i)
> A31    = AW1633 (sun6i)
> A20    = AW1651 (sun7i)
> A23    = AW1650 (sun8i)
> A80    = AW1635 (sun9i)
> A33    = AW1667 (...)
> 
> Now that's going to be real confusing.

That could be an option, but like you said, it's pretty confusing to
existing user of our code base.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Attachment: signature.asc
Description: Digital signature

Reply via email to