Subject: Re: ICH5 mixer issue, kern/20368 and kern/22548
To: TAMURA Kent <kent@netbsd.org>
From: None <lars@cubeportal.de>
List: tech-kern
Date: 09/08/2003 17:33:28
--=_21c39a20d8f1cc964c23ee7e8ccfe201
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
I've got a board with an 1985 (that is patches similar in Linux) with
separted headphone/lineout and surround ports.
I going to try different settings to hopefully enlighten the situation
a bit.
Lars
By the way it would by nice if kern/22120 could by fixed...
all new ids added in the last few month were added as case where the
sc->sc_flags |= FXPF_HAS_RESUME_BUG flag is set.
This kills some interfaces badly
This patch should only be applied to interfaces that need this feature
disabled
the switch case in fxp_pci_attach should read as
(the 82562EZ has a different eeprom layout and disabling the standby
mode shots the pci id)
switch (fpp->fpp_prodid) {
case PCI_PRODUCT_INTEL_82557:
case PCI_PRODUCT_INTEL_82559ER:
case PCI_PRODUCT_INTEL_IN_BUSINESS:
{
const char *chipname = NULL;
if (sc->sc_rev >= FXP_REV_82558_A4) {
chipname = "i82558 Ethernet";
/*
* Enable the MWI command for memory writes.
*/
if (pa->pa_flags & PCI_FLAGS_MWI_OKAY)
sc->sc_flags |= FXPF_MWI;
}
if (sc->sc_rev >= FXP_REV_82559_A0)
chipname = "i82559 Ethernet";
if (sc->sc_rev >= FXP_REV_82559S_A)
chipname = "i82559S Ethernet";
if (sc->sc_rev >= FXP_REV_82550)
chipname = "i82550 Ethernet";
/*
* Mark all i82559 and i82550 revisions as having
* the "resume bug". See i82557.c for details.
*/
if (sc->sc_rev >= FXP_REV_82559_A0)
sc->sc_flags |= FXPF_HAS_RESUME_BUG;
aprint_normal(": %s, rev %d\n", chipname != NULL ?
chipname :
fpp->fpp_name, sc->sc_rev);
break;
}
case PCI_PRODUCT_INTEL_82801BA_LAN:
aprint_normal(": %s, rev %d\n", fpp->fpp_name,
sc->sc_rev);
/*
* The 82801BA Ethernet has a bug which requires us to
send a
* NOP before a CU_RESUME if we're in 10baseT mode.
*/
if (fpp->fpp_prodid == PCI_PRODUCT_INTEL_82801BA_LAN)
sc->sc_flags |= FXPF_HAS_RESUME_BUG;
break;
case PCI_PRODUCT_INTEL_PRO_100_VE_0:
case PCI_PRODUCT_INTEL_PRO_100_VE_1:
case PCI_PRODUCT_INTEL_PRO_100_VM_0:
case PCI_PRODUCT_INTEL_PRO_100_VM_1:
aprint_normal(": %s, rev %d\n", fpp->fpp_name,
sc->sc_rev);
/*
* ICH3 chips apparently have problems with the enhanced
* features, so just treat them as an i82557. It also
* has the resume bug that the ICH2 has.
*/
sc->sc_rev = 1;
sc->sc_flags |= FXPF_HAS_RESUME_BUG;
break;
case PCI_PRODUCT_INTEL_82562EH_HPNA_0:
case PCI_PRODUCT_INTEL_82562EH_HPNA_1:
case PCI_PRODUCT_INTEL_82562EH_HPNA_2:
case PCI_PRODUCT_INTEL_PRO_100_VM_2:
case PCI_PRODUCT_INTEL_PRO_100_VM_3:
case PCI_PRODUCT_INTEL_PRO_100_VM_4:
case PCI_PRODUCT_INTEL_PRO_100_VM_5:
case PCI_PRODUCT_INTEL_PRO_100_VM_6:
aprint_normal(": %s, rev %d\n", fpp->fpp_name,
sc->sc_rev);
sc->sc_rev = 1;
break;
case PCI_PRODUCT_INTEL_82801E_LAN_1:
case PCI_PRODUCT_INTEL_82801E_LAN_2:
aprint_normal(": %s, rev %d\n", fpp->fpp_name,
sc->sc_rev);
/*
* XXX We have to read the C-ICH's developer's manual
* in detail
*/
break;
}
On Monday, Sep 8, 2003, at 17:09 Europe/Berlin, TAMURA Kent wrote:
>
> In message "ICH5 mixer issue, kern/20368 and kern/22548"
>> First of all, kern/20368 is wrong, although the fix does the right
>> thing
>> in the end. The main reason for that is that the codec listing is
>> erroneous: ADS 0x70 is ad1980, not ad1981. Thus the register names are
>> different. In the meantime, that codec should be probed as:
>
> Ok, I have fixed this.
>
>> The effect of kern/20368 is to have the headphone controlled by the
>> surround register, and the line-out controlled by the main mixer, thus
>> inverting the use of the two registers, creating the behaviour
>> described
>> in kern/22548.
>
> I have questions to understand the behavior of AD1980. When you
> play stereo audio data, do you have the audio output via the
> line-out with kern/20368, and via the headphone without
> kern/20368? How does outputs.headphones work, and how about
> setting AD1980_MISC_SPRD?
>
> --
> TAMURA Kent <kent2003@hauN.org> <kent@netbsd.org>
>
--=_21c39a20d8f1cc964c23ee7e8ccfe201
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
charset=US-ASCII
I've got a board with an 1985 (that is patches similar in Linux) with
separted headphone/lineout and surround ports.
I going to try different settings to hopefully enlighten the situation
a bit.
Lars
By the way it would by <color><param>0000,0000,0000</param>nice if
kern/22120 could by fixed...
</color>all new ids added in the last few month were added as case
where the
sc->sc_flags |= FXPF_HAS_RESUME_BUG flag is set.
This kills some interfaces badly
This patch should only be applied to interfaces that need this feature
disabled
the switch case in fxp_pci_attach should read as
(the 82562EZ has a different eeprom layout and disabling the standby
mode shots the pci id)
switch (fpp->fpp_prodid) {
case PCI_PRODUCT_INTEL_82557:
case PCI_PRODUCT_INTEL_82559ER:
case PCI_PRODUCT_INTEL_IN_BUSINESS:
{
const char *chipname = NULL;
if (sc->sc_rev >= FXP_REV_82558_A4) {
chipname = "i82558 Ethernet";
/*
* Enable the MWI command for memory writes.
*/
if (pa->pa_flags & PCI_FLAGS_MWI_OKAY)
sc->sc_flags |= FXPF_MWI;
}
if (sc->sc_rev >= FXP_REV_82559_A0)
chipname = "i82559 Ethernet";
if (sc->sc_rev >= FXP_REV_82559S_A)
chipname = "i82559S Ethernet";
if (sc->sc_rev >= FXP_REV_82550)
chipname = "i82550 Ethernet";
/*
* Mark all i82559 and i82550 revisions as having
* the "resume bug". See i82557.c for details.
*/
if (sc->sc_rev >= FXP_REV_82559_A0)
sc->sc_flags |= FXPF_HAS_RESUME_BUG;
aprint_normal(": %s, rev %d\n", chipname != NULL ?
chipname :
fpp->fpp_name, sc->sc_rev);
break;
}
case PCI_PRODUCT_INTEL_82801BA_LAN:
aprint_normal(": %s, rev %d\n", fpp->fpp_name,
sc->sc_rev);
/*
* The 82801BA Ethernet has a bug which requires us to
send a
* NOP before a CU_RESUME if we're in 10baseT mode.
*/
if (fpp->fpp_prodid == PCI_PRODUCT_INTEL_82801BA_LAN)
sc->sc_flags |= FXPF_HAS_RESUME_BUG;
break;
case PCI_PRODUCT_INTEL_PRO_100_VE_0:
case PCI_PRODUCT_INTEL_PRO_100_VE_1:
case PCI_PRODUCT_INTEL_PRO_100_VM_0:
case PCI_PRODUCT_INTEL_PRO_100_VM_1:
aprint_normal(": %s, rev %d\n", fpp->fpp_name,
sc->sc_rev);
/*
* ICH3 chips apparently have problems with the
enhanced
* features, so just treat them as an i82557. It also
* has the resume bug that the ICH2 has.
*/
sc->sc_rev = 1;
sc->sc_flags |= FXPF_HAS_RESUME_BUG;
break;
case PCI_PRODUCT_INTEL_82562EH_HPNA_0:
case PCI_PRODUCT_INTEL_82562EH_HPNA_1:
case PCI_PRODUCT_INTEL_82562EH_HPNA_2:
case PCI_PRODUCT_INTEL_PRO_100_VM_2:
case PCI_PRODUCT_INTEL_PRO_100_VM_3:
case PCI_PRODUCT_INTEL_PRO_100_VM_4:
case PCI_PRODUCT_INTEL_PRO_100_VM_5:
case PCI_PRODUCT_INTEL_PRO_100_VM_6:
aprint_normal(": %s, rev %d\n", fpp->fpp_name,
sc->sc_rev);
sc->sc_rev = 1;
break;
case PCI_PRODUCT_INTEL_82801E_LAN_1:
case PCI_PRODUCT_INTEL_82801E_LAN_2:
aprint_normal(": %s, rev %d\n", fpp->fpp_name,
sc->sc_rev);
/*
* XXX We have to read the C-ICH's developer's manual
* in detail
*/
break;
}
On Monday, Sep 8, 2003, at 17:09 Europe/Berlin, TAMURA Kent wrote:
<excerpt>
In message "ICH5 mixer issue, kern/20368 and kern/22548"
<excerpt>First of all, kern/20368 is wrong, although the fix does the
right thing
in the end. The main reason for that is that the codec listing is
erroneous: ADS 0x70 is ad1980, not ad1981. Thus the register names are
different. In the meantime, that codec should be probed as:
</excerpt>
Ok, I have fixed this.
<excerpt>The effect of kern/20368 is to have the headphone controlled
by the
surround register, and the line-out controlled by the main mixer, thus
inverting the use of the two registers, creating the behaviour
described
in kern/22548.
</excerpt>
I have questions to understand the behavior of AD1980. When you
play stereo audio data, do you have the audio output via the
line-out with kern/20368, and via the headphone without
kern/20368? How does outputs.headphones work, and how about
setting AD1980_MISC_SPRD?
--
TAMURA Kent <<kent2003@hauN.org> <<kent@netbsd.org>
</excerpt>
--=_21c39a20d8f1cc964c23ee7e8ccfe201--