macros and dtc

macros and dtc

[Kumar Gala]

After spending some time this weekend cleaning up dts files I figured  
it would be nice if we can some to consensus on how we are going to  
do macro support.  There is clearly a lot of duplication between  
dts's and it only gets worse when you add in slight variations for  
revs of boards.

I wasn't sure if we are thinking of using some style of preprocessor  
(cpp, m4, etc..) or trying to add something into dtc itself.

However, I think it would be good for us to get some traction towards  
a solution for in kernel dts files.

- k

Re: macros and dtc

[Geoff Levand]

Kumar Gala wrote:
> After spending some time this weekend cleaning up dts files I figured  
> it would be nice if we can some to consensus on how we are going to  
> do macro support.  There is clearly a lot of duplication between  
> dts's and it only gets worse when you add in slight variations for  
> revs of boards.
> 
> I wasn't sure if we are thinking of using some style of preprocessor  
> (cpp, m4, etc..) or trying to add something into dtc itself.
> 
> However, I think it would be good for us to get some traction towards  
> a solution for in kernel dts files.

Based on the previous discussions, there were some concerns with using CPP
on the dts.  m4 is a nice preprocessor and I think that it sould be the
choice.

It would be good to have the kernel config available when running the
preprosessor, so that would mean running it from the makefile, not the
wrapper script.  It also seems then that having a different file extension
so the processing would fall naturally into a makefile target.

$(obj)/xyz.dts:	xyz.dts.m4
	$(call cmd,m4)


-Geoff

Re: macros and dtc

[Dan Malek]

On Feb 18, 2007, at 11:58 AM, Kumar Gala wrote:

> After spending some time this weekend cleaning up dts files I figured
> it would be nice if we can some to consensus on how we are going to
> do macro support.

I'm not sure I'd like to use macros.  I can understand the case
today where we are still changing too many things that a
macro would be nice, but at some point this has to settle down.
There isn't that much information in the file, and I prefer to
see all of it clearly rather than locating macros to wonder
how they need to be invoked.

> There is clearly a lot of duplication between
> dts's and it only gets worse when you add in slight variations for
> revs of boards.

Of the few boards for which I've had to create new dts
files, I wonder how the macros would work.  Although the
variations are slight, there are many variables.  A macro
is going to have to allow nearly all of the property information
as parameters, so what's the big savings?  If you are
just using them to avoid syntax, then perhaps we should
have chosen a different syntax? :-)  I think a macro with
lots of parameters is more confusing than the syntax
we currently use.

I could envision using something like cpp with #include
to get some standard SOC block properties, but macros
that try to account for board variations could be quite
complex.

Thanks.

	-- Dan

RE: macros and dtc

[Yoder Stuart-B08248]

=20

> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Dan Malek
> Sent: Monday, February 19, 2007 12:08 PM
> To: Kumar Gala
> Cc: Linux PPC Dev ML; Jon Loeliger; David Gibson
> Subject: Re: macros and dtc
>=20
>=20
> On Feb 18, 2007, at 11:58 AM, Kumar Gala wrote:
>=20
> > After spending some time this weekend cleaning up dts files=20
> I figured
> > it would be nice if we can some to consensus on how we are going to
> > do macro support.
>=20
> I'm not sure I'd like to use macros.  I can understand the case
> today where we are still changing too many things that a
> macro would be nice, but at some point this has to settle down.
> There isn't that much information in the file, and I prefer to
> see all of it clearly rather than locating macros to wonder
> how they need to be invoked.
>=20
> > There is clearly a lot of duplication between
> > dts's and it only gets worse when you add in slight variations for
> > revs of boards.
>=20
> Of the few boards for which I've had to create new dts
> files, I wonder how the macros would work.  Although the
> variations are slight, there are many variables.  A macro
> is going to have to allow nearly all of the property information
> as parameters, so what's the big savings?  If you are
> just using them to avoid syntax, then perhaps we should
> have chosen a different syntax? :-)  I think a macro with
> lots of parameters is more confusing than the syntax
> we currently use.
>=20
> I could envision using something like cpp with #include
> to get some standard SOC block properties, but macros
> that try to account for board variations could be quite
> complex.

Heavy use of parameterized macros could make reading
device trees more difficult.

But for basic things like #include and #define constants it
would be a good thing.

bus-frequency =3D <33MHZ> is much better than
bus-frequency =3D <13ab6680>

Same would go for interrupts, interrupt-map, etc.

There are lot's of hardcoded constants floating around
in the dts files that for clarity should be #defined (or
whatever the m4 equivalent is) at the top of the file.

Stuart

Re: macros and dtc

[Kumar Gala]

On Feb 19, 2007, at 12:07 PM, Dan Malek wrote:

>
> On Feb 18, 2007, at 11:58 AM, Kumar Gala wrote:
>
>> After spending some time this weekend cleaning up dts files I figured
>> it would be nice if we can some to consensus on how we are going to
>> do macro support.
>
> I'm not sure I'd like to use macros.  I can understand the case
> today where we are still changing too many things that a
> macro would be nice, but at some point this has to settle down.
> There isn't that much information in the file, and I prefer to
> see all of it clearly rather than locating macros to wonder
> how they need to be invoked.
>
>> There is clearly a lot of duplication between
>> dts's and it only gets worse when you add in slight variations for
>> revs of boards.
>
> Of the few boards for which I've had to create new dts
> files, I wonder how the macros would work.  Although the
> variations are slight, there are many variables.  A macro
> is going to have to allow nearly all of the property information
> as parameters, so what's the big savings?  If you are
> just using them to avoid syntax, then perhaps we should
> have chosen a different syntax? :-)  I think a macro with
> lots of parameters is more confusing than the syntax
> we currently use.

Well, I was thinking one useful place would be the PCI range macro.   
Without reading the PCI OF spec 3 or 4 times, its pretty confusing to  
parse what's going on there.

> I could envision using something like cpp with #include
> to get some standard SOC block properties, but macros
> that try to account for board variations could be quite
> complex.

Agreed, I'm think some simple SOC block's like TSEC would be useful.

I think its something we need to play with and see how it works out.

- k

Re: macros and dtc

[Benjamin Herrenschmidt]

> I could envision using something like cpp with #include
> to get some standard SOC block properties, but macros
> that try to account for board variations could be quite
> complex.

For things like SoC, what I'd like is a way via #include or macros,
whatever, to layout in a part of the tree a standard block, and then, be
able to "overlay" on top of it.

I can see other uses for macros for things like making easier to build
interrupt-map properties for example, especially since most embedded
boards use standard swizzling

Ben.

Re: macros and dtc

[Dan Malek]

On Feb 19, 2007, at 1:57 PM, Yoder Stuart-B08248 wrote:

> bus-frequency = <33MHZ> is much better than
> bus-frequency = <13ab6680>

Except, 33MHZ isn't a valid macro name, and if
these constants would have been _decimal_
in the first place, 33000000, or 33333333 would
be understandable :-)  I've screwed up by thinking
(or not, I guess) these are decimal numbers.....
I agree with you, though.  Of course, these values
should be zero in the dts and filled in by
the boot loader/wrapper.

A real programmer would recognize these
standard constants in hex (or octal), too :-)


Thanks.

	-- Dan

RE: macros and dtc

[Yoder Stuart-B08248]

=20

> -----Original Message-----
> From: Dan Malek [mailto:dan@embeddedalley.com]=20
> Sent: Monday, February 19, 2007 2:17 PM
> To: Yoder Stuart-B08248
> Cc: Kumar Gala; Linux PPC Dev ML; Jon Loeliger; David Gibson
> Subject: Re: macros and dtc
>=20
>=20
> On Feb 19, 2007, at 1:57 PM, Yoder Stuart-B08248 wrote:
>=20
> > bus-frequency =3D <33MHZ> is much better than
> > bus-frequency =3D <13ab6680>
>=20
> Except, 33MHZ isn't a valid macro name, and if
> these constants would have been _decimal_
> in the first place, 33000000, or 33333333 would
> be understandable :-)  I've screwed up by thinking
> (or not, I guess) these are decimal numbers.....
> I agree with you, though.  Of course, these values
> should be zero in the dts and filled in by
> the boot loader/wrapper.

Ok. (guess I picked a bad example:)  The main point,
though, is that symbolic names are generally more
helpful and clear than bare constants. =20

Stuart

Re: macros and dtc

[David Gibson]

On Tue, Feb 20, 2007 at 07:04:44AM +1100, Benjamin Herrenschmidt wrote:
> 
> > I could envision using something like cpp with #include
> > to get some standard SOC block properties, but macros
> > that try to account for board variations could be quite
> > complex.
> 
> For things like SoC, what I'd like is a way via #include or macros,
> whatever, to layout in a part of the tree a standard block, and then, be
> able to "overlay" on top of it.

Yes, certainly macros on their own wouldn't be very useful for SoCs or
standard boards.  But macros plus overlays should be quite useful.

> I can see other uses for macros for things like making easier to build
> interrupt-map properties for example, especially since most embedded
> boards use standard swizzling

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: macros and dtc

[Segher Boessenkool]

> There are lot's of hardcoded constants floating around
> in the dts files that for clarity should be #defined (or
> whatever the m4 equivalent is) at the top of the file.

For *clarity*, they should be bare constants :-)

For maintainability, values that are not changing ever
(fixed addresses on some SoC for example) are fine as
a constant; they never change, after all.  Addresses
that are configurable though (PCI ranges for example)
could benefit from a macro def.  Then again, such things
should ideally be filled in by the boot wrapper instead
(for PCI, this means the boot wrapper would need to know
how to do PCI config on your PHB; it then could automatically
generate almost all of the PCI tree).  Well this is not
the best example I guess, Linux can do without the PCI
stuff in the tree, but the same idea goes for many other
features that can be probed; you have one basic DTB for
a whole family of boards and the boot wrapper fills in
the details.  It would be useful then (and now already)
to have some /proc/flatdevtree that outputs the binary
blob that the kernel was fed -- someone create that please :-)


Segher