[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#464197: linux-image-2.6.24-1-686: module snd-cs46xx still missing

The patch I posted leaves SND_CS46XX_NEW_DSP broken.  Because I
have neither rear speakers nor an S/PDIF capable amplifier, and
the newer firmware consists of multiple structures and so is more
difficult to load, I don't currently intend to work on that.

One trap with the patch is that it converts the endianness in
place.  With Linux 2.6.24, this works because request_firmware()
always makes a fresh copy.  However if a reference count is later
added to struct firmware, this scheme will break.  I see that
<linux/firmware.h> makes the struct firmware const but not the
bytes to which its "data" member points; might it be inferred
From this that the data is intended to be modified by drivers?

When testing the patch, I had linux-image-2.6.24-1-686 2.6.24-3
running.  I then unpacked the corresponding sources, made the
changes, ran make -f debian/rules.gen binary-arch_i386_none_686,
and loaded the generated cs46xx.ko without rebooting; the
interfaces between modules remain compatible.  With earlier
versions of the linux-2.6 source, building all the binary
packages has taken 11 to 22 hours here, so calling
debian/rules.gen directly was a huge timesaver.  If this shortcut
is documented, I don't know where.

The patch assumes the binary firmware image is little-endian, and
converts it to host byte order.  Personally, I prefer to have a
fixed format for each data file so that they can be freely shared
between architectures.  I chose little-endian u32 here because
that was easiest for me to output.  I did not bother to implement
the proper conversions in the write_images program though.  If
that source code is going to be added to an Architecture: any
package, then both word-size and endianness conversions should be
implemented.  The original cwcealdr1.zip/cwcimage.h does not
include the definition of struct BA1struct, so I suppose there
wouldn't be any problem in ripping it out again and instead
providing (in the #including file) a definition that has u32 in
the place of unsigned long.  Alternatively, the driver could be
changed to assume that the firmware is already in a host-specific

If Cirrus Logic grants permission to distribute the cs46xx
firmware included in the upstream Linux sources, will that
suffice for SND_CS46XX_NEW_DSP too, or will separate permission
be needed from the author of sound/pci/cs46xx/imgs/cwcdma.asp?

Attachment: pgpq2tt7R2pF0.pgp
Description: PGP signature

Reply to: