Messages in this thread |  | | Date | Thu, 7 Dec 2000 10:38:31 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: PCI irq routing.. |
| |
On Thu, 7 Dec 2000, Martin Diehl wrote: > > btw, I'm thinking I could guess the routing from the VLSI config space, > but I don't have any doc's. Would it be worth to try to add some specific > get/set methods for this device? What about testers (or people who have > access to the docs)?
Please do. You might leave them commented out right now, but this is actually how most of the pirq router entries have been created: by looking at various pirq tables and matching them up with other (non-pirq) documentation and testing. Th epirq "link" value is basically completely NDA'd, and is per-chipset-specific. Nobody documents it except in their bios writers guide, if even there.
> yenta_resume() does not exist. > yenta_*() replaced by cardbus_*() as explained.
Yes.
> The reason for this is in drivers/pci.c where bridges are touched > twice: once as a device on a bus and once via ->self from the bus behind. > I'm not sure whether this is the intended behavior - but it definitely > calls cardbus_suspend/resume() twice which breaks when forwarding to > pcmcia_suspend/resume_socket().
Not intended behaviour. The self case should be removed.
> So I've tentatively worked around using a "once" flag added to > pci_socket_t. This solves the problems during suspend/resume and the > cardbus' config space appears to be restored as intended - good. > > The bad news however is, the sockets are still broken after > resume. Unfortunately there are several candidates I've spotted: > > - calling yenta_init() stuff at resume - is this sufficient? > Probably we have to forward the pm-triggered resume from pm along > pci -> cardbus -> pcmcia -> yenta (last link currently missed, > because the pcmcia layer switches from incoming resume notification > to init path) > > - some content of the mem/io regions might need to be preserved > > - some TI1131 oddity wrt to CSC-INT's - requested IRQ's show up correctly > in /proc/interrupts and are properly triggered and handled at card > insert/eject. But after pm suspend/resume the box freezed when inserting > or ejecting the cards (no response to SysRq anymore).
Ok, definitely needs some more work. Thanks for testing - I have no hardware where this is needed.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |