That would make a good wiki page. Verb tables is a common problem. Thanks, Marc
On Wed, Apr 3, 2013 at 2:58 AM, Paul Menzel < [email protected]> wrote: > Dear Rudolf, > > > Am Donnerstag, den 28.03.2013, 08:36 +0100 schrieb Rudolf Marek: > > […] > > > > No idea. As you know already, according to Jens the Verb Table format > is > > > undocumented and Realtek does not give out any information [2]. > > > > > > What chip do you have? Realtek ALC887? At least that is what searching > > > for »f2a85-m realtek alc« seems to suggest. > > > > Yes think so. I my patch will simply write that verbs. > > thanks to the helpful reply of the ALSA developer Takashi Iwai [1], we > can use some tools from ALSA to decode the verb tables. > > > Am Dienstag, den 02.04.2013, 12:08 +0200 schrieb Takashi Iwai: > At Thu, 28 Mar 2013 22:56:37 +0100, > > Paul Menzel wrote: > > […] > > > Our developer Rudolf suggests to take the values from > > > > > > /sys/class/sound/hwC1D0/init_pin_configs > > > > > > when running the vendor BIOS [2]. > > > > Yes, that would work. You don't have to initialize the codec fully > > just to get the initial pin configs. Pass probe_only=1 to > > snd-hda-intel driver so that it will skip the codec initializations > > but just probing the codecs. The sysfs file should be available even > > in this mode. > > > > > How can a correct verb table be verified? > > > > It's difficult to say what's correct in general, because the pin setup > > is what's really depending on the hardware. Also, BIOS doesn't always > > give a correct pin config. There might be the pin config overridden > > by *.INI file on Windows. > > > > Also, BIOS may set up more than pin configs. It may set also some > > COEF verbs. > > > > > As for the ASRock E350M1 [4][5], I attach the output of `alsa-info.sh` > > > [6] when running coreboot. The one running with the vendor BIOS is > > > uploaded to the server [7] due to the size limit of this mailing list. > > > > > > $ wdiff vendorbios coreboot # init_pin_configs > > > 0x11 [-0x411111f0-] {+0x411110f0+} > > > 0x12 0x411111f0 > > > 0x14 [-0x01014010-] {+0x01014030+} > > > 0x15 [-0x01011012-] {+0x01011031+} > > > 0x16 [-0x01016011-] {+0x01016032+} > > > 0x17 [-0x411111f0-] {+0x01012033+} > > > 0x18 [-0x01a19840-] {+0x01a19850+} > > > 0x19 [-0x02a19950-] {+0x02a19c80+} > > > 0x1a [-0x0181304f-] {+0x01813051+} > > > 0x1b [-0x02214120-] {+0x02214c40+} > > > 0x1c [-0x411111f0-] {+0x9933105f+} > > > 0x1d [-0x4005e601-] {+0x00000100+} > > > 0x1e [-0x01452130-] {+0x01441070+} > > > 0x1f [-0x411111f0-] {+0x41c46060+} > > > > The values there can be decoded by hda-decode-pincfg program included > > in hda-emu: > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-emu.git > > > > In the case above, pins 0x14-16 are changed to have association number > > 3 instead of 1, and add the pin 0x17 as the side channel jack. > > > […] > > > Thanks, > > Paul > > > [3] > http://mailman.alsa-project.org/pipermail/alsa-devel/2013-April/060775.html > > -- > coreboot mailing list: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot > -- http://se-eng.com
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
