New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remaining sound issues #8

Open
Orochimarufan opened this Issue Oct 28, 2017 · 57 comments

Comments

Projects
None yet
10 participants
@Orochimarufan

Orochimarufan commented Oct 28, 2017

I thought it'd help to have somewhere to collect details on the remaining sound issues

PA crashing because of LPE: Upstream bug to watch is https://bugs.freedesktop.org/show_bug.cgi?id=100488

No speaker audio: Needs further investigation

I'm led to believe that it's not the former, since the UCM is reported to work with other similar devices. Also an UCM for the rt5651 has recently been added to upstream alsa-libs, but it's not changing anything for me.

See also plbossart/UCM#13

@Orochimarufan

This comment has been minimized.

Orochimarufan commented Dec 25, 2017

I have news on this topic: I was correct in assuming that some part of the previous design is left over in the Hi10 Pro (and probably Plus) board design regarding the speaker output. While what was previously used as an output muxer to choose between Speaker and HP out because the codec only had one output, it seems the HP port is now wired to the codec directly, so the left-over muxer is really just a hardware mute switch for the speakers.

With the speaker GPIO enabled both speakers and headphones work, depending on the PA profile. All that is missing is hp jack detection.

In my device (Hi10 pro HQ64G421703..; SKU P1D6_C109D Rev V100), the responsible GPIO is 418 on chip 1:

gpiochip1: GPIOs 397-455, parent: platform/INT33FF:01, INT33FF:01:
 gpio-400 (                    |id                  ) in  hi IRQ
 gpio-414 (                    |ACPI:OpRegion       ) out hi    
 gpio-416 (                    |ACPI:OpRegion       ) out lo    
 gpio-418 (                    |spken               ) out lo

It can be enabled by a few simple commands once this much is known:

GPIO=<speaker gpio number>
echo $GPIO >/sys/class/gpio/export
echo 1 >/sys/class/gpio/gpio$GPIO/value

The gpio number may differ on other revs/devices.

I'll put together a patch to have the driver do this later; It's probably safer to wait unti then.

@Orochimarufan

This comment has been minimized.

Orochimarufan commented Dec 25, 2017

A very simple patch is up: Orochimarufan/linux@00bc6f7 based on Linux 4.14

You can either rebuild your kernel with it or just replace the module:

cd <linux-tree-with-patch>
MODS=/usr/lib/modules/$(uname -r)
cp $MODS/build/{config,Module.symvers} ./
make oldconfig
make modules_prepare EXTRAVERSION=-<kernel package patchlevel>
make -C $MODS/build M="$(pwd)/sound/soc/codecs" snd-soc-rt5651.ko
sudo install -Dm644 -t $MODS/updates/ sound/soc/codecs/snd-soc-rt5651.ko
sudo depmod
sudo mkinitcpio -p <kernel package name>

and reboot. See also https://wiki.archlinux.org/index.php/Compile_kernel_module

Note that there seems to be some audible crackling when the codec gets set up.

I also had a quick look at 4.15, and it seems they added jack detection upstream. I haven't had a long enough look to see how it relates to this though (it also uses GPIOs, but differently). Maybe I'll find the time in the coming days.

@danielotero

This comment has been minimized.

Owner

danielotero commented Dec 26, 2017

@danielotero

This comment has been minimized.

Owner

danielotero commented Dec 27, 2017

Finally got the speakers working! Thank you very much @Orochimarufan!

I'm curious about how did you get the GPIO pin number and the "spken" identifier.

This are the steps I did to make it work:

  1. Replace the bytcr-rt5651 UCM folder with the bytcr_rt5651 (didn't seem to work with the first one)
  2. Turn the GPIO 418 on.
  3. Switch in pulseaudio from Headphones to Speakers.
    Everything works as expected except for the jack detection feature.

I will try the patch another time.

@Orochimarufan

This comment has been minimized.

Orochimarufan commented Dec 27, 2017

The pins are listed in the ACPI DSDT. However, I couldn't figure out how to get the linux gpio number from the ACPI chip/pin number combination (01/0x1B if you're interested). However, if the driver registers the pin with a name, it'll appear in the list at /sys/kernel/debug/gpio. The driver can just register it directly from ACPI using in-kernel apis. Since I didn't find any similar userspace APIs, I had to fix up the driver to look for it. The code on the kernel bug report for Hi10/Hi12 was pretty much exactly what was needed so I basically just ported it over to the rt5651 driver. That's also where 'spken' comes from. Have a look at the patch for details

