Merging alsa-firmware into linux-firmware

Merging alsa-firmware into linux-firmware

[David Henningsson]

Hi,

Chase Douglas (@canonical) and I plan to take what's left of
alsa-firmware and try to merge it into linux-firmware, this might happen
now or in the coming weeks. This will make alsa-firmware obsolete as all
firmware will be provided by linux-firmware instead.

Any words of disagreement, warnings or encouragement before we do so?

--
David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

Re: Merging alsa-firmware into linux-firmware

[David Woodhouse]

On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
> Hi,
> 
> Chase Douglas (@canonical) and I plan to take what's left of
> alsa-firmware and try to merge it into linux-firmware, this might happen
> now or in the coming weeks. This will make alsa-firmware obsolete as all
> firmware will be provided by linux-firmware instead.
> 
> Any words of disagreement, warnings or encouragement before we do so?

Encouragement, certainly...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: Merging alsa-firmware into linux-firmware

[David Henningsson]

On 2010-07-20 12:51, David Woodhouse wrote:
> On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
>> Hi,
>>
>> Chase Douglas (@canonical) and I plan to take what's left of
>> alsa-firmware and try to merge it into linux-firmware, this might happen
>> now or in the coming weeks. This will make alsa-firmware obsolete as all
>> firmware will be provided by linux-firmware instead.
>>
>> Any words of disagreement, warnings or encouragement before we do so?
> 
> Encouragement, certainly...

Great!

There are a few firmwares (e g echoaudio and hdsploader) that actually
are .c files with a big constant array in it, like this:

static u_int32_t digiface_firmware[24413] = {
0xffffffff, 0x66aa9955, 0x8001000c, 0xe0000000, 0x8006800c, 0xb0000000,
0x8004800c, 0xb4fc0100, 0x8003000c, 0x00000000, 0x8001000c, 0x90000000,
...etc...

Would you prefer the actual .c files in the linux-firmware git tree
source (and the makefile that goes with it), or just the output from
them (the binary firmware files)?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Merging alsa-firmware into linux-firmware

[David Woodhouse]

On Wed, 2010-07-21 at 11:29 +0200, David Henningsson wrote:
> On 2010-07-20 12:51, David Woodhouse wrote:
> > On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
> >> Hi,
> >>
> >> Chase Douglas (@canonical) and I plan to take what's left of
> >> alsa-firmware and try to merge it into linux-firmware, this might happen
> >> now or in the coming weeks. This will make alsa-firmware obsolete as all
> >> firmware will be provided by linux-firmware instead.
> >>
> >> Any words of disagreement, warnings or encouragement before we do so?
> > 
> > Encouragement, certainly...
> 
> Great!
> 
> There are a few firmwares (e g echoaudio and hdsploader) that actually
> are .c files with a big constant array in it, like this:
> 
> static u_int32_t digiface_firmware[24413] = {
> 0xffffffff, 0x66aa9955, 0x8001000c, 0xe0000000, 0x8006800c, 0xb0000000,
> 0x8004800c, 0xb4fc0100, 0x8003000c, 0x00000000, 0x8001000c, 0x90000000,
> ...etc...
> 
> Would you prefer the actual .c files in the linux-firmware git tree
> source (and the makefile that goes with it), or just the output from
> them (the binary firmware files)?

If it's just a big constant array, you might as well just give me the
binary. If there's *real* source, we'd want that too.

-- 
dwmw2

Re: Merging alsa-firmware into linux-firmware

[David Henningsson]

2010-07-20 12:51, David Woodhouse skrev:
> On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
>> Hi,
>>
>> Chase Douglas (@canonical) and I plan to take what's left of
>> alsa-firmware and try to merge it into linux-firmware, this might happen
>> now or in the coming weeks. This will make alsa-firmware obsolete as all
>> firmware will be provided by linux-firmware instead.
>>
>> Any words of disagreement, warnings or encouragement before we do so?
> 
> Encouragement, certainly...
> 

Okay, so now there's a preliminary version up for review here:
git://kernel.ubuntu.com/diwic/linux-firmware.git, alsa-merge branch.

Feel free to either merge it if you think it's okay, or if it needs
adjustments, let me know (or fix them yourself, whatever is simplest...).

Note that once this one's through, we should adjust alsa-tools for usx2y
to point to /lib/firmware/usx2y and nothing else.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Merging alsa-firmware into linux-firmware

[Takashi Iwai]

At Mon, 26 Jul 2010 10:15:10 +0200,
David Henningsson wrote:
> 
> 2010-07-20 12:51, David Woodhouse skrev:
> > On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
> >> Hi,
> >>
> >> Chase Douglas (@canonical) and I plan to take what's left of
> >> alsa-firmware and try to merge it into linux-firmware, this might happen
> >> now or in the coming weeks. This will make alsa-firmware obsolete as all
> >> firmware will be provided by linux-firmware instead.
> >>
> >> Any words of disagreement, warnings or encouragement before we do so?
> > 
> > Encouragement, certainly...
> > 
> 
> Okay, so now there's a preliminary version up for review here:
> git://kernel.ubuntu.com/diwic/linux-firmware.git, alsa-merge branch.
> 
> Feel free to either merge it if you think it's okay, or if it needs
> adjustments, let me know (or fix them yourself, whatever is simplest...).
> 
> Note that once this one's through, we should adjust alsa-tools for usx2y
> to point to /lib/firmware/usx2y and nothing else.

This is a regression.  It should check both paths if the path is
changed.


Takashi

Re: Merging alsa-firmware into linux-firmware

[Clemens Ladisch]

David Henningsson wrote:
> Chase Douglas (@canonical) and I plan to take what's left of
> alsa-firmware and try to merge it into linux-firmware, this might happen
> now or in the coming weeks. This will make alsa-firmware obsolete as all
> firmware will be provided by linux-firmware instead.

Good idea; these packages have exactly the same purpose.

> Any words of ... warnings

I wonder what you're going to do about the multisound firmware files;
the /lib/firmware/turtlebeach/*.bin files are just symbolic links to
the actual files in /etc/sound that owners of these cards (if any such
still exist) are supposed to have.  

The stuff in emi_26_62 isn't used.  (Er, wasn't there a regression
introduced in the emi62 firmware in 2.6.27?)


Regards,
Clemens

Re: Merging alsa-firmware into linux-firmware

[David Henningsson]

On 2010-07-20 15:31, Clemens Ladisch wrote:
> David Henningsson wrote:
>> Chase Douglas (@canonical) and I plan to take what's left of
>> alsa-firmware and try to merge it into linux-firmware, this might happen
>> now or in the coming weeks. This will make alsa-firmware obsolete as all
>> firmware will be provided by linux-firmware instead.
> 
> Good idea; these packages have exactly the same purpose.
> 
>> Any words of ... warnings
> 
> I wonder what you're going to do about the multisound firmware files;
> the /lib/firmware/turtlebeach/*.bin files are just symbolic links to
> the actual files in /etc/sound that owners of these cards (if any such
> still exist) are supposed to have.  

Ah, thanks for bringing this up to my attention. From where do these
.bin-files come originally? Can we include them?

> The stuff in emi_26_62 isn't used.  (Er, wasn't there a regression
> introduced in the emi62 firmware in 2.6.27?)

I noticed that linux-firmware had one emi26 and one emi62 directory, as
opposed to alsa-firmware that puts it in the emagic directory. So given
your comment, I'll just drop them from the emagic dir.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Merging alsa-firmware into linux-firmware

[Clemens Ladisch]

David Henningsson wrote:
> On 2010-07-20 15:31, Clemens Ladisch wrote:
> > I wonder what you're going to do about the multisound firmware files;
> > the /lib/firmware/turtlebeach/*.bin files are just symbolic links to
> > the actual files in /etc/sound that owners of these cards (if any such
> > still exist) are supposed to have.  
> 
> Ah, thanks for bringing this up to my attention. From where do these
> .bin-files come originally?

I don't know more than what Documentation/sound/oss/MultiSound says.
The download links in there are, of course, broken; with Google, I've
found msndvkit.zip but not pnddk100.zip.

> Can we include them?

| This developer's kit does not provide you with a license to distribute
| any of the contained software, including, but not limited to
| DSPCODE.OBJ, MCONTROL.C. Developers wishing to use these in specific
| applications can do so by requesting and returning the "MultiSound DSP
| OEM Licensing Agreement".
| 
| Turtle Beach's policy on redistribution is simple. For a license fee
| of $1, we allow developers to distribute the above code modules along
| with their products, provided that MultiSound hardware is included in
| the target product. Since DSP_CODE.OBJ only works with MultiSound
| hardware, this is the only logical use of the code.

Try asking Turtle Beach.

> > (Er, wasn't there a regression introduced in the emi62 firmware in
> > 2.6.27?)

http://xiphmont.livejournal.com/46858.html


Regards,
Clemens

Re: Merging alsa-firmware into linux-firmware

[David Henningsson]

On 2010-07-21 08:53, Clemens Ladisch wrote:
> David Henningsson wrote:
>> On 2010-07-20 15:31, Clemens Ladisch wrote:
>>> I wonder what you're going to do about the multisound firmware files;
>>> the /lib/firmware/turtlebeach/*.bin files are just symbolic links to
>>> the actual files in /etc/sound that owners of these cards (if any such
>>> still exist) are supposed to have.  
>>
>> Ah, thanks for bringing this up to my attention. From where do these
>> .bin-files come originally?
> 
> I don't know more than what Documentation/sound/oss/MultiSound says.
> The download links in there are, of course, broken; with Google, I've
> found msndvkit.zip but not pnddk100.zip.
> 
>> Can we include them?
> 
> | This developer's kit does not provide you with a license to distribute
> | any of the contained software, including, but not limited to
> | DSPCODE.OBJ, MCONTROL.C. Developers wishing to use these in specific
> | applications can do so by requesting and returning the "MultiSound DSP
> | OEM Licensing Agreement".
> | 
> | Turtle Beach's policy on redistribution is simple. For a license fee
> | of $1, we allow developers to distribute the above code modules along
> | with their products, provided that MultiSound hardware is included in
> | the target product. Since DSP_CODE.OBJ only works with MultiSound
> | hardware, this is the only logical use of the code.
> 
> Try asking Turtle Beach.

Right. I'll leave them out for now (i e I'll not merge them) for the
following reasons:

1) The people having these files could just put them in /lib/firmware
instead of in /etc/sound

2) The symlinks never worked on Medibuntu, and Medibuntu got no bugs
about that, so probably noone out there uses the firmware anyway. ;-)

>>> (Er, wasn't there a regression introduced in the emi62 firmware in
>>> 2.6.27?)
> http://xiphmont.livejournal.com/46858.html

The emi26/emi62 firmware already exists in linux-firmware, so I won't
merge them either (and that patch in the link is against linux-firmware
and not alsa-firmware).

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Merging alsa-firmware into linux-firmware

[David Woodhouse]

On Wed, 2010-07-21 at 14:31 +0100, David Henningsson wrote:
> The emi26/emi62 firmware already exists in linux-firmware, so I won't
> merge them either (and that patch in the link is against linux-firmware
> and not alsa-firmware). 

I think the *wrong* version is in linux-firmware. But nobody ever
offered a patch to fix that (only a kernel source patch).

-- 
dwmw2

Re: Merging alsa-firmware into linux-firmware

[David Henningsson]

On 2010-07-21 16:02, David Woodhouse wrote:
> On Wed, 2010-07-21 at 14:31 +0100, David Henningsson wrote:
>> The emi26/emi62 firmware already exists in linux-firmware, so I won't
>> merge them either (and that patch in the link is against linux-firmware
>> and not alsa-firmware). 
> 
> I think the *wrong* version is in linux-firmware. 

But the alsa-firmware package currently puts the firmware into the
emagic/ directory, which AFAIK is not used at all by the current kernel.

> But nobody ever
> offered a patch to fix that (only a kernel source patch).

I think the link Clemens just posted goes to such a patch.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Merging alsa-firmware into linux-firmware

[Takashi Iwai]

At Tue, 20 Jul 2010 12:38:01 +0200,
David Henningsson wrote:
> 
> Hi,
> 
> Chase Douglas (@canonical) and I plan to take what's left of
> alsa-firmware and try to merge it into linux-firmware, this might happen
> now or in the coming weeks. This will make alsa-firmware obsolete as all
> firmware will be provided by linux-firmware instead.
> 
> Any words of disagreement, warnings or encouragement before we do so?

Please go ahead.  I wanted to do it in this or next week anyway :)

But grab the very latest alsa-firmware from git tree.  There was an
update of asihpi firmwares.

We'll likely keep alsa-firmware as the "upstream", since it also
provides the file installation for 2.2 / 2.4 kernels.  But, once 
when files are merged to linux-firmware, we'll eventually forward any
changes in future to linux-firmware tree to sync.


thanks,

Takashi

Re: Merging alsa-firmware into linux-firmware

[David Henningsson]

Okay, I think I got most of it sorted out:

emi_26_62 / emagic
korg1212 / korg
maestro3 / ess
sb16 / sb16
wavefront / yamaha
ymfpci / yamaha
...are already in linux-firmware so they won't be merged.

multisound / turtlebeach symlinks won't be merged for the time being,
since the original firmware isn't easily accessible.

usx2yloader however seems to put files outside the /lib/firmware path
(/usr/share/alsa/...), and I believe it has a userspace firmware loader
triggered by an udev event. I'll put it into /lib/firmware/tascam or
something like that, but we need to update the loader as well to use the
new path.

The rest should merge without trouble.

On 2010-07-20 12:38, David Henningsson wrote:
> Hi,
> 
> Chase Douglas (@canonical) and I plan to take what's left of
> alsa-firmware and try to merge it into linux-firmware, this might happen
> now or in the coming weeks. This will make alsa-firmware obsolete as all
> firmware will be provided by linux-firmware instead.
> 
> Any words of disagreement, warnings or encouragement before we do so?
> 
> --
> David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
> 



-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Merging alsa-firmware into linux-firmware

[Takashi Iwai]

At Thu, 22 Jul 2010 12:07:33 +0200,
David Henningsson wrote:
> 
> Okay, I think I got most of it sorted out:
> 
> emi_26_62 / emagic
> korg1212 / korg
> maestro3 / ess
> sb16 / sb16
> wavefront / yamaha
> ymfpci / yamaha
> ...are already in linux-firmware so they won't be merged.
> 
> multisound / turtlebeach symlinks won't be merged for the time being,
> since the original firmware isn't easily accessible.
> 
> usx2yloader however seems to put files outside the /lib/firmware path
> (/usr/share/alsa/...), and I believe it has a userspace firmware loader
> triggered by an udev event.

These are basically for 2.2 / 2.4 kernels.  Don't touch them unless you
are 100% sure you do right :)


Takashi

Re: Merging alsa-firmware into linux-firmware

[David Henningsson]

On 2010-07-22 13:20, Takashi Iwai wrote:
> At Thu, 22 Jul 2010 12:07:33 +0200,
> David Henningsson wrote:
>> usx2yloader however seems to put files outside the /lib/firmware path
>> (/usr/share/alsa/...), and I believe it has a userspace firmware loader
>> triggered by an udev event.
> 
> These are basically for 2.2 / 2.4 kernels.  Don't touch them unless you
> are 100% sure you do right :)

Assuming you mean the tascam usx2yloader, a little digging shows that,

1) the usx2y driver never calls request_firmware (unless I really missed
something)

2) there is an Ubuntu specific patch which creates an udev rule for
calling tascam_fw and tascam_fpga (from alsa-tools) when a tascam device
is connected.

Are you saying that the tascam devices (us122, us224, us428) no longer
need that firmware?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: Merging alsa-firmware into linux-firmware

[Takashi Iwai]

At Thu, 22 Jul 2010 14:41:20 +0200,
David Henningsson wrote:
> 
> On 2010-07-22 13:20, Takashi Iwai wrote:
> > At Thu, 22 Jul 2010 12:07:33 +0200,
> > David Henningsson wrote:
> >> usx2yloader however seems to put files outside the /lib/firmware path
> >> (/usr/share/alsa/...), and I believe it has a userspace firmware loader
> >> triggered by an udev event.
> > 
> > These are basically for 2.2 / 2.4 kernels.  Don't touch them unless you
> > are 100% sure you do right :)
> 
> Assuming you mean the tascam usx2yloader, a little digging shows that,

Ah, OK, I was somehow confused about hdsploader & co installing to
different paths.
About usx2y stuff, it's like what you wrote below.

> 1) the usx2y driver never calls request_firmware (unless I really missed
> something)
> 
> 2) there is an Ubuntu specific patch which creates an udev rule for
> calling tascam_fw and tascam_fpga (from alsa-tools) when a tascam device
> is connected.
> 
> Are you saying that the tascam devices (us122, us224, us428) no longer
> need that firmware?

They need the firmware files.


Takashi