Re: [PATCH 1/3] firewire: fw-ohci: PPC PMac platform code

From: Stefan Richter
Date: Sat Mar 01 2008 - 03:07:37 EST


Benjamin Herrenschmidt wrote:
+#ifdef CONFIG_PPC_PMAC
+ /* Necessary on some machines if fw-ohci was loaded/ unloaded before */
+ if (machine_is(powermac)) {
+ struct device_node *ofn = pci_device_to_OF_node(dev);
+
+ if (ofn) {
+ pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
+ pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
+ }
+ }
+#endif /* CONFIG_PPC_PMAC */

I -think- that the hunk above can be removed if you just call
pci_enable_device(). I have a hook in the arch pcibios_enable_device()
that detects the internal firewire and does the calls. Can you verify it
works ?

The first test I did was
# modprobe ohci1394 # this has the same four feature call blocks
# modprobe -r ohci1394
# modprobe firewire-ohci
<boom>

Tried the same now again (actually modprobe -r firewire-ohci (patched); modprobe firewire-ohci (unpatched)):

Machine check in kernel mode.
Caused by (from SRR1=49030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
PowerMac
Modules linked in: firewire_ohci(+) firewire_core crc_itu_t af_packet apm_emu apm_emulation usbhid sungem sungem_phy yenta_socket rsrc_nonstatic ohci_hcd pcmcia_core usbcore ide_cd_mod cdrom evdev [last unloaded: crc_itu_t]
NIP: e18ee3dc LR: e18ee32c CTR: c0065178
REGS: d7c01c40 TRAP: 0200 Not tainted (2.6.25-rc3)
MSR: 00049030 <EE,ME,IR,DR> CR: 84004428 XER: 00000000
TASK = dedae6d0[5376] 'modprobe' THREAD: d7c00000
GPR00: e18e61c0 d7c01cf0 dedae6d0 defcf000 00000000 00000385 c06c09f8 00001000
GPR08: ffffec0f 00000000 e18e6000 dfafd000 24004428 1001e354 00000000 00000000
GPR16: 0000007a 0000007a 00000000 e18e9bf4 00000124 00000000 e18e6000 c0050280
GPR24: 00000019 e18e9cc4 c0290630 dfb61420 df85b800 dfafdcf8 00000000 dfafdcf8
NIP [e18ee3dc] ar_context_add_page+0xd0/0xf4 [firewire_ohci]
LR [e18ee32c] ar_context_add_page+0x20/0xf4 [firewire_ohci]
Call Trace:
[d7c01cf0] [e18ee32c] ar_context_add_page+0x20/0xf4 [firewire_ohci] (unreliable)
[d7c01d00] [e18ee440] ar_context_init+0x40/0x70 [firewire_ohci]
[d7c01d50] [e18f0004] pci_probe+0x118/0x70c [firewire_ohci]
[d7c01d70] [c010e0ac] pci_device_probe+0x80/0xa0
[d7c01d90] [c0146230] driver_probe_device+0xb8/0x1cc
[d7c01db0] [c0146528] __driver_attach+0xd4/0x104
[d7c01dd0] [c0144d78] bus_for_each_dev+0x58/0x94
[d7c01e00] [c0145f60] driver_attach+0x24/0x34
[d7c01e10] [c0145d48] bus_add_driver+0xb0/0x250
[d7c01e30] [c0146a18] driver_register+0x48/0x130
[d7c01e50] [c010dcb0] __pci_register_driver+0x48/0x94
[d7c01e70] [e101e028] fw_ohci_init+0x28/0x48 [firewire_ohci]
[d7c01e80] [c00516e8] sys_init_module+0xd4/0x1754
[d7c01f40] [c0013d98] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff7325c
LR = 0x10003b50
Instruction dump:
90690010 817f0000 907f0008 814b04b4 813f0010 7c0a4a14 7c0004ac 7ce0052c
817f0000 812b04b4 7c0004ac 7d204c2c <0c090000> 4c00012c 38000000 7c030378
---[ end trace a3cf91a5f7d45355 ]---


BTW, ohci1394 had traditionally only 3 of the blocks; I added the block by commit 48cfae44b4d6c7ca843d611a93ed2f94b59bcb38 in November 2006. This fixed http://bugzilla.kernel.org/show_bug.cgi?id=7431 .

[...]
@@ -2211,6 +2241,16 @@ static int pci_suspend(struct pci_dev *p
if (err)
fw_error("pci_set_power_state failed with %d\n", err);
+/* PowerMac suspend code comes last */
+#ifdef CONFIG_PPC_PMAC
+ if (machine_is(powermac)) {
+ struct device_node *ofn = pci_device_to_OF_node(pdev);
+
+ if (ofn)
+ pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+ }
+#endif /* CONFIG_PPC_PMAC */

I wonder why we don't do the cable power thingy here...

I don't know.

I tested with a bus powered device now. Actually, suspend to RAM switches off cable power nevertheless, but resume does not switch it on anymore...

Of course the same is true with ohci1394. Why did nobody ever complain? I suppose the last two users of FireWire + Linux + UniNorth rev01 don't use cable power or don't suspend and resume.
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/