Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: Alex Hung <alex.hung@canonical.com>
Cc: Hui Wang <hui.wang@canonical.com>, Takashi Iwai <tiwai@suse.de>,
	alsa-devel@alsa-project.org
Subject: Re: [PATCH 4/5] ALSA: hda - drop def association and sequence from pinconf comparing
Date: Tue, 27 May 2014 06:41:09 +0200	[thread overview]
Message-ID: <53841765.4000404@canonical.com> (raw)
In-Reply-To: <CAJ=jqub_w_9vppPdO0dnz0nYztsGr3yn5DM4eHu-PWmhQnv1SA@mail.gmail.com>



On 2014-05-27 04:25, Alex Hung wrote:
> Hi David,
>
> BIOS today implements verbtable which is provided by codec vendor
> based on hardware design, and it is indeed not uncommon that the
> verbtable includes used pin only and leaves unused pins untouched.

Sure, but those unused pins would then have the same default value that 
the codec initializes it with.

Also, it wouldn't be uncommon for BIOS (or codec vendors) to use the 
same verbtable for several machines if they share the same audio hardware.

But none of this explains why anyone would just change def association 
and sequence value between machines? It makes no sense.

>
> On Mon, May 26, 2014 at 6:11 PM, David Henningsson
> <david.henningsson@canonical.com> wrote:
>> (Add Alex Hung to CC)
>>
>> On 2014-05-26 10:22, Hui Wang wrote:
>>>
>>> A lot a machine have the same codec, but they have different default
>>> pinconf setting just because the def association and sequence is
>>> different, as a result they can't share a hda_pintbl[], to overcome
>>> it, we don't compare def association and sequence in the pinconf
>>> matching.
>>
>>
>> Uhm, really? Alex, does this seem reasonable from a BIOS perspective, i e,
>> that BIOS people normally would set def association and sequence different
>> while leaving everything else unchanged?
>>
>>>
>>> Signed-off-by: Hui Wang <hui.wang@canonical.com>
>>> ---
>>>    sound/pci/hda/hda_auto_parser.c | 3 ++-
>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/sound/pci/hda/hda_auto_parser.c
>>> b/sound/pci/hda/hda_auto_parser.c
>>> index b684c6e..3cf9137 100644
>>> --- a/sound/pci/hda/hda_auto_parser.c
>>> +++ b/sound/pci/hda/hda_auto_parser.c
>>> @@ -844,7 +844,8 @@ static bool pin_config_match(struct hda_codec *codec,
>>>    {
>>>          for (; pins->nid; pins++) {
>>>                  u32 def_conf = snd_hda_codec_get_pincfg(codec, pins->nid);
>>> -               if (pins->val != def_conf)
>>> +               u32 mask = 0xffffff00;
>>> +               if ((pins->val & mask) != (def_conf & mask))
>>>                          return false;
>>>          }
>>>          return true;
>>>
>>
>> --
>> David Henningsson, Canonical Ltd.
>> https://launchpad.net/~diwic
>
>
>

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

  reply	other threads:[~2014-05-27  4:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-26  8:22 [PATCH 1/5] ALSA: hda - Add fixup_forced flag Hui Wang
2014-05-26  8:22 ` [PATCH 2/5] ALSA: hda - Add a new quirk match based on default pin configuration Hui Wang
2014-05-26  8:22 ` [PATCH 3/5] ALSA: hda - get subvendor from codec rather than pci_dev Hui Wang
2014-05-26  8:22 ` [PATCH 4/5] ALSA: hda - drop def association and sequence from pinconf comparing Hui Wang
2014-05-26 10:11   ` David Henningsson
2014-05-27  2:25     ` Alex Hung
2014-05-27  4:41       ` David Henningsson [this message]
2014-05-27  6:40         ` Hui Wang
2014-05-27  6:47           ` David Henningsson
2014-05-27  6:53             ` Takashi Iwai
2014-05-27  6:55               ` Hui Wang
2014-05-27  9:24               ` Hui Wang
2014-05-26  8:22 ` [PATCH 5/5] ALSA: hda - add an instance to use snd_hda_pick_pin_fixup Hui Wang
2014-05-26 10:14   ` David Henningsson
2014-05-27  0:31     ` Hui Wang
2014-05-26  9:10 ` [PATCH 1/5] ALSA: hda - Add fixup_forced flag Takashi Iwai

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=53841765.4000404@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=alex.hung@canonical.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=hui.wang@canonical.com \
    --cc=tiwai@suse.de \
    /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