On Fri, 16 Nov 2018 15:02:15 +0100, David Ulricht wrote: > > Lukas Wunner helped with investigation on the topic, check his last post at: > https://bugzilla.kernel.org/show_bug.cgi?id=110561 > I am looking at sound/i2c/i2c.c and sound/i2c/cs8427.c but i don't understand > how to initialize the i2c bus having the Windows10 ini hexes about I2C. > I believe you are more familiar with the code and you can help with a brief > example how to initialize i2c bus and how to send the InitI2C hex to the I2C > bus. Still i2c.c is from 1998 should be of help. > Please advise. The stuff in sound/i2c/* are mostly for the i2c bus on a PCI sound cards, an implementation independent from the standard i2c stuff. And, in your case, it's hard to know how the i2c bus is connected. If it's controlled over HD-audio GPIO pin (one for clk and one for data), then some stuff in sound/i2c can be re-used. Or, if it's on another i2c bus, the story will be completely different... Takashi > On Sun, Aug 5, 2018 at 9:05 PM Takashi Iwai <tiwai@xxxxxxx> wrote: > > On Sat, 04 Aug 2018 22:30:29 +0200, > David Ulricht wrote: > > > > Excuse me for dropping CC.. > > > > I set the direction bit to 0 and used get_gpio_data and get only: value > = > > 0x0 N> > also checking "IO[0-7] data=0-1" value in /proc/asound/card0/codec#0 > shows > > no changes at all when insert audio jack. > > OK, then it's not about GPIO, something else. > It's hard to know without the datasheet... > > > I tried also booting with "acpi=off". I tried older kernels from few > years > > ago. Nothing helps. > > I wonder if there is some tool for Windows that I use to debug and see > what > > is sent to the codec so i replicate in Linux with hda-verb? > > acpi=off wouldn't work at all on modern machines. > > > What am I doing wrong ? Is the below script correct for testing the > GPIOs ? > > for x in range(0,256): > > mhex=("0x%0.2X" % x) > > os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK "+mhex) > > os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION "+mhex) > > os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA "+mhex) > > I think its not correct gpio_direction i guess could be only 0 or 1? > > What happens when I pass a different value to data than 0/1 ? this > should > > also not be correct. > > I guess 0x01 is the NID value is it okay to use 0x01 only or I have to > pass > > other values to it also ? > > Yes, NID 0x01 is usually the right value, which means AFG. > > BTW, I noticed that there is some downstream patch. Is it the repo > you mentioned earlier? > > https://github.com/joelkraehemann/hda-tool/blob/master/patch_cirrus.c.patch > > Did you try that? > > Takashi > > > On Sat, Aug 4, 2018 at 8:13 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > > > > Please don't drop Cc to ML. Also avoid top-posting. > > > > > > On Sat, 04 Aug 2018 19:02:53 +0200, > > > David Ulricht wrote: > > > > > > > > How can I do that ? > > > > I tried verifying if /proc/asound/card0/codec#0 changes when i put > > > > handphone jack in and out with "diff ver1 ver2" and it is exactly > the > > > same. > > > > > > Just do for each bit as you tried for GPIO output. In this case, the > > > direction bit should be different (set 0), and you need to read. > > > > > > > > > > > One strange thing I note is hda-jack-retask.fw contains: > > > > [pincfg] > > > > 0x24 0x90100080 > > > > 0x25 0x90100082 > > > > I have 0x90100080 for 0x24 but in /proc/asound/card0/codec#0 : > > > > Node 0x24 [Pin Complex] wcaps 0x400101: Stereo > > > > Pincap 0x00000010: OUT > > > > Pin Default 0x90100110: [Fixed] Speaker at Int N/A > > > > Conn = Unknown, Color = Unknown > > > > DefAssociation = 0x1, Sequence = 0x0 > > > > Misc = NO_PRESENCE > > > > Pin-ctls: 0x40: OUT > > > > Connection: 1 > > > > 0x02 > > > > > > > > Shouldn't "Pin Default 0x90100110" be 0x90100080 after applying the > > > patch ? > > > > > > No, the codec config value itself won't change, the driver uses the > > > given value only internally. > > > > > > > > > Takashi > > > > > > > I can see that Applying patch firmware 'hda-jack-retask.fw' is > before > > > > hdaudioC0D0: autoconfig for Generic: line_outs=2 (0x24/0x25/0x0/0x0/ > 0x0) > > > > type:speaker > > > > in dmesg and this worries me, maybe the pins are overriden by > generic > > > > cirrus logic ? > > > > > > > > > > > > On Sat, Aug 4, 2018 at 7:26 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > > > > > > > > On Sat, 04 Aug 2018 17:44:59 +0200, > > > > > David Ulricht wrote: > > > > > > > > > > > > I used the following script running as root to verify the 8 > GPIOs > > > while > > > > > > playing long youtube video, > > > > > > I have running pulseaudio meanwhile and not restarting it, i > think > > > its > > > > > okay > > > > > > like that people on the ubuntu forums say that after using > > > > > > hda-verb and setting a gpio active immediately sound appears, so > i > > > guess > > > > > > there is no need to restart pulseaudio. > > > > > > I have done the same test with headphones in. > > > > > > No sound in both scenarios, no input no output detected (i'm > watching > > > > > > pavucontrol for input detection). > > > > > > > > > > This codec is fairly unique and doesn't provide the standard jack > > > > > detection on each pin. Maybe it's via either GPIO or any other > > > > > method. You can try to read GPIO pins (set as input) to see > whether > > > > > any of them corresponds to the jack detection, for example. > > > > > > > > > > > > > > > Takashi > > > > > > > > > > > > > > > > > #!/usr/bin/env python3 > > > > > > import os,time > > > > > > for x in range(0,256): > > > > > > mhex=("0x%0.2X" % x) > > > > > > os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK > "+mhex) > > > > > > os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION > > > "+mhex) > > > > > > os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA > "+mhex) > > > > > > time.sleep(3) > > > > > > > > > > > > Meanwhile script is running I'm watching /proc/asound/card0/ > codec#0 > > > and > > > > > > IO[0-7] changes its configuration, > > > > > > in comparison Joel Krahemann in his scripts is changing the hex > right > > > > > after > > > > > > /dev/snd/hwC0D0 (0x01) e.g. i dont think he is modifiying the > GPIOs > > > > > > correctly. > > > > > > > > > > > > I found the following post: > > > > > > https://forum.manjaro.org/t/sound-not-working-on-a-2017- > > > > > imac-27-5k-retina/43638 > > > > > > According to https://bugzilla.kernel.org/show_bug.cgi?id=195671 > > > iMac27 > > > > > has > > > > > > a similar soundcard. > > > > > > How can i setup with command line or any other utility: > > > > > > """select “off” in the top menu that propose to setup the > Digital > > > > > > Surround""" > > > > > > this is some setting in xfce4-mixer package which is not > available > > > for > > > > > > ubuntu since 2 LTS versions behind. I tried current Manjaro and > > > couldn't > > > > > > find this setting in audio mixer of xfce4 either. > > > > > > > > > > > > On Sat, Aug 4, 2018 at 9:48 AM, Takashi Iwai <tiwai@xxxxxxx> > wrote: > > > > > > > > > > > > > On Sat, 04 Aug 2018 04:07:43 +0200, > > > > > > > David Ulricht wrote: > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > Macbook pro models containing CS8409 for sure are: > > > > > > > > MBP131 MBP141.I own MBP 14,1 e.g. 2017 model. > > > > > > > > > > > > > > > > I'm attaching working sound configuration from Windows 10 > > > registry > > > > > (note > > > > > > > > that the cs420x might need to be ignored or might be > important i > > > > > don't > > > > > > > > really know). I believe what is really used is in the > > > > > PinConfigOverride > > > > > > > > section. > > > > > > > > > > > > > > Comparing between BIOS default (init_pin_cfg in alsa-info.sh > > > output) > > > > > > > and your override (user_pin_cfg), there aren't so many > changes. > > > > > > > All changes are pretty minor, and I guess it won't influence > on the > > > > > > > driver behavior. > > > > > > > > > > > > > > > Interesting thing to note is that sound in MacOS is much > louder > > > than > > > > > > > > Bootcamp Windows, would be nice to hear how loud is on > linux. > > > > > > > > > > > > > > This is possibly with some vendor-specific GPIO or COEF verbs. > > > > > > > Or it's some direct I2C control. The INI file mentions it. > > > > > > > And that's above HD-audio driver's responsibility. > > > > > > > > > > > > > > > I did convert PinConfigOverride HEX strings to [pincfg] > format > > > in the > > > > > > > > attached hda-jack-retask.fw thanks to Takashi's guidance. > > > > > > > > > > > > > > > > I'm attaching also alsamixer ASCII. Only PCM, no Master ? > > > > > > > > > > > > > > It's because the codec chip has no output amplifier at all. > > > > > > > So there can be neither output volume nor mute control on this > > > chip. > > > > > > > > > > > > > > > What I have tried is execute: > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x@@ > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION 0x@@ > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x@@ > > > > > > > > putting @@ from 0x00 to 0x50 > > > > > > > > > > > > > > There are eight GPIOs, so you'd need to test each bit, i.e. > 0x01, > > > > > > > 0x02, 0x04, 0x08, ... 0x80. > > > > > > > > > > > > > > And how is the current situation? You can't play *and* record > > > > > > > anything from any inputs / outputs? > > > > > > > > > > > > > > > > > > > > > Takashi > > > > > > > > > > > > > [2 <text/html; UTF-8 (quoted-printable)>] > > > > > > > > > > > > > > > [2 <text/html; UTF-8 (quoted-printable)>] > > > > > > > > > [2 <text/html; UTF-8 (quoted-printable)>] > > > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
