On Fri, 19 May 2023 18:53:16 +0200, Olliver Schinagl wrote: > > Hey Takashi, > > On 19-05-2023 09:12, Takashi Iwai wrote: > > On Thu, 18 May 2023 17:11:53 +0200, > > Olliver Schinagl wrote: > >> > >> Hey Takashi, > >> > >> On 18-05-2023 16:27, Takashi Iwai wrote: > >>> On Thu, 18 May 2023 16:24:02 +0200, > >>> Olliver Schinagl wrote: > >>>> > >>>> Hey Takashi, > >>>> > >>>> I've applied the patch you've listed below. Is there some 'fool-proof' > >>>> way to produce _any_ output however? I've stopped pulse/pipe audio, > >>>> and only use aplay + alsamixer. Back to basics as they say. For aplay, > >>>> I use -D sysdefault:CARD=PCH (which was listed as a cirrus card with > >>>> -L). > >>>> > >>>> Alsamixer was used to ensure all volumes are open. > >>>> > >>>> Without anything running, I was able to use hdajackretask to apply > >>>> settings. But then, what to put. I get that I have to figure out, what > >>>> is routed where (i'll try to find the schematic for the macbook pro > >>>> 12,1), but hence my question, is there some way to produce something? > >>>> In hdajackretask I've enabled all pins, overriden them all, and set > >>>> them all to the same configuration. 'Internal, internal, speaker, > >>>> other-analog, green, not-present, 1, front'. I figured, by setting up > >>>> verything to the internal speaker, I must get sound out of something, > >>>> but alas. > >>>> > >>>> I also have a Macbook pro from 1 or 2 generations earlier, 11,2 afaik, > >>>> where the sound still does work. I've used the same config > >>>> hdajackretask showed was in use there, but (obviously?) that didn't > >>>> work. > >>>> > >>>> So I'm a bit grasping at straws. Trying _every_ combination is a bit much? > >>> > >>> It's the hard part. I'd try to copy the pin config of the existing > >>> models at first, then try shooting one pin by one if it doesn't work. > >> > >> Ok, so no easy way :) I did try copying things, but didn't get sound either. > >> > >> I did find the schematics for the 2013 and 2014 models of the macbook; > >> no luck yet on the 2015 (mine). But all 3 have the same model number > >> (A1502), and looking at the schematic (not even sure if it is just a > >> new revision, or actually for the different boards) they seem more or > >> less identical. Especially on the audio part. The nice thing is it > >> tells me what pins things are connected to :) But again, might not be > >> a perfect match to my board (crosses fingers). > >> > >> What is interesting, the schematics [0] actually list the HDA configuration. > >> > >> CODEC OUTPUT SIGNAL PATHS > >> > >> FUNCTION VOLUME CONVERTER PIN COMPLEX MUTE CONTROL > >> > >> HP/HS OUT 0x02 (2) 0x02 (2) 0x10 (16) N/A > >> TWEETERS 0x03 (3) 0x03 (3) 0x12 (18) CODEC GPIO0 > >> SUB 0x04 (4) 0x04 (4) 0x13 (19) CODEC GPIO0 > >> SPDIF OUT N/A 0x0e (14) 0x21 (33) N/A > >> > >> DMIC 1 0x09 (9) 0x1c (18) > >> DMIC 2 0x09 (9) 0x1c (18) > >> > >> HEADSET MIC 0x07 (7) 0x18 (24) > >> > >> OTHER CODEC GPIO LINES > >> LEFT SPEAKER ID GPIO2 INPUT HIGH = FG, LOW = MERRY > >> RIGHT SPEAKER ID GPIO3 INPUT HIGH = FG, LOW = MERRY > >> DFET CONTROL GPIO4 OUTPUT HIGH = DFETs OPEN > >> > >> Granted, that should yield the same infomration I can copy from the > >> other one, but I'm trying to understand what this would mean. Function > >> is obvious, aswell as the pin-complex, it's what hdajackretasks calls > >> pin ID. But the rest is a bit iffy. E.g. what would the volume column > >> indicate? What about the 'converter'? And the GPIO's? Are the's GPIO's > >> of the codec? Maybe my confusion mostly comes as I'm not sure how to > >> relate those fields to hdajackretask. > > > > It's a good information. > > It corresponds to spec->gpio_eapd_speaker, and GPIO2 would be the bit > > 0x04, GPIO3 would be 0x08, so it should be set to 0x0c. The headphone > > has no GPIO assignment, so spec->gpio_eapd_headphone=0. > > > > But subwoofers seem to have the GPIO controls as well, and the gpio > > bit 0x01 should be set. For that, we'll need to modify cs_automute() > > function. But let's investigate this later. > > > > FWIW, the GPIO bits can be flipped on the fly, too. Use hda-verb for > > setting SET_GPIO_MASK, SET_GPIO_DIRECTION and SET_GPIO_DATA. > > Thanks for that explanation! Great news. I don't know how; but I > managed to 'fix' the bios. Strange yeah. I wanted to create an uefi > boot image as that's something arch's mkinitcpio appearantly > supports. So I used efiboomgr to add an additional entry. > > After a reboot, I regained the apple logo at boot (which was gone for > ages), but also the boot chime returned. And for sure, in Linux also > sound is working again normally. I have no idea how or why this works, > but it does. > > For reference, this is what 6.3.x now shows: > > [ 15.642288] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for > CS4208: line_outs=2 (0x12/0x13/0x0/0x0/0x0) type:speaker > [ 15.642296] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 > (0x0/0x0/0x0/0x0/0x0) > [ 15.642299] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 > (0x10/0x0/0x0/0x0/0x0) > [ 15.642301] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 > [ 15.642303] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x21/0x0 > [ 15.642305] snd_hda_codec_cirrus hdaudioC1D0: inputs: > [ 15.642307] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c > [ 15.642309] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 > [ 15.735257] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops > i915_audio_component_bind_ops [i915]) > > And hdajackretask (without unconnected pins): > Pin ID: 0x10 [Green Headphone] > Jack; External; Headphone; Combination; > Green; Present; 2; Front; > > Pin ID: 0x12 [Internal Speaker] > <blank>; Internal; Speaker; Unknown; > Unknown; Not present; 1; Back; > > Pin ID: 0x13 [Internal Speaker] > <blank>; Internal; Speaker; Unknown; > Unknown; Not present; 1; Back; > > Pin ID: 0x18 [Pink Mic] > Jack; External; Microphone; Combination; > Pink; Present; 4; Front; > > Pin ID: 0x1c [Internal Mic] > <blank>; Internal; Microphone; Other Digital; > Unknown; Not present; <blank>; Front > > Pin ID: 0x21 [White SPDIF Out] > Jack; External; SPIDF Out; Combination; > White; Present; 3; Front; > > The blank connectivity options are a bit off, as is the blank channel > group on the internal mic. > > So curious on those ... > > Anyway, leaving this here for any future in case it is needed again. Good to hear that you managed to recover BIOS. Could you give alsa-info.sh output from the working state? Run the script with --no-upload option and attach the output. This will help in future if it gets broken again :) thanks, Takashi