Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12637 closed defect (fixed)

Q4D25 breaks sound output in Linux

Reported by: dsd Owned by: Quozl
Priority: high Milestone: 13.2.0
Component: kernel Version: not specified
Keywords: Cc: reubencaron
Blocked By: Blocking:
Deployments affected: Action Needed: test in build
Verified: no


Reported by NZ testing group. Sound output in Linux is no longer working in the latest firmware builds.

Testing 13.2.0 build 1 here, Q4D24 works, Q4D25 Q4D26 and Q4D27 all fail.

Change History (11)

comment:1 Changed 4 years ago by dsd

Forgot to mention the exact failure behaviour: the app that tries to play a sound simply hangs, and there is no audible output.

comment:2 Changed 4 years ago by wmb@…

The first thing I would try is this patch:

--- build-fw.fth	(revision 3622)
+++ build-fw.fth	(working copy)
@@ -690,10 +690,8 @@
 : pre-setup-for-linux  ( -- )
    [ ' linux-pre-hook behavior compile, ]    \ Chain to old behavior
-[ifdef] mmp3
    \ XXX Delete this when Linux is ready to turn on the audio island
    " audio-island-on" " /pmua" execute-device-method drop
 ' pre-setup-for-linux to linux-pre-hook

comment:3 Changed 4 years ago by Quozl

  • Action Needed changed from never set to diagnose

Tested with 13.1.0 build 20:

  • reproduced the symptom as described,
  • tried the patch to do audio-island-on, but symptom remained,
  • tried setting use-packmod?, but symptom remained,

Also tried with volume set off in Open Firmware. In Q4D24 as well as head, the same symptom occurs. Therefore the Linux kernel driver is still not initialising the hardware properly. See also:

  • #12165 (no sound from activities if startup sound set to zero).
  • #11082 (boot fails when audio muted).

Reviewed all changes from Q4D24 to Q4D25, but was unable to find any other obvious things to try. The extensive changes were engineering of the XO-4 audio while keeping the XO-1.75 Open Firmware audio operational. I wasn't checking Linux audio, unfortunately.

Have we any idea what Linux is doing at this point?

comment:4 Changed 4 years ago by dsd

Haven't investigated that yet. However I did check 12.1.0 with the new firmware and the same problem exists there. i.e. it does not seem to be related to any recent linux code changes.

comment:5 Changed 4 years ago by wmb@…

The problem is that recent versions of OFW clock the audio from the audio PLL instead of from the I2S_SYSCLK. XO-1.75 Linux uses I2S_SYSCLK, but since OFW does not use it, the I2S_SYSCLK bit in PMUM_CGR_PJ (AKA MPMU_ACGR) is not set, and thus that clock does not get to the SSPA unit.

The problem is further compounded by the fact that the MMP2 manual is incorrect. It says that the enable bit I2SCLK1 is on bit 5, but extensive testing has shown that it is actually on bit 21 (listed as reserved). The vendor steadfastly refused to acknowledge that fact despite clear proof ... I note that the android kernel turns on the "reserved" bit along with several others. I further note that the vendor insists, on the one hand, that we must do exactly as the manual says WRT reserved bits, but on the other hand, also says that "the" source code is the best guide - without specifying which of several inconsistent versions of the source code to believe.

(The reason why I switched to the audio PLL is because the vendor pretty much insisted, by refusing to answer audio questions while I was using I2S_SYSCLK.)

I could work around this in OFW - and in fact have tested such a workaround - you just have OFW use I2S_SYSCLK as before. But it would be better to work around it in Linux, because that would probably fix the "sound breaks when OFW volume is 0" problem.

The fix has been pushed to arm-3.0-wip as 53bc7a87f8e74ca60833d97cc0d2173d3fc1ff40

comment:6 Changed 4 years ago by dsd

  • Action Needed changed from diagnose to add to build
  • Component changed from ofw - open firmware to kernel

Thanks for solving this.

One thing we have to be mindful of is that running a new firmware on an old OS (which is most likely to happen after downgrading to an old build) will result in sound not working.

I suggest we not treat that as a problem unless a customer requests a fix, or if it causes a lot of confusion, in which case we could release a new firmware version with the workaround.

comment:7 Changed 4 years ago by Quozl

I'm mindful of it, but as the workaround is to downgrade the firmware or upgrade the kernel, and a downgrade to an old build is usually not done at scale, even if there is a request my reply would be to use Q4D24. I don't see the need for a new firmware version with a workaround.

comment:8 Changed 4 years ago by dsd

  • Cc reubencaron added

We should make reubencaron aware who might be the first to hear about any difficulties caused by this...

comment:9 Changed 4 years ago by dsd

  • Action Needed changed from add to build to test in build

Test in 13.2.0 build 3.

comment:10 Changed 4 years ago by dsd

  • Resolution set to fixed
  • Status changed from new to closed

Tested 13.1.0 build 3 on XO-1.75 (Q4D29), sound is working in Linx.

comment:11 Changed 4 years ago by dsd

that is, 13.2.0 build 3.

Note: See TracTickets for help on using tickets.