[bisected] lx6464es fails to open a second time

[bisected] lx6464es fails to open a second time

[Tim Blechmann]

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

Re: [alsa-devel] [bisected] lx6464es fails to open a second time

[Clemens Ladisch]

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

Re: [alsa-devel] [bisected] lx6464es fails to open a second time

[Tim Blechmann]

> > 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

Re: [alsa-devel] [bisected] lx6464es fails to open a second time

[Takashi Iwai]

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