From: "Raphaël Doursenaud" <rdoursenaud@free.fr>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH 1/1] hdsp: allow firmware loading from inside the kernel
Date: Tue, 12 May 2009 11:05:34 +0200 [thread overview]
Message-ID: <4A093BDE.8050703@free.fr> (raw)
In-Reply-To: <s5hbppyu34q.wl%tiwai@suse.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Takashi Iwai a écrit :
> At Tue, 12 May 2009 10:01:20 +0200,
> Raphaël Doursenaud wrote:
>> Takashi Iwai a écrit :
>>> At Tue, 12 May 2009 09:41:36 +0200,
>>> Raphaël Doursenaud wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Takashi Iwai a écrit :
>>>>> At Tue, 12 May 2009 09:25:27 +0200,
>>>>> Raphaël Doursenaud wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Takashi Iwai a écrit :
>>>>>>> At Tue, 12 May 2009 09:05:19 +0200,
>>>>>>> Raphaël Doursenaud wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA1
>>>>>>>>
>>>>>>>> Takashi Iwai a écrit :
>>>>>>>>> At Tue, 12 May 2009 08:47:29 +0200,
>>>>>>>>> Raphaël Doursenaud wrote:
>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>> Hash: SHA1
>>>>>>>>>>
>>>>>>>>>> Takashi Iwai a écrit :
>>>>>>>>>>> At Tue, 12 May 2009 08:16:08 +0200,
>>>>>>>>>>> Raphaël Doursenaud wrote:
>>>>>>>>>>>> From: Raphaël Doursenaud <rdoursenaud@free.fr>
>>>>>>>>>>>>
>>>>>>>>>>>> Allow the use of the FIRMWARE_IN_KERNEL option with hdsp cards and
>>>>>>>>>>>> in-kernel driver.
>>>>>>>>>>> Did it really work without problems?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Takashi
>>>>>>>>>> Tested over the weekend with two multifaces in my DAW.
>>>>>>>>>> Got no problem.
>>>>>>>>> Interesting.
>>>>>>>>> Did you build the firmware file into the kernel, or not?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Takashi
>>>>>>>> Yes I built all hdsp fimware files (multiface_firmware.bin
>>>>>>>> multiface_firmware_rev11.bin digiface_firmware.bin
>>>>>>>> digiface_firmware_rev11.bin) into the kernel.
>>>>>>>> It's the aim of this patch.
>>>>>>> Well, the problem I'm concerned is that the driver can be compiled
>>>>>>> in even if you have no built-in firmware. And there is no restriction
>>>>>>> or dependency check in Kconfig, so far.
>>>>>>>
>>>>>>> Could you test how the kernel behaves without the built-in firmware?
>>>>>>> Does it hang or give any critical error?
>>>>>>>
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Takashi
>>>>>> Could you be more specific?
>>>>>> I'm not sure to understand why it could be a problem.
>>>>>> Do you think that if I set FIRMWARE_IN_KERNEL without compiling the
>>>>>> firmware(s) in-kernel the request_firmware() will not resolve and cause
>>>>>> an error?
>>>>> Yes, exactly.
>>>>> request_firmware() shall fail in that case likely after a long
>>>>> time-out (unless you have the firmware files in initrd) because there
>>>>> is really no file / data available at the time it's called.
>>>>> And I'm not sure whether this could lead to a fatal operation error.
>>>>>
>>>>>
>>>>> Takashi
>>>> AFAIK this is handled in the code (from line 5080) and should lead to
>>>> "Hammerfall-DSP: couldn't get firmware from userspace. try using hdsploader"
>>> Yep, a fallback mechanism is found in hdsp driver itself.
>>> But the driver probe hangs for too long time, and I'm just worried
>>> about its influence on the whole kernel boot-up.
>>>
>>>> I'm building a kernel to test that case.
>>> Thanks.
>>>
>>>
>>> Takashi
>> Wow, you're right! Didn't think about that...
>>
>> It hangs for about 45s on :
>> Hammerfall-DSP: wait for FIFO status <= 0 failed after 30 iterations
>> RME Hammerfall DSP 0000:05:02.0: firmware: requesting
>> multiface_firmware_rev11.bin
>>
>> before going on with :
>> Hammerfall-DSP: cannot load firmware multiface_firmware_rev11.bin
>> Hammerfall-DSP: couldn't get firmware from userspace. try using hdsploader
>> Hammerfall-DSP: card initialization pending : waiting for firmware
>
> OK, so it doesn't lead to any critical error?
> Then it's better than the worst case I thought of :)
>
>> I wonder what would be the best way to deal with that while still
>> enabling in-kernel firmware.
>
> Well, it's basically a problem of the request_firmware() itself, so
> we can't fix the behavior properly in the driver side. There is an
> option to use *_nowait() call, but this will end up with a mess of
> code flow, I'm afraid.
>
> So, I'm going to apply your patch. But, maybe we should add a warning
> in Kconfig comment, such as
>
> comment "Don't forget to add built-in firmwares for HDSP driver"
> depends on SND_HDSP=y
>
> or so... Suggestions of a better text are appreciated.
>
>
> thanks,
>
> Takashi
mmm sounds good to me.
With the patch I'm about to propose to correct the firmwares path it
should fit most situations.
Thanks a lot for your input!
- --
Raphaël Doursenaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoJO9oACgkQaZKmNAdXaVU+gwCgmJz3c5YMbtF4KMYkSFX/8m21
L9cAnRc25qVBD57HeUtriA/tDDBI6vO7
=RnGG
-----END PGP SIGNATURE-----
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
prev parent reply other threads:[~2009-05-12 9:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 6:16 [PATCH 1/1] hdsp: allow firmware loading from inside the kernel Raphaël Doursenaud
2009-05-12 6:34 ` Takashi Iwai
2009-05-12 6:44 ` Florian Faber
2009-05-12 6:56 ` Takashi Iwai
2009-05-12 6:47 ` Raphaël Doursenaud
2009-05-12 7:00 ` Takashi Iwai
2009-05-12 7:10 ` Raphaël Doursenaud
[not found] ` <4A091FAF.9090400@free.fr>
2009-05-12 7:18 ` Takashi Iwai
2009-05-12 7:25 ` Raphaël Doursenaud
2009-05-12 7:36 ` Takashi Iwai
2009-05-12 7:42 ` Raphaël Doursenaud
[not found] ` <4A092830.8010602@free.fr>
2009-05-12 7:45 ` Takashi Iwai
2009-05-12 8:01 ` Raphaël Doursenaud
2009-05-12 8:39 ` Takashi Iwai
2009-05-12 9:05 ` Raphaël Doursenaud [this message]
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=4A093BDE.8050703@free.fr \
--to=rdoursenaud@free.fr \
--cc=alsa-devel@alsa-project.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.