As for the UCM, just use the upstream one from latest alsa-libs. It works fine.

@Orochimarufan

This comment has been minimized.

Orochimarufan commented Jan 14, 2018

A short heads-up: 418 is definitely not a constant. It seems it not only depends on the hardware but even on the kernel build. It should always be the the 22nd pin on INT33FF:01 though, at least on the same H/W (look at /sys/kernel/debug/gpio and add 21 to the range on the relevant gpiochip)

Since I've been trying out the stock kernel now and then, I whipped up something to try and somewhat reliably enable it from userspace:
https://gist.github.com/Orochimarufan/d8e42cfaa32c2cdd13640dad6a10b847

It'd be better to get the gpio from ACPI directly like the kernel patch does, but I haven't figured out whether there's a sane way to get that info in userspace. Also, like the shell commands above, use this at your own risk; especially on a different device.

Also probably won't get around to testing 4.15 anytime soon. I saw you updated the kernel config in the repo to 4.15rc; How did it go sound-wise? Does jack detection work?

@gsantner

This comment has been minimized.

gsantner commented Jan 14, 2018

Just a comment about the "PA gets killed because of Intel LPE" thing: I don't know why, but if I start pulseaudio over ssh, it seems not to get killed on start.

@danielotero

This comment has been minimized.

Owner

danielotero commented Jan 14, 2018

@Orochimarufan Now I wonder where the 22nd PIN come from 😄
The -rc7 doesn't have any improvements so far, no jack detection but your patch works flawlessly. Did you try to mainline the patch or get any feedback from other kernel developers?

@gsantner That also happened to me. I think the solution reached master in PulseAudio, so probably get fixed in the next release.

@jumperdos

This comment has been minimized.

jumperdos commented Jan 14, 2018

Hi,
Work for jumper ezbook 2??,,,,should something be modified?
Thanks .
nano /sys/kernel/debug/gpio
piochip4: GPIOs 315-369, parent: platform/INT33FF:03, INT33FF:03:
gpio-365 ( |? ) in hi IRQ

gpiochip3: GPIOs 370-393, parent: platform/INT33FF:02, INT33FF:02:
gpio-387 ( |ACPI:Event ) in hi IRQ

gpiochip2: GPIOs 394-452, parent: platform/INT33FF:01, INT33FF:01:
gpio-435 ( |ACPI:OpRegion ) out hi

gpiochip1: GPIOs 453-508, parent: platform/INT33FF:00, INT33FF:00:

gpiochip0: GPIOs 509-511, parent: platform/INT0002:00, INT0002 Virtual GPIO:
gpio-511 ( |ACPI:Event ) in lo IRQ

please help
Thanks

@Orochimarufan

This comment has been minimized.

Orochimarufan commented Jan 14, 2018

