On Tue, Sep 09, 2014 at 12:41:41PM +0200, Michal Suchanek wrote:
> On 9 September 2014 11:53, Maxime Ripard
> <maxime.rip...@free-electrons.com> wrote:
> > On Mon, Sep 08, 2014 at 09:53:21PM +0200, Michal Suchanek wrote:
> >> >> 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.
> >>
> >> Ok, so how about printing all of the above?
> >
> > It's not just about printing. If we want to be consistent, we would
> > have to stick with a single naming scheme. So that would mean also
> > fixing up the source code of linux/uboot, the configuration files, the
> > wiki, etc.
> >
> > If you want to spend time doing so, great. But I have no intention to
> > follow you down this road.
> >
> >> The chip id is something burnt into the SoC and cannot be disputed.
> >> From the chip id it can be guessed what is probably printed on the
> >> package unless AW marketing got *really* creative.
> >
> > As far as I know, it's indeed on the package. But the package might
> > not be visible, due to an heatsink for example.
> >
> 
> But it's what it sells as and what is in the marketing material of the
> product that includes the SoC in cases when it is correct.

Not really, you'll never find any board/device sold as embedding an
AW1635.

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

Attachment: signature.asc
Description: Digital signature

Reply via email to