[alsa-devel] [bisected] lx6464es fails to open a second time
hi all, especially brian and takashi,
some time ago, i've been developing the driver for the lx6464es ethersound sound card, which has been included into the kernel for some time. however i haven't been able to use it in kernels after 2.6.33.
today, i was able to bisect the issue and the first bad commit is:
commit 6175ddf06b6172046a329e3abfd9c901a43efd2e Author: Brian Gerst brgerst@gmail.com Date: Fri Feb 5 09:37:07 2010 -0500
x86: Clean up mem*io functions.
Iomem has no special significance on x86. Use the standard mem* functions instead of trying to call other versions. Some fixups are needed to match the function prototypes.
Signed-off-by: Brian Gerst brgerst@gmail.com LKML-Reference: 1265380629-3212-6-git-send-email-brgerst@gmail.com Signed-off-by: H. Peter Anvin hpa@zytor.com
the problem was: the sound card could only be started once, but i haven't been able to start it a second time, probably because the driver doesn't shut down the device correctly.
the communication with the device is done by passing simple commands via memcpy_fromio and memcpy_toio (compare sound/pci/lx6464es/lx_core.c, lines 75 to 99). any idea, what is going wrong there?
thanks, tim
Tim Blechmann wrote:
some time ago, i've been developing the driver for the lx6464es ethersound sound card, which has been included into the kernel for some time. however i haven't been able to use it in kernels after 2.6.33.
today, i was able to bisect the issue and the first bad commit is:
commit 6175ddf06b6172046a329e3abfd9c901a43efd2e Author: Brian Gerst brgerst@gmail.com Date: Fri Feb 5 09:37:07 2010 -0500
x86: Clean up mem*io functions.the communication with the device is done by passing simple commands via memcpy_fromio and memcpy_toio (compare sound/pci/lx6464es/lx_core.c, lines 75 to 99). any idea, what is going wrong there?
The old and new implementations of memcpy_*io do not have any differences in the documented API, but the new ones are much more optimized, so they might not use 8- or 32-bit accesses or a different access pattern.
Does the card's mapped I/O region behave exactly like memory, or has it any restrictions on how it can be used? In the latter case, you should implement your readbuf/writebuf functions by hand to use plain 32-bit accesses in order (or whatever is required).
Regards, Clemens
today, i was able to bisect the issue and the first bad commit is:
commit 6175ddf06b6172046a329e3abfd9c901a43efd2e Author: Brian Gerst brgerst@gmail.com Date: Fri Feb 5 09:37:07 2010 -0500
x86: Clean up mem*io functions.the communication with the device is done by passing simple commands via memcpy_fromio and memcpy_toio (compare sound/pci/lx6464es/lx_core.c, lines 75 to 99). any idea, what is going wrong there?
The old and new implementations of memcpy_*io do not have any differences in the documented API, but the new ones are much more optimized, so they might not use 8- or 32-bit accesses or a different access pattern.
Does the card's mapped I/O region behave exactly like memory, or has it any restrictions on how it can be used? In the latter case, you should implement your readbuf/writebuf functions by hand to use plain 32-bit accesses in order (or whatever is required).
indeed, emulating memcpy_*io with ioread32/iowrite32 fixes the issue.
thanks, tim
At Tue, 22 Nov 2011 11:17:45 +0100, Tim Blechmann wrote:
today, i was able to bisect the issue and the first bad commit is:
commit 6175ddf06b6172046a329e3abfd9c901a43efd2e Author: Brian Gerst brgerst@gmail.com Date: Fri Feb 5 09:37:07 2010 -0500
x86: Clean up mem*io functions.the communication with the device is done by passing simple commands via memcpy_fromio and memcpy_toio (compare sound/pci/lx6464es/lx_core.c, lines 75 to 99). any idea, what is going wrong there?
The old and new implementations of memcpy_*io do not have any differences in the documented API, but the new ones are much more optimized, so they might not use 8- or 32-bit accesses or a different access pattern.
Does the card's mapped I/O region behave exactly like memory, or has it any restrictions on how it can be used? In the latter case, you should implement your readbuf/writebuf functions by hand to use plain 32-bit accesses in order (or whatever is required).
indeed, emulating memcpy_*io with ioread32/iowrite32 fixes the issue.
Good to hear. Could you submit a patch?
thanks,
Takashi
participants (3)
-
Clemens Ladisch -
Takashi Iwai -
Tim Blechmann