[lkml]   [2000]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:51    [W:0.066 / U:13.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site