* Feature needed for EMU1820m driver @ 2006-09-27 18:15 James Courtier-Dutton 2006-09-27 18:43 ` Lee Revell 2006-09-27 18:58 ` Jaroslav Kysela 0 siblings, 2 replies; 7+ messages in thread From: James Courtier-Dutton @ 2006-09-27 18:15 UTC (permalink / raw) To: alsa-devel 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. 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature needed for EMU1820m driver 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 1 sibling, 0 replies; 7+ messages in thread From: Lee Revell @ 2006-09-27 18:43 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: alsa-devel On Wed, 2006-09-27 at 19:15 +0100, 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. Standard kernel timer? That's what network drivers use to poll for link state changes... Lee ------------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature needed for EMU1820m driver 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 1 sibling, 1 reply; 7+ messages in thread From: Jaroslav Kysela @ 2006-09-27 18:58 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: alsa-devel 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. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs ------------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature needed for EMU1820m driver 2006-09-27 18:58 ` Jaroslav Kysela @ 2006-09-28 12:54 ` Takashi Iwai 2006-09-28 17:02 ` James Courtier-Dutton 0 siblings, 1 reply; 7+ messages in thread From: Takashi Iwai @ 2006-09-28 12:54 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: alsa-devel, James Courtier-Dutton 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 ------------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature needed for EMU1820m driver 2006-09-28 12:54 ` Takashi Iwai @ 2006-09-28 17:02 ` James Courtier-Dutton 2006-09-28 17:19 ` Lee Revell 2006-09-29 10:08 ` Takashi Iwai 0 siblings, 2 replies; 7+ messages in thread From: James Courtier-Dutton @ 2006-09-28 17:02 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, Jaroslav Kysela 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature needed for EMU1820m driver 2006-09-28 17:02 ` James Courtier-Dutton @ 2006-09-28 17:19 ` Lee Revell 2006-09-29 10:08 ` Takashi Iwai 1 sibling, 0 replies; 7+ messages in thread From: Lee Revell @ 2006-09-28 17:19 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Takashi Iwai, alsa-devel, Jaroslav Kysela On Thu, 2006-09-28 at 18:02 +0100, James Courtier-Dutton wrote: > > 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? You must use a workqueue - it's the only bottom half mechanism that can sleep. Lee ------------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature needed for EMU1820m driver 2006-09-28 17:02 ` James Courtier-Dutton 2006-09-28 17:19 ` Lee Revell @ 2006-09-29 10:08 ` Takashi Iwai 1 sibling, 0 replies; 7+ messages in thread From: Takashi Iwai @ 2006-09-29 10:08 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: alsa-devel, Jaroslav Kysela At Thu, 28 Sep 2006 18:02:34 +0100, James Courtier-Dutton wrote: > > 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? A workqueue. > 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. What is the difference with a system timer? > If the poll returns true, the kernel should then > schedule a function to be run. This would use less task switching. A timer handler can schedule a workq. That's exactly what we suggested... Alternatively, you can make your workq task polling by itself. A work can reschedule itself with a certain delay. Takashi ------------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-09-29 10:08 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2006-09-28 17:19 ` Lee Revell 2006-09-29 10:08 ` Takashi Iwai
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.