Re: handling of firmware calls (Efika boots)

[Matt Sealey <matt%genesi-usa.com@localhost>]

A lot of the PowerQuicc lines have different names but very similar
components; the naming scheme falls down hard here. You *will end
up sharing code, otherwise you *will* end up duplicating great
deals of it.

I don't think it's prudent to give them all their own directory
anywa, therefore.

What about just naming the drivers after the first chip that is
supported. for instance mpc5200_eth.c - any compatible chips
can be listed in the header and grepped for. It would always be
fairly easy to pick these out for which chip needs which
components. Replacing things with xxx or arbitrarily grouping
them just makes it more confusing as to what the file really
supports - you would be going into the source to check, so why
not just take advantage of that.

Cleanliness of the tree is an issue, but I really do recall that
most of the drivers inside the SoC for most of these chips will
NOT be in the arch directory anyway. I would suggest in that
case that you name any directories after the core code (440, e300,
e500 etc.) aor where relevant use the chip brand name (powerquicc)
which catches a lot more code. PowerQUICC stretches across a vast
range of chips and cores, but the peripherals are nearly all
identical. The 8641D (e600 core) uses a lot of componnets from
the PowerQUICC design library but isn't under the brand though.

How about we code it now (since there is only 3 chips to support
as I read the list.. mpc5200b, an 834x chip and someone doing
a 440spe port?) ad we can move them around into directories
when the code dictates it's required.

--
Matt Sealey <matt%genesi-usa.com@localhost>
Genesi, Manager, Developer Relations

Masao Uebayashi wrote:
> > > there shouldn't be a special directory for it.  It's simple a 603 (OEA).
> > Sure, agreed about the core. I was speaking about the various
> > peripherals that the SoC can drive.
>
> I'd propose somewhat redundant but straightforward hierarchy for SoCs;
> create a subdirectory (called cpu/ here, but whatever you want) and
> under it have one directory for each supposedly compatible SoC
> versions and put definitions (mainly for peripherals), like:
>
>         src/sys/arch/powerpc/cpu/mpc52xx
>         src/sys/arch/powerpc/cpu/mpc74xx
>         src/sys/arch/powerpc/cpu/mpc83xx
>         src/sys/arch/powerpc/cpu/mpc85xx
>         src/sys/arch/powerpc/cpu/mpc86xx
>         :
>
> The reason I did this (locally) and I like this is that I want to keep
> (register) definitions exactly corresponding to their datasheets.
>
> If you go "these modules look similar, let's share headers and codes"
> way, it's you who has to figure out the differences and
> (in)compatibilities of versions.  I once tried this for SuperH CPUs,
> and I concluded this is just plain waste of time.  Sharing code didn't
> save my time at all.
>
> Newer core definitions and its code (e300, e500, e600, ...) can be
> aligned to current oea/ directory.
>
> Masao
>
> P.S. I feel populating src/sys/arch/* directory is ugly.