[alsa-devel] Patch Update for OpenFrame Sigmatel STAC9202
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.
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
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
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
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.
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
participants (3)
-
Andrew Davison -
Andy Davison
-
Takashi Iwai