[alsa-devel] Patch Update for OpenFrame Sigmatel STAC9202

[Andrew Davison]

Hi Takashi,

Thank you very much for your response. We’ve managed to use this configuration via hda-jack-retask:

[codec]
0x83847632 0x00000100 0

[pincfg]
0x07 0x01c5e150
0x08 0x01451130
0x0a 0x90170150
0x0b 0x02a19020
0x0c 0x01813021
0x0d 0x0321403f
0x10 0x500701f0
0x11 0x90330122
0x15 0x50a001f1

This corrects the behaviour of the HP detection and mutes (and unmutes) the correct outputs, but leaves us with a crackling sound from the internal speakers which sounds like system interference noise. It’s as if something has been left floating and the amplification for the internal speakers has not been shut off. I’m making the assumption that this is related to the 0xffbc0100 you mention.

What would be our next course of action to correct the crackling?

Thanks again,

     Andy.



> On 19 Jul 2019, at 16:02, Takashi Iwai <tiwai at suse.de> wrote:
> 
> On Wed, 19 Jun 2019 14:25:37 +0200,
> Andy Davison wrote:
>> 
>> Hi all,
>> 
>> Would anybody on this list have a little time to investigate this patch and
>> bring it up to date for application against the latest 5.1 kernel, or
>> indeed anything being actively developed?
>> 
>> https://gist.github.com/andydvsn/c0c159f99bf19d5b30b5e5e156dcac3e
>> 
>> This applies correctly against the 2.6.33 kernel, but I I lack the
>> necessary ALSA knowledge and programming skills to make the appropriate
>> corrections for anything more recent.
>> 
>> Alternatively, any other advice on where I could seek help with this would
>> be much appreciated. It is the only outstanding kernel issue for this
>> device and would love to have it fixed.
> 
> Oh well, that's a patch against the pretty old code base...
> 
> First of all, you need to identify which changes are missing.
> Basically your patch does:
> - The pin configuration override (openpeak9202_pin_configs[])
> - GPIO pin #0 (needs clear?)
> 
> Both could be done even without patching the kernel.  I'd start just
> setting up the pin configs and adjust GPIO manually via hda-verb to
> see what actually it does.
> 
> A tricky part is the strange code that is peeking the 0xffbc0100
> address.  I don't know exactly what it detects, but some pin configs
> are changed according to the value read there.  This can't be
> implemented in the upstream code in that way, but we may provide two
> different models so that user can simply choose, for example.
> 
> 
> Takashi