Found that i810_audio has been broken in kernel 2.4.20-pre4-ac1. It was Ok with
2.4.20-pre1-ac1 I used before.
With 2.4.20-pre4-ac1 I'm only getting garbled sound and kernel messages (see below).
Didn't have time yet to study mire detailed which change breaks driver.
In Alan's changelog I see:
2.4.20-pre2-ac5: Further i810_audio updates for 845 (Juergen Sawinski)
2.4.20-pre1-ac3: Tidy up error paths on i810_audio init (Alan)
2.4.20-pre1-ac2: First set of i810 audio updates (Doug Ledford)
Andris
------ at startup -----------------
Intel 810 + AC97 Audio, version 0.22, 11:18:00 Aug 26 2002
PCI: Found IRQ 5 for device 00:1f.5
PCI: Sharing IRQ 5 with 00:1f.3
PCI: Setting latency timer of device 00:1f.5 to 64
i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, MEM 0x0000 and 0x0000, IRQ 5
i810_audio: Audio Controller supports 2 channels.
i810_audio: Defaulting to base 2 channel mode.
i810_audio: resetting hw channel 0
ac97_codec: AC97 Audio codec, id: 0x4144:0x5348 (Analog Devices AD1881A)
i810_audio: AC'97 codec 0 Unable to map surround DAC's (or DAC's not present), to
------ error messages ------------
i810_audio: DMA overrun on write
i810_audio: CIV 0, LVI 27, hwptr 253a, count -13626
i810_audio: DMA overrun on write
i810_audio: CIV 0, LVI 27, hwptr 2662, count -296
i810_audio: DMA overrun on write
i810_audio: CIV 0, LVI 27, hwptr 2662, count -296
i810_audio: DMA overrun on write
i810_audio: CIV 0, LVI 27, hwptr 266a, count -8
i810_audio: DMA overrun on write
i810_audio: CIV 1, LVI 31, hwptr 2924, count -10526
i810_audio: DMA overrun on write
i810_audio: CIV 1, LVI 31, hwptr 2924, count -10526
i810_audio: DMA overrun on write
i810_audio: CIV 0, LVI 3, hwptr 253a, count -5434
i810_audio: DMA overrun on write
i810_audio: CIV 0, LVI 3, hwptr 2562, count -40
......
--------- error message from artsd (KDE-3.1 beta1) -------
Sound server fatal error:
AudioSubSystem::handleIO: write failed
len = 3228, can_write = 4096, errno = 17 (File exists)
This might be a sound hardware/driver specific problem (see aRts FAQ)
--------------------------------------------------------------------
Kernel was compiled with gcc-3.1 (like earlier kernels where i810_audio worked
Ok)
On Tue, Aug 27, 2002 at 12:53:12PM +0300, Andris Pavenis wrote:
> Found that i810_audio has been broken in kernel 2.4.20-pre4-ac1. It was Ok with
> 2.4.20-pre1-ac1 I used before.
>
> With 2.4.20-pre4-ac1 I'm only getting garbled sound and kernel messages (see below).
> Didn't have time yet to study mire detailed which change breaks driver.
The important part of my change is just two lines. There is the line that
prints out the message "Defaulting to base 2 channel mode." and the line
after it where we mask off a couple bits in the global control register.
Comment those two lines out and let me know if it makes a difference on
your machine.
> In Alan's changelog I see:
>
> 2.4.20-pre2-ac5: Further i810_audio updates for 845 (Juergen Sawinski)
> 2.4.20-pre1-ac3: Tidy up error paths on i810_audio init (Alan)
> 2.4.20-pre1-ac2: First set of i810 audio updates (Doug Ledford)
>
> Andris
>
> ------ at startup -----------------
> Intel 810 + AC97 Audio, version 0.22, 11:18:00 Aug 26 2002
> PCI: Found IRQ 5 for device 00:1f.5
> PCI: Sharing IRQ 5 with 00:1f.3
> PCI: Setting latency timer of device 00:1f.5 to 64
> i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, MEM 0x0000 and 0x0000, IRQ 5
> i810_audio: Audio Controller supports 2 channels.
> i810_audio: Defaulting to base 2 channel mode.
> i810_audio: resetting hw channel 0
> ac97_codec: AC97 Audio codec, id: 0x4144:0x5348 (Analog Devices AD1881A)
> i810_audio: AC'97 codec 0 Unable to map surround DAC's (or DAC's not present), to
> ------ error messages ------------
> i810_audio: DMA overrun on write
> i810_audio: CIV 0, LVI 27, hwptr 253a, count -13626
> i810_audio: DMA overrun on write
> i810_audio: CIV 0, LVI 27, hwptr 2662, count -296
> i810_audio: DMA overrun on write
> i810_audio: CIV 0, LVI 27, hwptr 2662, count -296
> i810_audio: DMA overrun on write
> i810_audio: CIV 0, LVI 27, hwptr 266a, count -8
> i810_audio: DMA overrun on write
> i810_audio: CIV 1, LVI 31, hwptr 2924, count -10526
> i810_audio: DMA overrun on write
> i810_audio: CIV 1, LVI 31, hwptr 2924, count -10526
> i810_audio: DMA overrun on write
> i810_audio: CIV 0, LVI 3, hwptr 253a, count -5434
> i810_audio: DMA overrun on write
> i810_audio: CIV 0, LVI 3, hwptr 2562, count -40
> ......
>
> --------- error message from artsd (KDE-3.1 beta1) -------
> Sound server fatal error:
> AudioSubSystem::handleIO: write failed
> len = 3228, can_write = 4096, errno = 17 (File exists)
> This might be a sound hardware/driver specific problem (see aRts FAQ)
>
> --------------------------------------------------------------------
> Kernel was compiled with gcc-3.1 (like earlier kernels where i810_audio worked
> Ok)
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
I can't see any reason, why my i845 updates should touch dma stuff...
The only changes I could think of causing troubles are
1. dma reset (line 790, 842): no check if dma reset is complete
2. dma reset: reset occurs before latent interrupt bits are cleared
3. channel support (lines 1951 ff): more bits are cleared then should
be? (look for 0xcfffff, shouldn't that read 0xffcfffff; compare
lines 2829 and 2487)
4. At least on ICH4, OFF_CIV is a read only location, but writes
occur quite frequently.
Don't know if that helps.
George
P.S.: The attached patch goes to Alan seperately. Give it a try. (You
can also remove the comment tags from line 795:
while( inb(card->iobase + PI_CR) & 0x02 ) ;
and line 849
while( inb(card->iobase + PO_CR) & 0x02 ) ;
They are not necessary on my box, but...
)
On Tue, 2002-08-27 at 20:46, Doug Ledford wrote:
> On Tue, Aug 27, 2002 at 12:53:12PM +0300, Andris Pavenis wrote:
> > Found that i810_audio has been broken in kernel 2.4.20-pre4-ac1. It was Ok with
> > 2.4.20-pre1-ac1 I used before.
> >
> > With 2.4.20-pre4-ac1 I'm only getting garbled sound and kernel messages (see below).
> > Didn't have time yet to study mire detailed which change breaks driver.
>
> The important part of my change is just two lines. There is the line that
> prints out the message "Defaulting to base 2 channel mode." and the line
> after it where we mask off a couple bits in the global control register.
> Comment those two lines out and let me know if it makes a difference on
> your machine.
>
> > In Alan's changelog I see:
> >
> > 2.4.20-pre2-ac5: Further i810_audio updates for 845 (Juergen Sawinski)
> > 2.4.20-pre1-ac3: Tidy up error paths on i810_audio init (Alan)
> > 2.4.20-pre1-ac2: First set of i810 audio updates (Doug Ledford)
> >
> > Andris
> >
> > ------ at startup -----------------
> > Intel 810 + AC97 Audio, version 0.22, 11:18:00 Aug 26 2002
> > PCI: Found IRQ 5 for device 00:1f.5
> > PCI: Sharing IRQ 5 with 00:1f.3
> > PCI: Setting latency timer of device 00:1f.5 to 64
> > i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, MEM 0x0000 and 0x0000, IRQ 5
> > i810_audio: Audio Controller supports 2 channels.
> > i810_audio: Defaulting to base 2 channel mode.
> > i810_audio: resetting hw channel 0
> > ac97_codec: AC97 Audio codec, id: 0x4144:0x5348 (Analog Devices AD1881A)
> > i810_audio: AC'97 codec 0 Unable to map surround DAC's (or DAC's not present), to
> > ------ error messages ------------
> > i810_audio: DMA overrun on write
> > i810_audio: CIV 0, LVI 27, hwptr 253a, count -13626
> > i810_audio: DMA overrun on write
> > i810_audio: CIV 0, LVI 27, hwptr 2662, count -296
> > i810_audio: DMA overrun on write
> > i810_audio: CIV 0, LVI 27, hwptr 2662, count -296
> > i810_audio: DMA overrun on write
> > i810_audio: CIV 0, LVI 27, hwptr 266a, count -8
> > i810_audio: DMA overrun on write
> > i810_audio: CIV 1, LVI 31, hwptr 2924, count -10526
> > i810_audio: DMA overrun on write
> > i810_audio: CIV 1, LVI 31, hwptr 2924, count -10526
> > i810_audio: DMA overrun on write
> > i810_audio: CIV 0, LVI 3, hwptr 253a, count -5434
> > i810_audio: DMA overrun on write
> > i810_audio: CIV 0, LVI 3, hwptr 2562, count -40
> > ......
> >
> > --------- error message from artsd (KDE-3.1 beta1) -------
> > Sound server fatal error:
> > AudioSubSystem::handleIO: write failed
> > len = 3228, can_write = 4096, errno = 17 (File exists)
> > This might be a sound hardware/driver specific problem (see aRts FAQ)
> >
> > --------------------------------------------------------------------
> > Kernel was compiled with gcc-3.1 (like earlier kernels where i810_audio worked
> > Ok)
>
> --
> Doug Ledford <[email protected]> 919-754-3700 x44233
> Red Hat, Inc.
> 1801 Varsity Dr.
> Raleigh, NC 27606
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Juergen "George" Sawinski
Max-Planck Institute for Medical Research
Dept. of Biomedical Optics
Jahnstr. 29
D-69120 Heidelberg
Germany
Phone: +49-6221-486-308
Fax: +49-6221-486-325
priv.
Phone: +49-6221-418 858
Mobile: +49-171-532 5302
I sent the wrong patch...
On Wed, 2002-08-28 at 02:21, Juergen Sawinski wrote:
> I can't see any reason, why my i845 updates should touch dma stuff...
>
> The only changes I could think of causing troubles are
> 1. dma reset (line 790, 842): no check if dma reset is complete
> 2. dma reset: reset occurs before latent interrupt bits are cleared
> 3. channel support (lines 1951 ff): more bits are cleared then should
> be? (look for 0xcfffff, shouldn't that read 0xffcfffff; compare
> lines 2829 and 2487)
> 4. At least on ICH4, OFF_CIV is a read only location, but writes
> occur quite frequently.
>
> Don't know if that helps.
>
> George
>
> P.S.: The attached patch goes to Alan seperately. Give it a try. (You
> can also remove the comment tags from line 795:
> while( inb(card->iobase + PI_CR) & 0x02 ) ;
> and line 849
> while( inb(card->iobase + PO_CR) & 0x02 ) ;
> They are not necessary on my box, but...
> )
>
> On Tue, 2002-08-27 at 20:46, Doug Ledford wrote:
> > On Tue, Aug 27, 2002 at 12:53:12PM +0300, Andris Pavenis wrote:
> > > Found that i810_audio has been broken in kernel 2.4.20-pre4-ac1. It was Ok with
> > > 2.4.20-pre1-ac1 I used before.
> > >
> > > With 2.4.20-pre4-ac1 I'm only getting garbled sound and kernel messages (see below).
> > > Didn't have time yet to study mire detailed which change breaks driver.
> >
> > The important part of my change is just two lines. There is the line that
> > prints out the message "Defaulting to base 2 channel mode." and the line
> > after it where we mask off a couple bits in the global control register.
> > Comment those two lines out and let me know if it makes a difference on
> > your machine.
> >
> > > In Alan's changelog I see:
> > >
> > > 2.4.20-pre2-ac5: Further i810_audio updates for 845 (Juergen Sawinski)
> > > 2.4.20-pre1-ac3: Tidy up error paths on i810_audio init (Alan)
> > > 2.4.20-pre1-ac2: First set of i810 audio updates (Doug Ledford)
> > >
> > > Andris
> > >
> > > ------ at startup -----------------
> > > Intel 810 + AC97 Audio, version 0.22, 11:18:00 Aug 26 2002
> > > PCI: Found IRQ 5 for device 00:1f.5
> > > PCI: Sharing IRQ 5 with 00:1f.3
> > > PCI: Setting latency timer of device 00:1f.5 to 64
> > > i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, MEM 0x0000 and 0x0000, IRQ 5
> > > i810_audio: Audio Controller supports 2 channels.
> > > i810_audio: Defaulting to base 2 channel mode.
> > > i810_audio: resetting hw channel 0
> > > ac97_codec: AC97 Audio codec, id: 0x4144:0x5348 (Analog Devices AD1881A)
> > > i810_audio: AC'97 codec 0 Unable to map surround DAC's (or DAC's not present), to
> > > ------ error messages ------------
> > > i810_audio: DMA overrun on write
> > > i810_audio: CIV 0, LVI 27, hwptr 253a, count -13626
> > > i810_audio: DMA overrun on write
> > > i810_audio: CIV 0, LVI 27, hwptr 2662, count -296
> > > i810_audio: DMA overrun on write
> > > i810_audio: CIV 0, LVI 27, hwptr 2662, count -296
> > > i810_audio: DMA overrun on write
> > > i810_audio: CIV 0, LVI 27, hwptr 266a, count -8
> > > i810_audio: DMA overrun on write
> > > i810_audio: CIV 1, LVI 31, hwptr 2924, count -10526
> > > i810_audio: DMA overrun on write
> > > i810_audio: CIV 1, LVI 31, hwptr 2924, count -10526
> > > i810_audio: DMA overrun on write
> > > i810_audio: CIV 0, LVI 3, hwptr 253a, count -5434
> > > i810_audio: DMA overrun on write
> > > i810_audio: CIV 0, LVI 3, hwptr 2562, count -40
> > > ......
> > >
> > > --------- error message from artsd (KDE-3.1 beta1) -------
> > > Sound server fatal error:
> > > AudioSubSystem::handleIO: write failed
> > > len = 3228, can_write = 4096, errno = 17 (File exists)
> > > This might be a sound hardware/driver specific problem (see aRts FAQ)
> > >
> > > --------------------------------------------------------------------
> > > Kernel was compiled with gcc-3.1 (like earlier kernels where i810_audio worked
> > > Ok)
> >
> > --
> > Doug Ledford <[email protected]> 919-754-3700 x44233
> > Red Hat, Inc.
> > 1801 Varsity Dr.
> > Raleigh, NC 27606
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> --
> Juergen "George" Sawinski
> Max-Planck Institute for Medical Research
> Dept. of Biomedical Optics
> Jahnstr. 29
> D-69120 Heidelberg
> Germany
>
> Phone: +49-6221-486-308
> Fax: +49-6221-486-325
>
> priv.
> Phone: +49-6221-418 858
> Mobile: +49-171-532 5302
>
> ----
>
> --- linux-2.4.20-pre4-ac2/drivers/sound/i810_audio.c Tue Aug 27 21:44:25 2002
> +++ jsaw/drivers/sound/i810_audio.c Wed Aug 28 01:26:28 2002
> @@ -69,12 +69,12 @@
> *
> * ICH 4 caveats
> *
> - * The ICH4 has the feature, that the codec ID may not be congruent
> - * with the AC-link channel.
> + * The ICH4 has the feature, that the codec ID doesn't have to be
> + * congruent with the IO connection.
> *
> - * Right now, the codec ID is not the real codec ID but the AC-link
> - * channel. A ID <-> AC-link mapping has still to be implemented.
> - *
> + * Therefore, from driver version 0.23 on, there is a "codec ID" <->
> + * "IO register base offset" mapping (card->ac97_id_map) field.
> + *
> * Juergen "George" Sawinski (jsaw)
> */
>
> @@ -207,7 +207,7 @@
> CAS = 0x34 /* Codec Write Semaphore Register */
> };
>
> -ENUM_ENGINE(MC2,4); /* Mic. 2 */
> +ENUM_ENGINE(MC2,4); /* Mic In 2 */
> ENUM_ENGINE(PI2,5); /* PCM In 2 */
> ENUM_ENGINE(SP,6); /* S/PDIF */
>
> @@ -234,8 +234,7 @@
> #define INT_GPI (1<<0)
> #define INT_MASK (INT_SEC|INT_PRI|INT_MC|INT_PO|INT_PI|INT_MO|INT_NI|INT_GPI)
>
> -
> -#define DRIVER_VERSION "0.22"
> +#define DRIVER_VERSION "0.23"
>
> /* magic numbers to protect our data structures */
> #define I810_CARD_MAGIC 0x5072696E /* "Prin" */
> @@ -295,7 +294,7 @@
> /*@FIXME to be verified*/ { 2, 0x0000 }, /* SI7012 */
> /*@FIXME to be verified*/ { 2, 0x0000 }, /* NVIDIA_NFORCE */
> /*@FIXME to be verified*/ { 2, 0x0000 }, /* AMD768 */
> - /*@FIXME to be verified*/ { 2, 0x0000 }, /* AMD8111 */
> + /*@FIXME to be verified*/ { 3, 0x0001 }, /* AMD8111 */
> };
>
> static struct pci_device_id i810_pci_tbl [] __initdata = {
> @@ -417,6 +416,7 @@
> int dev_audio;
>
> /* structures for abstraction of hardware facilities, codecs, banks and channels*/
> + u16 ac97_id_map[NR_AC97];
> struct ac97_codec *ac97_codec[NR_AC97];
> struct i810_state *states[NR_HW_CH];
> struct i810_channel *channel; /* 1:1 to states[] but diff. lifetime */
> @@ -449,6 +449,9 @@
> int initializing;
> };
>
> +/* extract register offset from codec struct */
> +#define IO_REG_OFF(codec) (((struct i810_card *) codec->private_data)->ac97_id_map[codec->id])
> +
> static struct i810_card *devs = NULL;
>
> static int i810_open_mixdev(struct inode *inode, struct file *file);
> @@ -1948,13 +1955,13 @@
>
> switch ( val ) {
> case 2: /* 2 channels is always supported */
> - outl(i_glob_cnt & 0xcfffff,
> + outl(i_glob_cnt & 0xffcfffff,
> state->card->iobase + GLOB_CNT);
> /* Do we need to change mixer settings???? */
> break;
> case 4: /* Supported on some chipsets, better check first */
> if ( state->card->channels >= 4 ) {
> - outl((i_glob_cnt & 0xcfffff) | 0x100000,
> + outl((i_glob_cnt & 0xffcfffff) | 0x100000,
> state->card->iobase + GLOB_CNT);
> /* Do we need to change mixer settings??? */
> } else {
> @@ -1963,7 +1970,7 @@
> break;
> case 6: /* Supported on some chipsets, better check first */
> if ( state->card->channels >= 6 ) {
> - outl((i_glob_cnt & 0xcfffff) | 0x200000,
> + outl((i_glob_cnt & 0xffcfffff) | 0x200000,
> state->card->iobase + GLOB_CNT);
> /* Do we need to change mixer settings??? */
> } else {
> @@ -2553,8 +2560,7 @@
> {
> struct i810_card *card = dev->private_data;
> int count = 100;
> - u16 reg_set = ((u16) reg) & 0x7f;
> - reg_set |= ((u16) dev->id) << 7;
> + u16 reg_set = IO_REG_OFF(dev) | (reg&0x7f);
>
> while(count-- && (readb(card->iobase_mmio + CAS) & 1))
> udelay(1);
> @@ -2574,7 +2580,7 @@
> {
> struct i810_card *card = dev->private_data;
> int count = 100;
> - u8 reg_set = ((dev->id)?((reg&0x7f)|0x80):(reg&0x7f));
> + u16 reg_set = IO_REG_OFF(dev) | (reg&0x7f);
>
> while(count-- && (inb(card->iobase + CAS) & 1))
> udelay(1);
> @@ -2586,8 +2592,7 @@
> {
> struct i810_card *card = dev->private_data;
> int count = 100;
> - u16 reg_set = ((u16) reg) & 0x7f;
> - reg_set |= ((u16) dev->id) << 7;
> + u16 reg_set = IO_REG_OFF(dev) | (reg&0x7f);
>
> while(count-- && (readb(card->iobase_mmio + CAS) & 1))
> udelay(1);
> @@ -2603,7 +2608,7 @@
> {
> struct i810_card *card = dev->private_data;
> int count = 100;
> - u8 reg_set = ((dev->id)?((reg&0x7f)|0x80):(reg&0x7f));
> + u16 reg_set = IO_REG_OFF(dev) | (reg&0x7f);
>
> while(count-- && (inb(card->iobase + CAS) & 1))
> udelay(1);
> @@ -2779,7 +2784,7 @@
> if ((card->pci_id == PCI_DEVICE_ID_INTEL_ICH4)
> && (card->use_mmio)) {
> primary_codec_id = (int) readl(card->iobase_mmio + SDM) & 0x3;
> - printk(KERN_INFO "i810_audio: primary codec id %d\n",
> + printk(KERN_INFO "i810_audio: Primary codec has ID %d\n",
> primary_codec_id);
> }
>
> @@ -2803,6 +2808,7 @@
> int num_ac97 = 0;
> int ac97_id;
> int total_channels = 0;
> + int nr_ac97_max = card_cap[card->pci_id_internal].nr_ac97;
> struct ac97_codec *codec;
> u16 eid;
> u32 reg;
> @@ -2828,13 +2834,15 @@
> reg = inl(card->iobase + GLOB_CNT);
> outl(reg & 0xffcfffff, card->iobase + GLOB_CNT);
>
> - for (num_ac97 = 0; num_ac97 < card_cap[card->pci_id_internal].nr_ac97; num_ac97++) {
> + for (num_ac97 = 0; num_ac97 < NR_AC97; num_ac97++)
> card->ac97_codec[num_ac97] = NULL;
> - }
>
> - for (num_ac97 = 0; num_ac97 < card_cap[card->pci_id_internal].nr_ac97; num_ac97++) {
> + /*@FIXME I don't know, if I'm playing to safe here... (jsaw) */
> + if ((nr_ac97_max > 2) && !card->use_mmio) nr_ac97_max = 2;
> +
> + for (num_ac97 = 0; num_ac97 < nr_ac97_max; num_ac97++) {
> /* codec reset */
> - printk(KERN_INFO "i810_audio: resetting hw channel %d\n", num_ac97);
> + printk(KERN_INFO "i810_audio: Resetting connection %d\n", num_ac97);
> if (card->use_mmio) readw(card->ac97base_mmio + 0x80*num_ac97);
> else inw(card->ac97base + 0x80*num_ac97);
>
> @@ -2846,7 +2854,7 @@
> if ((card->pci_id == PCI_DEVICE_ID_INTEL_ICH4)
> && (card->use_mmio)) {
> ac97_id = (int) readl(card->iobase_mmio + SDM) & 0x3;
> - printk(KERN_INFO "i810_audio: hw channel %d, codec id %d\n",
> + printk(KERN_INFO "i810_audio: Connection %d with codec id %d\n",
> num_ac97, ac97_id);
> }
> else {
> @@ -2869,9 +2877,8 @@
> /* initialize some basic codec information, other fields will be filled
> in ac97_probe_codec */
> codec->private_data = card;
> -
> - /*@FIXME this will lead to problems!!! id=2 <-> io offset=0*/
> - codec->id = num_ac97;
> + codec->id = ac97_id;
> + card->ac97_id_map[ac97_id] = num_ac97 * 0x80;
>
> if (card->use_mmio) {
> codec->codec_read = i810_ac97_get_mmio;
> @@ -2883,7 +2890,7 @@
> }
>
> if(!i810_ac97_probe_and_powerup(card,codec)) {
> - printk(KERN_ERR "i810_audio: timed out waiting for codec %d analog ready.\n", num_ac97);
> + printk(KERN_ERR "i810_audio: timed out waiting for codec %d analog ready.\n", ac97_id);
> kfree(codec);
> break; /* it didn't work */
> }
> @@ -2903,7 +2910,7 @@
> codec->codec_write(codec, AC97_EXTENDED_MODEM_ID, 0L);
> if(codec->codec_read(codec, AC97_EXTENDED_MODEM_ID))
> {
> - printk(KERN_WARNING "i810_audio: codec %d is a softmodem - skipping.\n", num_ac97);
> + printk(KERN_WARNING "i810_audio: codec %d is a softmodem - skipping.\n", ac97_id);
> kfree(codec);
> continue;
> }
--
Juergen "George" Sawinski
Max-Planck Institute for Medical Research
Dept. of Biomedical Optics
Jahnstr. 29
D-69120 Heidelberg
Germany
Phone: +49-6221-486-308
Fax: +49-6221-486-325
priv.
Phone: +49-6221-418 858
Mobile: +49-171-532 5302
On Tuesday 27 August 2002 21:46, Doug Ledford wrote:
> On Tue, Aug 27, 2002 at 12:53:12PM +0300, Andris Pavenis wrote:
> > Found that i810_audio has been broken in kernel 2.4.20-pre4-ac1. It was
> > Ok with 2.4.20-pre1-ac1 I used before.
> >
> > With 2.4.20-pre4-ac1 I'm only getting garbled sound and kernel messages
> > (see below). Didn't have time yet to study mire detailed which change
> > breaks driver.
>
> The important part of my change is just two lines. There is the line that
> prints out the message "Defaulting to base 2 channel mode." and the line
> after it where we mask off a couple bits in the global control register.
> Comment those two lines out and let me know if it makes a difference on
> your machine.
>
> > In Alan's changelog I see:
> >
> > 2.4.20-pre2-ac5: Further i810_audio updates for 845 (Juergen Sawinski)
> > 2.4.20-pre1-ac3: Tidy up error paths on i810_audio init (Alan)
> > 2.4.20-pre1-ac2: First set of i810 audio updates (Doug Ledford)
Verified that sound is already broken with 2.4.20-pre1-ac2, but works with
i810_audio.c from 2.4.19-pre1-ac1. Commenting 2 above mentioned lines out
doesn't help
Andris
Can you drop in the old (working) source into the new tree and see if
that works? If that works I'll try making a step by step patch series,
to see what breaks it.
George
On Wed, 2002-08-28 at 09:04, Andris Pavenis wrote:
> Verified that sound is already broken with 2.4.20-pre1-ac2, but works with
> i810_audio.c from 2.4.19-pre1-ac1. Commenting 2 above mentioned lines out
> doesn't help
>
> Andris
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Juergen "George" Sawinski
Max-Planck-Institute for Medical Research
Dept. of Biomedical Optics
Jahnstr. 29
D-69120 Heidelberg
Germany
Phone: +49-6221-486-309
Fax: +49-6221-486-325
priv.
Phone: +49-6221-418 848
Mobile: +49-171-532 5302
On Wednesday 28 August 2002 15:51, Juergen Sawinski wrote:
> Can you drop in the old (working) source into the new tree and see if
> that works? If that works I'll try making a step by step patch series,
> to see what breaks it.
Today's tests were done in that way (I only replaced i810_audio.c,
removed i810_audio.o, run 'make modules' and 'make modules_install' and tested
the results). As I wrote earlier it seems that Dough's patch (to
2.4.20-pre1-ac2) broke driver
Andris
> On Wed, 2002-08-28 at 09:04, Andris Pavenis wrote:
> > Verified that sound is already broken with 2.4.20-pre1-ac2, but works
> > with i810_audio.c from 2.4.19-pre1-ac1. Commenting 2 above mentioned
> > lines out doesn't help
On Wed, Aug 28, 2002 at 04:22:30PM +0300, Andris Pavenis wrote:
> On Wednesday 28 August 2002 15:51, Juergen Sawinski wrote:
> > Can you drop in the old (working) source into the new tree and see if
> > that works? If that works I'll try making a step by step patch series,
> > to see what breaks it.
>
> Today's tests were done in that way (I only replaced i810_audio.c,
> removed i810_audio.o, run 'make modules' and 'make modules_install' and tested
> the results). As I wrote earlier it seems that Dough's patch (to
> 2.4.20-pre1-ac2) broke driver
(In an email Juergen sent to me privately he mentioned that on the ICH4
the CIV register is now read-only where as on previous ICH chips it was
read-write, which is something I missed as far as changes to the chip are
concerned)
Now, given the tidbit of information above, I would expect ICH4 chipsets
to break with the driver. We currently rely upon the ability to set the
CIV register to what we want in order to start the DMA where we want. If
that's now readonly, I'll have to rethink how I reset the DMA hardware and
how I will have to start recording the new DMA position instead of setting
the new DMA position. The one thing about this though, I would expect
this issue to cause previously non-working ICH4 chips to work poorly with
my patch instead of previously working ICH4 chips to now start working
poorly since my patch didn't change the (/me stops mid-sentence and
realizes that "yes, in fact there is a change in my patch to base DMA
operations that could cause this"). Hmmm...backup....try backing out my
changes to stop_dac and stop_adc (the part where I change how we do a DMA
engine reset every time we stop the dac and adc) and see if that solves
your problem. The changes to __stop_dac() and __stop_adc() are localized
actually and you should be able to safely leave all of those hunks out
without effecting the rest of the patch.
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
I'll check the CIV read-only thing with ICH4 tonight (maybe I've
overseen some doc errata or the manual is just lying). On the other
hand, the CIV register is set to zero on reset (AFAICS), maybe a DMA
engine reset sets CIV to 0 implicitly on ICH4.
But if CIV is really RO, I could add a CAP_CIV_RO define to the card_cap
struct. Then I'd only have to set LVI appropialty to CIV... hmmm....
*sigh*
BTW, sound is working perfectly on my machine (ICH4).
George
On Wed, 2002-08-28 at 17:21, Doug Ledford wrote:
> On Wed, Aug 28, 2002 at 04:22:30PM +0300, Andris Pavenis wrote:
> > On Wednesday 28 August 2002 15:51, Juergen Sawinski wrote:
> > > Can you drop in the old (working) source into the new tree and see if
> > > that works? If that works I'll try making a step by step patch series,
> > > to see what breaks it.
> >
> > Today's tests were done in that way (I only replaced i810_audio.c,
> > removed i810_audio.o, run 'make modules' and 'make modules_install' and tested
> > the results). As I wrote earlier it seems that Dough's patch (to
> > 2.4.20-pre1-ac2) broke driver
>
> (In an email Juergen sent to me privately he mentioned that on the ICH4
> the CIV register is now read-only where as on previous ICH chips it was
> read-write, which is something I missed as far as changes to the chip are
> concerned)
>
> Now, given the tidbit of information above, I would expect ICH4 chipsets
> to break with the driver. We currently rely upon the ability to set the
> CIV register to what we want in order to start the DMA where we want. If
> that's now readonly, I'll have to rethink how I reset the DMA hardware and
> how I will have to start recording the new DMA position instead of setting
> the new DMA position. The one thing about this though, I would expect
> this issue to cause previously non-working ICH4 chips to work poorly with
> my patch instead of previously working ICH4 chips to now start working
> poorly since my patch didn't change the (/me stops mid-sentence and
> realizes that "yes, in fact there is a change in my patch to base DMA
> operations that could cause this"). Hmmm...backup....try backing out my
> changes to stop_dac and stop_adc (the part where I change how we do a DMA
> engine reset every time we stop the dac and adc) and see if that solves
> your problem. The changes to __stop_dac() and __stop_adc() are localized
> actually and you should be able to safely leave all of those hunks out
> without effecting the rest of the patch.
>
> --
> Doug Ledford <[email protected]> 919-754-3700 x44233
> Red Hat, Inc.
> 1801 Varsity Dr.
> Raleigh, NC 27606
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Juergen "George" Sawinski
Max-Planck Institute for Medical Research
Dept. of Biomedical Optics
Jahnstr. 29
D-69120 Heidelberg
Germany
Phone: +49-6221-486-308
Fax: +49-6221-486-325
priv.
Phone: +49-6221-418 858
Mobile: +49-171-532 5302
On Wed, Aug 28, 2002 at 06:59:38PM +0300, Andris Pavenis wrote:
>
> Tried, it helps for i810_audio.c both from 2.4.20-pre1-ac2 and
> 2.4.20-pre4-ac1. (Patch simply to be sure we're talking about the
> same thing). In both cases I put i810_audio.c in 2.4.20-pre4-ac1 source
> tree.
[ Alan, you should be perking your ears up about now I think... ]
OK, let's be more precise on this ;-) If you put this patch into the
2.4.20-pre4-ac1 kernel, does it actually solve the DMA overrun problem
(as in they don't happen anymore) or does it only reduce the frequency
of the problem but it does still exist? Same question for the drain_dac()
DMA timeout messages?
>
> Andris
>
> --- i810_audio.c-2.4.20-pre1-ac2 2002-08-28 09:50:44.000000000 +0300
> +++ i810_audio.c 2002-08-28 18:51:34.000000000 +0300
> @@ -732,8 +732,6 @@
> outb(0, card->iobase + PI_CR);
> // wait for the card to acknowledge shutdown
> while( inb(card->iobase + PI_CR) != 0 ) ;
> - // reset the dma engine now
> - outb(0x02, card->iobase + PI_CR);
> // now clear any latent interrupt bits (like the halt bit)
> if(card->pci_id == PCI_DEVICE_ID_SI_7012)
> outb( inb(card->iobase + PI_PICB), card->iobase + PI_PICB );
> @@ -784,8 +782,6 @@
> outb(0, card->iobase + PO_CR);
> // wait for the card to acknowledge shutdown
> while( inb(card->iobase + PO_CR) != 0 ) ;
> - // reset the dma engine now
> - outb(0x02, card->iobase + PO_CR);
> // now clear any latent interrupt bits (like the halt bit)
> if(card->pci_id == PCI_DEVICE_ID_SI_7012)
> outb( inb(card->iobase + PO_PICB), card->iobase + PO_PICB );
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
On Wed, Aug 28, 2002 at 05:47:38PM +0200, Juergen Sawinski wrote:
> I'll check the CIV read-only thing with ICH4 tonight (maybe I've
> overseen some doc errata or the manual is just lying). On the other
> hand, the CIV register is set to zero on reset (AFAICS), maybe a DMA
> engine reset sets CIV to 0 implicitly on ICH4.
It'e entirely possible that a DMA engine reset could reasonably set CIV to
any of 0 (CIV = 0, offset 0), beginning of next SG segment (CIV + 1,
offset = 0), beginning of current SG segment (CIV unchanged, offset = 0).
I wasn't bothering to try and figure it out on each chip that we support,
instead I was just calling a reset to make the hardware stop everything
and get back to a sane state, then I would set the actual value to where
ever we wanted it to be. In most cases, that was either CIV + 1, offset =
0 or CIV = 0, offset = 0. However, that was really only a convenience,
not a requirement.
> But if CIV is really RO, I could add a CAP_CIV_RO define to the card_cap
> struct. Then I'd only have to set LVI appropialty to CIV... hmmm....
> *sigh*
No, I wouldn't do this. If there are some chips now that have a read only
CIV, then no big deal. We change the DMA engine to treat all chips as
having a read only CIV and then we don't bother needing to know which ones
have which capability and we only need one DMA engine to drive all chips,
problem solved.
> BTW, sound is working perfectly on my machine (ICH4).
Well, that could just be luck ;-) The particular sound problem that
Andris is seeing is related to DMA start and stop operations. If you
happen to be using an artsd or esd daemon that is configured to DMA
silence when there isn't anything else going on, then DMA on your machine
would *not* be starting and stopping and you wouldn't see this problem.
That's why my standard battery of tests includes using play from the
command line without X running at all since it actually starts and stops
the DMA with each operation and does lots of drain_dac() calls.
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
On Wednesday 28 August 2002 18:21, Doug Ledford wrote:
> On Wed, Aug 28, 2002 at 04:22:30PM +0300, Andris Pavenis wrote:
> > On Wednesday 28 August 2002 15:51, Juergen Sawinski wrote:
> > > Can you drop in the old (working) source into the new tree and see if
> > > that works? If that works I'll try making a step by step patch series,
> > > to see what breaks it.
> >
> > Today's tests were done in that way (I only replaced i810_audio.c,
> > removed i810_audio.o, run 'make modules' and 'make modules_install' and
> > tested the results). As I wrote earlier it seems that Dough's patch (to
> > 2.4.20-pre1-ac2) broke driver
>
> (In an email Juergen sent to me privately he mentioned that on the ICH4
> the CIV register is now read-only where as on previous ICH chips it was
> read-write, which is something I missed as far as changes to the chip are
> concerned)
>
> Now, given the tidbit of information above, I would expect ICH4 chipsets
> to break with the driver. We currently rely upon the ability to set the
> CIV register to what we want in order to start the DMA where we want. If
> that's now readonly, I'll have to rethink how I reset the DMA hardware and
> how I will have to start recording the new DMA position instead of setting
> the new DMA position. The one thing about this though, I would expect
> this issue to cause previously non-working ICH4 chips to work poorly with
> my patch instead of previously working ICH4 chips to now start working
> poorly since my patch didn't change the (/me stops mid-sentence and
> realizes that "yes, in fact there is a change in my patch to base DMA
> operations that could cause this"). Hmmm...backup....try backing out my
> changes to stop_dac and stop_adc (the part where I change how we do a DMA
> engine reset every time we stop the dac and adc) and see if that solves
> your problem. The changes to __stop_dac() and __stop_adc() are localized
> actually and you should be able to safely leave all of those hunks out
> without effecting the rest of the patch.
Tried, it helps for i810_audio.c both from 2.4.20-pre1-ac2 and
2.4.20-pre4-ac1. (Patch simply to be sure we're talking about the
same thing). In both cases I put i810_audio.c in 2.4.20-pre4-ac1 source
tree.
Andris
--- i810_audio.c-2.4.20-pre1-ac2 2002-08-28 09:50:44.000000000 +0300
+++ i810_audio.c 2002-08-28 18:51:34.000000000 +0300
@@ -732,8 +732,6 @@
outb(0, card->iobase + PI_CR);
// wait for the card to acknowledge shutdown
while( inb(card->iobase + PI_CR) != 0 ) ;
- // reset the dma engine now
- outb(0x02, card->iobase + PI_CR);
// now clear any latent interrupt bits (like the halt bit)
if(card->pci_id == PCI_DEVICE_ID_SI_7012)
outb( inb(card->iobase + PI_PICB), card->iobase + PI_PICB );
@@ -784,8 +782,6 @@
outb(0, card->iobase + PO_CR);
// wait for the card to acknowledge shutdown
while( inb(card->iobase + PO_CR) != 0 ) ;
- // reset the dma engine now
- outb(0x02, card->iobase + PO_CR);
// now clear any latent interrupt bits (like the halt bit)
if(card->pci_id == PCI_DEVICE_ID_SI_7012)
outb( inb(card->iobase + PO_PICB), card->iobase + PO_PICB );