proposed change to dtc to allow multiple dts files per single chip

[ron minnich]

This patch needed because some chips (mostly north) can have more than
one function.

patch attached.

ron

[Carl-Daniel Hailfinger]

On 28.01.2008 18:05, ron minnich wrote:
> This patch needed because some chips (mostly north) can have more than
> one function.
>
> In the current version of dtc, if one has the line:
> /config/ = "northbridge/amd/geodelx";
>
> Then the file northbridge/amd/geodelx/dts is read in and processed. 
> Magic(TM) appends the name "/dts" to the path.

This is nice if you want to make it easy for the developer porting v3 to
a new target.
> This hack is fine with chips that only do one thing. 
> But some (all) northbridge parts play several roles: APIC cluster, PCI domain
> device, and PCI device. The result is a need for more than one dts, since
> there are three possible devices, with three types of IDs, and so on.

That rules out automatic "intelligent" selection of the dts.
> To keep things sane, I am proposing to put three seperate dts files in the 
> northbridge directory, name as follows:
> domaindts
> pcidts
> apicdts
>
> (of course these names can be anything, this is just an example).
> This change will require a change to the dtc, since we can no longer
> assume just one dts file, and hence need a way to name these different 
> files.

OK.
> The proposed change is very simple. Given a config path as above, the 
> dtc will at first try to open the path as a file, BEFORE trying to open the 
> the path by appending "/dts" to it.
>
> So, 
> /config/ = "northbridge/amd/geodelx/pcidts";
>
> will open the pcidts file. But, 
> /config/="southbridge/amd/cs5536";
> will open the southbridge/amd/cs5536/dts file as before.
>
> Is this really going to far?

Sorry, yes.
> Shouldn't we just require the users to 
> name the dts file, instead of the magic? I am comfortable with that idea
> too -- reduce magic, make things more clear.

For someone with no experience with the dtc and the /config/
specification, implicit side-effects are bad, especially if they happen
only in a subset of cases. We have seen in v2 that porting mostly
happens by copying over an existing target and beating it into shape. I
sometimes also try to deduce meaning from the code without reading all
the functions and utilities it calls. Implicit behaviour changes make
that a lot more difficult.

If possible, please require explicit naming of the dts. That also has
the benefit that people unfamimilar with the code instantly see where
the config is taken from.

Regards,
Carl-Daniel