[Linux-Xtensa] Re: [patch 0/8] xtensa: s6000 & s6105 - Git Repo Pulled; will try to merge early next week and get back to ya.

[linux-xtensa at linux-xtensa.org]

On Tue, Mar 31, 2009 at 09:37:02AM -0700, Marc Gauthier wrote:
> Hi Johannes,
> 
> Johannes Weiner wrote:
> > > I discussed the VARIANT change with
> > > Marc this afternoon with a Makefile now being required for 
> > > a Variant. We were wondering why you
> > > don't put this code in the platform dir. Seem Chris 
> > > Zankel's philosophy was that the platform
> > > directory should be as tight as possible.
> > 
> > We tried hard to separate what is core-specific and what is specific
> > to our eval board so if somebody else puts the S6000 on a different
> > board, she should be able to just port to the new platform and use the
> > s6000 support code from the variant directory instead of duplicating
> > it in the platform directory.
> 
> Ah, here-in lies the confusion:  we consider *core* (or "core variant")
> to be the processor only, described entirely by the Xtensa core overlay
> (2 or 3 header files).  Whereas you are using the term core here to
> refer to an SOC (chip), which happens to have two cores in it (one of
> which you are using).  It's clear that separating board (platform) and
> chip/soc is useful and necessary.  We also need to clearly separate
> these two from processor cores, so that we can properly and clearly
> match each core with their associated toolchain, automatically install
> Xtensa core overlays, etc.
> 
> It's quite possible for Stretch to use the Xtensa core they licensed
> from Tensilica, for multiple SOCs.  Even if they don't, keeping the
> processor-core-specific variant directory separate from the SOC
> directory doesn't hurt, it's just one more directory.  And it helps
> making the distinction.  Maybe some README in Documentation/xtensa
> will help too :-)
> 
> I personally am not sure the term "variant" is the most appropriate
> to describe processor-core-specific things -- variant of what? --
> so if we're into moving these directories around anyway, perhaps
> the directory prefix can be renamed as well.  I like core-xxxx but
> perhaps the term *core* isn't widely used to refer to a processor
> (or variant thereof).  So maybe proc-xxxx or something else??

Thanks for the detailed description!

> > > Marc and I looked a bit at the ARM and MIPS arch in search 
> > > of the correct paradigm for VARIANT code.
> > 
> > They do it all differently ;) Our conclusion is that there isn't a
> > 'right way', it strongly depends on the environment where the
> > architecture is used.  I.e. what organization of code brings the least
> > hassle if new hardware pops up etc.
> 
> Yes indeed.  I think for us, platform/soc/core are a good set of
> hardware specificities to work with.  Though what terms to use for
> each that is most inline with the rest of the kernel, isn't as clear :-)

I think the other archs are not really comparable, are they?

But the whole splitting is really a practicability issue.  We just
thought it is more likely that someone wants to use the s6000 with a
different board compared to someone wanting to use a different chip
with the same tensilica core.

We happily agree that it should be cleaned up in the long run, though.

	Hannes