On 08/02/2015 03:17 PM, Takashi Iwai wrote:
On Fri, 31 Jul 2015 03:54:55 +0200,
Hui Wang wrote:
On 07/30/2015 09:57 PM, Takashi Iwai wrote:
On Thu, 30 Jul 2015 12:11:00 +0200,
Hui Wang wrote:
On 07/27/2015 06:52 PM, Takashi Iwai wrote:
On Mon, 27 Jul 2015 12:34:31 +0200,
woodrow.shen@xxxxxxxxxxxxx wrote:
From: Woodrow Shen <woodrow.shen@xxxxxxxxxxxxx>
The new Dell laptop with codec 256 can't detect headset mic when headset was
inserted on the machine. From alsa-info, we check init_pin_configs and need to
define the new register value for pin 0x1d & 0x1e because the original macro
ALC256_STANDARD_PINS can't match pin definition. Also, the macro ALC256_STANDARD_PINS
is simplified by removing them. This makes headset mic works on laptop.
Codec: Realtek ALC256
Vendor Id: 0x10ec0256
Subsystem Id: 0x102806f2
BugLink: https://bugs.launchpad.net/bugs/1478497
Signed-off-by: Woodrow Shen <woodrow.shen@xxxxxxxxxxxxx>
I applied this as is now. But the code there is already messy, and I
wonder whether we should treat all 0x4xxxxxxx equally. So far, all
pincfgs are regarded as a kind of fingerprint. But, judging from the
actual values, the difference of 0x4xxxxxxx might be just a leftover
of wastes by BIOS programmers.
I don't mind any other way, but a sane cleanup would be appreciated.
thanks,
Takashi
Something like below?
remove all 0x4xxxxxxx from pin quirk table
rewrite the pin_config_match()
- first, compare all pins in a quirk table with the corresponding pin
on the machine, if all pins get a matching,
- second, compare all pins on the machine with the corresponding pin
in the quirk table
if the pin is non-0x4xxxxxxx, it needs match a corresponding
pin in the quirk table, otherwise, it return false
if the pin is 0x4xxxxxxx, the corresponding pin in the quirk
table is 0x4xxxxxxxx as well, it matches; if the corresponding pin in
the quirk table is non-0x4xxxxxxx, it return false
if the pin is 0x4xxxxxxx, and can't find the corresponding pin
in the quirk table, it matches.
Yes, something like that. But I think the first loop can be
reduced.
If the first loop is removed, there is some situation the second one
can't handle.
e.g.
a quirk table has:
{0x12, 0x9xxxxxxx},
{0x14, 0x9xxxxxxx},
{0x21, 0x02xxxxxx}
while a machine only has
{0x12, 0x9xxxxxxx},
{0x21, 0x02xxxxxx}
and the NID 0x14 on the machine is a [Vendor Defined Widget] instead of
a [pin complex].
Hm, OK, then it's a problem. Does it happen actually -- i.e. the same
codec ID / revision, but containing have different widget types?
Takashi
In practice, I have never seen this situation before. I will remove the
first loop and send a patch to review.
Thanks,
Hui.
In this situation, only the first loop can detect they are not matching.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html