[coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts

[ron minnich]

On Sat, May 3, 2008 at 9:25 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at 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