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 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)>]