* 2.4.17 and dmasound
@ 2002-02-22 18:07 Michael Zucca
2002-02-22 18:31 ` benh
0 siblings, 1 reply; 5+ messages in thread
From: Michael Zucca @ 2002-02-22 18:07 UTC (permalink / raw)
To: linuxppc-dev
I recently downloaded 2.4.17 from kernel.org hoping to get my kernel
more up to date. Unfortunately, when I looked at the dmasound driver I
didn't see the fix for dbdma DEAD problems which occur on some
PowerComputing machines.
Was this patch ever submitted or was it lost in the shuffle?
Thanks!
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.4.17 and dmasound
2002-02-22 18:07 2.4.17 and dmasound Michael Zucca
@ 2002-02-22 18:31 ` benh
2002-03-03 19:22 ` 2.4.18 and dmasound and rebooting Michael Zucca
0 siblings, 1 reply; 5+ messages in thread
From: benh @ 2002-02-22 18:31 UTC (permalink / raw)
To: mrz5149, linuxppc-dev
>I recently downloaded 2.4.17 from kernel.org hoping to get my kernel
>more up to date. Unfortunately, when I looked at the dmasound driver I
>didn't see the fix for dbdma DEAD problems which occur on some
>PowerComputing machines.
>
>Was this patch ever submitted or was it lost in the shuffle?
Look for 2.4.18, it will be released soon, or use one of the PPC trees
or the current 2.4.18-rc4. All of them should work.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* 2.4.18 and dmasound and rebooting
2002-02-22 18:31 ` benh
@ 2002-03-03 19:22 ` Michael Zucca
2002-03-03 23:34 ` benh
2002-03-04 0:03 ` benh
0 siblings, 2 replies; 5+ messages in thread
From: Michael Zucca @ 2002-03-03 19:22 UTC (permalink / raw)
To: linuxppc-dev
Ok, I tried 2.4.18 from kernel.org on my PowerCenter 132 and the DMA
dead patch works. However, as a side note, it only seems to work if the
sound code is compiled into the kernel. The same code in a module does
not work and still causes the sound hang. As I recall, the way the
emergency buffer was allocated was critical to it functioning properly.
I usually compile in the sound driver so it's not a big deal for me but
it might be for other folks.
On another note, I've noticed that if I reboot my machine using shutdown
-r the machine will reboot to a gray screen and then just hang there. It
won't boot into MacOS. I've noticed that on 68k Macs, it is important to
map the ROMs back into memory before rebooting or the machine just hangs
around forever. Is it possible that we're not remapping stuff back to
its usual place before rebooting on OldWorld machines? This has been a
persistant problem for a long time on 2.4.
Thanks!
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.4.18 and dmasound and rebooting
2002-03-03 19:22 ` 2.4.18 and dmasound and rebooting Michael Zucca
@ 2002-03-03 23:34 ` benh
2002-03-04 0:03 ` benh
1 sibling, 0 replies; 5+ messages in thread
From: benh @ 2002-03-03 23:34 UTC (permalink / raw)
To: Michael Zucca, linuxppc-dev
>
>Ok, I tried 2.4.18 from kernel.org on my PowerCenter 132 and the DMA
>dead patch works. However, as a side note, it only seems to work if the
>sound code is compiled into the kernel. The same code in a module does
>not work and still causes the sound hang. As I recall, the way the
>emergency buffer was allocated was critical to it functioning properly.
>I usually compile in the sound driver so it's not a big deal for me but
>it might be for other folks.
Well, I see no problem with the way the buffer is allocated. However,
the emergency buffer code looks wrong: It should really contain a
branch command to branch back the DBDMA controller to the normal buffer.
>On another note, I've noticed that if I reboot my machine using shutdown
>-r the machine will reboot to a gray screen and then just hang there. It
>won't boot into MacOS. I've noticed that on 68k Macs, it is important to
>map the ROMs back into memory before rebooting or the machine just hangs
>around forever. Is it possible that we're not remapping stuff back to
>its usual place before rebooting on OldWorld machines? This has been a
>persistant problem for a long time on 2.4.
That is weird, I don't think we have to take care of any sort of MMU
mapping, looks more like some driver would need to be restored in some
"pristine" state (sound ?)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.4.18 and dmasound and rebooting
2002-03-03 19:22 ` 2.4.18 and dmasound and rebooting Michael Zucca
2002-03-03 23:34 ` benh
@ 2002-03-04 0:03 ` benh
1 sibling, 0 replies; 5+ messages in thread
From: benh @ 2002-03-04 0:03 UTC (permalink / raw)
To: Michael Zucca, linuxppc-dev
Can you try this patch and tell me if it helps ?
===== drivers/sound/dmasound/dmasound_awacs.c 1.21 vs edited =====
--- 1.21/drivers/sound/dmasound/dmasound_awacs.c Tue Feb 5 09:58:03 2002
+++ edited/drivers/sound/dmasound/dmasound_awacs.c Mon Mar 4 11:32:36 2002
@@ -963,7 +963,9 @@
st_le16(&cp->res_count, 0);
st_le16(&cp->xfer_status, 0);
st_le32(&cp->phy_addr, phy);
- st_le16(&cp->command, OUTPUT_MORE + INTR_ALWAYS);
+ st_le32(&cp->cmd_dep, virt_to_bus
(&awacs_tx_cmds[(i+1)%write_sq.max_count]));
+ st_le16(&cp->command, OUTPUT_MORE | BR_ALWAYS | INTR_ALWAYS);
+
/* point at our patched up command block */
out_le32(&awacs_txdma->cmdptr, virt_to_bus(cp));
/* we must re-start the controller */
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-03-04 0:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-02-22 18:07 2.4.17 and dmasound Michael Zucca
2002-02-22 18:31 ` benh
2002-03-03 19:22 ` 2.4.18 and dmasound and rebooting Michael Zucca
2002-03-03 23:34 ` benh
2002-03-04 0:03 ` benh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).