[Top] [All Lists]

Re: [alsa-devel] SB16 build error.

To: Ralf Baechle <>
Subject: Re: [alsa-devel] SB16 build error.
From: Clemens Ladisch <>
Date: Thu, 30 Jun 2011 15:10:21 +0200
Cc: Takashi Iwai <>,,,,, "David S. Miller" <>, Benjamin Herrenschmidt <>,, Ivan Kokshaysky <>,, Paul Mackerras <>, Matt Turner <>, Florian Fainelli <>, Richard Henderson <>
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=Cn1EpHEy9V8Pg9vDofG2ppFvUI4=; b=HbRAjeTHyzl/zHQNJRtHhRFTrlcEmnu48bEUc7aLiYBMrh/q5v8st339/vM5TKKRYG+p8Xncy648z4LbHUkKgqSFQ1e2T0Nh+yZBnmeay23lDU8NQBf8CAhxSPKuA6+S08tPlj8lwQija6C3SEXit8W/jy1NYod4PUQzmBXgg8U=
In-reply-to: <>
References: <> <> <>
User-agent: Thunderbird (Windows/20100228)
Ralf Baechle 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 biggest file is WFM0001A.CSP with 0x2df0 bytes.

> I don't see how the old ioctl can possibly have been
> used before so there isn't a compatibility problem.

The code uses SNDRV_SB_CSP_MAX_MICROCODE_FILE_SIZE but doesn't care what
the size field of the ioctl code is, so we could use any random value on
those architectures.

> Or you could entirely sidestep the problem and use request_firmware()
> but I guess that's more effort than you want to invest.

The driver already implements this for a bunch of predefined CSP code
blobs.  I'm not sure whether anybody has ever loaded additional .csp


<Prev in Thread] Current Thread [Next in Thread>