lkml.org 
[lkml]   [2000]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PCI irq routing..

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/

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