@danielotero 21 is just the offset from the first pin (i.e. 418-397/415-394), with 22 being the same but counted from 1 (Which you really don't even do for pins now that I think about it).
The patch is in no condition to be mainlined. It's pretty much a hack and needs to be integrated with the new jack stuff or have special jack stuff added if it's different. I also don't have a big enough sample size to know what devices it needs to be enabled for.

@jumperdos It's possible that it's similar. You'd need to check your DSDT. Unfortuntely, I don't have an ezbook nor much time to spare right now.

@gsantner

This comment has been minimized.

gsantner commented Jan 17, 2018

@Orochimarufan

How did you get this mapping info?

In my device (Hi10 pro HQ64G421703..; SKU P1D6_C109D Rev V100), the responsible GPIO is 418 on chip 1:

gpiochip1

@Orochimarufan

This comment has been minimized.

Orochimarufan commented Jan 21, 2018

@gsantner It's embedded in the ACPI DSDT. See #8 (comment)

@jcromero

This comment has been minimized.

jcromero commented Jan 27, 2018

I have a Chuwi Lapbook 15.6
I have audio via headphones, but not speakers. But:

# cat /sys/kernel/debug/gpio
gpiochip4: GPIOs 315-317, parent: platform/INT0002:00, INT0002 Virtual GPIO:
 gpio-317 (                    |ACPI:Event          ) in  lo IRQ

gpiochip3: GPIOs 318-372, parent: platform/INT33FF:03, INT33FF:03:
 gpio-368 (                    |?                   ) in  hi IRQ

gpiochip2: GPIOs 373-396, parent: platform/INT33FF:02, INT33FF:02:
 gpio-381 (                    |power               ) in  hi IRQ
 gpio-390 (                    |ACPI:Event          ) in  hi IRQ

gpiochip1: GPIOs 397-455, parent: platform/INT33FF:01, INT33FF:01:
 gpio-418 (                    |sysfs               ) out hi    
 gpio-438 (                    |ACPI:OpRegion       ) out hi    

gpiochip0: GPIOs 456-511, parent: platform/INT33FF:00, INT33FF:00:

How can I get GPIO pin number and the "spken" identifier in my machine? It doesn't work with GPIO 418.

Thanks.

@jcromero

This comment has been minimized.

jcromero commented Jan 27, 2018

@gsantner Do you also have a Chuwi Lapbook 15.6?

@gsantner

This comment has been minimized.

gsantner commented Jan 27, 2018

no, and this is about chuwi Hi10 ^^

@jcromero

This comment has been minimized.

jcromero commented Jan 27, 2018

Yes, I know, but the problem seems soooo similar :/

@gsantner

This comment has been minimized.

gsantner commented Jan 27, 2018

i didnt get a single speaker sound either yet

@jcromero

This comment has been minimized.

jcromero commented Jan 27, 2018

@gsantner On Chuwi hi10?

@gsantner

This comment has been minimized.

gsantner commented Jan 27, 2018

+

@jcromero

This comment has been minimized.

jcromero commented Jan 27, 2018

@gsantner

This comment has been minimized.

gsantner commented Jan 27, 2018

I did and various other things but still had no success :d

@jumperdos

This comment has been minimized.

jumperdos commented Feb 14, 2018

This are the steps I did to make it work:

1:/ Replace the bytcr-rt5651 UCM folder with the bytcr_rt5651 (didn't seem to work with the first one)
OK,,,,

2:/Turn the GPIO 418 on.

Please ,,explains how it is done "Turn the GPIO 418 on."
3:/Switch in pulseaudio from Headphones to Speakers.
4:/Everything works as expected except for the jack detection feature.
Thanks in advance.

@boschkundendienst

This comment has been minimized.

boschkundendienst commented Apr 16, 2018

Thanks to the little C program from @Orochimarufan I have now working sound.

I blacklisted the snd_hdmi_lpe_audio in /etc/modprobe.d/blacklist.conf.

# see https://wiki.archlinux.org/index.php/Kernel_module#Blacklisting
# do not load "snd_hdmi_lpe_audio" to make Chuwi sound work
install snd_hdmi_lpe_audio /bin/false

copied the compiled executable spken to /usr/local/sbin/spken and created the following daemon file (/etc/systemd/system/my_speakerenabler.service) to start it at boot:

[Unit]
Description=CHUWI Hi10 Pro speaker enabler daemon
After=sound.target

[Service]
Type=oneshot
RemainAfterExit=yes
User=root
WorkingDirectory=/usr/local/sbin
ExecStart=/usr/local/sbin/spken 1
ExecStop=/usr/local/sbin/spken 0


[Install]
WantedBy=multi-user.target

After a

sudo systemctl daemon-reload
sudo systemctl enable my_speakerenabler.service

I have now working sound either from headset or speakers (by manual selection).

Thanks @Orochimarufan for this!

So for me personally the only thing I am missing are working cameras (Arch Linux Kernel 4.15.15-1)

@boschkundendienst

This comment has been minimized.

boschkundendienst commented Apr 20, 2018

Well, it turned out, the spken.c fix wasn't a long living one. Yesterday kernel 4.16.2 arrived in Arch Linux and now enabling the speaker via GPIO pin no longer works. It is now telling Could not write gpio pin: Operation not permitted.

sudo /usr/local/sbin/spken 1
Using gpio 362
Could not write gpio pin: Operation not permitted

If someone has an idea what is wrong now, just send me a note. - Thanks

@danielotero

This comment has been minimized.

Owner

danielotero commented Apr 20, 2018

I also have problems with the speaker in the 4.16 version. Will try to debug that (not sure how).

@boschkundendienst

This comment has been minimized.

boschkundendienst commented Apr 20, 2018

I wrote some infos here. I think the kernel should have out in /sys/class/gpio/gpio<pin>/direction after exporting the gpio pin. It shows in now with latest kernel but out is necessary to be able to write to the pin. I also tried to write out in there manually and then setting the value to 1 which then works but sound does not go on.

I don' t know how to address this maybe as kernel bug to the kernel devs? Or it is a problem with the module snd_soc_rt5651 ?

I tried with the ARCH LTS kernel 4.14.35, with that the gpio pin fix still works and I have sound.

@Orochimarufan

This comment has been minimized.

Orochimarufan commented Apr 22, 2018

I've got good news and bad news:

The speaker enable gpio offset seems to have moved around with 4.16. I think it's at 27 now (from previously 21). You can try it by substituting the 27 in my gist and recompiling it. Unfortunately I don't have a proper internet connection right now, so I won't be updating the gist until probably sometime later this week.

Now for the bad news: they're me too be some kind of regression somewhere agreeing the last 4.15 releases as well as in 4.16: when using those kernels, some kind of noise will down out any sound (on my device at least). Most of the noise can be torn rid of by playing with the amixer settings, but not all of it. I'll have to look into it. Please let me know if you encounter an issue like that

EDIT: Managed to get internet working after all, so I updated the gist. Also, the "regression" was actually my UCM mamaging to corrupt itself. Possibly an alsa-lib update or something. Also sorry for the typos in this message, it was originally written on a smartphone and autocorrect got the better of me. Should have skimmed over it a second time before submitting; oh well

@Orochimarufan

This comment has been minimized.

Orochimarufan commented Apr 22, 2018

All right, scratch that last one.

The pin offset changed in 4.16 (from 21 to 27); I don't know why but the gist has been updated.

@Carsuzan

This comment has been minimized.

Carsuzan commented May 14, 2018

I have opened a new issue for readibility at #11 if someone can have a look as suppose it's looks like what was described here.Thank you.

@gsantner

This comment has been minimized.

gsantner commented May 16, 2018

Tried to get it working too, but no success. I'm having a Chuwi Hi 10 Plus.

I tried with both 4.14 and 4.16 manjaro kernel on my device + spken started + UCM byctr_5651 installed (/usr/..).

Sadly does not work at all, I still just see "dummy output" and no sign of audio working or selectable :/

Kernel 4.16.
Can it be that 10Plus don't have audio hardware kill switch? I cannot see any spken for example.
Thats what i have at /sys/class/gpio:

drwxr-xr-x 54 root root    0 16. Mai 16:49 ..
lrwxrwxrwx  1 root root    0 16. Mai 16:49 gpiochip414 -> ../../devices/platform/INT33FF:00/gpio/gpiochip414
lrwxrwxrwx  1 root root    0 16. Mai 16:49 gpiochip341 -> ../../devices/platform/INT33FF:01/gpio/gpiochip341
lrwxrwxrwx  1 root root    0 16. Mai 16:49 gpiochip314 -> ../../devices/platform/INT33FF:02/gpio/gpiochip314
lrwxrwxrwx  1 root root    0 16. Mai 16:49 gpiochip228 -> ../../devices/platform/INT33FF:03/gpio/gpiochip228
drwxr-xr-x  2 root root    0 16. Mai 16:49 .
lrwxrwxrwx  1 root root    0 16. Mai 16:49 gpio368 -> ../../devices/platform/INT33FF:01/gpiochip1/gpio/gpio368
lrwxrwxrwx  1 root root    0 16. Mai 16:51 gpiochip225 -> ../../devices/platform/INT0002:00/gpio/gpiochip225
--w-------  1 root root 4096 16. Mai 16:51 export
--w-------  1 root root 4096 16. Mai 16:51 unexport

gpiochip4: GPIOs 225-227, parent: platform/INT0002:00, INT0002 Virtual GPIO:
 gpio-227 (                    |ACPI:Event          ) in  lo IRQ

gpiochip3: GPIOs 228-313, parent: platform/INT33FF:03, INT33FF:03:
 gpio-309 (                    |80860F14:03         ) in  lo IRQ

gpiochip2: GPIOs 314-340, parent: platform/INT33FF:02, INT33FF:02:
 gpio-322 (                    |power               ) in  hi IRQ
 gpio-336 (                    |ACPI:Event          ) in  hi IRQ

gpiochip1: GPIOs 341-413, parent: platform/INT33FF:01, INT33FF:01:
 gpio-344 (                    |ACPI:Event          ) in  hi IRQ
 gpio-364 (                    |ACPI:OpRegion       ) out hi    
 gpio-368 (                    |sysfs               ) out hi    

gpiochip0: GPIOs 414-511, parent: platform/INT33FF:00, INT33FF:00:
 gpio-492 (                    |volume_up           ) in  hi IRQ
 gpio-494 (                    |volume_down         ) in  hi IRQ

Has somebody an idea?

@Carsuzan

This comment has been minimized.

Carsuzan commented May 19, 2018

My headset is now working on my Chuwi Hi10 plus but no sound on internal speaker.
Chwui Kernel: 4.15.0-20
I'm using code kindly provided by Orochimarufan
sudo ./chuwispeaker 1
Using gpio 362
Could not write gpio pin: Operation not permitted

ls -al /sys/class/gpio
total 0
drwxr-xr-x 2 root root 0 mai 19 18:12 .
drwxr-xr-x 66 root root 0 mai 19 18:12 ..
--w------- 1 root root 4096 mai 19 18:12 export
lrwxrwxrwx 1 root root 0 mai 19 18:12 gpio362 -> ../../devices/platform/INT33FF:01/gpiochip1/gpio/gpio362
lrwxrwxrwx 1 root root 0 mai 19 18:12 gpiochip225 -> ../../devices/platform/INT0002:00/gpio/gpiochip225
lrwxrwxrwx 1 root root 0 mai 19 18:12 gpiochip228 -> ../../devices/platform/INT33FF:03/gpio/gpiochip228
lrwxrwxrwx 1 root root 0 mai 19 18:12 gpiochip314 -> ../../devices/platform/INT33FF:02/gpio/gpiochip314
lrwxrwxrwx 1 root root 0 mai 19 18:12 gpiochip341 -> ../../devices/platform/INT33FF:01/gpio/gpiochip341
lrwxrwxrwx 1 root root 0 mai 19 18:12 gpiochip414 -> ../../devices/platform/INT33FF:00/gpio/gpiochip414
--w------- 1 root root 4096 mai 19 18:12 unexport

As far as i understand code should work with 4.15 kernel.
Thank you for your help.

@danielotero

This comment has been minimized.

Owner

danielotero commented May 20, 2018

I think that the Orochimarufan C program it's only for HI10 Pro, not plus.

Try with the #8 (comment) solution to see if it works.

@boschkundendienst

This comment has been minimized.

boschkundendienst commented Jun 4, 2018

@gsantner Have you blacklisted the module snd_hdmi_lpe_audio like this in /etc/modprobe.d/backlist.conf?

# /etc/modprobe.d/blacklist.conf
install snd_hdmi_lpe_audio /bin/false

This special blacklisting is needed to make sure that no other module loads this module which would happen if you do normal blacklisting.

Then you should have a sound device. Then spken.c comes in place.

@gsantner

This comment has been minimized.

gsantner commented Jun 4, 2018

yes I have blacklisted and no dont have spken. But its Chuwi Hi10 plus, not pri

@youling257

This comment has been minimized.

youling257 commented Jun 28, 2018

jwrdegoede/linux-sunxi@9833cc8
jwrdegoede/linux-sunxi@204b754

ASoC: rt5651: Add support for external amplifier enable GPIO

The rt5651 does not have a built-in speaker amplifier, so it is often
used together with an external amplifier. On some boards the external
amplifier's enable pin is driven through a GPIO, add support for this.

ASoC: Intel: bytcr_rt5651: Add support for external amplifier enable ……GPIO

The rt5651 does not have a built-in speaker amplifier, so it is often
used together with an external amplifier. On Cherry Trail boards this
external amplifier's enable pin is driven through a GPIO, which is
given as the first GPIO in the ACPI resources of the codec fwnode.

This commit adds a mapping from the first GPIO to "ext-amp-enable-gpios"
to the codec device, so that the codec driver can find and contorl the
GPIO.

try to build kernel and modules use https://github.com/jwrdegoede/linux-sunxi/commits/master
try to build alsa-lib use https://github.com/jwrdegoede/alsa-lib/commits/master

@youling257

This comment has been minimized.

youling257 commented Jun 28, 2018

jwrdegoede/linux-sunxi@f026e06
ASoC: Intel: bytcr_rt5651: Add new IN2_HS_IN3 input map and a quirk u…sing it

Add a new IN2_HS_IN3 input map and add a quirk for the input mapping and
jack-detect source for the Chuwi Vi8 Plus tablet, which uses this new map.

Note the Chuwi Vi8 Plus lists an extra GPIO in its codecs ACPI resources
which needs to be driven high to enable the external speaker amplifier,
this is not supported yet and will be fixed in a future patch.

jwrdegoede/linux-sunxi@94cad7c
Hans de Goede do big works for atom tablet,he has chuwi vi8 plus tablet.

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Oct 8, 2018

Glad I found this thread. Thanks to everyone involved.
I had the exact same issue as discussed here with an identical hardware (marketed in India as RDP Thinbook). Thought of sharing my experience.
I have two such devices with mainline Kernel 4.14 on Debian stretch, one purchased 3 months back and the other last week.
In the older device, I manage to get audio through speakers and headphone using pulseaudio switch, no jack detection and mic support in 4.14. But with 4.18.5 mainline I manage to get jack detection and mic(both internal and external) as well.

Coming to the new device. I was promised by the vendor that the hardware is exactly the same, but when I received it the audio through the speakers wasn't working at all. I tried everything in my head and things mentioned in this thread with no luck. Though the GPIO approach is logical and correct, in my case, it ceases to work. I have then compared the DSDT SSDT* files from both hardware
and found the files differ in more than one place, one such change was in DSDT RTK audio. The left side of the image is of old device and right one is the new.

dsdt-comparison

So I had two options.
a) Find the GPIO pin responsible to trigger the audio amplifier in the new device (the one mentioned in this thread doesn't worked for me)
b) Or believe that the hardware is indeed identical and the firmware(BIOS) is to be blamed (as I already
spotted changes in DSDT and SSDT files)

The changes in DSDT clearly suggest that there is some change in BIOS. So when I noticed again I was surprised to find the following:
i) The boot logo was smaller in new device
ii) The build date was different, however, build number, version number and everything else was the same

