arch/ppc/kernel clutter

arch/ppc/kernel clutter

[Paul Mackerras]

I feel that arch/ppc/kernel in the linuxppc_2_4_devel tree is getting
more than a bit cluttered.  I propose that we make a new
arch/ppc/platforms directory and move the platform-specific files into
there - i.e. all of *_setup.c, *_pic.c, *_pci.c, and maybe some
others.  What would be left in arch/ppc/kernel is the more generic
stuff, i.e. things relating to the different base processors, the
different types of interrupt controllers or PCI host bridges, the
generic stuff that interfaces to the rest of the kernel (e.g. setup.c)
and so on.

My idea is that adding support for a new board would not normally
require changes in arch/ppc/kernel unless the new board has a new type
of interrupt controller, PCI host bridge, etc.

Thoughts?  Objections?

Another thing I would like to do is to generalize the drivers for the
various on-chip peripherals a bit more.  The platform code would then
specify in some way "this platform has an XYZZY on-chip ethernet
controller with registers at 0xabcdef00, using interrupt 123, with
quirks A, D and F".  (This sort of thing is what the OF device tree
was designed for and does very well, BTW.)

The configuration scripts could force CONFIG_XYZZY on when this
platform is selected and that would compile in the xyzzy driver.
The xyzzy driver initialization would get called during boot and would
look up whether the platform has any XYZZY's, and if so, what
addresses and interrupts to use.  So the XYZZY code doesn't need to
know anything about which platforms have an XYZZY at all.

This would be a bit of work in the short term to implement but would
mean that we could potentially reuse code more easily for new
platforms.  The idea is that if a new platform has an XYZZY, the
platform setup code just has to create a device tree (or whatever)
node for it, make sure the XYZZY driver is configured in, and it
should (hopefully :) Just Work.

This could extend to things like interrupt controllers and PCI host
bridges as well as regular I/O devices, too.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: arch/ppc/kernel clutter

[Michael Schmitz]

> I feel that arch/ppc/kernel in the linuxppc_2_4_devel tree is getting
> more than a bit cluttered.  I propose that we make a new
> arch/ppc/platforms directory and move the platform-specific files into
> there - i.e. all of *_setup.c, *_pic.c, *_pci.c, and maybe some

I was wondering how you guys could live with that situation anyway. Why
not have arch/ppc/powermac/, arch/ppc/prep/, arch/ppc/chrp/ and more of
the same?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: arch/ppc/kernel clutter

[Benjamin Herrenschmidt]

>
>Another thing I would like to do is to generalize the drivers for the
>various on-chip peripherals a bit more.  The platform code would then
>specify in some way "this platform has an XYZZY on-chip ethernet
>controller with registers at 0xabcdef00, using interrupt 123, with
>quirks A, D and F".  (This sort of thing is what the OF device tree
>was designed for and does very well, BTW.)

And which is also what the bi_rec's can do well if designed properly.
The idea here is when you deal with several revs of your embedded
board, you just need the firmware or the wrapper to pass proper HW
infos to your kernel via bi_recs and keep a common kernel for your
entire product range.

>The configuration scripts could force CONFIG_XYZZY on when this
>platform is selected and that would compile in the xyzzy driver.
>The xyzzy driver initialization would get called during boot and would
>look up whether the platform has any XYZZY's, and if so, what
>addresses and interrupts to use.  So the XYZZY code doesn't need to
>know anything about which platforms have an XYZZY at all.
>
>This would be a bit of work in the short term to implement but would
>mean that we could potentially reuse code more easily for new
>platforms.  The idea is that if a new platform has an XYZZY, the
>platform setup code just has to create a device tree (or whatever)
>node for it, make sure the XYZZY driver is configured in, and it
>should (hopefully :) Just Work.
>
>This could extend to things like interrupt controllers and PCI host
>bridges as well as regular I/O devices, too.
>
>Paul.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: arch/ppc/kernel clutter

[Tom Rini]

On Fri, Oct 19, 2001 at 10:19:32PM +1000, Paul Mackerras wrote:

> I feel that arch/ppc/kernel in the linuxppc_2_4_devel tree is getting
> more than a bit cluttered.  I propose that we make a new
> arch/ppc/platforms directory and move the platform-specific files into
> there - i.e. all of *_setup.c, *_pic.c, *_pci.c, and maybe some
> others.  What would be left in arch/ppc/kernel is the more generic
> stuff, i.e. things relating to the different base processors, the
> different types of interrupt controllers or PCI host bridges, the
> generic stuff that interfaces to the rest of the kernel (e.g. setup.c)
> and so on.

I think we should go and look at what MIPS is doing.  They've got
something like:
arch/mips/<chipset>/
                    common/pci.c, irq.c
		    board_name/setup.c, other board specific stuffs.
I think doing something like this, but inside of arch/ppc/platforms
would make sense.

> My idea is that adding support for a new board would not normally
> require changes in arch/ppc/kernel unless the new board has a new type
> of interrupt controller, PCI host bridge, etc.

Sounds good.

> Another thing I would like to do is to generalize the drivers for the
> various on-chip peripherals a bit more.  The platform code would then
> specify in some way "this platform has an XYZZY on-chip ethernet
> controller with registers at 0xabcdef00, using interrupt 123, with
> quirks A, D and F".  (This sort of thing is what the OF device tree
> was designed for and does very well, BTW.)

How about we put the totally platform specific stuff, like say 8xx
microcode updating into arch/ppc/platforms/cpm8xx/drivers/ or something
like that, and move the enet/serial drivers out.  But yes, the 8xx/8260
enet/serial drivers need some work.  The ppc405 enet driver is a bit
better about some of these things.

With the ppc405 enet driver we can detect things like the PHY, but other
infos are still a compile-time option.  Some of these might be
detectible, but I think in the case where you don't have any control
over the firmware, and it's either buggy or it's lacking in features,
it's a toss up if you want to figure stuff out at compile time with a
config option or hardcode stuff either in the driver or wrapper based on
best-guessing.

> The configuration scripts could force CONFIG_XYZZY on when this
> platform is selected and that would compile in the xyzzy driver.
> The xyzzy driver initialization would get called during boot and would
> look up whether the platform has any XYZZY's, and if so, what
> addresses and interrupts to use.  So the XYZZY code doesn't need to
> know anything about which platforms have an XYZZY at all.

Erm, I don't think you can get rid of asking things about CONFIG_XYZZY
tho.  I _think_ depending on how you build the drivers it's sometimes
possible to have the same HW either have 2 XYZZYs or an XYZZY and a
ZYXXY.  But the drivers can certainly be cleaned up a bit to probe
around in some cases instead of big ugly #ifdef tables.

> This could extend to things like interrupt controllers and PCI host
> bridges as well as regular I/O devices, too.

Eh?  I'm pretty sure all of the bridge stuff is pretty well extracted.
Pass it your board values (which are unchanging constants) and it just
works.  There are a couple of funny issues which could be handled a bit
better (Sandpoint X2 vs Sandpoint X3) but by and large the I/O device
drivers are the ones with some glaring uglies in it (which I have been
thinking about..)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: arch/ppc/kernel clutter

[Larry McVoy]

If you do this reorg and send it out to Linus as a patch and then get it
back again, can you let me do that merge or work with whoever does it?
The key thing is that you want to catch the renames and BK will help you
with that if you let it.
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Renames (Was Re: arch/ppc/kernel clutter)

[Tom Rini]

On Fri, Oct 19, 2001 at 08:16:49AM -0700, Larry McVoy wrote:

> If you do this reorg and send it out to Linus as a patch and then get it
> back again, can you let me do that merge or work with whoever does it?
> The key thing is that you want to catch the renames and BK will help you
> with that if you let it.

Er, I thought we've just intentionally not been tracking renames in our
kernel.org version of the tree...

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Renames, BK, PPC, etc

[Larry McVoy]

On Fri, Oct 19, 2001 at 08:34:30AM -0700, Tom Rini wrote:
> On Fri, Oct 19, 2001 at 08:16:49AM -0700, Larry McVoy wrote:
>
> > If you do this reorg and send it out to Linus as a patch and then get it
> > back again, can you let me do that merge or work with whoever does it?
> > The key thing is that you want to catch the renames and BK will help you
> > with that if you let it.
>
> Er, I thought we've just intentionally not been tracking renames in our
> kernel.org version of the tree...

Well this raises an interesting issue.  Some of the other kernel people have
started asking about a BK tree to track, one that has the kernel history in
it and is well maintained.  Ted Tso went so far as to import a bunch of
history, complete with the release notes checked in as changeset comments,
into a new BK tree.  One option is to use that tree for anyone who wants
to use BK with the kernel.  If that catches on, that's likely to be the
tree that Linus would pick up and use if/when he starts using BK.

On the other hand, there is a lot of history in the various PPC BK trees.

The question is this: if Linus & Co were to start using BK, does anyone
here care whether it is the current PPC maintained tree or are you willing
to start over?  BK is not going to let you pull from the new tree to your
current tree, as far as BK is concerned those are completely unrelated
repositories.  So you'd have to switch.

If you haven't been maintaining the renames all along and there is lots
of crud in the tree, then I can see you not caring at all.  In fact, it
would probably be desirable to do a reset.  Paul?  Cort?  Others?

I'm putting Ted's tree up at http://linux.bkbits.net/ so you can take a
look at the nice job he did importing the data.  Let me know what you
think.
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Renames, BK, PPC, etc

[Tom Rini]

On Fri, Oct 19, 2001 at 09:16:45AM -0700, Larry McVoy wrote:

> The question is this: if Linus & Co were to start using BK, does anyone
> here care whether it is the current PPC maintained tree or are you willing
> to start over?  BK is not going to let you pull from the new tree to your
> current tree, as far as BK is concerned those are completely unrelated
> repositories.  So you'd have to switch.

Well, I guess part of the question/problem is how easy is it to keep one
of the trees up to date?  We still haven't decided what to do for 2.5
yet (I'd like to for linux_2_4 and keep going w/ the _devel tree as a
2_5 tree, but that's just me probably.)  If Ted's tree is reasonably up
to date (or it'd be possible for myself/Paul to help keep it so), I
wouldn't be opposed to trying linuxppc_2_5 as a subtree of Ted's.

> If you haven't been maintaining the renames all along and there is lots
> of crud in the tree, then I can see you not caring at all.  In fact, it
> would probably be desirable to do a reset.  Paul?  Cort?  Others?

I don't think the crud is hurting much tho..  I'd rather keep history,
but I'm also not opposed to change. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: arch/ppc/kernel clutter

[Ralph Blach]

Paul,

I don't feel the PPC tree, or most of the developers, realize what's
happening in the Power PC hardware Arena.
The powerpc hardware is becoming increasingly diverse because  of the
IBM core connect technology.
CoreConnect allows hardware designers to easily reusable hardware cores
much like a programmer uses a subroutine.
(See www.chips.ibm.com).  (I am not sure what Mot has)

This allows IBM to quickly integrate different sets of peripherals to a
processor core.
One only has to look to the 405 to see the effects of this.  Announced
for the 405 are the
405CR, 405GP, NPE405H, NPE405L, the Ranier network processor, the 405LP
and the stb04xxx. There are also many CSSPs which
have 405 processor cores that have been designed or are in process.
These CSSP's  have peripherals that are not in any of the
of the released chips but are in IBM core library.  Many of these
CSSP's  have customer designed peripherals.
(This is NOT a sales pitch.  This is just to let everybody know that way
IBM (and probably Mot ) stitches processors
and peripherals together has changed. IE, It a LOT easier now to stich
together Processor cores and components
to make a CSSP. )

All of these chips have a different mix of on chip peripherals.  Given
the ease that the hardware designers
now have in creating chips, we need a PPC linux structure that
recognizes this.

The linux kernel ppc tree is going to have to become much more flexible
to recognize the incredible flexibility that
IBM and Motorola are  designing into the PPC hardware.

Chip

Paul Mackerras wrote:
>
> I feel that arch/ppc/kernel in the linuxppc_2_4_devel tree is getting
> more than a bit cluttered.  I propose that we make a new
> arch/ppc/platforms directory and move the platform-specific files into
> there - i.e. all of *_setup.c, *_pic.c, *_pci.c, and maybe some
> others.  What would be left in arch/ppc/kernel is the more generic
> stuff, i.e. things relating to the different base processors, the
> different types of interrupt controllers or PCI host bridges, the
> generic stuff that interfaces to the rest of the kernel (e.g. setup.c)
> and so on.
>
> My idea is that adding support for a new board would not normally
> require changes in arch/ppc/kernel unless the new board has a new type
> of interrupt controller, PCI host bridge, etc.
>
> Thoughts?  Objections?
>
> Another thing I would like to do is to generalize the drivers for the
> various on-chip peripherals a bit more.  The platform code would then
> specify in some way "this platform has an XYZZY on-chip ethernet
> controller with registers at 0xabcdef00, using interrupt 123, with
> quirks A, D and F".  (This sort of thing is what the OF device tree
> was designed for and does very well, BTW.)
>
> The configuration scripts could force CONFIG_XYZZY on when this
> platform is selected and that would compile in the xyzzy driver.
> The xyzzy driver initialization would get called during boot and would
> look up whether the platform has any XYZZY's, and if so, what
> addresses and interrupts to use.  So the XYZZY code doesn't need to
> know anything about which platforms have an XYZZY at all.
>
> This would be a bit of work in the short term to implement but would
> mean that we could potentially reuse code more easily for new
> platforms.  The idea is that if a new platform has an XYZZY, the
> platform setup code just has to create a device tree (or whatever)
> node for it, make sure the XYZZY driver is configured in, and it
> should (hopefully :) Just Work.
>
> This could extend to things like interrupt controllers and PCI host
> bridges as well as regular I/O devices, too.
>
> Paul.
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: arch/ppc/kernel clutter

[Tom Rini]

On Fri, Oct 19, 2001 at 01:42:44PM -0400, Ralph Blach wrote:

> This allows IBM to quickly integrate different sets of peripherals to a
> processor core.
> One only has to look to the 405 to see the effects of this.  Announced
> for the 405 are the
> 405CR, 405GP, NPE405H, NPE405L, the Ranier network processor, the 405LP
> and the stb04xxx. There are also many CSSPs which
> have 405 processor cores that have been designed or are in process.
> These CSSP's  have peripherals that are not in any of the
> of the released chips but are in IBM core library.  Many of these
> CSSP's  have customer designed peripherals.
> (This is NOT a sales pitch.  This is just to let everybody know that way
> IBM (and probably Mot ) stitches processors
> and peripherals together has changed. IE, It a LOT easier now to stich
> together Processor cores and components
> to make a CSSP. )

So it's a 405 core + other board (I use the term loosely here) bits
attached on a bus, right?  I think more work might still need to be
done for seperating stuff that's specific to a certain 405 board from
the more generic 'board bits', but I don't think it'll be too hard,
or too dramatic.

> All of these chips have a different mix of on chip peripherals.  Given
> the ease that the hardware designers
> now have in creating chips, we need a PPC linux structure that
> recognizes this.

So it's sort-of like throwing more PCI cards in a pmac?  They're always
on some sort of standard interface(s), yes?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: arch/ppc/kernel clutter

[Dan Malek]

Paul Mackerras wrote:

> Thoughts?  Objections?

Matt Porter made a very good comment the other day that must not get
lost.  Any of the software we have available here should be useful to
and able to be enhanced by others.  To me, it doesn't make sense to
have a large number of subdirectories and matrix of configuration options.
For all practical purposes, a "board" will define everything we need
to know about a configuration.  We can have a variety of implied
options from this point, but things like this need to evolve as we
gain experience.

I'm not objecting to changes, I just want to ensure we don't go 180
degrees off the deep end in the other direction :-).  Just look at
the mess we created with the "simple" piggyback loader reorganization
that is still in progress.

> Another thing I would like to do is to generalize the drivers for the
> various on-chip peripherals a bit more.

I don't understand what you mean.  There are the 8xx, 8260, and 405
peripherals.  The only reason the 8xx has it's own IO directory was
back in those days it was difficult to get any write access into
something outside of our architecture tree.  They are also unique to
that processor family, not useful for anyone else.  The only advantage
to having them in the drivers/* directory is to recognize functional
interface changes when they occur.


> The configuration scripts could force CONFIG_XYZZY on when this
> platform is selected and that would compile in the xyzzy driver.

Isn't that what happens today?  Selecting a configuraion option isn't
related to a directory structure unless you want to somehow automate
the Makefile processing and derive knowledge from the option itself.

> This would be a bit of work in the short term to implement but would
> mean that we could potentially reuse code more easily for new
> platforms.

Do you actually understand how the current embedded platforms work?
To implement a new 8xx or 8260 today takes me just a few hours.
Matt does something similar with PreP/CHRP cPCI platforms.  Don't
confuse the ability to quickly turn out a new platform port with
moving some files out of the kernel directory.  I don't notice the
clutter in the kernel directory because of the way files are named
and simply using wildcard on commands works pretty well :-).

> This could extend to things like interrupt controllers and PCI host
> bridges as well as regular I/O devices, too.

Don't get me started on interrupt controllers.......I've been complaining
about this for many years since I did the first 8xx port.  My changes
either get reverted or fscked up further upstream when someone decides
only part of what we do is generically useful :-).  I think we finally
have a pretty nice PCI bridge management that should be part of the
generic kernel.  Until Linux determines the design baseline isn't a PeeCee
we are stuck with a bunch of legacy crap that doesn't extend well into
flexible architectures like we use every day.

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Renames (Was Re: arch/ppc/kernel clutter)

[Paul Mackerras]

Tom Rini writes:

> Er, I thought we've just intentionally not been tracking renames in our
> kernel.org version of the tree...

Haven't you?  I have been doing the renames when I check in Linus'
patches.  Do you use the takelinuspatch script?  It pops up a
renametool and I usually try to work out what has been renamed.

Paul.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: arch/ppc/kernel clutter

[Paul Mackerras]

Michael Schmitz writes:

> I was wondering how you guys could live with that situation anyway. Why
> not have arch/ppc/powermac/, arch/ppc/prep/, arch/ppc/chrp/ and more of
> the same?

We had that at one stage and decided that it was better to have
powermac, prep and chrp in one directory.  Having a directory per
platform would give us a lot of directories each with only a couple of
files, which I don't want to see.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: arch/ppc/kernel clutter

[Michael Schmitz]

> > I was wondering how you guys could live with that situation anyway. Why
> > not have arch/ppc/powermac/, arch/ppc/prep/, arch/ppc/chrp/ and more of
> > the same?
>
> We had that at one stage and decided that it was better to have
> powermac, prep and chrp in one directory.  Having a directory per
> platform would give us a lot of directories each with only a couple of
> files, which I don't want to see.

Well, I suppose it's a matter of taste. Even collecting the *_setup.c
etc. files in a new directory would cut down on the clutter enough :-)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/