Feature needed for EMU1820m driver

Feature needed for EMU1820m driver

[James Courtier-Dutton]

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

Re: Feature needed for EMU1820m driver

[Lee Revell]

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

Re: Feature needed for EMU1820m driver

[Jaroslav Kysela]

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

Re: Feature needed for EMU1820m driver

[Takashi Iwai]

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

Re: Feature needed for EMU1820m driver

[James Courtier-Dutton]

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

Re: Feature needed for EMU1820m driver

[Lee Revell]

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

Re: Feature needed for EMU1820m driver

[Takashi Iwai]

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