Stefan Reinauer stepan@openbios.org writes:
- Eric W. Biederman ebiederman@lnxi.com [050118 12:51]:
I agree that there is an issue particularly with respect to interrupts. A lot of this has waited until we have the time to do this properly.
I agree. However I also think we are coming close to the point were the existing infrastructure is fine enough to handle distributed table generation sanely.
Agreed.
Autocreation of those tables should belong to the driver code of each supported device.
No. The devices should have no idea about the format of the data we present to the user. We should push all of the information into the device tree so we can derive it from there.
This is certainly true. But it will require some extra layer to be introduced that is completely missing at the moment. Representation of IOAPICs in the device tree are completely missing at the moment for example. We will also need quite some extra information from the config files.
A small amount or we just get the devices to populate the IOAPICs. When the IOAPICs happen to be a pci device we already represent them. When the path to an IOAPIC is something else we don't. Devices with well known programming interfaces need a little extra care so we can report their well known resources properly.
No. A write_tables method is bad. We need to enhance the dynamic device tree with irq information. And possible with something like pci class so we can recognize devices with well know software programming interfaces.
ACPI has things like IRQ override entries in it's MADT. There are quite some other pretty exceptional situations of working around hardware layout and kernel design allowed by the specification. I am not sure how we want to associate information like this with a certain device. Is it part of the "mainboard" device then? I am scared that we have to invent a proper representation of things like this, just to be able to convert it to acpi later on while in the end ACPI tables are simple to produce and on non-x86 the hardware and linux kernel is less broken.
Maybe. Let's handle the sane cases and see where that puts us. With respect to irq handling we need enough information to route the interrupts before Linux loads. With the pirq and other interrupt routing tables simply standing in the background.
This would also allow to extend the generic information provided by the bridges, by adding such functionality to the mainboard specific code, so we won't end up with something that is worse than now in any case.
I think allowing additional work to be done at a per port level is a valid critique. I would prefer we leave it until we find an actual need however.
This might be now, even though I am probably able to work around by factorizing the ACPI code seperating the table creator functions and the main function calling those. This one would go to the motherboard directory, next to mptable.c and irq_table.c. The problem I have is that I designed the ACPI code originally for the AMD Solo motherboard, and someone updated it to be useful on the Epia. But with every new motherboard there need to be different devices filled into the MADT. Say "then drop ACPI", but Linux is not able to boot this machine properly without ACPI. As sad as it is.
Hmm. I had not seen that problem. But the SOLO was always a weird board. Is this because linux has/had a bug in it's pirq table parser and did not recognize the 8111? Is the problem that we did not get the fix pushed upstream?
Roughly thinking, table_t could look like:
That is terrible.
:-)))) Which is why I kept myself from implementing it yet.
For a subset of the idea look at how we generate the cpu information and the memory information directly from the LinuxBIOS table already.
Can you give me a quick pointer? I am not sure that i am looking at the right piece of code.
Sorry I don't have a good example handy. I just know that for some parts of the process we already do use the existing tables. It is not very sophisticated.
A good starting exercise would be to get the apics and ioapics into the device tree (which requires not extensions) and simply hard code the interrupt source information. That should generate about half of the interrupt routing table.
We need an internal format for the information that we can consume and control, and enhance. The fact that we are passing on that information is secondary.
I agree, though plugging a good concept between 2 broken ones might be hard.
True. But one small step at a time. If we are lucky we won't have to support the really broken ones. And if not we will have enough momentum to carry us through.
For IRQ routing something very like the work done with open firmware is needed. Open firmware actually cannot represent x86 irq routing as there is it cannot handle a the separate descriptions of apic and non-apic modes. But otherwise it should be able to handle everything.
How does it handle APIC modes? If there is an APIC, I don't see any need to go non-APIC except for academical interest.
Open firmware reports interrupts as a property of a bus. And then those bus lines are hooked somewhere.
So there are two mapping steps. Device to bus interrupt line. Bus interrupt line to interrupt sink. And if we can have multiple interrupt sinks per bus we may be able to do model everything trivially.
And of course there is a simple default that the bus interrupt lines connect up to their corresponding bus interrupts lines in the parent bus.
Consuming that and programming the appropriate interrupt routers would also be interesting.
Eric