Can you send me the source that you have with separate email
(tar/bzip2)? I am wondering if the source base is old. Send to
twoller@crystal.cirrus.com I'll take a look at it with what I
have as the latest.
I don't know of any such problem on the x86 or the IA64
platforms.
Now, if you are trying use the MMAP interface with capture (ADC)
then I know that there will be some problems. non-mmap capture
should work fine. Also, if s->dma_adc.count is not decrementing
then interrupts have ceased or there is a bug in the driver,
maybe a race condition in the driver that needs to be fixed.
Thanks
tom
-----Original Message-----
From: Bao C. Ha [mailto:baoha@sensoria.com]
Sent: Thursday, September 13, 2001 2:29 PM
To: twoller@crystal.cirrus.com
Cc: audio@crystal.cirrus.com; linux-kernel@vger.kernel.org
Subject: Problems with Crystal cs4281 driver in 2.4.8
We are running kernel 2.4.8 on the sh4 platform.
We are encoutering a problem with the cs4281
driver as described in the following:
The device file is opened normally. Everything
is working fine. Then, when it is closed, the
application hangs. A ctrl-C is required to get
out of it. Upon further examining, we find that
the close() call is not returning. It is stuck
at the drain_adc().
In the cs4281_release(),
...
if (file->f_mode & FMODE_READ) {
------> drain_adc(s, file->f_flags & O_NONBLOCK);
down(&s->open_sem_adc);
stop_adc(s);
...
And in the drain_adc(),
...
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
spin_lock_irqsave(&s->lock, flags);
-----> count = s->dma_adc.count;
CS_DBGOUT(CS_FUNCTION, 2,
printk(KERN_INFO "cs4281: drain_adc()
%d\n",
count));
spin_unlock_irqrestore(&s->lock, flags);
...
It seems that since s->dma_adc.count=8192, we
are going into an infinite loop there, in
drain_adc(),
The work-around that we are currently looking
at is setting the flag to O_NONBLOCKING just
prior to closing the device to take advantages
of this.
...
if (nonblock) {
remove_wait_queue(&s->dma_adc.wait,
&wait);
current->state = TASK_RUNNING;
return -EBUSY;
}
...
Unfortunately, it causes problems later
since it is in non-blocking mode. Do a
fcntl(fd, F_SETFL, 0);
did not reset to the normal/blocking mode.
What would be the proper way to handle this
situation? Since I am not familiar with the
driver, I don't know if removing the
drain_adc() from cs4281_release() would cause
problems later or not. I am also not sure
this behavior is specific to the sh4-linux
port or not.
Appreciate any suggestions/comments.
Regards.
Bao
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 15 2001 - 21:00:43 EST