From: James Courtier-Dutton <James@superbug.co.uk>
To: Takashi Iwai <tiwai@suse.de>
Cc: Sergey Vlasov <vsu@altlinux.ru>,
alsa-devel <alsa-devel@lists.sourceforge.net>
Subject: Re: Update: emu1212m
Date: Wed, 21 Jun 2006 13:01:02 +0100 [thread overview]
Message-ID: <449934FE.8070904@superbug.co.uk> (raw)
In-Reply-To: <s5hirmueqvi.wl%tiwai@suse.de>
Takashi Iwai wrote:
> At Wed, 21 Jun 2006 13:14:47 +0400,
> Sergey Vlasov wrote:
>
>>> The trouble is, that if one changes some controls on the device, e.g.
>>> switching from SPDIF to ADAT digital outputs, a whole new different
>>> firmware image is loaded. So, one has multiple different firmware
>>> images, with one swapping between them. Should these firmware images be
>>> left in the kernel then, instead of using the userspace firmware api?
>>>
>> There are some drivers in the kernel which load different firmware images
>> in different modes. E.g., the ipw2200 driver can load ipw2200-bss.fw,
>> ipw2200-ibss.fw or ipw2200-sniffer.fw depending on the mode set by
>> iwconfig (and can switch between them at runtime).
>>
>> There is also an option to use a single firmware file consisting of
>> multiple parts used for different modes, but this obviously has a higher
>> memory overhead. IMHO this should be used only when there are some
>> latency restrictions for switching modes (so that a driver can request all
>> firmware parts during initialization and then load different parts without
>> waiting for userspace helpers).
>>
>
> Well, from programming perspective, keeping all firmware images
> would be easier, so I would implement the cached images at first.
> In addition, these images are also useful to implement
> suspend/resume.
>
>
> Takashi
>
Ok, but if I am going to cache the images, I might as well just include
them in the driver .c code. The space taken up will be the same.
I suppose the advantage of using the cache, it that the images are then
only loaded for the card variants that need it. I.e. loaded for
emu1212m, but not loaded to Audigy2.
James
next prev parent reply other threads:[~2006-06-21 12:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-18 9:14 Update: emu1212m James Courtier-Dutton
2006-06-21 7:56 ` James Courtier-Dutton
2006-06-21 8:04 ` Jaroslav Kysela
2006-06-21 9:14 ` Sergey Vlasov
2006-06-21 10:37 ` Takashi Iwai
2006-06-21 12:01 ` James Courtier-Dutton [this message]
2006-06-21 11:58 ` James Courtier-Dutton
2006-06-21 12:40 ` Takashi Iwai
2006-06-29 22:24 ` James Courtier-Dutton
2006-07-10 23:06 ` James Courtier-Dutton
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=449934FE.8070904@superbug.co.uk \
--to=james@superbug.co.uk \
--cc=alsa-devel@lists.sourceforge.net \
--cc=tiwai@suse.de \
--cc=vsu@altlinux.ru \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox