Greg Watson gwatson@lanl.gov writes:
The issue for me is that I need to have static initialization working before I can continue, so my intention is build something that will hopefully be acceptable to everyone. I can probably merge the chip and device structures that
gives me a way forward without replicating what Eric is doing. However a single call to enumerate_static_devices, particularly at the current location, is NOT acceptable to me.
That is fine. What I have right now in hardwaremain is just a first pass not a final solution to this problem.
Here's my suggestion to move forward:
- I need to be able to enable/configure static devices at specific points in
hardwaremain, particularly on entry, after console_init and prior to pci enumeration. I suggest a routine called device_configure() that is passed the root of the device tree and a pass flag:
void device_configure(struct device *, enum dev_pass)
enum dev_pass { DEV_PASS_PRE_CONSOLE, DEV_PASS_PRE_PCI, DEV_PASS_ENUMERATE, DEV_PASS_CONFIGURE, DEV_PASS_ENABLE, DEV_PASS_INITIALIZE };
Calls to device_configure() with the appropriate flag will be inserted in the appropriate locations in hardwaremain. More flags/calls call be added if necessary. Calls to dev_enumerate(), dev_configure(), etc. to probe and configure dynamic bus devices will be replaced with calls to device_configure() with the appropriate flag. Dynamic devices will be added to the device tree as appropriate.
I have nits to pick with a single device_configure(). After we have something working I will start picking them.
- New fields added to struct device, including a 'static' flag that is set for
static devices, and something analogous to the chip structure for static device info.
Reasonable.
- Continue use of the chip.h files in configuration directories (although the
name could be changed to device.h) and the 'register' configuration directive.
I don't have a problem with that.
- Removal of all device specific calls from hardwaremain, such as
'init_timer()' into static initialization files using (4) above.
OK. I think.
In general timer services are a generic part of LinuxBIOS and just like the console we may need an init routine. We have avoided it many times in the past by having a static variable and having the timer code magically do something the very first time it is called.
When I built code that could be compiled with romcc I discovered that idiom would not always work.
- The configuration process will build a static device tree that will be called
device_{target}.c in the target build directory and linked with the linuxbios image.
My intention is to start coding this tomorrow, so if anyone has any major objections/suggestions, please let me know asap.
Long term I would like to see if we can get the cpus into this structure as well. But expressing the dependencies is an interesting process.
I plan on reviewing what you have when I get back from OLS.
Eric