[PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware

[Jon Loeliger]

On Fri, 2007-05-18 at 13:23, Scott Wood wrote:
> Jon Loeliger wrote:
> > First of all, I wanted to get away from the notion of calling
> > anything a "jumper".  What I said to you was to predicate the
> > clause based on some arbitrary conditional, not just some "jumper
> > setting."
> 
> Yes, I like the "hwoption" name better.

I think my point was missed.  It could be more general
than "a hardware thing".  Sure, HW contributes.


> No, we were pretty much always talking about a run-time thing.

On he contrary, here are copies of two pieces of mail from
roughly May 2006 and Feb 2007 in which CPP and M4 as _compiled_time_
processing are being discussed.  In the latter, you discuss it more:.

	From: 	Kumar Gala <galak at kernel.crashing.org>
	To: 	Jon Loeliger <jdl at freescale.com>
	Cc:	Jon Loeliger <jdl at jdl.com>, Benjamin Herrenschmidt
		<benh at kernel.crashing.org>, linuxppc-dev at ozlabs.org list
		<linuxppc-dev at ozlabs.org>
	Subject: 	Re: DTC/dts modifications
	Date: 	Mon, 1 May 2006 14:52:23 -0500	

	[snip]


	>> If these used some other symbol instead of '#' cpp 
	>> will be happy and we can use it to create macros for us.
	>
	> Yeah, we're not going to be able to change those; they
	> are "By The Book".

	By what book?  It would seem to me that BNF for dtc is
	completely under our control and if we want to change it we can.
	I understand that there is some correspondence to Open Firmware,
	but it seems that if its people are ok with the dts format
	changing that's a lot easier than implementing tons of support
	in dtc for features that cpp gives us.

	[I'm also guessing no one's really got time to go and implement
	these features in dtc]

	> Instead, we'll have to make the lexical analysis conscious
	> of something like a <newline> context sensitive token or so.
	> Or throw some flag to cpp to not emit location markers.

	- kumar





	From: 	Jon Loeliger <jdl at jdl.com>
	To: 	Benjamin Herrenschmidt <benh at kernel.crashing.org>
	Cc: 	linuxppc-dev at ozlabs.org,
		Roland Dreier <rdreier at cisco.com>,
	          Stefan Roese <sr at denx.de>, linuxppc-embedded at ozlabs.org
	Subject:Re: [PATCH] ppc: Add support for AMCC Taishan 440GX eval board
	Date: 	Mon, 12 Feb 2007 14:16:21 -0600	

	So, like, the other day Benjamin Herrenschmidt mumbled:
	> Note that there are still things that we might want to
	> change. For example, I think we really should look into adding
	> a macro mecanism and/or an include mecanism to dtc so that we
	> can do things like #include <ibm440gp.dtc> to get the base
	> processor/SoC definition and then "overlay" some properties on
	> top of it (like emac phy mode etc...)

	What do people prefer here?  Straight CPP pre-run?
	Direct support built into dtc to do file-inclusion, macros?

	Thoughts, opinions, suggestions, pre-NACKs, Cabernet Franc bribes?

	jdl


And you reply:


	Simple textual macros would make it difficult to define 123A and
	123B SoCs whose device tree nodes are mostly a generic 123, but
	require a few changes in various parts.  I'd rather see dtc
	support overlaying trees, with the "newer" tree able to add,
	modify, and remove nodes and properties from the "older", more
	generic tree.

	Parametric macros (or "template" nodes) might be nice for a few
	things on top of that, though (preferably with better syntax
	than CPP).

Clearly, we have in fact historically discussed compile-time
conditional DTC behavior.

> Compile-time would just give you a more convenient way of generating 
> multiple dtbs; it wouldn't address the root problem of combinatorial 
> explosion with several independent options.  Even when the number of 
> alternatives isn't high, it's much nicer to the user to be able to just 
> type a command into u-boot (or better yet, have it be autodetected) when 
> an option changes than to have to rebuild and install a new dtb.

Yes, I understand.  But I think, say, the Linux build handles
the compile time combinatorial explosion of compile time options
reasonably well so far... :-)

jdl