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@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
