Patch Update for OpenFrame Sigmatel STAC9202

Patch Update for OpenFrame Sigmatel STAC9202

[Andy Davison]

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.

All the best,

     Andy.

Re: Patch Update for OpenFrame Sigmatel STAC9202

[Takashi Iwai]

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

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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Patch Update for OpenFrame Sigmatel STAC9202

[Takashi Iwai]

On Wed, 31 Jul 2019 10:36:13 +0200,
Andrew Davison wrote:
> 
> 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?

As mentioned, you might need to control GPIO as well.  Try to adjust
the GPIO pin via hda-verb.


Takashi

> 
> Thanks again,
> 
>      Andy.
> 
> 
> 
> > On 19 Jul 2019, at 16:02, Takashi Iwai <tiwai@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
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Patch Update for OpenFrame Sigmatel STAC9202

[Andrew Davison]

> On 31 Jul 2019, at 09:37, Takashi Iwai <tiwai@suse.de> wrote:
> 
> On Wed, 31 Jul 2019 10:36:13 +0200,
> Andrew Davison wrote:
>> 
>> 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?
> 
> As mentioned, you might need to control GPIO as well.  Try to adjust
> the GPIO pin via hda-verb.
> 

Would you be able to provide an example of how to do this? I’m not sure where to start on that one.

Thanks,

    A.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Patch Update for OpenFrame Sigmatel STAC9202

[Takashi Iwai]

On Wed, 31 Jul 2019 10:39:29 +0200,
Andrew Davison wrote:
> 
> 
> > On 31 Jul 2019, at 09:37, Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > On Wed, 31 Jul 2019 10:36:13 +0200,
> > Andrew Davison wrote:
> >> 
> >> 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?
> > 
> > As mentioned, you might need to control GPIO as well.  Try to adjust
> > the GPIO pin via hda-verb.
> > 
> 
> Would you be able to provide an example of how to do this? I’m not sure where to start on that one.

Something like:
  hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x01
  hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
  hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01

Above will enable the GPIO pin #0 to the write direction, and set high.
It's a bit mask, so for pass 0x02 for pin#1, 0x04 for pin#2, etc.
Try to fiddle with the data high/low and dir high/low.
Most likely the first bit controls some external amp like the
speaker.

And the device /dev/snd/hwC0D0 depends on the system.  hwC0D0 is for
the card 0 device 0.

Once when we figure out the GPIO pin role, we can hook the pin up/down
along with the speaker mixer mute state.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel