On Wed, Nov 12, 2008 at 6:57 PM, Peter Stuge peter@stuge.se wrote:
not the issue. The issue is you're going to need a control variable for a.most every file in the southbridge.
Hmm, how come? Because a board dts might not have all of them?
because a board might not have all of them and they might not want to compile them all in.
This is as unexpected for me as it is for you. Chips with this many devices are kind of new to me. There are so many devices on that part that it really strains our ideas about dts.
The Hamburg design is in need of further work.
There's another problem. If you don't reference ide in the dts, then the ide.c won't compile -- no config struct for it. So you have to build the ide.c in and reference it in the dts. I don't like that -- people should not have to include code they don't want. But to tailor the code, we either reference it in the makefile for the mainboard, or we have lots of control variables.
Could they be set automatically? The dts dictates what code we need, couldn't it be used also to create build dependencies?
Sure, if we don't mind bringing forward the v2 config program. I don't think we want that.
- pci@1f,3{
- /config/("southbridge/intel/i82801gx/smbus.dts");
- };
I'd like the same principle for dts. More reuse and one single include line pulling in whatever is needed for one complex device.
Do you mean device or chip? Again, this was discussed and this is how we decided to go. One dts per device.
Actually, I would like both. :) A component dts (geodelx, cs5536, c7, vt8237, all superios) could include atom device dtses, or might choose not to. A mainboard dts includes complex component dtses.
OK, but this is a change, and recall that if the component (can we please just call this a chip) dts includes all the device dtses, you now have the problem of what to do when some of them are turned off and in one case (a la via) the occupy the same pci bus/dev/fn. This is kind of tricky. This is also a change. Again.
So let's see a proposal and see what we can do.
-static void pci_domain_set_resources(struct device * dev) +static void I945_pci_domain_set_resources(struct device * dev)
This is just one example, there are many cases of copypaste like this. Is it really neccessary? I think the design has failed if we can't reuse this kind of code.
I am copying this from v2. v2 has been acked. The principle is that if it was acked in v2, we can consider it acked in v3.
Aha! I don't really with that universally. My interpretation of the principle is that code that accomplishes something good in v2 could be moved over to v3 without separate review, but not without making sure it adheres to the v3 model.
The v3 model? But this adheres to the v3 model. It will build fine.
Also if the code was only casually reviewed before going into v2, maybe more effort would be suitable for v3.
Sure, but who's going to do it? We have lots of work to do, not all the people we might want.
Saying "more effort would be suitable" is not sufficient to getting the work done.
That said, I don't understand why the code is this way.
That's the reason I don't think it should be committed as is.
OK, here's the challenge from me: it seems obvious it can be fixed. So fix it. Clean it up. :-)
I won't mind :-)
STAGE2_CHIPSET_SRC += \
$(src)/southbridge/intel/i82801gx/ac97.c \This has to change back. Any solution that does not keep this list>
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
of files in southbridge/ is plain wrong. Sorry.
Any recommendation that makes sense is welcome.
My only problem at the moment is that I don't have a real good overview of the v3 Makefile layout, and no time to study it.
and we're back to that time thing. It's not going to get us anywhere to say "fix this" absent the knowledge of Why Things Are The Way They Are.
Anyway, I changed it back.
For example, we could have 11 control variables to selectively include the files we want.
I wouldn't mind that if they were set automatically.
And you would do this how?
What do you think of the "multi tier" approach?
I think it needs a convincing demo that it can work.
I think we're all agreed that the current setup is not quite what we want. What's happening is that the integration of lots of devices on chip is overtaking our pretty dts ideas. It's going to get worse. The new pci "extended function space" will allow dozens of devices on chip. What we're doing now won't work.
+++ coreboot-v3/southbridge/intel/i82801gx/ac97.c 2008-11-12 23:09:42 UTC (rev 1009) +void i82801gx_enable(struct device * dev);
What? This function has to get a better name.
It's the v2 name. I'm not going to change it.
Spot on. Remember what Marc said. This is our chance to get it right.
But Stefan likes it :-) you will have to argue with him :-)
The rule of one dts for one device is simple. I like simple rules. It was also the result of a long argument. I did not design it that way initially -- I changed it at people's request.
Maybe the rule is too simple.
That may well be.
If we want to go back to one dts/file per chip, fine; see the southbridge/amd/cs5536/cs5536.c which, IIRC, a number of people were not happy with; that unhappiness is why I tried the experiment of splitting things out in subsequent chips.
Hm, you mean because there is code in there for different functions of the same component? I don't think that is so bad?
Um, Peter, I believe you are one of the guys who complained about this :-)
If not, sorry. :-)
Anyway, I think the current dts approach is not workable. We need to try One More Time.
The only good news: all the code to date will continue to work, even if we extend the dts. Thank goodness.
I'm going back to Blue Gene for a while -- but you smart guys need to really think about this. It's hard.
ron