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/
This archive was generated by hypermail 2b29 : Thu Dec 07 2000 - 21:00:18 EST