Re: Feature needed for EMU1820m driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux