From: Ralf Baechle <ralf@linux-mips.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: linux-arch@vger.kernel.org, linux-mips@linux-mips.org,
alsa-devel@alsa-project.org, florian@linux-mips.org,
"David S. Miller" <davem@davemloft.net>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linux-kernel@vger.kernel.org,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
sparclinux@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Matt Turner <mattst88@gmail.com>,
Florian Fainelli <florian@openwrt.org>,
Richard Henderson <rth@twiddle.net>
Subject: Re: SB16 build error.
Date: Thu, 30 Jun 2011 13:32:12 +0100 [thread overview]
Message-ID: <20110630123212.GA6690@linux-mips.org> (raw)
In-Reply-To: <s5hy60jwocc.wl%tiwai@suse.de>
On Thu, Jun 30, 2011 at 01:28:03PM +0200, Takashi Iwai wrote:
> > > I have no idea how big the soundblaster microcode being loaded actually is,
> > > that is if the reduced size of 0x1f00 will be sufficient.
> >
> > The files found in /lib/firmware/sb16 are all under 2kB, thus likely
> > sufficient.
>
> Too shortly answered. It turned out that some CSP codes (like Qsound)
> can be above that size, it's almost 12kB. So the size in the original
> code is really the necessary requirement, and the patch breaks for
> such a case.
>
> An ugly workaround would be to fake the ioctl size. But this is
> certainly to be avoided, since it has been broken on the specific
> platforms for ages, thus breaking for them would be mostly harmless,
> too.
>
> > > Aside of that I
> > > don't see a problem - I don't see how the old ioctl can possibly have been
> > > used before so there isn't a compatibility problem.
> > >
> > > Or you could entirely sidestep the problem and use request_firmware() but
> > > I guess that's more effort than you want to invest.
> >
> > Yeah, that's another option I thought of. But it's too intrusive for
> > 3.0-rc6, so I'd like waive it for 3.1.
>
> Actually the request_firmware() was implemented for some auto-loadable
> CSP codes. Others need the manual loading, so it is via ioctl. It
> can be converted, but I don't think it makes sense for such old
> stuff. After all, it still works with x86-ISA as is.
In userland an empty definition will be used for _IOC_TYPECHECK so there
won't be an error. So userland already is already using the existing
value for SNDRV_SB_CSP_IOCTL_LOAD_CODE ...
With a crude hack like
#define SNDRV_SB_CSP_IOCTL_LOAD_CODE \
_IOC(_IOC_WRITE,'H', 0x11, sizeof(struct snd_sb_csp_microcode))
error checking can be bypassed and all will be fine as long as the
resulting value doesn't result in in a a duplicate case value - which it
doesn't, at least not in my testing.
Should work but isn't nice.
Ralf
WARNING: multiple messages have this Message-ID (diff)
From: Ralf Baechle <ralf@linux-mips.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: Jaroslav Kysela <perex@perex.cz>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
linux-mips@linux-mips.org, florian@linux-mips.org,
Florian Fainelli <florian@openwrt.org>,
linux-arch@vger.kernel.org, Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"David S. Miller" <davem@davemloft.net>,
sparclinux@vger.kernel.org
Subject: Re: SB16 build error.
Date: Thu, 30 Jun 2011 13:32:12 +0100 [thread overview]
Message-ID: <20110630123212.GA6690@linux-mips.org> (raw)
Message-ID: <20110630123212.5ZnRH3AIaVoUVgRH_ha41jYkYbEpFMj7ZwBajyTb7eg@z> (raw)
In-Reply-To: <s5hy60jwocc.wl%tiwai@suse.de>
On Thu, Jun 30, 2011 at 01:28:03PM +0200, Takashi Iwai wrote:
> > > I have no idea how big the soundblaster microcode being loaded actually is,
> > > that is if the reduced size of 0x1f00 will be sufficient.
> >
> > The files found in /lib/firmware/sb16 are all under 2kB, thus likely
> > sufficient.
>
> Too shortly answered. It turned out that some CSP codes (like Qsound)
> can be above that size, it's almost 12kB. So the size in the original
> code is really the necessary requirement, and the patch breaks for
> such a case.
>
> An ugly workaround would be to fake the ioctl size. But this is
> certainly to be avoided, since it has been broken on the specific
> platforms for ages, thus breaking for them would be mostly harmless,
> too.
>
> > > Aside of that I
> > > don't see a problem - I don't see how the old ioctl can possibly have been
> > > used before so there isn't a compatibility problem.
> > >
> > > Or you could entirely sidestep the problem and use request_firmware() but
> > > I guess that's more effort than you want to invest.
> >
> > Yeah, that's another option I thought of. But it's too intrusive for
> > 3.0-rc6, so I'd like waive it for 3.1.
>
> Actually the request_firmware() was implemented for some auto-loadable
> CSP codes. Others need the manual loading, so it is via ioctl. It
> can be converted, but I don't think it makes sense for such old
> stuff. After all, it still works with x86-ISA as is.
In userland an empty definition will be used for _IOC_TYPECHECK so there
won't be an error. So userland already is already using the existing
value for SNDRV_SB_CSP_IOCTL_LOAD_CODE ...
With a crude hack like
#define SNDRV_SB_CSP_IOCTL_LOAD_CODE \
_IOC(_IOC_WRITE,'H', 0x11, sizeof(struct snd_sb_csp_microcode))
error checking can be bypassed and all will be fine as long as the
resulting value doesn't result in in a a duplicate case value - which it
doesn't, at least not in my testing.
Should work but isn't nice.
Ralf
WARNING: multiple messages have this Message-ID (diff)
From: Ralf Baechle <ralf@linux-mips.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: linux-arch@vger.kernel.org, linux-mips@linux-mips.org,
alsa-devel@alsa-project.org, florian@linux-mips.org,
"David S. Miller" <davem@davemloft.net>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linux-kernel@vger.kernel.org,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
sparclinux@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Matt Turner <mattst88@gmail.com>,
Florian Fainelli <florian@openwrt.org>,
Richard Henderson <rth@twiddle.net>
Subject: Re: SB16 build error.
Date: Thu, 30 Jun 2011 12:32:12 +0000 [thread overview]
Message-ID: <20110630123212.GA6690@linux-mips.org> (raw)
In-Reply-To: <s5hy60jwocc.wl%tiwai@suse.de>
On Thu, Jun 30, 2011 at 01:28:03PM +0200, Takashi Iwai wrote:
> > > I have no idea how big the soundblaster microcode being loaded actually is,
> > > that is if the reduced size of 0x1f00 will be sufficient.
> >
> > The files found in /lib/firmware/sb16 are all under 2kB, thus likely
> > sufficient.
>
> Too shortly answered. It turned out that some CSP codes (like Qsound)
> can be above that size, it's almost 12kB. So the size in the original
> code is really the necessary requirement, and the patch breaks for
> such a case.
>
> An ugly workaround would be to fake the ioctl size. But this is
> certainly to be avoided, since it has been broken on the specific
> platforms for ages, thus breaking for them would be mostly harmless,
> too.
>
> > > Aside of that I
> > > don't see a problem - I don't see how the old ioctl can possibly have been
> > > used before so there isn't a compatibility problem.
> > >
> > > Or you could entirely sidestep the problem and use request_firmware() but
> > > I guess that's more effort than you want to invest.
> >
> > Yeah, that's another option I thought of. But it's too intrusive for
> > 3.0-rc6, so I'd like waive it for 3.1.
>
> Actually the request_firmware() was implemented for some auto-loadable
> CSP codes. Others need the manual loading, so it is via ioctl. It
> can be converted, but I don't think it makes sense for such old
> stuff. After all, it still works with x86-ISA as is.
In userland an empty definition will be used for _IOC_TYPECHECK so there
won't be an error. So userland already is already using the existing
value for SNDRV_SB_CSP_IOCTL_LOAD_CODE ...
With a crude hack like
#define SNDRV_SB_CSP_IOCTL_LOAD_CODE \
_IOC(_IOC_WRITE,'H', 0x11, sizeof(struct snd_sb_csp_microcode))
error checking can be bypassed and all will be fine as long as the
resulting value doesn't result in in a a duplicate case value - which it
doesn't, at least not in my testing.
Should work but isn't nice.
Ralf
next prev parent reply other threads:[~2011-06-30 12:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 9:17 SB16 build error Ralf Baechle
2011-06-30 9:17 ` Ralf Baechle
2011-06-30 9:17 ` Ralf Baechle
2011-06-30 10:15 ` Takashi Iwai
2011-06-30 10:15 ` Takashi Iwai
2011-06-30 10:52 ` Ralf Baechle
2011-06-30 10:52 ` Ralf Baechle
2011-06-30 10:52 ` Ralf Baechle
2011-06-30 11:05 ` Takashi Iwai
2011-06-30 11:05 ` Takashi Iwai
2011-06-30 11:28 ` Takashi Iwai
2011-06-30 11:28 ` Takashi Iwai
2011-06-30 12:32 ` Ralf Baechle [this message]
2011-06-30 12:32 ` Ralf Baechle
2011-06-30 12:32 ` Ralf Baechle
2011-06-30 12:38 ` Takashi Iwai
2011-06-30 12:38 ` Takashi Iwai
2011-06-30 12:38 ` Takashi Iwai
2011-06-30 12:43 ` Ralf Baechle
2011-06-30 12:43 ` Ralf Baechle
2011-06-30 12:43 ` Ralf Baechle
2011-06-30 13:14 ` Takashi Iwai
2011-06-30 13:14 ` Takashi Iwai
2011-06-30 13:14 ` Takashi Iwai
2011-07-01 15:31 ` David Howells
2011-07-01 15:31 ` David Howells
2011-06-30 12:54 ` Arnd Bergmann
2011-06-30 12:54 ` Arnd Bergmann
2011-06-30 13:10 ` [alsa-devel] " Clemens Ladisch
2011-06-30 13:10 ` Clemens Ladisch
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=20110630123212.GA6690@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=alsa-devel@alsa-project.org \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=florian@linux-mips.org \
--cc=florian@openwrt.org \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=mattst88@gmail.com \
--cc=paulus@samba.org \
--cc=rth@twiddle.net \
--cc=sparclinux@vger.kernel.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.