On Tue, Sep 09, 2014 at 02:29:23PM +0200, Luc Verhaegen wrote: > On Tue, Sep 09, 2014 at 12:05:54PM +0200, Maxime Ripard wrote: > > On Mon, Sep 08, 2014 at 06:01:25PM +0200, Luc Verhaegen wrote: > > > > > > For now. > > > > Forgive me, I don't have the chance to own a crystal ball. > > And logically extrapolating is not one of your strengths either > apparently.
Insults. Again. > > > It was a consistent scheme, which allwinner followed for many many > > > years. > > > > No, it was not. If it was to be a purely time-driven naming scheme, > > A10s should have been sun6i. > > See below. It was consistent. > > > > A10s is A13. > > > > [citation needed] > > Why else does allwinner call them both sun5i? Why else does A13 have a > fully working hdmi block sitting there? > > Citation: my uboot cfbconsole code where i successfully use HPD > detection on A13. This fails nicely, as no hpd pin is exported outside > of the chip, and it is never raised to 5V. > > But please go ask our Allwinner contacts or Tom Cubie or something. The fact that the internals of the SoC are alike or even the same doesn't matter much. What really matters is really what is exposed to the user, ie what is routed to the externals pins. And from that point of view, they're just "similar", but the fact that the HDMI, EMAC, GPS, etc. are not at least usable in the A13 makes it a different SoC. > > > The A20 design was a stopgap, and the design started after A31 was > > > started. So it was chronological, just not chronological with the > > > release dates. > > > > Yeah, right. So it's chronological, but we have no way to tell, except > > by fully trusting you. The argument of (which?) authority is not > > really something that usually convince me. > > It is pretty logical. A31 was named sun6i, A20 was named sun7i. A31 was > a major redesign. A20 was throwing 2 A7s and a second fragment shader, > and some minor fixes onto A10. The latter was either a stopgap, or a > deliberate market decision, it at least took a lot less time to > complete. Hence them both arriving at the same time. > > Again, the above is the best logical explanation for events. Ok. > > > But this is not consistent with Allwinner naming. Being consistent with > > > allwinner naming would mean renaming most of the upstream code. And then > > > doing it again a few months from now. > > > > It is. You can find some reference to A31 being sun6i, and A20 being > > sun7i. Can you find any reference to A33 being sun10i? > > You did find A31 and A20 as sun6i and sun7i when Allwinner was still on > a relatively sane naming scheme. You cannot find these references > anymore on anything allwinner produces today. > > So either you go allwinner, or you don't. Probably, but we still have to find a consistent naming. Sticking with sun6i and sun7i is somewhat consistent with both ourselves and Allwinner. sun10i is just made out of nowhere, as a hack because you don't really like the new naming scheme. > > > Sun8i for A23 and A33 will only work until we see allwinner give out the > > > codename for A83, and whether the early marketing noise for it matches > > > reality and it really is a octal A7 with powervr. Something tells me > > > that this is going to be an A80, with less dram channels, less rogue > > > shaders, and with A7s instead of A15. > > > > I guess it could fit into both sun8i and sun9i. But A83 isn't really > > the topic here, is it? > > But it is. Or it very much will be, in about 6 months time. Ok, let's consider it then. I guess we have four options: - It's made part of sun8i by Allwinner - It's made part of sun9i by Allwinner - It's made sun10i by Allwinner - It's made something completely different and crazy. By introducing sun11i like you suggest, you're making it inconsistent with all of these options. While my proposal doesn't conflict with any of them. > > And even if Allwinner introduces a sun10i for A83, it will only proves > > that we were wrong by trying to stick it to A33. > > Or it could end up proving that we were right to not use Allwinners > current scheme, and instead diverged and stuck to Allwinners older, > saner scheme. > > > > It will be a very short pain. > > > > Look closer into your crystal ball. > > We'd just keep on counting up. Since we wouldn't be calling this chip > sun10iw1p1 but instead sun12i or so, there will be no real discrepancy. > We'd be talking about sun10i without a suffix. And there would be only > minimal room for confusion. > > > > But ok, so what do you want to call A33, and do we rename A23 away from > > > sun8i, by adding suffixes there as well? > > > > > > The sun8i<suffix> "solution" is only a band-aid though. Perhaps A83 will > > > fit in this scheme, perhaps not. Something tells me that armv8 is going > > > to seriously kill this, and will require a more permanent solution to > > > this problem. > > > > A more permanent solution to a problem that isn't even a > > problem. Yeah, definitely looks way more important than a proper > > display driver. > > Why not? > > So you do not want to support any users beyond a20 and a31? That's not what I'm saying, and you know it very well. > And we've already established that you are against collecting device > information and helping users get a proper linux up on their random > android devices. This is ridiculous. > You do find it necessary to complain about a naming scheme, and then you > go and state that it is not important. Which is it? First, I'm not complaining. I thought this was open source, and that opensource was supposed to be also about good software practice, such as peer review. It's only what it was about. Then, the issue is not there, but is created by your patch. Like I suggested in my previous mail, you can handle things nicely for everyone involved, while sticking with some Allwinner naming. Sure, for the A20 and A31, there will be two different namings, but this is a transition period, and everyone knows them by their old naming. > Is it not important (especially since it is on software you do not > want to care about, as it is there to help bring up new devices), > then why did you care to complain? If it is important, then why are > you not contributing more to things surrounding and supporting > mainline kernel code? Because I don't work full time on this, and I have to make choices. It seems like you have either more time, or chose another thing to work on. Fine. Could we at least respect each other choices? And this is exactly why I looked at your patches, because even though I don't have time to actively work on this, this is code that is "surrounding and supporting mainline kernel code", and as such is of interest to me. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
