[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 linux-xtensa at linux-xtensa.org
Tue Mar 31 09:37:02 PDT 2009


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??

> > 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 :-)

-Marc




More information about the linux-xtensa mailing list