So as my GPIO route not showing any promise, I requested the vendor for the previous BIOS version, to my surprise they shared the instructions almost immediately (great support from RDP). The vendor also selling a GNU/Linux version of this laptop so they too probably wanted this to be resolved ASAP.
Once the BIOS downgraded the audio worked perfectly.

Ok, what if the vendor didn't had the BIOS with them?
This is more practical scenario. In such case I had planned to use the DSDT and SSDT* files from old
laptop to the new using the grub route as stated in this Arch wiki link.
The DSDT file in my case fail to compile as it was dependent on other files, haven't tried further as I
got the audio working through BIOS downgrade.
Hope my experience is useful to someone :-)

@youling257

This comment has been minimized.

youling257 commented Oct 8, 2018

@srikantpatnaik
you should use upstream method,
https://github.com/torvalds/linux/commits/master/sound/soc/intel/boards/bytcr_rt5651.c
torvalds/linux@0a3badd#diff-f58a610ab1024305f3ad1e2dc89480ab
torvalds/linux@5f6fb23#diff-f58a610ab1024305f3ad1e2dc89480ab
upstream support gpio externar amplifier begin with 4.19 kernel.
if you can make a quirk patch for your new bios.
you can contact Hans de Goede hdegoede@redhat.com .

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Oct 9, 2018

Thanks @youling257
The Kernel 4.19 worked straightaway. The pin 407 populated with 'speaker-amp' tag out of the box. No 'echo' to /sys was needed. However, I lost the jack detection, microphone, and Bluetooth.
audio-with-4 19rc7

I have tried Kernel 4.18.5 as well and pin 407 needed to be echoed to /sys to turn on the speaker. Again, lost jack detection, mics, and bluetooth here.
With Kernel 4.14.5 the pin number was 449 (found through trial and error). Jack detection and mics were not implemented, bluetooth works as usual.

@youling257

This comment has been minimized.

youling257 commented Oct 10, 2018

did you use https://github.com/plbossart/UCM/blob/master/bytcr-rt5651/ files? needn't asound.state, only use bytcr-rt5651.conf and HiFi.conf.
so the default quirk not work for your jack and mic,

#define BYT_RT5651_DEFAULT_QUIRKS (BYT_RT5651_MCLK_EN |
BYT_RT5651_JD1_1 |
BYT_RT5651_OVCD_TH_2000UA |
BYT_RT5651_OVCD_SF_0P75)

/* Default: jack-detect on JD1_1, internal mic on in2, headsetmic on in3 */
static unsigned long byt_rt5651_quirk = BYT_RT5651_DEFAULT_QUIRKS |
BYT_RT5651_IN2_MAP;

you can make a quirk for your device.
what your device Bluetooth chip?

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Oct 10, 2018

did you use https://github.com/plbossart/UCM/blob/master/bytcr-rt5651/ files? needn't asound.state, only use bytcr-rt5651.conf and HiFi.conf.

Yes, the very same.

so the default quirk not work for your jack and mic,

#define BYT_RT5651_DEFAULT_QUIRKS (BYT_RT5651_MCLK_EN |
BYT_RT5651_JD1_1 |
BYT_RT5651_OVCD_TH_2000UA |
BYT_RT5651_OVCD_SF_0P75)

/* Default: jack-detect on JD1_1, internal mic on in2, headsetmic on in3 */
static unsigned long byt_rt5651_quirk = BYT_RT5651_DEFAULT_QUIRKS |
BYT_RT5651_IN2_MAP;

Thanks. I will try them.

you can make a quirk for your device.
what your device Bluetooth chip?

rtl8723bs

@youling257

This comment has been minimized.

youling257 commented Oct 10, 2018

you needn't patch rfkill_gpio, you needn't rtk_hciattach -n -s 115200 /dev/ttyS1 rtk_h5
you need CONFIG_BT_HCIUART_RTL=y
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Hans+de+Goede
config BT_HCIUART_RTL
bool "Realtek protocol support"
depends on BT_HCIUART
depends on BT_HCIUART_SERDEV
depends on GPIOLIB
depends on ACPI
select BT_HCIUART_3WIRE
select BT_RTL
help
The Realtek protocol support enables Bluetooth HCI over 3-Wire
serial port internface for Realtek Bluetooth controllers.

  Say Y here to compile support for Realtek protocol.

Bluetooth: hci0: RTL: rtl: loading rtl_bt/rtl8723bs_fw.bin
Bluetooth: hci0: RTL: rtl: loading rtl_bt/rtl8723bs_config-OBDA8723.bin

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Oct 11, 2018

@youling257 I compiled the kernel 4.19rc7 with your suggested configs, unfortunately, no improvement.
My bigger worry is my poor wifi strength, this is consistent from Kernel 4.16 onwards. I have r8723bs wifi adapter which works perfectly with my 4.14.

I see the following error only in 4.19
[ 4.996920] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 4.996930] cfg80211: failed to load regulatory.db

In 4.14 working wifi setup I see this
[ 6.579818] rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin [ 6.581487] rtl8723bs mmc1:0001:1: firmware: direct-loading firmware rtlwifi/rtl8723bs_nic.bin
But, there is no direct-firmware loading in 4.19, hence the problem?

Also, in my case these firmware never get called/load:
Bluetooth: hci0: RTL: rtl: loading rtl_bt/rtl8723bs_fw.bin Bluetooth: hci0: RTL: rtl: loading rtl_bt/rtl8723bs_config-OBDA8723.bin

@youling257

This comment has been minimized.

youling257 commented Oct 12, 2018

/lib/firmware/rtl_bt/rtl8723bs_fw.bin,rename from rtlbt_fw
/lib/firmware/rtl_bt/rtl8723bs_config-OBDA8723.bin,rename from rtlbt_config
https://github.com/lwfinger/rtl8723bs_bt

config BT_HCIUART_SERDEV
bool
depends on SERIAL_DEV_BUS && BT_HCIUART
default y

CONFIG_SERIAL_DEV_BUS=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y

CONFIG_BT_INTEL=m
CONFIG_BT_BCM=m
CONFIG_BT_RTL=m
CONFIG_BT_QCA=m
CONFIG_BT_HCIBTUSB=m
CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y
CONFIG_BT_HCIBTUSB_BCM=y
CONFIG_BT_HCIBTUSB_RTL=y
CONFIG_BT_HCIBTSDIO=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_SERDEV=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_ATH3K=y
CONFIG_BT_HCIUART_LL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_BT_HCIUART_INTEL=y
CONFIG_BT_HCIUART_BCM=y
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_QCA=y
CONFIG_BT_HCIUART_AG6XX=y
CONFIG_BT_HCIUART_MRVL=y

what your .config

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Oct 12, 2018

/lib/firmware/rtl_bt/rtl8723bs_fw.bin,rename from rtlbt_fw
/lib/firmware/rtl_bt/rtl8723bs_config-OBDA8723.bin,rename from rtlbt_config
https://github.com/lwfinger/rtl8723bs_bt

Thanks. I'm using the same repository for my bluetooth, it works till kernel 4.15.
I did a small experiment now:
Renamed my rtlwifi/rtl8723bs_nic.bin and restarted. The wifi failed, but bluetooth started working.
I think not loading the firmware rtl8723bs_nic.bin in 4.19 is causing the problem, as I mentioned it get
loaded neatly till 4.15.

config BT_HCIUART_SERDEV
bool
depends on SERIAL_DEV_BUS && BT_HCIUART
default y

CONFIG_SERIAL_DEV_BUS=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y

CONFIG_BT_INTEL=m
CONFIG_BT_BCM=m
CONFIG_BT_RTL=m
CONFIG_BT_QCA=m
CONFIG_BT_HCIBTUSB=m
CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y
CONFIG_BT_HCIBTUSB_BCM=y
CONFIG_BT_HCIBTUSB_RTL=y
CONFIG_BT_HCIBTSDIO=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_SERDEV=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_ATH3K=y
CONFIG_BT_HCIUART_LL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_BT_HCIUART_INTEL=y
CONFIG_BT_HCIUART_BCM=y
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_QCA=y
CONFIG_BT_HCIUART_AG6XX=y
CONFIG_BT_HCIUART_MRVL=y

what your .config

Here is my config file
https://gist.github.com/srikantpatnaik/3b59722aee60ea127058e217cbbe87f9

@youling257

This comment has been minimized.

youling257 commented Oct 12, 2018

my tablet rtl8723bs chip wifi and Bluetooth work well though Linux 4.19 upstream method.

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Oct 12, 2018

I have stopped using start_bt.sh since I started experimenting with 4.19. I used it in 4.14 only. It was just one time I tried when you asked me to.
Leaving the rfkill_gpio was my mistake, I misunderstood when you said patch I thought you meant external patch which I wasn't using (I was using few patches in 4.14 though). I will compile 4.19 without rfkill support. I will rename the firmware and try. My apologies.
I will test in a few hours(reached office). Thanks for your kind support.

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Oct 12, 2018

Just in case, is it possible for you to share your "config" file?

@youling257

This comment has been minimized.

youling257 commented Oct 12, 2018

must CONFIG_SERIAL_DEV_BUS=y then can CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
suggest CONFIG_DW_DMAC_CORE=y CONFIG_DW_DMAC=y

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Oct 12, 2018

Bluetooth works!
Thanks to your inputs now I have a working and reliable connectivity.
However, my wifi strength still bothers me, I get around 30% link strength compare to 90% in kernel 4.14.
What I see is the firmware rtlwifi/rtl8723bs_nic.bin is called but never gets loaded properly?
Any suggestions?

My current config file and dmesg output.

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Oct 13, 2018

What I meant was there should be another line in dmesg after
rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin
like this
mmc1:0001:1: firmware: direct-loading firmware rtlwifi/rtl8723bs_nic.bin

But I'm getting only the first line not the second "direct-loading" line in 4.19rc7 which may indicate the improper loading of the firmware.

@youling257

This comment has been minimized.

youling257 commented Nov 4, 2018

“My bigger worry is my poor wifi strength, this is consistent from Kernel 4.16 onwards”
@srikantpatnaik
do you online? go to here, https://bugzilla.kernel.org/show_bug.cgi?id=201611

@Danct12

This comment has been minimized.

Danct12 commented Nov 7, 2018

Well, curious asking, do you guys get the sound driver issue? After upgrading to kernel 4.19, there's a high pitched sound playing in my loud speaker at full volume.

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Nov 7, 2018

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Nov 7, 2018

Did anyone notice a muted left channel since Kernel 4.19+? The right channel audio plays on both speakers in my settings?
speaker-test -t wav -c2

@Danct12

This comment has been minimized.

Danct12 commented Nov 8, 2018

@srikantpatnaik Thank you, that actually worked.
Also in kernel 4.19, you don't need to turn on the speaker GPIO anymore, it works right out of the box. (I'm on 4.19.1 if you ask me)

Speaking of the muted left channel, I tried your config and both speakers worked fine. Perhaps could be the GPIO speaker patch, try disable that.

@srikantpatnaik

This comment has been minimized.

srikantpatnaik commented Nov 8, 2018

@Danct12 Glad it worked for you. I'm not setting GPIO manually since 4.19.
Both speakers work for me too, the right one plays on both, but you can spot the difference by using speaker-test -t wav -c2.
Are you using Linux or Android?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment