[Letux-kernel] [PATCH 0/8] Get sound playback working on the Pandora again

Stefan Leichter sle85276 at gmx.de
Sat Jan 8 17:30:31 CET 2022


Hello Grond,

On 07.01.22 23:01, Grond wrote:
> On Fri, Jan 07, 2022 at 09:17:50PM +0100, Stefan Leichter wrote:
>> Hi Grond,
>>
>> On 07.01.22 18:28, Grond wrote:
>>> Hey Stephan.
>>>
>>> I'm pretty sure I know what's causing at least one of the problems.
>>>
>>> On Fri, Jan 07, 2022 at 05:50:34PM +0100, Stefan Leichter wrote:
>>>> Hello Grond,
>>>>
>>>> a late happy new year and thank you for your work.
>>>>
>>>> On 31.12.21 01:41, Grond wrote:
>>>>> Note that these changes only fix playback. Recording sound does not
>>>>> currently work for as yet unknown reasons. However, given the (mind
>>>>> boggling) number of ALSA kcontrols exposed by the TWL4030's sound
>>>>> capture codec, it is likely that there is just a switch that is turned
>>>>> off somewhere.
>>>>
>>>> Today I tried on my 1GHz pandora the new kernel from hns (5.16.0-rc8-letux+) with includes you patches. Did you notice in /var/log/syslog or dmesg output the line:
>>>>
>>>> [   17.557952] omap3pandora-sound omap3pandora-sound: Failed to register sound card: -517
>>>>
>>>
>>> -517 is -EPROBE_DEFER. As Nicolaus pointed out, it just means that the
>>> first attempt to probe the driver failed because one of the components
>>> it depends on wasn't probed yet. However, this should not be considered
>>> a good reason to use dev_err (since it's expected behaviour). Perhaps I
>>> should modify the patch series?
>>>
>>>> This can be the reason for the not working audio input. If you change in soc-core.c line 858 from dev_dbg to dev_err you will see the problem in dmesg:
>>>>
>>>> [   17.246490] omap3pandora-sound omap3pandora-sound: ASoC: codec component pcm1773-codec not found for link PCM1773
>>>>
>>>> One thing was driving me mad. When I login only via ssh aplay -l doesn't show any audio devices. After login on the pandora keyboard the playback device (pcm1773-hifi-0) appears and is usable.
>>>
>>> I have no good explanation for this. Generally speaking, what is the
>>> timing for you logging in via SSH versus the keyboard? If SSH is always
>>> earlier, it may simply be the driver taking a while to load (but I
>>> cannot imagine why that would be).
>>
>> Not exactly sure what you mean with timing, but let me try to explain what I did now:
>>
>> The pandora was started at 20:50. Booting to the console prompt takes about 35 seconds. At 20:55 login via ssh, check for the loaded modules, run aplay, login on the console, second aplay:
>>
>> letux at letux:~$ lsmod | grep -e pandora -e pcm ; aplay -l ; date
>> snd_soc_pcm1773        16384  1
>> pandora_bl             16384  0
>> snd_soc_omap3pandora    16384  0
>> pandora_nub            20480  0
>> aplay: device_list:270: no soundcards found...
>> Fri Jan  7 20:55:32 UTC 2022
>> letux at letux:~$ aplay -l ; date
>> **** List of PLAYBACK Hardware Devices ****
>> card 0: omap3pandora [omap3pandora], device 0: HiFi Out pcm1773-hifi-0 [HiFi Out pcm1773-hifi-0]
>>    Subdevices: 1/1
>>    Subdevice #0: subdevice #0
>> Fri Jan  7 20:55:50 UTC 2022
>> letux at letux:~$
>>
>> I can wait longer between the startup an the ssh login, just suggest a duration.
>>
>> If I first login at the console the playback device will appear directly at the first aplay call after the login, even if I did not wait for five minutes after starting the pandora.
> The reason I mention that it might be a timing issue is that the console
> login is not very well-coupled to the audio driver stack. It seems
> really unlikely that logging in on the console actually *causes* sound
> card probe to succeed. But I would be really interested to see what
> dmesg looks like after the sound card probe has succeeded. Also, if you
> could try compiling a kernel with DYNAMIC_DEBUG enabled, you can see all
> of the ASoC core debug messages, which I've found is really helpful in
> running down the root cause of why the sound card driver isn't loading.
> (I would suggest adding dyndbg="file sound/* +fp" to the kernel command
> line as well.)
>
I don't see anything new in the dmesg output after the console login.

Please find the log of the ssh session (including dmesg output) attached

Regards
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssh.log
Type: text/x-log
Size: 37989 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20220108/08b00a92/attachment-0001.bin>


More information about the Letux-kernel mailing list