From: James Courtier-Dutton <James@superbug.co.uk>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel <alsa-devel@lists.sourceforge.net>,
Jaroslav Kysela <perex@suse.cz>
Subject: Re: Feature needed for EMU1820m driver
Date: Thu, 28 Sep 2006 18:02:34 +0100 [thread overview]
Message-ID: <451C002A.6060706@superbug.co.uk> (raw)
In-Reply-To: <s5hk63o2lt0.wl%tiwai@suse.de>
Takashi Iwai wrote:
> At Wed, 27 Sep 2006 20:58:57 +0200 (CEST),
> Jaroslav Kysela wrote:
>
>> On Wed, 27 Sep 2006, James Courtier-Dutton wrote:
>>
>>
>>> Hi,
>>>
>>> The E-MU 1820m consists of a PCI card with a connector on it.
>>> A cable then runs to an external box called the AudioDock with all the
>>> audio IO on it.
>>> The AudioDock is hot pluggable.
>>> The problem is that no interrupts occur if one connects the AudioDock.
>>> One would have to poll the device until one saw a certain bit being set.
>>> One would then know the AudioDock was there. The driver then needs to
>>> load some firmware into the AudioDock.
>>>
>>> My question is, what should I use to monitor for the plug/unplug of the
>>> AudioDock? I would expect some user land app could do the polling, but
>>> that might require some new ALSA api to support it.
>>>
>> I would use a low resolution (probably ~1 sec) system timer to check this
>> bit and request the additional firmware in tasklet or workqueue. In this
>> case, the userland is not required to participate.
>>
>
> Agreed (tasklet cannot used for firmware loading, though).
>
> The unplug would be more tough, I guess. The driver has to accept
> that the box can be unplugged at any time.
>
>
> Takashi
>
Ok, that's and interesting problem them, because about the only thing it
has to do when plugged in is load the firmware.
So, if a tasklet it not useable for firmware loading, what should I use?
It is a shame that the kernel does not have a global poll function,
where one justs adds their function to a queue with minimum and maximum
poll intervals, and a single kernel task then steps through each one
doing the poll. If the poll returns true, the kernel should then
schedule a function to be run. This would use less task switching.
James
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
next prev parent reply other threads:[~2006-09-28 17:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-27 18:15 Feature needed for EMU1820m driver James Courtier-Dutton
2006-09-27 18:43 ` Lee Revell
2006-09-27 18:58 ` Jaroslav Kysela
2006-09-28 12:54 ` Takashi Iwai
2006-09-28 17:02 ` James Courtier-Dutton [this message]
2006-09-28 17:19 ` Lee Revell
2006-09-29 10:08 ` Takashi Iwai
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=451C002A.6060706@superbug.co.uk \
--to=james@superbug.co.uk \
--cc=alsa-devel@lists.sourceforge.net \
--cc=perex@suse.cz \
--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.