On Sat, May 3, 2008 at 9:25 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Sorry, but I have to disagree with the design. Your proposed change scatters interrupt settings and routing info into totally different types of files. Either interrupt settings are something we want to have in the DTS (and that would mean we have to keep the PIR table in the dts as well) or they are kept in separate tables in irq_tables.h.
good point.
The geode is a very odd beast, however, and does not follow the rules. The USB is not really connected via the IRQ router. You can specify USB IRQs in the PIR table and get working boards, but you are restricting the USB interrupts to one of four choices and that is really not necessary or required. It would be better if we do not restrict ourselves unnecessarily.
Which really means the PIR table must die! die! die! die!
dev = dev_find_pci_device(PCI_VENDOR_ID_AMD,PCI_DEVICE_ID_AMD_CS5536_AUDIO, 0);I see dev_pci_find_device crop up more and more often in v3 and it scares me. Is the device tree code really that bad that we can't avoid dev_pci_find_device? Or did I misunderstand the benefits of the device tree?
I don't see the problem. This strikes me as a fairly cheap and safe way to ensure that the device you think is there is there. Given vendor's propensity for undocumented chipset changes, I think this is safe.
I could blindly trust the bus:dev.fn I put in the tree, however; I had not even thought of this. Good point again but ... look at the cs5536 code and the dts. Much of cs5536 init code involves things not in the dts, as there is no reason to put it in the dts. Why burden people with all this specification when a simple find_device can resolve it?
I see v3 as a big promise of clean design, readable code and easy porting and I fiercely try to keep it that way. This motivates me to work on secret projects which will transform the current v3 code to fulfill its design destiny. Expect code sometime in July.
Well, I trust you to create a great design, but still, a 'secret project' sounds a little worrisome. We used to get these from one vendor, just submitted with no comments, and they were not really usable. I think if you're doing a redesign you should do what I try to do -- bring it to the list and take the comments.
I will probably drop this patch I guess. But I suspect there are some deep-rooted IRQ problems in the LX port, even down into the VSA, and that's why we're having MFGPT and other issues. The Geode is just not quite right yet, and interrupts are a part of the problem.
The DBE62 does not really set up IRQs for USB, and that may be related to why there is a power issue. Mart, note that alix1c sets up USB in the PIR table and dbe62 does not. How are you getting USB to work at all?
thanks
ron