From: Doug Ledford <dledford@redhat.com>
To: Nathan Bryant <nbryant@optonline.net>
Cc: Mario Mikocevic <mozgy@hinet.hr>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: i810 audio patch
Date: Wed, 05 Dec 2001 22:39:17 -0500 [thread overview]
Message-ID: <3C0EE865.1090607@redhat.com> (raw)
In-Reply-To: <3C0C16E7.70206@optonline.net> <3C0C58DE.9020703@optonline.net> <3C0C5CB2.6000602@optonline.net> <3C0C61CC.1060703@redhat.com> <20011204153507.A842@danielle.hinet.hr> <3C0D1DD2.4040609@optonline.net> <3C0D223E.3020904@redhat.com> <3C0D350F.9010408@optonline.net> <3C0D3CF7.6030805@redhat.com> <3C0D4E62.4010904@optonline.net> <3C0D52F1.5020800@optonline.net> <3C0D5796.6080202@redhat.com> <3C0D5CB6.1080600@optonline.net> <3C0D5FC7.3040408@redhat.com> <3C0D77D9.70205@optonline.net> <3C0D8B00.2040603@optonline.net> <3C0D8F02.8010408@redhat.com> <3C0D9456.6090106@optonline.net> <3C0DA1CC.1070408@redhat.com> <3C0DAD26.1020906@optonline.net> <3C0DAF35.50008@redhat.com> <3C0E7DCB.6050600@optonline.net> <3C0E7DFB.2030400@optonline.net> <3C0E7F1C.4060603@redhat.com> <3C0E8DBF.5010000@optonline.net> <3C0E90B2.1030601@redhat.com> <3C0EB1F2.7050007@optonline.net> <3C0EB46C.4010806@optonline.net> <3C0EBAEF.5090402@redhat.com> <3C0EC219.8010107@redhat! .com> <3C0EDDC2.608@optonl! ine.net>
Nathan Bryant wrote:
> as evidenced by,
>
>
> /* if we are currently stopped, then our CIV is actually set to our
> * *last* sg segment and we are ready to wrap to the next. However,
> * if we set our LVI to the last sg segment, then it won't wrap to
> * the next sg segment, it won't even get a start. So, instead,
> when
> * we are stopped, we set both the LVI value and also we increment
> * the CIV value to the next sg segment to be played so that when
> * we call start_{dac,adc}, things will operate properly
> */
> if (!dmabuf->enable) {
> #ifdef DEBUG_MMAP
> printk("fnord? %d\n", inb(port+OFF_CIV));
> #endif
> /* maybe we have to increment LVI to make room before
> incrementing CIV,
> (databook says CELV isn't cleared until new val written
> to LVI.)
> we'll set LVI where we really want it down below. */
> //outb((inb(port+OFF_LVI)+1)&31, port+OFF_LVI);
> newciv = (inb(port+OFF_CIV)+1)&31;
> outb(newciv, port+OFF_CIV);
> for (x = 0; inb(port+OFF_CIV) != newciv && x< 5000000; x++);
> if (x==5000000) printk("foo! civ != %d\n", newciv);
> }
>
> and
>
> Dec 5 21:34:32 lasn-001 kernel: foo! civ != 1
>
> CIV doesn't seem to respond to writes on my chipset, at least not in
> this situation. you'll note that nowhere in the driver are we
> initializing CIV to anything other than 0 anyway.
>
> two alternatives I can think of:
>
> first fix:
> set LVI to desired value minus one SG
> start_dac (which should have side effect of incrementing CIV by one)
> increment LVI to desired value
>
> 2nd fix:
> back off and perform DMA reset.
>
> 3rd fix (really fix 1a ;)
> just don't allow use of the last SG when restarting
>
Try this out:
/* if we are currently stopped, then our CIV is actually set to our
* *last* sg segment and we are ready to wrap to the next.
However,
* if we set our LVI to the last sg segment, then it won't wrap to
* the next sg segment, it won't even get a start. So,
instead, when
* we are stopped, we set both the LVI value and also we increment
* the CIV value to the next sg segment to be played so that when
* we call start_{dac,adc}, things will operate properly
*/
if (!dmabuf->enable) {
outb((inb(port+OFF_CIV)+1)&31, port+OFF_LVI);
if(rec) {
__start_adc(state);
while( !(inb(port + OFF_CR) & ((1<<4) | (1<<2))) )
barrier();
} else {
__start_dac(state);
while( !(inb(port + OFF_CR) & ((1<<4) | (1<<2))) )
barrier();
}
}
--
Doug Ledford <dledford@redhat.com> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
next prev parent reply other threads:[~2001-12-06 3:39 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-04 0:20 i810 audio patch Nathan Bryant
2001-12-04 4:26 ` Doug Ledford
[not found] ` <3C0C58DE.9020703@optonline.net>
2001-12-04 5:18 ` Nathan Bryant
2001-12-04 5:40 ` Doug Ledford
2001-12-04 6:07 ` Nathan Bryant
2001-12-04 7:08 ` Nathan Bryant
2001-12-04 16:46 ` Doug Ledford
2001-12-04 20:14 ` Nathan Bryant
2001-12-04 20:16 ` Doug Ledford
2001-12-04 14:35 ` Mario Mikocevic
2001-12-04 19:02 ` Nathan Bryant
2001-12-04 19:21 ` Doug Ledford
2001-12-04 20:41 ` Nathan Bryant
2001-12-04 21:15 ` Doug Ledford
2001-12-04 21:39 ` Nathan Bryant
2001-12-04 21:53 ` Nathan Bryant
2001-12-04 22:29 ` Nathan Bryant
2001-12-04 22:49 ` Nathan Bryant
2001-12-04 23:09 ` Doug Ledford
2001-12-04 23:31 ` Nathan Bryant
2001-12-04 23:44 ` Doug Ledford
2001-12-05 1:26 ` Nathan Bryant
2001-12-05 2:48 ` Nathan Bryant
2001-12-05 3:05 ` Doug Ledford
2001-12-05 3:28 ` Nathan Bryant
2001-12-05 4:25 ` Doug Ledford
2001-12-05 5:14 ` Nathan Bryant
2001-12-05 5:23 ` Doug Ledford
2001-12-05 20:04 ` Nathan Bryant
2001-12-05 20:05 ` Nathan Bryant
2001-12-05 20:10 ` Doug Ledford
2001-12-05 21:12 ` Nathan Bryant
2001-12-05 21:25 ` Doug Ledford
2001-12-05 21:36 ` Nathan Bryant
2001-12-05 21:56 ` Nathan Bryant
2001-12-05 22:31 ` Doug Ledford
2001-12-05 22:43 ` Doug Ledford
2001-12-05 23:46 ` Nathan Bryant
2001-12-05 23:51 ` Doug Ledford
2001-12-05 23:57 ` Nathan Bryant
2001-12-06 0:25 ` Doug Ledford
2001-12-06 0:50 ` Nathan Bryant
[not found] ` <3C0EC0ED.3000603@optonl! ine.net>
2001-12-06 0:55 ` Doug Ledford
[not found] ` <3C0EC219.8010107@redhat! .com>
2001-12-06 2:53 ` Nathan Bryant
[not found] ` <3C0EDDC2.608@optonl! ine.net>
2001-12-06 3:39 ` Doug Ledford [this message]
[not found] ` <3C0EC219.8010107@redhat!.com>
[not found] ` <3C0EE865.1090607@red! hat.com>
2001-12-06 4:02 ` Nathan Bryant
2001-12-06 4:09 ` Doug Ledford
2001-12-06 15:45 ` i810 audio patch (it _works_ for me :) Mario Mikocevic
2001-12-06 17:00 ` i810 audio patch Pascal Junod
2001-12-05 4:41 ` Nathan Bryant
2001-12-05 5:10 ` Doug Ledford
2001-12-05 5:35 ` Nathan Bryant
2001-12-05 7:24 ` Nathan Bryant
2001-12-04 23:05 ` Doug Ledford
2001-12-04 9:03 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2001-12-06 19:49 Nathan Bryant
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=3C0EE865.1090607@redhat.com \
--to=dledford@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mozgy@hinet.hr \
--cc=nbryant@optonline.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox