Re: include/asm-ppc/platforms/

Re: include/asm-ppc/platforms/

[Ralph Blach]

Guys,

I think we are missing the boat, on the include/asm-ppc/platforms.

This does not take into account the embedded world at all.
The correct form of the file should be asm-ppc/core/chip/revsion/board

This is because the IBM Core Connect and the Motorola OCEAN internal
interconnect systems.

These allow for a 405/book E/Mot processor cores to be customized around a
large set of
customized on chip perphials.  It will make the availabily of a large
number different
customized chips with different on chip perphials available.

Thats my justification for core/chip

Now for revsion/intersections   This is a little more difficult.
Book E is now a reality.  The Mot E500 and the IBM 440 have been announced
and are book E processors.
A reality of book E not discussed in the forum here is the expansion op
codes.

This means that different book E processors will have different expansion
op codes.
The Mot book E has an isel instruction and the IBM book 440  has deterine
leftmost zero byte in a string.
(See

http://www-3.ibm.com/chips/techlib/techlib.nsf/products/PowerPC_440GP_Embedded_Processor
Read Writing High performance Assembly functions for the PowerPC 440 Core
and
http://e-www.motorola.com/news_center/press_releases/PR010612C.html

for info on these)

This is my justification for Revision, because different Chip Revision will
Have differnet Expansion
instruction sets.  The following statements have HUGE implecation on
Libraries, because the loader will have to load correct library
according to Chip Revision.

Life is going to be very interesting.

Chip


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

Re: include/asm-ppc/platforms/

[Paul Mackerras]

Ralph Blach writes:

> This does not take into account the embedded world at all.
> The correct form of the file should be asm-ppc/core/chip/revsion/board
>
> This is because the IBM Core Connect and the Motorola OCEAN internal
> interconnect systems.
>
> These allow for a 405/book E/Mot processor cores to be customized around a
> large set of
> customized on chip perphials.  It will make the availabily of a large
> number different
> customized chips with different on chip perphials available.
>
> Thats my justification for core/chip

How is the kernel supposed to know what on-chip peripherals exist?
By the CPU version/revision numbers?  Are you *always* going to change
the cpu revision number when you change the set of on-chip
peripherals?  Or will the kernel have to "just know" what on-chip
peripherals there are?

The scenario you outline leads me to think that we should flatten the
structure, rather than making a very deep hierarchical structure as
you suggest.  What I mean is that we should structure things so that
we have a collection of device drivers for various on-chip devices, a
collection of PCI host bridge drivers, a collection of interrupt
controller drivers, etc.  And these drivers should not make any
assumptions about addresses etc.

Then for each platform we have a device tree, or some similar kind of
database, that tells us what devices are where and how they are
connected.  We could consider using such a database at config time as
well as at run-time.  The database could be supplied statically by the
board support package or it could be supplied at runtime by the boot
loader.

Basically I want the knowledge that "because this is a 405gp chip we
must have an XYZ ethernet controller at address FOO using interrupt
N" to be concentrated in one place, not spread out through the
code.  Then when IBM brings out a 405gp-A that has two XYZ's (neither
of which are at the same address as in the 405gp) there is just one
place that we have to change.

> This is my justification for Revision, because different Chip Revision will
> Have differnet Expansion
> instruction sets.  The following statements have HUGE implecation on
> Libraries, because the loader will have to load correct library
> according to Chip Revision.

It's more a problem for the distributions - they will need to make
sure the correct libraries get installed.  My guess is that most
libraries will end up not using the extra instructions.

Paul.

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

Re: include/asm-ppc/platforms/

[Frank Rowand]

Paul Mackerras wrote:
>
> Ralph Blach writes:
>
> > This does not take into account the embedded world at all.
> > The correct form of the file should be asm-ppc/core/chip/revsion/board
> >
> > This is because the IBM Core Connect and the Motorola OCEAN internal
> > interconnect systems.
> >
> > These allow for a 405/book E/Mot processor cores to be customized around a
> > large set of
> > customized on chip perphials.  It will make the availabily of a large
> > number different
> > customized chips with different on chip perphials available.
> >
> > Thats my justification for core/chip
>
> How is the kernel supposed to know what on-chip peripherals exist?
> By the CPU version/revision numbers?  Are you *always* going to change
> the cpu revision number when you change the set of on-chip
> peripherals?  Or will the kernel have to "just know" what on-chip
> peripherals there are?

I'm not sure why Ralph added revision into the mix.  The chip should be
sufficient to define the set of on-chip peripherals.  Some concrete
examples of core / chip / board are:

  403
    403GCX
  405
    405cr
    405gp
      walnut
      cpci405
      ep405
    stb03xxx
      redwood-4
    NPe405H
    NPe405L

> The scenario you outline leads me to think that we should flatten the
> structure, rather than making a very deep hierarchical structure as
> you suggest.  What I mean is that we should structure things so that
> we have a collection of device drivers for various on-chip devices, a
> collection of PCI host bridge drivers, a collection of interrupt
> controller drivers, etc.  And these drivers should not make any
> assumptions about addresses etc.

(I use the word "processor" as a synonym for "chip" in the following.)

Yes, that was the direction I was headed in with my original 4xx work.
Implementation didn't always match the goals, but that's where I was
headed.  Many of the drivers still need some work to be properly
generalized (eg ethernet driver able to handle multiple EMACS on a
single processor, i2c driver able to handle multiple i2c busses [which
was done for the redwood-4 but doesn't seem to have shown up in the
tree yet]).

The IBM "Blue Logic" device cells tend to be compatible or consistent
versions so far (empirical observation) and IBM has told me that I
should expect the DCR register block for a device to be consistent
accross processors.  So a foobar controller may have a control register
at offset 0 within the block, an interrupt status register at offset 4
within the block, and an error status register at offset 8 within the
block.  The driver simply has to know what the base address of the
block is for a given processor.

There are a few devices that have not been consistent from processor
to processor.  GPIO seems especially processor specific.  The interrupt
controller is mostly the same, but may or may not have a cascade level.


> Then for each platform we have a device tree, or some similar kind of
> database, that tells us what devices are where and how they are
> connected.  We could consider using such a database at config time as
> well as at run-time.  The database could be supplied statically by the
> board support package or it could be supplied at runtime by the boot
> loader.


The original 4xx design was to have the block of DCR registers for a device
defined in a single place (could be the device's header file or a more
central header file, whatever is preferred).  Then the address of the
base of each block was defined for each target, where target could be
either processor or processor/board, depending on which defined the
address.  That is the intent of the DCRN_*_BASE #defines in headers like
include/asm-ppc/platforms/ibm405gp.h.  Unfortunately in the merge from
my tree to the ppc tree the definition of the block of DCR registers
also got replicated into the same header that contains the address
of the block.  That should be cleaned up - each block should be defined
just once (except maybe those like GPIO that vary significantly with
each processor).

One nice thing about the way the block of DCR registers are defined is
that if the constant providing the base address of the block is not
defined, then the DCRs in the block are defined to be zero and the
mfdcr() and mtdcr() macros will detect the zero value and not attempt
to access a non-existent DCR.  mfdcr() returns zero in this case and
mtdcr() does nothing.  This means that, if used carefully, there are
many cases where there is no need to use #ifdefs to decide whether
to access a DCR or not.


> Basically I want the knowledge that "because this is a 405gp chip we
> must have an XYZ ethernet controller at address FOO using interrupt
> N" to be concentrated in one place, not spread out through the
> code.  Then when IBM brings out a 405gp-A that has two XYZ's (neither
> of which are at the same address as in the 405gp) there is just one
> place that we have to change.
>
> > This is my justification for Revision, because different Chip Revision will
> > Have differnet Expansion
> > instruction sets.  The following statements have HUGE implecation on
> > Libraries, because the loader will have to load correct library
> > according to Chip Revision.

Oh, this is where you explain revision.  Will instruction set really
change with revision, or with processor name?


> It's more a problem for the distributions - they will need to make
> sure the correct libraries get installed.  My guess is that most
> libraries will end up not using the extra instructions.


-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

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

Re: include/asm-ppc/platforms/

[Dan Malek]

Frank Rowand wrote:

> ....Some concrete
> examples of core / chip / board are:
>
>   403
>     403GCX
>   405
>     405cr
>     405gp
>       walnut
>       cpci405
>       ep405
>     stb03xxx
>       redwood-4
>     NPe405H
>     NPe405L

I think the 4xx has always had this backward from other PowerPC platform
definiitons.  While we should define processor cores, their peripherals,
and boards, the least common denominator is the processor core.  With the execption
of few boards (the Sandpoint comes to mind), simply configuring a board
type will allow you to know which processor package is used and further
the processor core.  If I say "Walnut" configuration, I already know everything
else, I don't need to be asked all of the other configuration questions.
Our files should also follow this structure.  The Walnut configuration file
should include 405GP (which defines peripherals) which should then include
the processor core definitions (if necessary).  This way, when a new processor
package with a different peripheral configuration is added, all you need to
do is ensure the proper lower level core file is included, you don't have
to update all of the board configuration files with stuff they don't care about.

If, in this example, the Walnut had different processor types available, it
would make sense within that configuration to ask the processor type, but no
one else would (nor should) care.  Again, the file structure would follow,
with the Walnut board configuration including the appropriately configured
processor package.

Thanks.


	-- Dan


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

Re: include/asm-ppc/platforms/

[Frank Rowand]

Dan Malek wrote:
>
> Frank Rowand wrote:
>
> > ....Some concrete
> > examples of core / chip / board are:
> >
> >   403
> >     403GCX
> >   405
> >     405cr
> >     405gp
> >       walnut
> >       cpci405
> >       ep405
> >     stb03xxx
> >       redwood-4
> >     NPe405H
> >     NPe405L
>
> I think the 4xx has always had this backward from other PowerPC platform
> definiitons.  While we should define processor cores, their peripherals,
> and boards, the least common denominator is the processor core.  With the execption
> of few boards (the Sandpoint comes to mind), simply configuring a board
> type will allow you to know which processor package is used and further
> the processor core.  If I say "Walnut" configuration, I already know everything
> else, I don't need to be asked all of the other configuration questions.
> Our files should also follow this structure.  The Walnut configuration file
> should include 405GP (which defines peripherals) which should then include
> the processor core definitions (if necessary).  This way, when a new processor
> package with a different peripheral configuration is added, all you need to
> do is ensure the proper lower level core file is included, you don't have
> to update all of the board configuration files with stuff they don't care about.
>
> If, in this example, the Walnut had different processor types available, it
> would make sense within that configuration to ask the processor type, but no
> one else would (nor should) care.  Again, the file structure would follow,
> with the Walnut board configuration including the appropriately configured
> processor package.
>
> Thanks.
>
>         -- Dan


If I understand correctly, you are talking only about the configuration
structure, not the header file structure -- so a different topic than
what this thread has been.  Please correct me if you are also talking
about header file structure.

arch/ppc/config.in has already been changed to match what you propose.

-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

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

Re: include/asm-ppc/platforms/

[Dan Malek]

Frank Rowand wrote:



> If I understand correctly, you are talking only about the configuration
> structure, not the header file structure -- so a different topic than
> what this thread has been.

I'm talking about both.  Yes, I know the configuration has been mostly
changed, but today the ibm4xx.h file includes ibm405gp.h which then
includes walnut.h.  This is totally backward.  The ibm4xx.h file should
include walnut.h, which should include ibm405gp.h, which should include
a core or peripheral definition file if necessary.

The ibm4xx.h file (and the mpc8xx.h file) should be replaced by an
appropriate platform.h file which would remove all of the ifdefs we
currently have in the include lists of the C files and some of the
problems with multiple definitions these ifdefs are in place to solve.

Thanks.


	-- Dan


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

Re: include/asm-ppc/platforms/

[Tom Rini]

On Sat, Dec 01, 2001 at 05:22:47PM -0500, Dan Malek wrote:
>
> Frank Rowand wrote:
>
>
>
> >If I understand correctly, you are talking only about the configuration
> >structure, not the header file structure -- so a different topic than
> >what this thread has been.
>
> I'm talking about both.  Yes, I know the configuration has been mostly
> changed, but today the ibm4xx.h file includes ibm405gp.h which then
> includes walnut.h.  This is totally backward.

It used to be like that.  It's now ibm4xx.h -> board.h -> proc.h

> The ibm4xx.h file (and the mpc8xx.h file) should be replaced by an
> appropriate platform.h file which would remove all of the ifdefs we
> currently have in the include lists of the C files and some of the
> problems with multiple definitions these ifdefs are in place to solve.

Maybe we can do this in 2.5.  We've already got the bits around for
making symlinks from CONFIG_FOO -> foo.h, and an empty foo.h if it
doesn't exist.  So we could do CONFIG_8xx -> symlink
include/asm-ppc/platform to mpc-8xx, and so on..

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

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

Re: include/asm-ppc/platforms/

[Armin Kuster]

Paul Mackerras wrote:
>
> Basically I want the knowledge that "because this is a 405gp chip we
> must have an XYZ ethernet controller at address FOO using interrupt
> N" to be concentrated in one place, not spread out through the
> code.  Then when IBM brings out a 405gp-A that has two XYZ's (neither
> of which are at the same address as in the 405gp) there is just one
> place that we have to change.
>

Exactly.

Actual its an issue for the NP405H & L.  I will outline how this can be
addressed soon + all the other 4xx internal pripherials.

> Paul.
>

--armin

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

include/asm-ppc/platforms/

[Paul Mackerras]

I want to create a new directory, include/asm-ppc/platforms, for those
files which mainly contain configuration information for specific
platforms, such as address and IRQ assignments for on-board devices.
The files that I want to move into include/asm-ppc/platforms are:

bseip.h		  ibm405gp.h	    mvme5100_serial.h	  rpxclassic.h
ccm.h		  ibmnp405.h	    oak.h		  rpxhiox.h
ceder.h		  ibmstbx.h	    pcu_e.h		  rpxlite.h
cpci405.h	  ip860.h	    powerpmc250.h	  sandpoint_serial.h
ep405.h		  ivms8.h	    powerpmc250_serial.h  spd8xx.h
est8260.h	  lantec.h	    ppc4xx_serial.h	  spruce.h
ev64260_serial.h  lopec_serial.h    prpmc750.h		  spruce_serial.h
fads.h		  lwmon.h	    prpmc750_serial.h	  tqm8260.h
gemini.h	  mbx.h		    prpmc800.h		  tqm8xx.h
gemini_serial.h   mcpn765_serial.h  prpmc800_serial.h	  walnut.h
hermes.h	  mvme5100.h	    redwood.h		  zx4500_serial.h

This requires corresponding minor changes to 14 files in
arch/ppc/platforms and 5 files in include/asm-ppc, plus some changes
in the files that move to include/asm-ppc/platforms.

Does anyone have any comments or objections?

Paul.

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

Re: include/asm-ppc/platforms/

[Tom Rini]

On Tue, Nov 27, 2001 at 10:32:40PM +1100, Paul Mackerras wrote:

> I want to create a new directory, include/asm-ppc/platforms, for those
> files which mainly contain configuration information for specific
> platforms, such as address and IRQ assignments for on-board devices.
> The files that I want to move into include/asm-ppc/platforms are:
[snip]

What about:
amgia*.h ans-lcd.h backlight.h heathrow.h keylargo.h pmac_feature.h
prep_nvram.h gg2.h uninorth.h and maybe ppc405_dma.h as well.  I think I
might have missed a few pmac-specific platform headers in there...

> This requires corresponding minor changes to 14 files in
> arch/ppc/platforms and 5 files in include/asm-ppc, plus some changes
> in the files that move to include/asm-ppc/platforms.
>
> Does anyone have any comments or objections?

Like I said on IRC, I don't think this really helps much.  I will
conceed that in _devel we have more .h files in include/asm-$(ARCH) than
anyone else, but if we're going to do some organization, lets do more
than throwing lots of files in one directory, which could keep on
growing...

I sort of like the include/asm-ppc/platforms symlink idea, but I forget
if kbuild-2.5 works well with this or if it is/was painful.  Keith?

Barring that, maybe make processor, platform and peripheral dirs?

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

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

Re: include/asm-ppc/platforms/

[Roman Zippel]

Hi,

Tom Rini wrote:

> What about:
> amgia*.h ans-lcd.h backlight.h heathrow.h keylargo.h pmac_feature.h
> prep_nvram.h gg2.h uninorth.h and maybe ppc405_dma.h as well.  I think I
> might have missed a few pmac-specific platform headers in there...

Be careful with amiga*.h, there are included by several drivers, which
also have to continue to work under m68k.

bye, Roman

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

Re: include/asm-ppc/platforms/

[Keith Owens]

On Tue, 27 Nov 2001 08:22:44 -0700,
Tom Rini <trini@kernel.crashing.org> wrote:
>I sort of like the include/asm-ppc/platforms symlink idea, but I forget
>if kbuild-2.5 works well with this or if it is/was painful.  Keith?

It is only painful it you want to generate files in that directory at
compile time, you have to jump through hoops to prevent the files being
written to the source tree when source and object are seperate
directories.  Symlinks for read only files are not a problem.


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

Re: include/asm-ppc/platforms/

[Dan Malek]

Paul Mackerras wrote:


> Does anyone have any comments or objections?

That's a pretty good idea, and I have another one.  Name the
directory include/asm-ppc/ppc-platforms or something, then
have a symbolic link
	include/asm/platform -> include/asm-ppc/ppc-platforms/<board-file>

That way we can just #include <platform.h> instead of having lots
of ifdefs in upper level files to determine which one is needed.  If
we are moving files around, let's have some effect on actually making
it easier to use them, too.

Thanks.


	-- Dan


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

Re: include/asm-ppc/platforms/

[Matt Porter]

On Thu, Dec 27, 2001 at 09:59:59AM -0500, Dan Malek wrote:
>
> Paul Mackerras wrote:
>
>
> > Does anyone have any comments or objections?
>
> That's a pretty good idea, and I have another one.  Name the
> directory include/asm-ppc/ppc-platforms or something, then
> have a symbolic link
> 	include/asm/platform -> include/asm-ppc/ppc-platforms/<board-file>
>
> That way we can just #include <platform.h> instead of having lots
> of ifdefs in upper level files to determine which one is needed.  If
> we are moving files around, let's have some effect on actually making
> it easier to use them, too.

Yes, this is similar to what has worked well in the arm tree.

--
Matt Porter
MontaVista Software, INc.
mporter@mvista.com

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

Re: include/asm-ppc/platforms/

[Geert Uytterhoeven]

On Tue, 27 Nov 2001, Matt Porter wrote:
> On Thu, Dec 27, 2001 at 09:59:59AM -0500, Dan Malek wrote:
> > Paul Mackerras wrote:
> > > Does anyone have any comments or objections?
> >
> > That's a pretty good idea, and I have another one.  Name the
> > directory include/asm-ppc/ppc-platforms or something, then
> > have a symbolic link
> > 	include/asm/platform -> include/asm-ppc/ppc-platforms/<board-file>
> >
> > That way we can just #include <platform.h> instead of having lots
> > of ifdefs in upper level files to determine which one is needed.  If
> > we are moving files around, let's have some effect on actually making
> > it easier to use them, too.
>
> Yes, this is similar to what has worked well in the arm tree.

Note that ARM has include/asm-arm/arch-$(PLATFORM)/, i.e. a whole directory
with platform-specific files, not a single header file.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: include/asm-ppc/platforms/

[Dan Malek]

>> have a symbolic link
>> 	include/asm/platform -> include/asm-ppc/ppc-platforms/<board-file>

Oooops.  I meant 'include/asm/platform.h'.......


	-- Dan


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

Re: include/asm-ppc/platforms/

[Wolfgang Denk]

In message <3C2B376F.9070508@embeddededge.com> you wrote:
>
> That's a pretty good idea, and I have another one.  Name the
> directory include/asm-ppc/ppc-platforms or something, then
> have a symbolic link
> 	include/asm/platform -> include/asm-ppc/ppc-platforms/<board-file>

Isn't that redundand?

IMHO "include/asm/platform -> include/asm-ppc/platforms/<board-file>"
would do just fine - I don't expect anyone to create a
include/asm-ppc/i386-platforms/ directory?


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
People with narrow minds usually have broad tongues.

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

Re: include/asm-ppc/platforms/

[Paul Mackerras]

Dan Malek writes:

> That's a pretty good idea, and I have another one.  Name the
> directory include/asm-ppc/ppc-platforms or something, then
> have a symbolic link
> 	include/asm/platform -> include/asm-ppc/ppc-platforms/<board-file>
>
> That way we can just #include <platform.h> instead of having lots
> of ifdefs in upper level files to determine which one is needed.  If
> we are moving files around, let's have some effect on actually making
> it easier to use them, too.

I have figured out a way to do this without too much pain.  The idea
is that we will have platform.h and platform-serial.h be symlinks to
files in include/asm-ppc/platforms/.  The way that I am suggesting
that we do this is to have special comments in those files (the ones
in include/asm-ppc/platforms) that say what should be symlinked, like
this, from include/asm-ppc/platforms/all_ppc_serial.h:

/* Link to platform_serial.h if CONFIG_ALL_PPC=y */

The comment has to be of the form:

/* Link to <filename> if CONFIG_<option>=y */

and filename can't contain slashes.

The patch below does all this.  It does mean that we will need a
platform header for every platform, and a platform_serial header for
every platform where we want to use the standard serial driver.  As an
example, I have made an all_ppc_serial.h that contains most of what
was in serial.h before.  In fact, with a bit of care we could make
serial.h be the symlink.

Note that we can use one header for multiple platforms, just by
putting multiple magic comments in.  We can also potentially use this
mechanism for config options other than the platform selection
options.

Thoughts?

Paul.

diff -urN linuxppc_2_4_devel/arch/ppc/Makefile pmac/arch/ppc/Makefile
--- linuxppc_2_4_devel/arch/ppc/Makefile	Wed Nov 14 02:50:13 2001
+++ pmac/arch/ppc/Makefile	Wed Nov 28 16:22:01 2001
@@ -14,6 +14,8 @@
 # Rewritten by Cort Dougan and Paul Mackerras
 #

+MRPROPER_FILES += include/asm-ppc/platform.h include/asm-ppc/platform-serial.h
+
 # Be sure to change PAGE_OFFSET in include/asm-ppc/page.h to match
 KERNELLOAD	=0xc0000000

@@ -123,5 +125,11 @@

 archmrproper:

-archdep: scripts/mkdep
+archdep: scripts/mkdep platformlinks
 	$(MAKEBOOT) fastdep
+
+platformlinks:
+	rm -f include/asm-ppc/platform.h
+	rm -f include/asm-ppc/platform-serial.h
+	grep '=y$$' .config | grep -f - include/asm-ppc/platforms/*.h | \
+	awk -f arch/ppc/mklinks.awk
diff -urN linuxppc_2_4_devel/arch/ppc/mklinks.awk pmac/arch/ppc/mklinks.awk
--- linuxppc_2_4_devel/arch/ppc/mklinks.awk	Thu Jan 01 10:00:00 1970
+++ pmac/arch/ppc/mklinks.awk	Wed Nov 28 16:33:48 2001
@@ -0,0 +1,8 @@
+/^[-_A-Za-z0-9.\/]+:\/\* Link to [-_A-Za-z0-9.]+ if CONFIG.* \*\/$/ {
+	target=$1;
+	gsub(/:.*$/, "", target);
+	gsub(/^include\/asm-ppc\//, "", target);
+	link="include/asm-ppc/" $4;
+	print link " -> " target;
+	system("ln -sf " target " " link);
+}
diff -urN linuxppc_2_4_devel/include/asm-ppc/platforms/all_ppc_serial.h pmac/include/asm-ppc/platforms/all_ppc_serial.h
--- linuxppc_2_4_devel/include/asm-ppc/platforms/all_ppc_serial.h	Thu Jan 01 10:00:00 1970
+++ pmac/include/asm-ppc/platforms/all_ppc_serial.h	Wed Nov 28 16:42:57 2001
@@ -0,0 +1,128 @@
+/*
+ * Platform-specific header for serial devices on
+ * the (badly-named) ALL_PPC platform.
+ */
+
+/* Link to platform_serial.h if CONFIG_ALL_PPC=y */
+
+#include <linux/config.h>
+#include <asm/processor.h>
+
+/*
+ * This assumes you have a 1.8432 MHz clock for your UART.
+ *
+ * It'd be nice if someone built a serial card with a 24.576 MHz
+ * clock, since the 16550A is capable of handling a top speed of 1.5
+ * megabits/second; but this requires the faster clock.
+ */
+#define BASE_BAUD ( 1843200 / 16 )
+
+#if defined(CONFIG_MAC_SERIAL)
+#define SERIAL_DEV_OFFSET	((_machine == _MACH_prep || _machine == _MACH_chrp) ? 0 : 2)
+#endif
+
+#ifdef CONFIG_SERIAL_MANY_PORTS
+#define RS_TABLE_SIZE  64
+#else
+#define RS_TABLE_SIZE  4
+#endif
+
+/* Standard COM flags (except for COM4, because of the 8514 problem) */
+#ifdef CONFIG_SERIAL_DETECT_IRQ
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ)
+#define STD_COM4_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
+#else
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
+#define STD_COM4_FLAGS ASYNC_BOOT_AUTOCONF
+#endif
+
+#ifdef CONFIG_SERIAL_MANY_PORTS
+#define FOURPORT_FLAGS ASYNC_FOURPORT
+#define ACCENT_FLAGS 0
+#define BOCA_FLAGS 0
+#define HUB6_FLAGS 0
+#endif
+
+/*
+ * The following define the access methods for the HUB6 card. All
+ * access is through two ports for all 24 possible chips. The card is
+ * selected through the high 2 bits, the port on that card with the
+ * "middle" 3 bits, and the register on that port with the bottom
+ * 3 bits.
+ *
+ * While the access port and interrupt is configurable, the default
+ * port locations are 0x302 for the port control register, and 0x303
+ * for the data read/write register. Normally, the interrupt is at irq3
+ * but can be anything from 3 to 7 inclusive. Note that using 3 will
+ * require disabling com2.
+ */
+
+#define C_P(card,port) (((card)<<6|(port)<<3) + 1)
+
+#define STD_SERIAL_PORT_DEFNS			\
+	/* UART CLK   PORT IRQ     FLAGS        */			\
+	{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS },	/* ttyS0 */	\
+	{ 0, BASE_BAUD, 0x2F8, 3, STD_COM_FLAGS },	/* ttyS1 */	\
+	{ 0, BASE_BAUD, 0x3E8, 4, STD_COM_FLAGS },	/* ttyS2 */	\
+	{ 0, BASE_BAUD, 0x2E8, 3, STD_COM4_FLAGS },	/* ttyS3 */
+
+
+#ifdef CONFIG_SERIAL_MANY_PORTS
+#define EXTRA_SERIAL_PORT_DEFNS			\
+	{ 0, BASE_BAUD, 0x1A0, 9, FOURPORT_FLAGS }, 	/* ttyS4 */	\
+	{ 0, BASE_BAUD, 0x1A8, 9, FOURPORT_FLAGS },	/* ttyS5 */	\
+	{ 0, BASE_BAUD, 0x1B0, 9, FOURPORT_FLAGS },	/* ttyS6 */	\
+	{ 0, BASE_BAUD, 0x1B8, 9, FOURPORT_FLAGS },	/* ttyS7 */	\
+	{ 0, BASE_BAUD, 0x2A0, 5, FOURPORT_FLAGS },	/* ttyS8 */	\
+	{ 0, BASE_BAUD, 0x2A8, 5, FOURPORT_FLAGS },	/* ttyS9 */	\
+	{ 0, BASE_BAUD, 0x2B0, 5, FOURPORT_FLAGS },	/* ttyS10 */	\
+	{ 0, BASE_BAUD, 0x2B8, 5, FOURPORT_FLAGS },	/* ttyS11 */	\
+	{ 0, BASE_BAUD, 0x330, 4, ACCENT_FLAGS },	/* ttyS12 */	\
+	{ 0, BASE_BAUD, 0x338, 4, ACCENT_FLAGS },	/* ttyS13 */	\
+	{ 0, BASE_BAUD, 0x000, 0, 0 },	/* ttyS14 (spare) */		\
+	{ 0, BASE_BAUD, 0x000, 0, 0 },	/* ttyS15 (spare) */		\
+	{ 0, BASE_BAUD, 0x100, 12, BOCA_FLAGS },	/* ttyS16 */	\
+	{ 0, BASE_BAUD, 0x108, 12, BOCA_FLAGS },	/* ttyS17 */	\
+	{ 0, BASE_BAUD, 0x110, 12, BOCA_FLAGS },	/* ttyS18 */	\
+	{ 0, BASE_BAUD, 0x118, 12, BOCA_FLAGS },	/* ttyS19 */	\
+	{ 0, BASE_BAUD, 0x120, 12, BOCA_FLAGS },	/* ttyS20 */	\
+	{ 0, BASE_BAUD, 0x128, 12, BOCA_FLAGS },	/* ttyS21 */	\
+	{ 0, BASE_BAUD, 0x130, 12, BOCA_FLAGS },	/* ttyS22 */	\
+	{ 0, BASE_BAUD, 0x138, 12, BOCA_FLAGS },	/* ttyS23 */	\
+	{ 0, BASE_BAUD, 0x140, 12, BOCA_FLAGS },	/* ttyS24 */	\
+	{ 0, BASE_BAUD, 0x148, 12, BOCA_FLAGS },	/* ttyS25 */	\
+	{ 0, BASE_BAUD, 0x150, 12, BOCA_FLAGS },	/* ttyS26 */	\
+	{ 0, BASE_BAUD, 0x158, 12, BOCA_FLAGS },	/* ttyS27 */	\
+	{ 0, BASE_BAUD, 0x160, 12, BOCA_FLAGS },	/* ttyS28 */	\
+	{ 0, BASE_BAUD, 0x168, 12, BOCA_FLAGS },	/* ttyS29 */	\
+	{ 0, BASE_BAUD, 0x170, 12, BOCA_FLAGS },	/* ttyS30 */	\
+	{ 0, BASE_BAUD, 0x178, 12, BOCA_FLAGS },	/* ttyS31 */
+#else
+#define EXTRA_SERIAL_PORT_DEFNS
+#endif
+
+/* You can have up to four HUB6's in the system, but I've only
+ * included two cards here for a total of twelve ports.
+ */
+#if (defined(CONFIG_HUB6) && defined(CONFIG_SERIAL_MANY_PORTS))
+#define HUB6_SERIAL_PORT_DFNS		\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,0) },  /* ttyS32 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,1) },  /* ttyS33 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,2) },  /* ttyS34 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,3) },  /* ttyS35 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,4) },  /* ttyS36 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,5) },  /* ttyS37 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,0) },  /* ttyS38 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,1) },  /* ttyS39 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,2) },  /* ttyS40 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,3) },  /* ttyS41 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,4) },  /* ttyS42 */	\
+	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,5) },  /* ttyS43 */
+#else
+#define HUB6_SERIAL_PORT_DFNS
+#endif
+
+#define SERIAL_PORT_DFNS		\
+	STD_SERIAL_PORT_DEFNS		\
+	EXTRA_SERIAL_PORT_DEFNS		\
+	HUB6_SERIAL_PORT_DFNS
diff -urN linuxppc_2_4_devel/include/asm-ppc/serial.h pmac/include/asm-ppc/serial.h
--- linuxppc_2_4_devel/include/asm-ppc/serial.h	Wed Nov 28 10:22:04 2001
+++ pmac/include/asm-ppc/serial.h	Wed Nov 28 16:54:03 2001
@@ -9,149 +9,7 @@
 #ifndef __ASM_SERIAL_H__
 #define __ASM_SERIAL_H__

-#include <linux/config.h>
+#include <asm/platform_serial.h>

-#if defined(CONFIG_EV64260)
-#include <asm/platforms/ev64260_serial.h>
-#elif defined(CONFIG_GEMINI)
-#include <asm/platforms/gemini_serial.h>
-#elif defined(CONFIG_POWERPMC250)
-#include <asm/platforms/powerpmc250_serial.h>
-#elif defined(CONFIG_LOPEC)
-#include <asm/platforms/lopec_serial.h>
-#elif defined(CONFIG_MCPN765)
-#include <asm/platforms/mcpn765_serial.h>
-#elif defined(CONFIG_MVME5100)
-#include <asm/platforms/mvme5100_serial.h>
-#elif defined(CONFIG_PRPMC750)
-#include <asm/platforms/prpmc750_serial.h>
-#elif defined(CONFIG_PRPMC800)
-#include <asm/platforms/prpmc800_serial.h>
-#elif defined(CONFIG_SANDPOINT)
-#include <asm/platforms/sandpoint_serial.h>
-#elif defined(CONFIG_SPRUCE)
-#include <asm/platforms/spruce_serial.h>
-#elif defined(CONFIG_ZX4500)
-#include <asm/platforms/zx4500_serial.h>
-#elif defined(CONFIG_4xx)
-#include <asm/platforms/ppc4xx_serial.h>
-#else
-
-/*
- * This assumes you have a 1.8432 MHz clock for your UART.
- *
- * It'd be nice if someone built a serial card with a 24.576 MHz
- * clock, since the 16550A is capable of handling a top speed of 1.5
- * megabits/second; but this requires the faster clock.
- */
-#define BASE_BAUD ( 1843200 / 16 )
-
-#ifdef CONFIG_SERIAL_MANY_PORTS
-#define RS_TABLE_SIZE  64
-#else
-#define RS_TABLE_SIZE  4
-#endif
-
-/* Standard COM flags (except for COM4, because of the 8514 problem) */
-#ifdef CONFIG_SERIAL_DETECT_IRQ
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ)
-#define STD_COM4_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
-#else
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
-#define STD_COM4_FLAGS ASYNC_BOOT_AUTOCONF
-#endif
-
-#ifdef CONFIG_SERIAL_MANY_PORTS
-#define FOURPORT_FLAGS ASYNC_FOURPORT
-#define ACCENT_FLAGS 0
-#define BOCA_FLAGS 0
-#define HUB6_FLAGS 0
-#endif
-
-/*
- * The following define the access methods for the HUB6 card. All
- * access is through two ports for all 24 possible chips. The card is
- * selected through the high 2 bits, the port on that card with the
- * "middle" 3 bits, and the register on that port with the bottom
- * 3 bits.
- *
- * While the access port and interrupt is configurable, the default
- * port locations are 0x302 for the port control register, and 0x303
- * for the data read/write register. Normally, the interrupt is at irq3
- * but can be anything from 3 to 7 inclusive. Note that using 3 will
- * require disabling com2.
- */
-
-#define C_P(card,port) (((card)<<6|(port)<<3) + 1)
-
-#define STD_SERIAL_PORT_DEFNS			\
-	/* UART CLK   PORT IRQ     FLAGS        */			\
-	{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS },	/* ttyS0 */	\
-	{ 0, BASE_BAUD, 0x2F8, 3, STD_COM_FLAGS },	/* ttyS1 */	\
-	{ 0, BASE_BAUD, 0x3E8, 4, STD_COM_FLAGS },	/* ttyS2 */	\
-	{ 0, BASE_BAUD, 0x2E8, 3, STD_COM4_FLAGS },	/* ttyS3 */
-
-
-#ifdef CONFIG_SERIAL_MANY_PORTS
-#define EXTRA_SERIAL_PORT_DEFNS			\
-	{ 0, BASE_BAUD, 0x1A0, 9, FOURPORT_FLAGS }, 	/* ttyS4 */	\
-	{ 0, BASE_BAUD, 0x1A8, 9, FOURPORT_FLAGS },	/* ttyS5 */	\
-	{ 0, BASE_BAUD, 0x1B0, 9, FOURPORT_FLAGS },	/* ttyS6 */	\
-	{ 0, BASE_BAUD, 0x1B8, 9, FOURPORT_FLAGS },	/* ttyS7 */	\
-	{ 0, BASE_BAUD, 0x2A0, 5, FOURPORT_FLAGS },	/* ttyS8 */	\
-	{ 0, BASE_BAUD, 0x2A8, 5, FOURPORT_FLAGS },	/* ttyS9 */	\
-	{ 0, BASE_BAUD, 0x2B0, 5, FOURPORT_FLAGS },	/* ttyS10 */	\
-	{ 0, BASE_BAUD, 0x2B8, 5, FOURPORT_FLAGS },	/* ttyS11 */	\
-	{ 0, BASE_BAUD, 0x330, 4, ACCENT_FLAGS },	/* ttyS12 */	\
-	{ 0, BASE_BAUD, 0x338, 4, ACCENT_FLAGS },	/* ttyS13 */	\
-	{ 0, BASE_BAUD, 0x000, 0, 0 },	/* ttyS14 (spare) */		\
-	{ 0, BASE_BAUD, 0x000, 0, 0 },	/* ttyS15 (spare) */		\
-	{ 0, BASE_BAUD, 0x100, 12, BOCA_FLAGS },	/* ttyS16 */	\
-	{ 0, BASE_BAUD, 0x108, 12, BOCA_FLAGS },	/* ttyS17 */	\
-	{ 0, BASE_BAUD, 0x110, 12, BOCA_FLAGS },	/* ttyS18 */	\
-	{ 0, BASE_BAUD, 0x118, 12, BOCA_FLAGS },	/* ttyS19 */	\
-	{ 0, BASE_BAUD, 0x120, 12, BOCA_FLAGS },	/* ttyS20 */	\
-	{ 0, BASE_BAUD, 0x128, 12, BOCA_FLAGS },	/* ttyS21 */	\
-	{ 0, BASE_BAUD, 0x130, 12, BOCA_FLAGS },	/* ttyS22 */	\
-	{ 0, BASE_BAUD, 0x138, 12, BOCA_FLAGS },	/* ttyS23 */	\
-	{ 0, BASE_BAUD, 0x140, 12, BOCA_FLAGS },	/* ttyS24 */	\
-	{ 0, BASE_BAUD, 0x148, 12, BOCA_FLAGS },	/* ttyS25 */	\
-	{ 0, BASE_BAUD, 0x150, 12, BOCA_FLAGS },	/* ttyS26 */	\
-	{ 0, BASE_BAUD, 0x158, 12, BOCA_FLAGS },	/* ttyS27 */	\
-	{ 0, BASE_BAUD, 0x160, 12, BOCA_FLAGS },	/* ttyS28 */	\
-	{ 0, BASE_BAUD, 0x168, 12, BOCA_FLAGS },	/* ttyS29 */	\
-	{ 0, BASE_BAUD, 0x170, 12, BOCA_FLAGS },	/* ttyS30 */	\
-	{ 0, BASE_BAUD, 0x178, 12, BOCA_FLAGS },	/* ttyS31 */
-#else
-#define EXTRA_SERIAL_PORT_DEFNS
-#endif
-
-/* You can have up to four HUB6's in the system, but I've only
- * included two cards here for a total of twelve ports.
- */
-#if (defined(CONFIG_HUB6) && defined(CONFIG_SERIAL_MANY_PORTS))
-#define HUB6_SERIAL_PORT_DFNS		\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,0) },  /* ttyS32 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,1) },  /* ttyS33 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,2) },  /* ttyS34 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,3) },  /* ttyS35 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,4) },  /* ttyS36 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(0,5) },  /* ttyS37 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,0) },  /* ttyS38 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,1) },  /* ttyS39 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,2) },  /* ttyS40 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,3) },  /* ttyS41 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,4) },  /* ttyS42 */	\
-	{ 0, BASE_BAUD, 0x302, 3, HUB6_FLAGS, C_P(1,5) },  /* ttyS43 */
-#else
-#define HUB6_SERIAL_PORT_DFNS
-#endif
-
-#define SERIAL_PORT_DFNS		\
-	STD_SERIAL_PORT_DEFNS		\
-	EXTRA_SERIAL_PORT_DEFNS		\
-	HUB6_SERIAL_PORT_DFNS
-
-#endif /* !CONFIG_GEMINI and others */
 #endif /* __ASM_SERIAL_H__ */
 #endif /* __KERNEL__ */

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

Re: include/asm-ppc/platforms/

[Dan Malek]

Paul Mackerras wrote:


> I have figured out a way to do this without too much pain.  The idea
> is that we will have platform.h and platform-serial.h be symlinks ....

> Thoughts?


Cool (although I really dislike looking at that serial.h file :-).

Thanks.

	-- Dan


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

Re: include/asm-ppc/platforms/

[Paul Mackerras]

I have run the platform.h stuff past Keith Owens, the kbuild
maintainer.  He makes several points:

* He much prefers generated files (including symlinks) to be created
  in arch/$(ARCH) rather than include.  In particular he doesn't like
  mixing supplied and generated headers in the one directory.

* He prefers a copy rather than a symlink, particularly for
  kbuild-2.5, so that we have real pathnames and timestamps in the
  dependency tree.

* He wrote a new script that uses sed rather than awk, checks a few
  things (e.g. exactly one platform.h file is selected) and also
  creates empty files if e.g. no platform_serial.h file is selected.

The only reason for having include/asm-ppc/platforms under
include/asm-ppc is so that serial.h can include the right
blah_serial.h file.  We can get around that by using
early_serial_setup except that that doesn't work if the serial driver
is built as a module.  The boot stuff also needs to get at the first
serial port but we can manage that by requiring the platform.h file to
define e.g. BOOT_SERIAL_ADDRESS, BOOT_SERIAL_REG_SHIFT, etc., if it
wants to use a serial port in the boot wrapper.  The boot wrapper code
then just does #include <platform.h>.

Alternatively we can add a -Iarch/$(ARCH) flag for cc and put
platform.h in arch/ppc and the platform headers in
arch/ppc/platforms.  This is Keith's preferred solution and it feels
right to me too.

Platform maintainers can continue to statically initialize rs_table
for their serial ports if they wish.  I think I will move all those
crufty old fourport, accent, boca and hub6 declarations into
include/asm-ppc/isa_serial.h so that they are still available but not
getting in our faces all the time.

Comments?

Paul.

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

Re: include/asm-ppc/platforms/

[Tom Rini]

On Thu, Nov 29, 2001 at 10:48:46PM +1100, Paul Mackerras wrote:

> The only reason for having include/asm-ppc/platforms under
> include/asm-ppc is so that serial.h can include the right
> blah_serial.h file.  We can get around that by using
> early_serial_setup except that that doesn't work if the serial driver
> is built as a module.  The boot stuff also needs to get at the first
> serial port but we can manage that by requiring the platform.h file to
> define e.g. BOOT_SERIAL_ADDRESS, BOOT_SERIAL_REG_SHIFT, etc., if it
> wants to use a serial port in the boot wrapper.  The boot wrapper code
> then just does #include <platform.h>.

What would <asm/serial.h> contain here?  Keep in mind that some ports
'just work' with the default <asm/serial.h>.

> Alternatively we can add a -Iarch/$(ARCH) flag for cc and put
> platform.h in arch/ppc and the platform headers in
> arch/ppc/platforms.  This is Keith's preferred solution and it feels
> right to me too.

This would probably be better.

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

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

Re: include/asm-ppc/platforms/

[Keith Owens]

On Thu, 29 Nov 2001 08:26:25 -0700,
Tom Rini <trini@kernel.crashing.org> wrote:
>On Thu, Nov 29, 2001 at 10:48:46PM +1100, Paul Mackerras wrote:
>> The only reason for having include/asm-ppc/platforms under
>> include/asm-ppc is so that serial.h can include the right
>> blah_serial.h file.  We can get around that by using
>> early_serial_setup except that that doesn't work if the serial driver
>> is built as a module.  The boot stuff also needs to get at the first
>> serial port but we can manage that by requiring the platform.h file to
>> define e.g. BOOT_SERIAL_ADDRESS, BOOT_SERIAL_REG_SHIFT, etc., if it
>> wants to use a serial port in the boot wrapper.  The boot wrapper code
>> then just does #include <platform.h>.
>
>What would <asm/serial.h> contain here?  Keep in mind that some ports
>'just work' with the default <asm/serial.h>.

The make rules I sent to Paul automatically generate platform.h and
platform_serial.h by copying the platform specific files to arch/ppc
under standard names.  If the platform has no *_serial.h file then
platform_serial.h is a zero length file.  So ppc code can always

#include <platform.h>
#include <platform_serial.h>

without #ifdef in the main code.


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

Re: include/asm-ppc/platforms/

[Tom Rini]

On Fri, Nov 30, 2001 at 09:19:20AM +1100, Keith Owens wrote:
> On Thu, 29 Nov 2001 08:26:25 -0700,
> Tom Rini <trini@kernel.crashing.org> wrote:
> >On Thu, Nov 29, 2001 at 10:48:46PM +1100, Paul Mackerras wrote:
> >> The only reason for having include/asm-ppc/platforms under
> >> include/asm-ppc is so that serial.h can include the right
> >> blah_serial.h file.  We can get around that by using
> >> early_serial_setup except that that doesn't work if the serial driver
> >> is built as a module.  The boot stuff also needs to get at the first
> >> serial port but we can manage that by requiring the platform.h file to
> >> define e.g. BOOT_SERIAL_ADDRESS, BOOT_SERIAL_REG_SHIFT, etc., if it
> >> wants to use a serial port in the boot wrapper.  The boot wrapper code
> >> then just does #include <platform.h>.
> >
> >What would <asm/serial.h> contain here?  Keep in mind that some ports
> >'just work' with the default <asm/serial.h>.
>
> The make rules I sent to Paul automatically generate platform.h and
> platform_serial.h by copying the platform specific files to arch/ppc
> under standard names.  If the platform has no *_serial.h file then
> platform_serial.h is a zero length file.  So ppc code can always
>
> #include <platform.h>
> #include <platform_serial.h>

So <asm/serial.h> just has the above two lines and all platforms need a
platform/platform_serial.h file for serial to work with this scheme?

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

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

Re: include/asm-ppc/platforms/

[Keith Owens]

On Thu, 29 Nov 2001 15:27:41 -0700,
Tom Rini <trini@kernel.crashing.org> wrote:
>On Fri, Nov 30, 2001 at 09:19:20AM +1100, Keith Owens wrote:
>> The make rules I sent to Paul automatically generate platform.h and
>> platform_serial.h by copying the platform specific files to arch/ppc
>> under standard names.  If the platform has no *_serial.h file then
>> platform_serial.h is a zero length file.  So ppc code can always
>>
>> #include <platform.h>
>> #include <platform_serial.h>
>
>So <asm/serial.h> just has the above two lines

Yes.  We don't need no steenking #ifdefs.

>and all platforms need a
>platform/platform_serial.h file for serial to work with this scheme?

No, an empty one is automatically generated if necessary.


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

Re: include/asm-ppc/platforms/

[Tom Rini]

On Fri, Nov 30, 2001 at 09:38:36AM +1100, Keith Owens wrote:
> On Thu, 29 Nov 2001 15:27:41 -0700,
> Tom Rini <trini@kernel.crashing.org> wrote:
> >On Fri, Nov 30, 2001 at 09:19:20AM +1100, Keith Owens wrote:
> >> The make rules I sent to Paul automatically generate platform.h and
> >> platform_serial.h by copying the platform specific files to arch/ppc
> >> under standard names.  If the platform has no *_serial.h file then
> >> platform_serial.h is a zero length file.  So ppc code can always
> >>
> >> #include <platform.h>
> >> #include <platform_serial.h>
> >
> >So <asm/serial.h> just has the above two lines
>
> Yes.  We don't need no steenking #ifdefs.
>
> >and all platforms need a
> >platform/platform_serial.h file for serial to work with this scheme?
>
> No, an empty one is automatically generated if necessary.

So yes, for CONFIG_SERIAL to work, the file needs to exist.  Which has
the downside that at least a handful of platforms will need to cp
all_ppc_serial.h.

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

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

Re: include/asm-ppc/platforms/

[Keith Owens]

On Thu, 29 Nov 2001 15:46:10 -0700,
Tom Rini <trini@kernel.crashing.org> wrote:
>On Fri, Nov 30, 2001 at 09:38:36AM +1100, Keith Owens wrote:
>> Tom Rini <trini@kernel.crashing.org> wrote:
>> >and all platforms need a
>> >platform/platform_serial.h file for serial to work with this scheme?
>>
>> No, an empty one is automatically generated if necessary.
>
>So yes, for CONFIG_SERIAL to work, the file needs to exist.  Which has
>the downside that at least a handful of platforms will need to cp
>all_ppc_serial.h.

Are the *_serial.h files intended as extensions for asm-ppc/serial.h or
as complete replacements for it?  If they are extensions then adding
#include <platform_serial.h> to asm-ppc/serial.h is enough.  If they are
complete replacements then the code is a little harder, but not much.

*.c files include only <asm/serial.h>.  In platform *_serial.h files,
#define REPLACES_PPC_SERIAL_H.  In asm-ppc/serial.h,

#include <platform_serial.h>
#ifndef REPLACES_PPC_SERIAL_H
... default ppc serial definitions
#endif

Do that once and forget about it, instead of needing #ifdef CONFIG for
each platform throughout the code.


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

Re: include/asm-ppc/platforms/

[Tom Rini]

On Fri, Nov 30, 2001 at 10:12:33AM +1100, Keith Owens wrote:
> On Thu, 29 Nov 2001 15:46:10 -0700,
> Tom Rini <trini@kernel.crashing.org> wrote:
> >On Fri, Nov 30, 2001 at 09:38:36AM +1100, Keith Owens wrote:
> >> Tom Rini <trini@kernel.crashing.org> wrote:
> >> >and all platforms need a
> >> >platform/platform_serial.h file for serial to work with this scheme?
> >>
> >> No, an empty one is automatically generated if necessary.
> >
> >So yes, for CONFIG_SERIAL to work, the file needs to exist.  Which has
> >the downside that at least a handful of platforms will need to cp
> >all_ppc_serial.h.
>
> Are the *_serial.h files intended as extensions for asm-ppc/serial.h or
> as complete replacements for it?

They could be <asm/serial.h> yes.

> If they are extensions then adding
> #include <platform_serial.h> to asm-ppc/serial.h is enough.  If they are
> complete replacements then the code is a little harder, but not much.
>
> *.c files include only <asm/serial.h>.  In platform *_serial.h files,
> #define REPLACES_PPC_SERIAL_H.  In asm-ppc/serial.h,
>
> #include <platform_serial.h>
> #ifndef REPLACES_PPC_SERIAL_H
> ... default ppc serial definitions
> #endif

That would probably work best, yes.

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

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

Re: include/asm-ppc/platforms/

[Adrian Cox]

Paul Mackerras wrote:

> The patch below does all this.  It does mean that we will need a
> platform header for every platform, and a platform_serial header for
> every platform where we want to use the standard serial driver.  As an
> example, I have made an all_ppc_serial.h that contains most of what
> was in serial.h before.  In fact, with a bit of care we could make
> serial.h be the symlink.


All my boards now use early_serial_setup() instead of a platform header
file. This approach is simple to write, and requires no modifications
outside the platform_setup.c file. I'd rather not go back to providing
platform specific serial definitions in a header file.

--
Adrian Cox   http://www.humboldt.co.uk/


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

Re: include/asm-ppc/platforms/

[Paul Mackerras]

Adrian Cox writes:

> All my boards now use early_serial_setup() instead of a platform header
> file. This approach is simple to write, and requires no modifications
> outside the platform_setup.c file. I'd rather not go back to providing
> platform specific serial definitions in a header file.

Perfectly reasonable - I wish all the platforms used early_serial_setup.
Would you mind posting your code that does the early_serial_setup calls?

Paul.

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

Re: include/asm-ppc/platforms/

[Adrian Cox]

Paul Mackerras wrote:


> Perfectly reasonable - I wish all the platforms used early_serial_setup.
> Would you mind posting your code that does the early_serial_setup calls?



Mangled by Mozilla below. This is a 7400 board with a memory mapped
uart. It is important to zero out the entries for serial ports that
aren't present, otherwise the serial driver will attempt to use the
traditional locations.



static void __init
tpe3_setup_arch(void)
{
	struct serial_struct req;

	...

	memset(&req, 0, sizeof (req));
	req.line = 0;
	req.io_type = SERIAL_IO_MEM;
	req.iomem_base = (void *) (tpe3_uart_base + 0x10);
	req.baud_base = 6144000 / 16;
	req.irq = 3;
	req.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
	early_serial_setup(&req);
	memset(&req, 0, sizeof (req));
	req.line = 1;
	early_serial_setup(&req);
	req.line = 2;
	early_serial_setup(&req);
	req.line = 3;
	early_serial_setup(&req);

	...
}


--
Adrian Cox   http://www.humboldt.co.uk/


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

Re: include/asm-ppc/platforms/

[Frank Rowand]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

Adrian Cox wrote:
>
> Paul Mackerras wrote:
>
> > Perfectly reasonable - I wish all the platforms used early_serial_setup.
> > Would you mind posting your code that does the early_serial_setup calls?
>
> Mangled by Mozilla below. This is a 7400 board with a memory mapped
> uart. It is important to zero out the entries for serial ports that
> aren't present, otherwise the serial driver will attempt to use the
> traditional locations.
>
> static void __init
> tpe3_setup_arch(void)
> {
>         struct serial_struct req;
>
>         ...
>
>         memset(&req, 0, sizeof (req));
>         req.line = 0;
>         req.io_type = SERIAL_IO_MEM;
>         req.iomem_base = (void *) (tpe3_uart_base + 0x10);
>         req.baud_base = 6144000 / 16;
>         req.irq = 3;
>         req.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
>         early_serial_setup(&req);
>         memset(&req, 0, sizeof (req));
>         req.line = 1;
>         early_serial_setup(&req);
>         req.line = 2;
>         early_serial_setup(&req);
>         req.line = 3;
>         early_serial_setup(&req);
>
>         ...
> }


And a more generic approach (that can pull the port definitions from
a header file) is attached...


-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

[-- Attachment #2: example --]
[-- Type: text/plain, Size: 1908 bytes --]

Date: Wed, 27 Jun 2001 17:55:06 -0700
From: Frank Rowand <frank_rowand@mvista.com>
Reply-To: frowand@mvista.com
Subject: Paulus, Trini: here's how to dynamically register serial port

You guys were discussing how to get rid of all the #ifdef ... includes for
the serial ports, and wondering how to dynamically register ports.  The
interface the serial driver provides for this is early_serial_setup().
Here's an example of using it (this example uses the SERIAL_PORT_DFNS from
ppc4xx_serial.h just because it was already defined there):


        {
#include <linux/serialP.h>

                int k;
                struct serial_struct req;
                struct serial_state tmp_rs_table[RS_TABLE_SIZE] = {
                        SERIAL_PORT_DFNS   /* Defined in ppc4xx_serial.h */
                };

                for (k = 0; k < RS_TABLE_SIZE; k++) {
                        if (tmp_rs_table[k].iomem_base != 0) {

        req.baud_base       = tmp_rs_table[k].baud_base;
        req.port            = tmp_rs_table[k].port;
        req.port_high       = 0;
        req.irq             = tmp_rs_table[k].irq;
        req.flags           = tmp_rs_table[k].flags;
        req.close_delay     = tmp_rs_table[k].close_delay;
        req.io_type         = tmp_rs_table[k].io_type;
        req.hub6            = tmp_rs_table[k].hub6;
        req.iomem_base      = ioremap((int)tmp_rs_table[k].iomem_base, PAGE_SIZE);
        req.iomem_reg_shift = tmp_rs_table[k].iomem_reg_shift;
        req.type            = tmp_rs_table[k].type;
        req.xmit_fifo_size  = tmp_rs_table[k].xmit_fifo_size;
        req.custom_divisor  = tmp_rs_table[k].custom_divisor;
        req.closing_wait    = tmp_rs_table[k].closing_wait;

                                early_serial_setup(&req);
                        }
                }
        }


-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

Re: include/asm-ppc/platforms/

[Tom Rini]

On Wed, Nov 28, 2001 at 08:46:59AM +0000, Adrian Cox wrote:
>
> Paul Mackerras wrote:
>
> >The patch below does all this.  It does mean that we will need a
> >platform header for every platform, and a platform_serial header for
> >every platform where we want to use the standard serial driver.  As an
> >example, I have made an all_ppc_serial.h that contains most of what
> >was in serial.h before.  In fact, with a bit of care we could make
> >serial.h be the symlink.
>
> All my boards now use early_serial_setup() instead of a platform header
> file. This approach is simple to write, and requires no modifications
> outside the platform_setup.c file. I'd rather not go back to providing
> platform specific serial definitions in a header file.

What do you use for a bootloader tho?  I'm guessing PPCBoot.  The
in-kernel wrappers have a basic serial driver and need to know about
these things.

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

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

Re: include/asm-ppc/platforms/

[Paul Mackerras]

Adrian Cox writes:

> All my boards now use early_serial_setup() instead of a platform header
> file. This approach is simple to write, and requires no modifications
> outside the platform_setup.c file. I'd rather not go back to providing
> platform specific serial definitions in a header file.

I have just realized again that this is not possible if the serial
driver is built as a module, since you don't get the chance to call
early_serial_init between when it is loaded and when rs_init (which is
the module init function) is called.

Paul.

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

Re: include/asm-ppc/platforms/

[Tom Rini]

On Wed, Nov 28, 2001 at 05:13:30PM +1100, Paul Mackerras wrote:
>
> Dan Malek writes:
>
> > That's a pretty good idea, and I have another one.  Name the
> > directory include/asm-ppc/ppc-platforms or something, then
> > have a symbolic link
> > 	include/asm/platform -> include/asm-ppc/ppc-platforms/<board-file>
> >
> > That way we can just #include <platform.h> instead of having lots
> > of ifdefs in upper level files to determine which one is needed.  If
> > we are moving files around, let's have some effect on actually making
> > it easier to use them, too.
>
> I have figured out a way to do this without too much pain.  The idea
> is that we will have platform.h and platform-serial.h be symlinks to
> files in include/asm-ppc/platforms/.  The way that I am suggesting
> that we do this is to have special comments in those files (the ones
> in include/asm-ppc/platforms) that say what should be symlinked, like
> this, from include/asm-ppc/platforms/all_ppc_serial.h:

The one thing I don't like about this is that there's a handfull of
platforms which would use the 'all_ppc_serial.h' file.

> The patch below does all this.  It does mean that we will need a
> platform header for every platform, and a platform_serial header for
> every platform where we want to use the standard serial driver.  As an
> example, I have made an all_ppc_serial.h that contains most of what
> was in serial.h before.  In fact, with a bit of care we could make
> serial.h be the symlink.

Well, if I read that mess if #ifdefs, they already are a whole
'serial.h', so lets just do it in one go. :)

Aside from that it looks good.

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

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