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@suse.de 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@suse.de> 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@suse.de> 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@suse.de> 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)>] >