Re: CS8409 Macbook Pro 2016 2017

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux