Re: testers needed for auich(4)
On Friday 02 April 2010 21:57:54 J.C. Roberts wrote: > Take a look at the last line of the dmesg below (taken just a moment > ago). The system has been up for about a day, and the last line was > added some time after it first booted up. It's typically not seen right > after a fresh cold boot. A *nearly* identical system running a newer > snapshot doesn't have the last speed tweak line. As for what exactly Because it was disabled by default. from my laptop.. auich0: measured ac97 link rate at 47756 Hz, will use 48000 Hz -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: testers needed for auich(4)
On Fri, Apr 02, 2010 at 06:57:54PM -0700, J.C. Roberts wrote: > On Fri, 2 Apr 2010 22:45:12 +0200 Alexandre Ratchov > wrote: > > > > A short summary of the changes: > > > > > > - According to specification AUICH_RR may only be set after DMA > > > is halted (AUICH_DCH is 0 in AUICH_STS). To accomplish this I > > > revived auich_halt_pipe(); > > > - auich_calibrate() did not clear interrupt and event bits in > > > AUICH_STS. Do that now. Further it did watch the CIV index > > > counter to see when all samples are processed. I changed it to > > > watch AUICH_STS instead and set LVI=CIV. therefore it won't > > > change the CIV counter. > > > - my last patch introduced a small bug in auich_trigger_pipe() I > > > fixed that. > > > > > > > I think we should put the corresponding chunk in, sooner > > than later. > > > > BTW, I start wondering why this calibration exists at all? > > do devices running at the wrong rate exist (which would mean > > they don't have the proper clock). If so should we start > > adding calibration code in all of our audio drivers? > > > > -- Alexandre > > Take a look at the last line of the dmesg below (taken just a moment > ago). The system has been up for about a day, and the last line was > added some time after it first booted up. It's typically not seen right > after a fresh cold boot. A *nearly* identical system running a newer > snapshot doesn't have the last speed tweak line. As for what exactly > the speed tweak actually means, I'm not entirely certain. --It kind of > smells like the improper clock you mentioned above, but it does seem to > answer your question if devices running at the wrong rate exist. > auich0: measured ac97 link rate at 48008 Hz, will use 48000 Hz 0.017% deviation is negligible. src/regress/sys/dev/audio measures the difference in audio and system clocks. I wonder how those ISA cards compare to the auich ;) -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: testers needed for auich(4)
On Fri, 2 Apr 2010 22:45:12 +0200 Alexandre Ratchov
wrote:
> > A short summary of the changes:
> >
> > - According to specification AUICH_RR may only be set after DMA
> > is halted (AUICH_DCH is 0 in AUICH_STS). To accomplish this I
> > revived auich_halt_pipe();
> > - auich_calibrate() did not clear interrupt and event bits in
> > AUICH_STS. Do that now. Further it did watch the CIV index
> > counter to see when all samples are processed. I changed it to
> > watch AUICH_STS instead and set LVI=CIV. therefore it won't
> > change the CIV counter.
> > - my last patch introduced a small bug in auich_trigger_pipe() I
> > fixed that.
> >
>
> I think we should put the corresponding chunk in, sooner
> than later.
>
> BTW, I start wondering why this calibration exists at all?
> do devices running at the wrong rate exist (which would mean
> they don't have the proper clock). If so should we start
> adding calibration code in all of our audio drivers?
>
> -- Alexandre
Take a look at the last line of the dmesg below (taken just a moment
ago). The system has been up for about a day, and the last line was
added some time after it first booted up. It's typically not seen right
after a fresh cold boot. A *nearly* identical system running a newer
snapshot doesn't have the last speed tweak line. As for what exactly
the speed tweak actually means, I'm not entirely certain. --It kind of
smells like the improper clock you mentioned above, but it does seem to
answer your question if devices running at the wrong rate exist.
The system is not set up to do any power management (speed stepping,
apm, suspend, resume, ...). It just runs at full power. But this could
explain why the auich rate change in the dmesg is not seen consistently.
Is it possible some audio devices *expect* recalibration after a power
management event?
I've got the most recent snap downloading at the moment, but as usual,
I'll be lucky if it arrives without errors, and at best it will be late
tomorrow before I can start testing it. The most recent snap I have on
hand is March 24th, before the pmem and isa stuff went in.
$ dmesg
OpenBSD 4.7-beta (GENERIC) #521: Tue Feb 2 17:34:24 MST 2010
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.40GHz ("GenuineIntel" 686-class) 2.40
GHz cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem = 2137550848 (2038MB) avail mem = 2062446592 (1966MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/10/05, BIOS32 rev. 0 @
0xfd844, SMBIOS rev. 2.31 @ 0xf00f0 (51 entries) bios0: vendor IBM
version "24KT55AUS" date 05/10/2005 bios0: IBM 8315XX4
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP TCPA APIC BOOT
acpi0: wakeup devices USB1(S3) USB2(S3) USB3(S3) USBE(S3) SLOT(S5) KBC_
(S3) COMA(S5) COMB(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (SLOT)
acpiprt2 at acpi0: bus -1 (AGP_)
acpicpu0 at acpi0
acpitz0 at acpi0: critical temperature 105 degC
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xb400 0xe/0x1!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82845G Host" rev 0x01
vga1 at pci0 dev 2 function 0 "Intel 82845G Video" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0x8800, size 0x800
inteldrm0 at vga1: apic 1 int 16 (irq 11)
drm0 at inteldrm0
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: apic 1
int 16 (irq 11) uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev
0x01: apic 1 int 19 (irq 10) uhci2 at pci0 dev 29 function 2 "Intel
82801DB USB" rev 0x01: apic 1 int 18 (irq 5) ehci0 at pci0 dev 29
function 7 "Intel 82801DB USB" rev 0x01: apic 1 int 23 (irq 9) usb0 at
ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev
2.00/1.00 addr 1 ppb0 at pci0 dev 30 function 0 "Intel 82801BA
Hub-to-PCI" rev 0x81 pci1 at ppb0 bus 2
fxp0 at pci1 dev 8 function 0 "Intel PRO/100 VE" rev 0x81, i82562: apic
1 int 20 (irq 11), address 00:09:6b:cf:f5:2b inphy0 at fxp0 phy 1:
i82562EM 10/100 PHY, rev. 0 ichpcib0 at pci0 dev 31 function 0 "Intel
82801DB LPC" rev 0x01 pciide0 at pci0 dev 31 function 1 "Intel 82801DB
IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1
configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 239372MB, 490234752 sectors wd0
6Y250L6> (pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI
5/cdrom removable wd1 at pciide0 channel 1 drive 1:
wd1: 16-
Re: testers needed for auich(4)
On Thu, Apr 01, 2010 at 05:37:13PM +0200, Christopher Zimmermann wrote:
> Hi,
>
> here's a patch for auich(4). It fixes some issues with SIS 7012
> and possibly others. But since it relies on correct behaviour of
> the hardware at some places it needs some testing. Especially try
> to run something like:
>
> aucat -l; play test.wav
>
> right after booting and before anything else is played or
> recorded.
>
> the typical output would be:
>
> auich0: ac97 link rate calibration took 83337 us
> sts=7 civ=0 auich0: after calibration and reset
> sts=1 civ=0 auich0: measured ac97 link rate at 47997 Hz,
> will use 48000 Hz auich_trigger_output(ed99000, eda7600, 11776,
> 0x80271e20, 0x8015dc00, 0x8015dd90)
> sts=1 auich_trigger_pipe: qptr=0
> auich_trigger_input(eda9000, edb7600, 11776, 0x80272010,
> 0x8015dc00, 0x8015ddb8) sts=1
> auich_trigger_pipe: qptr=0 auich0: halt_input auich0: halt_output
>
> Important is the value of sts. dch means "DMA halted" - one
> should not set AUICH_RR before this bit is set.
> In auich_calibrate() I wait for any of the three bits
> to be set.
> If something goes wrong here you will see:
> auich0: ac97 link rate timed out %d us sts=%b civ=%d\n"
>
> If something goes wrong in halt_pipe you will see:
> auich_halt_pipe: halt took %d cycles
>
>
> please send me your dmesg if anything goes wrong or if you chip
> does set the sts flags in another way.
>
below is the result on the intel chip
> A short summary of the changes:
>
> - According to specification AUICH_RR may only be set after DMA
> is halted (AUICH_DCH is 0 in AUICH_STS). To accomplish this I
> revived auich_halt_pipe();
> - auich_calibrate() did not clear interrupt and event bits in
> AUICH_STS. Do that now. Further it did watch the CIV index
> counter to see when all samples are processed. I changed it to
> watch AUICH_STS instead and set LVI=CIV. therefore it won't
> change the CIV counter.
> - my last patch introduced a small bug in auich_trigger_pipe() I
> fixed that.
>
I think we should put the corresponding chunk in, sooner
than later.
BTW, I start wondering why this calibration exists at all?
do devices running at the wrong rate exist (which would mean
they don't have the proper clock). If so should we start
adding calibration code in all of our audio drivers?
-- Alexandre
OpenBSD 4.7-current (GENERIC) #1: Fri Apr 2 21:17:19 CEST 2010
a...@poc.localdomain:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) M processor 1.10GHz ("GenuineIntel" 686-class) 1.10
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2
real mem = 526807040 (502MB)
avail mem = 501723136 (478MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/28/05, BIOS32 rev. 0 @ 0xfd740, SMBIOS
rev. 2.33 @ 0xe0010 (56 entries)
bios0: vendor IBM version "1UETC8WW (2.03 )" date 09/28/2005
bios0: IBM 2371CJ9
apm0 at bios0: Power Management spec V1.2
apm0: battery life expectancy 100%
apm0: AC on, battery charge high
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xfd6d0/0x930
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdeb0/256 (14 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #3 is the last bus
bios0: ROM list: 0xc/0xc800! 0xcc800/0x1000 0xcd800/0x1000 0xdc000/0x4000!
0xe/0x1
cpu0 at mainbus0: (uniprocessor)
cpu0: Enhanced SpeedStep 1097 MHz: speeds: 1100, 1000, 900, 800, 600 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
io address conflict 0x5800/0x8
io address conflict 0x5808/0x4
io address conflict 0x5810/0x8
io address conflict 0x580c/0x4
mem address conflict 0x1f70/0x400
pchb0 at pci0 dev 0 function 0 "Intel 82855GM Host" rev 0x02
"Intel 82855GM Memory" rev 0x02 at pci0 dev 0 function 1 not configured
"Intel 82855GM Config" rev 0x02 at pci0 dev 0 function 3 not configured
vga1 at pci0 dev 2 function 0 "Intel 82855GM Video" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x800
inteldrm0 at vga1: irq 11
drm0 at inteldrm0
"Intel 82855GM Video" rev 0x02 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 11
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 11
ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x01: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb0 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x81
pci1 at ppb0 bus 2
mem address conflict 0xb000/0x1000
cbb0 at pci1 dev 0 function 0 "Ricoh 5C476 CardBus" rev 0x8d: irq 11
sdhc0 at pci1 dev 0 function 1 "Ricoh 5C822 SD/MMC" rev 0x13: irq 11
sdmmc0 at sdhc0
em0 at pc
testers needed for auich(4)
Hi,
here's a patch for auich(4). It fixes some issues with SIS 7012
and possibly others. But since it relies on correct behaviour of
the hardware at some places it needs some testing. Especially try
to run something like:
aucat -l; play test.wav
right after booting and before anything else is played or
recorded.
the typical output would be:
auich0: ac97 link rate calibration took 83337 us
sts=7 civ=0 auich0: after calibration and reset
sts=1 civ=0 auich0: measured ac97 link rate at 47997 Hz,
will use 48000 Hz auich_trigger_output(ed99000, eda7600, 11776,
0x80271e20, 0x8015dc00, 0x8015dd90)
sts=1 auich_trigger_pipe: qptr=0
auich_trigger_input(eda9000, edb7600, 11776, 0x80272010,
0x8015dc00, 0x8015ddb8) sts=1
auich_trigger_pipe: qptr=0 auich0: halt_input auich0: halt_output
Important is the value of sts. dch means "DMA halted" - one
should not set AUICH_RR before this bit is set.
In auich_calibrate() I wait for any of the three bits
to be set.
If something goes wrong here you will see:
auich0: ac97 link rate timed out %d us sts=%b civ=%d\n"
If something goes wrong in halt_pipe you will see:
auich_halt_pipe: halt took %d cycles
please send me your dmesg if anything goes wrong or if you chip
does set the sts flags in another way.
A short summary of the changes:
- According to specification AUICH_RR may only be set after DMA
is halted (AUICH_DCH is 0 in AUICH_STS). To accomplish this I
revived auich_halt_pipe();
- auich_calibrate() did not clear interrupt and event bits in
AUICH_STS. Do that now. Further it did watch the CIV index
counter to see when all samples are processed. I changed it to
watch AUICH_STS instead and set LVI=CIV. therefore it won't
change the CIV counter.
- my last patch introduced a small bug in auich_trigger_pipe() I
fixed that.
Cheers,
Christopher Zimmermann
Index: sys/dev/pci/auich.c
===
RCS file: /cvs/src/sys/dev/pci/auich.c,v
retrieving revision 1.81
diff -u -p -r1.81 auich.c
--- sys/dev/pci/auich.c 30 Mar 2010 09:38:07 - 1.81
+++ sys/dev/pci/auich.c 31 Mar 2010 12:30:28 -
@@ -26,7 +26,7 @@
* THE POSSIBILITY OF SUCH DAMAGE.
*/
-/* #define AUICH_DEBUG */
+#defineAUICH_DEBUG
/*
* AC'97 audio found on Intel 810/815/820/440MX chipsets.
* http://developer.intel.com/design/chipsets/datashts/290655.htm
@@ -75,7 +75,7 @@
#defineAUICH_BCIS 0x08/* r- buf cmplt int sts; wr ack
*/
#defineAUICH_LVBCI 0x04/* r- last valid bci, wr ack */
#defineAUICH_CELV 0x02/* current equals last valid */
-#defineAUICH_DCH 0x01/* dma halted */
+#defineAUICH_DCH 0x01/* dma halted */
#defineAUICH_ISTS_BITS
"\020\01dch\02celv\03lvbci\04bcis\05fifoe"
#defineAUICH_PICB 0x08/* 16 bits */
#defineAUICH_PIV 0x0a/* 5 bits prefetched index
value */
@@ -232,7 +232,8 @@ struct auich_softc {
#ifdef AUICH_DEBUG
#defineDPRINTF(l,x)do { if (auich_debug & (l)) printf x; } while(0)
-int auich_debug = 0xfffe;
+/*int auich_debug = 0xfffe;*/
+int auich_debug = 0x0002;
#defineAUICH_DEBUG_CODECIO 0x0001
#defineAUICH_DEBUG_DMA 0x0002
#defineAUICH_DEBUG_INTR0x0004
@@ -1174,14 +1175,22 @@ void
auich_halt_pipe(struct auich_softc *sc, int pipe)
{
int i;
- uint32_t status;
+ uint32_t sts;
bus_space_write_1(sc->iot, sc->aud_ioh, pipe + AUICH_CTRL, 0);
- for (i = 0; i < 100; i++) {
- status = bus_space_read_4(sc->iot, sc->aud_ioh, pipe +
AUICH_STS);
- if (status & AUICH_DCH)
- break;
- DELAY(1);
+
+ /* wait for DMA halted and clear interrupt / event bits if needed */
+ for (i = 0; i < 1000; i++) {
+ sts = bus_space_read_2(sc->iot, sc->aud_ioh, pipe + sc->sc_sts_reg);
+
+ if (sts & (AUICH_CELV | AUICH_LVBCI | AUICH_BCIS | AUICH_FIFOE))
+ bus_space_write_2(sc->iot, sc->aud_ioh, pipe + sc->sc_sts_reg,
+ AUICH_CELV | AUICH_LVBCI | AUICH_BCIS | AUICH_FIFOE);
+
+ if (sts & AUICH_DCH)
+ break;
+
+ DELAY(100);
}
bus_space_write_1(sc->iot, sc->aud_ioh, pipe + AUICH_CTRL, AUICH_RR);
@@ -1199,7 +1208,8 @@ auich_halt_output(v)
DPRINTF(AUICH_DEBUG_DMA, ("%s: halt_output\n", sc->sc_dev.dv_xname));
- bus_space_write_1(sc->iot, sc->aud_ioh, AUICH_PCMO + AUICH_CTRL,
AUICH_RR);
+ auich_halt_pipe(sc, AUICH_PCMO);
+
sc->pcmo.intr = NULL;
return 0;
@@ -1216,8 +1226,9 @@ auich_halt_input(v)
/* XXX halt both unless known otherwise */
- bus_space_write_1(sc->iot, sc->aud_ioh, AUICH_PCMI + AUICH_CTRL,
AUICH_RR);
- bus_space_write_1(sc->iot
