[alsa-devel] ASoC: rt5640, rt5651 jack-detect and BYT SST suspend/resume patches / status update
Hi Pierre-Louis, Carlo, et al,
This mail is mostly just FYI, I've been doing a lot of work on $subject lately and the purpose of this mail is to avoid people doing double work.
As Pierre-Louis knows already, I've been working on adding support for rt5640 jack-detect, this is harder then it should be really, since the micbias overcurrent detect on the rt5640 seems to be very finicky if I don't enable things in exactly the right order its gets in some sort of "unhappy" state where it still works but only sometimes / it is unreliable. This "unhappy" state looks exactly the same as normal working state from a reg-dump pov.
So I've jack-detect including headphones vs headset detect working reliable now, after a reboot, but it becomes wonky again after a suspend/resume.
Which let me deeper into the rabbit hole. Suspend/resume while streams are active / allocated in the SST-DSP is broken on Bay Trail. I've written a fix for this and I can now suspend/ resume BYT devices while audio is playing over the speakers and the audio properly resumes playing properly. Also these related errors are gone now:
intel_sst_acpi 80860F28:00: FW sent error response 0x4000e intel_sst_acpi 80860F28:00: FW sent error response 0x4000f
I've added a quirk to the SST driver for this and I was wondering if I needed this at the platform (byt) level or at the machine-driver (so platform+codec combo) level. I've a Ployer momo7w tablet which uses the bytcr-rt5651 machine-driver, so I started testing with that.
So the bytcr-rt5651 machine-driver despite its name does not actually work with bytcr devices, which only have SSP0 available, so I fixed that, then had some issues with the jack-detection Carlo recently added, so I've done a bunch of fixes for those too.
I also have some UCM fixes for bytcr-rt5651 + SSP0, I will send a pull-req to Pierre-Louis' UCM github repo for those when I get around to it.
The kernel patches for all this can be found here:
https://github.com/jwrdegoede/linux-sunxi/commits/master
Noe this is somewhat in a state of flux, e.g. the BYT SST suspend/resume fixes are good, but currently only enabled on the bytcr-rt5640 combo, testing has shown I need them on the ployer too, but I still need to rework the quirk handling to move the quirk to the sst_platform_info struct. Also this needs to be rebased on top of 4.16-rc1, I know there will be some minor conflicts in the rt5651 code.
Note the rt5651 jack change to fix headset vs headphone detection does not work yet, now it sees everything as headphones ...
I probably won't have much time to continue work on this today and as said the main purpose of this mail is to get you aware of these patches to avoid double work. I hope to be able to rebase on top of 4.16-rc1, and do an upstream submission of everything except for the rt5640 jack-detect code sometime the next week.
Regards,
Hans
p.s.
Carlo or Pierre-Louis can one of you check using e.g. the left + right speaker test in gnome-control-panel's sound config-applet if that left only goes to the left speaker and right only goes to the right speaker?
My bytcr-rt5651 tablet has only one speaker, but I here sound for both the left and right speaker tests which suggests some right-to-left mixing is happening which we don't want on devices with stereo speakers. Could be there is some mixing happening outside of the codec on this tablet, still it would be good to test this.
On Sun, Feb 11, 2018 at 12:00 PM, Hans de Goede hdegoede@redhat.com wrote:
Hi Pierre-Louis, Carlo, et al,
Hey Hans,
This mail is mostly just FYI, I've been doing a lot of work on $subject lately and the purpose of this mail is to avoid people doing double work.
really nice. Thank you for this.
/cut
Note the rt5651 jack change to fix headset vs headphone detection does not work yet, now it sees everything as headphones ...
I tried your latest kernel and it works fine detecting my headset. AFAICT the problem (that I have also with the current driver shipped in the latest mainline kernel) is that the headset/mic detection _does not always work fine_. Sometimes the headset is only recognized as headphones but if you keep trying (usually detaching and attaching again the jack) then the driver is able to recognize it as headset (usually after a few tries).
I probably won't have much time to continue work on this today and as said the main purpose of this mail is to get you aware of these patches to avoid double work. I hope to be able to rebase on top of 4.16-rc1, and do an upstream submission of everything except for the rt5640 jack-detect code sometime the next week.
Regards,
Hans
p.s.
Carlo or Pierre-Louis can one of you check using e.g. the left + right speaker test in gnome-control-panel's sound config-applet if that left only goes to the left speaker and right only goes to the right speaker?
My bytcr-rt5651 tablet has only one speaker, but I here sound for both the left and right speaker tests which suggests some right-to-left mixing is happening which we don't want on devices with stereo speakers. Could be there is some mixing happening outside of the codec on this tablet, still it would be good to test this.
Just tested this and it works fine on my hardware.
Cheers,
Hi,
On 14-02-18 10:59, Carlo Caione wrote:
On Sun, Feb 11, 2018 at 12:00 PM, Hans de Goede hdegoede@redhat.com wrote:
Hi Pierre-Louis, Carlo, et al,
Hey Hans,
This mail is mostly just FYI, I've been doing a lot of work on $subject lately and the purpose of this mail is to avoid people doing double work.
really nice. Thank you for this.
/cut
Note the rt5651 jack change to fix headset vs headphone detection does not work yet, now it sees everything as headphones ...
I tried your latest kernel and it works fine detecting my headset.
Yes I've fixed that since writing the mail :)
AFAICT the problem (that I have also with the current driver shipped in the latest mainline kernel) is that the headset/mic detection _does not always work fine_. Sometimes the headset is only recognized as headphones but if you keep trying (usually detaching and attaching again the jack) then the driver is able to recognize it as headset (usually after a few tries).
Ack, I've seen the same on the rt5640 I've a better algorithm for headset vs headphone detection in the patch adding jack-detect to the rt5640 driver. I plan to port (copy and paste mostly) that to the rt5651 driver soonish, once that is done and I've run some final tests I plan to submit the whole bunch of patches (minus the rt5640 support which actually started all this) upstream, I will try to remember to put you in the Cc.
I probably won't have much time to continue work on this today and as said the main purpose of this mail is to get you aware of these patches to avoid double work. I hope to be able to rebase on top of 4.16-rc1, and do an upstream submission of everything except for the rt5640 jack-detect code sometime the next week.
Regards,
Hans
p.s.
Carlo or Pierre-Louis can one of you check using e.g. the left + right speaker test in gnome-control-panel's sound config-applet if that left only goes to the left speaker and right only goes to the right speaker?
My bytcr-rt5651 tablet has only one speaker, but I here sound for both the left and right speaker tests which suggests some right-to-left mixing is happening which we don't want on devices with stereo speakers. Could be there is some mixing happening outside of the codec on this tablet, still it would be good to test this.
Just tested this and it works fine on my hardware.
Great, thank you.
Note I've seem the same magic mono mixing happening on a CHT + rt5651 tablet I've also been testing on. It is weird how the hardware seems to magically mix the left and right channels to the mono speaker without explicitly enabling that in the codec/mixer settings as one needs to do for the rt5640 and rt5645. But hey if it works it works :)
Regards,
Hans
Carlo or Pierre-Louis can one of you check using e.g. the left + right speaker test in gnome-control-panel's sound config-applet if that left only goes to the left speaker and right only goes to the right speaker?
My bytcr-rt5651 tablet has only one speaker, but I here sound for both the left and right speaker tests which suggests some right-to-left mixing is happening which we don't want on devices with stereo speakers. Could be there is some mixing happening outside of the codec on this tablet, still it would be good to test this.
Just tested this and it works fine on my hardware.
Great, thank you.
Note I've seem the same magic mono mixing happening on a CHT + rt5651 tablet I've also been testing on. It is weird how the hardware seems to magically mix the left and right channels to the mono speaker without explicitly enabling that in the codec/mixer settings as one needs to do for the rt5640 and rt5645. But hey if it works it works :)
The rt5651 does not have a built-in amplifier, it provides a line out that is then fed into a discrete amplifier, the mixing could happen at that level too. We use the rt5651 for validation with a line-out -> line-in loopback and there is no issue with implicit mixing with the UCM files I pushed on my github (evolved from Carlo's rework).
Hi,
On 14-02-18 15:51, Pierre-Louis Bossart wrote:
Carlo or Pierre-Louis can one of you check using e.g. the left + right speaker test in gnome-control-panel's sound config-applet if that left only goes to the left speaker and right only goes to the right speaker?
My bytcr-rt5651 tablet has only one speaker, but I here sound for both the left and right speaker tests which suggests some right-to-left mixing is happening which we don't want on devices with stereo speakers. Could be there is some mixing happening outside of the codec on this tablet, still it would be good to test this.
Just tested this and it works fine on my hardware.
Great, thank you.
Note I've seem the same magic mono mixing happening on a CHT + rt5651 tablet I've also been testing on. It is weird how the hardware seems to magically mix the left and right channels to the mono speaker without explicitly enabling that in the codec/mixer settings as one needs to do for the rt5640 and rt5645. But hey if it works it works :)
The rt5651 does not have a built-in amplifier, it provides a line out that is then fed into a discrete amplifier, the mixing could happen at that level too.
Yes I think that that is what is happening, thank you for your answer.
Regards,
Hans
participants (3)
-
Carlo Caione -
Hans de Goede -
Pierre-Louis Bossart