On Wed, 6 Dec 2000, Linus Torvalds wrote:
> On Wed, 6 Dec 2000, Martin Diehl wrote:
> >
> [Cardbus config space lost after APM suspend/resume]
>
> Can you remind me in a day or two if I haven't gotten back to you? I don't
> have any machines that need this, but I've seen ones that do, and if
> you're willing to test..
sure, will to do testing (and reminding ;-)
> Yes, this is expected for routers that we don't know about: we will still
> use the irq that the device claims it has, but we will obviously fail to
> try to route it (but it still works if the BIOS had already routed it -
> which is how the old code always worked anyway).
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)?
> Anyway, for the suspend-resume thing, if you want to go ahead on your own
> without a real patch from me, the fix is along the lines of
well, took me some time to follow all the paths thru cardbus/pcmcia stuff
wrt suspend/resume from pm - but ended up at:
> - add two functions:
>
> static void yenta_save_config(pci_socket_t *socket)
> static void yenta_restore_config(pci_socket_t *socket)
That's the crucial point, imho. The PCI layer forwards the PM events to
the cardbus-driver's suspend/resume methods, which are calling
pcmcia_suspend/resume_socket(). The latter in turn will call back the
appropriate yenta_operations which are registered to it. So much for sure.
However, there is no pcmcia_resume path forwarded to yenta since the
traditional pccard_operations did not provide such a method and pcmcia
simply re-initialized it's sockets. My assumption is, you haven't meant
to add a do-nothing resume to all the pcmcia-stuff (including i82365,
tcic) just to allow yenta to register for a resume operation which would
be there for cardbus only.
So my suggestion is to have cardbus_save/restore_config() exactly doing
what you've said for yenta_*.
> - do a "yenta_save_config()" in "yenta_suspend()" and a
> "yenta_restore_config()" at the top of "yenta_resume()"
yenta_resume() does not exist.
yenta_*() replaced by cardbus_*() as explained.
> - test. Also test with the "pci_set_power_state(3)" in suspend enabled,
> because it may/should actually work with that enabled too.
same point: pci_set_power_state(3) should go to cardbus_suspend(), not
yenta.
A first try of this ended oopsing at pm suspend somewhere below
pci_pm_*(). It turned out the reason was the cardbus_suspend() (and resume
too) method which was *invoked several times* in a row!
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().
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).
I'll try to continue on this.
Regards
Martin
-
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