From: Clemens Ladisch <clemens@ladisch.de>
To: Tim Blechmann <tim@klingt.org>
Cc: Takashi Iwai <tiwai@suse.de>, Brian Gerst <brgerst@gmail.com>,
alsa-devel@alsa-project.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [bisected] lx6464es fails to open a second time
Date: Tue, 22 Nov 2011 08:42:15 +0100 [thread overview]
Message-ID: <4ECB5257.4040600@ladisch.de> (raw)
In-Reply-To: <2428359.JOQWRg64O4@moka>
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
WARNING: multiple messages have this Message-ID (diff)
From: Clemens Ladisch <clemens@ladisch.de>
To: Tim Blechmann <tim@klingt.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.de>,
Brian Gerst <brgerst@gmail.com>
Subject: Re: [alsa-devel] [bisected] lx6464es fails to open a second time
Date: Tue, 22 Nov 2011 08:42:15 +0100 [thread overview]
Message-ID: <4ECB5257.4040600@ladisch.de> (raw)
In-Reply-To: <2428359.JOQWRg64O4@moka>
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
next prev parent reply other threads:[~2011-11-22 7:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-22 0:00 [bisected] lx6464es fails to open a second time Tim Blechmann
2011-11-22 0:00 ` Tim Blechmann
2011-11-22 7:42 ` Clemens Ladisch [this message]
2011-11-22 7:42 ` [alsa-devel] " Clemens Ladisch
2011-11-22 10:17 ` Tim Blechmann
2011-11-22 10:17 ` [alsa-devel] " Tim Blechmann
2011-11-22 10:26 ` Takashi Iwai
2011-11-22 10:26 ` [alsa-devel] " Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ECB5257.4040600@ladisch.de \
--to=clemens@ladisch.de \
--cc=alsa-devel@alsa-project.org \
--cc=brgerst@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tim@klingt.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.