search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.11k stars 4.98k forks source link

5.10.63 causes 1000s of lines of errors relating to hdmi-audio-codec hdmi-audio-codec.2.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 #4575

Closed graysky2 closed 1 year ago

graysky2 commented 3 years ago

Describe the bug

  1. When kodi starts, dmesg is polluted with thousands of lines like this: 
    hdmi-audio-codec hdmi-audio-codec.2.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
  2. If I start my RPi4 with the attached TV off, the RPi4 does not detect that an external monitor is connected and the only way to enable HDMI output is to reboot the RPi4 with the TV on.

Downgrading to 5.10.59-1 fixes both issues. There are only 5 lines in dmesg displaying that error. That kernel is based on this commit: https://github.com/raspberrypi/linux/commit/22201d4868f66aa7773d5c4bad7bab1795ee6757

To reproduce

Expected behaviour

  1. dmesg should not be spammed with 1000s of lines
  2. HDMI detection should work regardless of TV on/off state

Actual behaviour

  1. dmesg is spammed with 1000s of lines.
  2. HDMI detection is broken relative to 5.10.59

System Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

Logs If applicable, add the relevant output from dmesg or similar.

Additional context Add any other relevant context for the problem.

lategoodbye commented 3 years ago

I submitted a RFC patch last year, but it wasn't accepted because the issue must be solved differently: https://www.spinics.net/lists/dri-devel/msg284535.html

More recent discussion: https://www.spinics.net/lists/alsa-devel/msg127150.html

graysky2 commented 3 years ago

I find it odd that under the older kernel, I do not see this problem. To me something changed between those two kernel commits. I verified this on a separate RPi4 connected to a different monitor.

I can run a bisect but before I do that work/time I wanted to get some feedback. Thanks.

popcornmix commented 3 years ago

A bisect would be useful. https://github.com/raspberrypi/linux/pull/4538 would be my first guess (although I'm only seeing the usual couple of dmesg entries with a kernel with that in).

graysky2 commented 3 years ago

I will git it a shot but I am having an issue getting the bisect to track the rpi/5.10.y branch. It seems to be using another branch.

% git status
On branch rpi-5.10.y
Your branch is up to date with 'origin/rpi-5.10.y'.

nothing to commit, working tree clean

% git bisect start
% git bisect bad 597cd63b48c6dc3746827504f191744c120fbb4d
% git bisect good 22201d4868f66aa7773d5c4bad7bab1795ee6757
Bisecting: 174 revisions left to test after this (roughly 8 steps)
[8f499a90e7eecafd44e8206a3ab586d024930485] mmc: mmci: stm32: Check when the voltage switch procedure should be done

When I built this commit the boot process froze. Usually I see 4x raspberry pi logos when booting, but this kernel was 4 tux logos. Am I some how jumping branches?

popcornmix commented 3 years ago

Yes, the upstream merge commits (e.g. Linux 5.10.60 do complicate things). You can just do a git bisect --skip for a commit upstream. Or manually check the commits after each Linux 5.10.60 type commit and then bisect between them.

Someone with more knowledge may know a better way.

graysky2 commented 3 years ago

Google has failed me. Running git bisect skip seems to be stepping back one at a time but after 5 itterations, I am still unable to find the hash git bisect wants me to build in the rpi-5.10.y tree. Must be a better way to do this staying on the rpi-5.10.y branch.

pelwell commented 3 years ago

My workaround has been to write a script to revert all of the commits in question, cherry-pick the originals, and bisect through the cherry-picks.

graysky2 commented 3 years ago

@pelwell - Do you have some code you can share for this case?

good: https://github.com/raspberrypi/linux/commit/22201d4868f66aa7773d5c4bad7bab1795ee6757 bad: https://github.com/raspberrypi/linux/commit/597cd63b48c6dc3746827504f191744c120fbb4d

Alternatively, how can I just get an ordered list of the all commits between those two points? I could manually do the bisect with simple checkouts and manually notes.

EDIT: no, this doesn't work either.

% git rev-list 2201981d674d..HEAD|wc -l                        
9119

There are not 9,119 commits between the last-good and HEAD staying on the branch.

graysky2 commented 3 years ago

I updated the first post in this Issue just now to detail further breakage. Note that reverting the PR @popcornmix called out (assuming I did it correctly, see these two patches and provide feedback), did not fix the issue.

0001-Revert-drm-vc4-hdmi-Actually-check-for-the-connector.patch.txt 0002-Revert-drm-probe-helper-Create-a-HPD-IRQ-event-helpe.patch.txt

pelwell commented 3 years ago

There are a few commits in the range that don't want to revert without intervention, but fortunately I think we can ignore them.

Try this:

$ glo --no-merges 22201d4..597cd63 | cut -d' ' -f1 | grep -v -E "(2566c1d|8849a8c)" | xargs -n 1 git revert --no-edit
$ glo --no-merges 22201d4..597cd63 | cut -d' ' -f1 | grep -v -E "(2566c1d|8849a8c)" | tac | xargs -n 1 git cherry-pick

There are 344 commits that have been reverted and reapplied (git branch -vv should show us to be 688 commits ahead of upstream) , so we can:

$ git bisect start
$ git bisect good HEAD~344
$ git bisect bad HEAD
popcornmix commented 3 years ago

glo? Is that a wrapper around git?

pelwell commented 3 years ago

Sorry, yes -- it's muscle memory for me. The full version is:

$ git log --oneline --no-merges 22201d4..597cd63 | cut -d' ' -f1 | grep -v -E "(2566c1d|8849a8c)" | xargs -n 1 git revert --no-edit
$ git log --oneline --no-merges 22201d4..597cd63 | cut -d' ' -f1 | grep -v -E "(2566c1d|8849a8c)" | tac | xargs -n 1 git cherry-pick
graysky2 commented 3 years ago

https://github.com/graysky2/linux-1/tree/try Trying now...

graysky2 commented 3 years ago 
79aec5148d54db32f92da3232325411d5d3a8916 is the first bad commit
commit 79aec5148d54db32f92da3232325411d5d3a8916
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Tue May 11 17:05:11 2021 +0200

    drm/vc4: hdmi: Remove the DDC probing for status detection

Log

% git bisect log
git bisect start
# good: [b4b4599db2e70ac200201de62cc65aeb1e21e0ec] Revert "iio: adc: ti-ads7950: Ensure CS is deasserted after reading channels"
git bisect good b4b4599db2e70ac200201de62cc65aeb1e21e0ec
# bad: [9c080eb267f8a42e11c5def69575d7362503c860] gpio-fsm: Clamp the delay time to zero
git bisect bad 9c080eb267f8a42e11c5def69575d7362503c860
# bad: [fa2d25b0314a9880b6c340d7fb6abaf348167bc3] ovs: clear skb->tstamp in forwarding path
git bisect bad fa2d25b0314a9880b6c340d7fb6abaf348167bc3
# good: [b23bec822620daa5667cc5b421e75e5ab6cc4246] powerpc/smp: Fix OOPS in topology_init()
git bisect good b23bec822620daa5667cc5b421e75e5ab6cc4246
# bad: [a994014c7b08bdc5d00ca643451f66b5c80ee7c8] dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller is not yet available
git bisect bad a994014c7b08bdc5d00ca643451f66b5c80ee7c8
# good: [ce311708d967b4fb51e7780b2deea8448901d2f5] drm/probe-helper: Create a HPD IRQ event helper for a single connector
git bisect good ce311708d967b4fb51e7780b2deea8448901d2f5
# bad: [a0504af09349b0bfcbe386cb88e39e9426dc0578] media: zr364xx: fix memory leaks in probe()
git bisect bad a0504af09349b0bfcbe386cb88e39e9426dc0578
# bad: [2dd6c17c378d951bf9c864d978744fc75534ab57] ath9k: Clear key cache explicitly on disabling hardware
git bisect bad 2dd6c17c378d951bf9c864d978744fc75534ab57
# bad: [79aec5148d54db32f92da3232325411d5d3a8916] drm/vc4: hdmi: Remove the DDC probing for status detection
git bisect bad 79aec5148d54db32f92da3232325411d5d3a8916
# good: [14db98aca2e26b56b42d05785b9b2567f54d1c86] drm/vc4: hdmi: Actually check for the connector status in hotplug
git bisect good 14db98aca2e26b56b42d05785b9b2567f54d1c86
# first bad commit: [79aec5148d54db32f92da3232325411d5d3a8916] drm/vc4: hdmi: Remove the DDC probing for status detection
graysky2 commented 3 years ago

That commit from my branch maps to https://github.com/raspberrypi/linux/commit/17a554471341cabeb583feb02f04eb785d7d9bf8

0001-Revert-drm-vc4-hdmi-Remove-the-DDC-probing-for-statu.patch

When I reverted it from HEAD, the bug is resolved:

  1. No more spamming dmseg (only 5 entries).
  2. TV is detected even though it is off when booting.
% uname -a
Linux treetop 5.10.63-3-ARCH #1 SMP PREEMPT Sat Sep 11 13:31:02 EDT 2021 aarch64 GNU/Linux
% dmesg | tail
[  +0.000026] random: 7 urandom warning(s) missed due to ratelimiting
[  +0.027801] Console: switching to colour frame buffer device 240x67
[  +0.020980] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
[  +3.515289] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  +0.000078] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  +3.593794] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[  +0.007797] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[  +0.004113] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[  +0.001735] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[  +0.001877] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
popcornmix commented 3 years ago

Ping @mripard

mripard commented 3 years ago

Do you have a prebuilt image (or some way to generate one) I can grab to reproduce this bug ?

graysky2 commented 3 years ago

I don't... it's just Arch ARM + kodi-rpi package. If it is helpful for you, I could tar it up and you could just extract that tarball to prepared SD card. Let me know.

popcornmix commented 3 years ago

@graysky2 I'm not seeing this issue with LibreELEC running kodi on 5.10.63. So there may be something unique to the specific arch versions of kodi/kernel, some settings you've selected within kodi or your display/edid. Do you have the ability to upload the whole sdcard (e.g. dd and gzip)? Otherwise instructions starting from a clean Arch install that are confirmed to show the problem would be useful.

I assume you have one hdmi display connected? And to HDMI0 (next to power)? Are you using 4kp60?

graysky2 commented 3 years ago

I am happy to spin up a fresh instance and create an image. I never used dd to do it but will google it.

Yes, one HDMI connected to HDMI0 but not 4kp60. The monitor is 1080p HDTV.

graysky2 commented 3 years ago

As I test, I took the uSD card from the RPi4 connected to the HDTV on which I see this bug and moved it to another RPi4 which is connected to a different monitor, all other settings were the same, I do not see the bug.

When I put the uSD back into the original RPi4 connected to the HDTV and boot, I see the bug.

This is consistent with @popcornmix experience and hypothesis that it is my-setup-specific. Very annoying.

popcornmix commented 3 years ago

If it's display specific I'd expect it's related to edid or hotplug behaviour. Can you use the edid from good display on bad (and/or vice versa) and see if issue follows the edid? (e.g. using drm.edid_firmware in cmdline.txt).

6by9 commented 3 years ago

Or capture the EDID and post it here for analysis and testing with.

graysky2 commented 3 years ago

Yes and Yes. Just need some time.

mripard commented 3 years ago

One thing worth testing too would be to double-check the cables and connectors. Before that patch was merged, it was relying on fetching the EDID as the primary mean to detect whether the display was connected or not. If this doesn't work anymore, it hints at the fact that the hotplug detect line stays (or is read) low for some reason

graysky2 commented 3 years ago

@mripard - Connections are tight. Is there a test to verify that fetching was successful?

mripard commented 3 years ago

I'd try to swap things around :)

You have the setup A with a Pi4, cable and TV that doesn't work, and a setup B with a Pi4, cable and monitor that works.

I'd try to test Pi4 B with the cable B on the display A. If it still doesn't work, it's an issue related to the TV. If it works, try the Pi4 B with the cable A on the display A. If it doesn't work, the issue is the cable. If it works, the issue is the Pi4 A.

graysky2 commented 3 years ago

I extracted the EDID from the monitor that did not exhibit the bug and placed it on the setup exhibiting the bug. Booting with it fixes the bug.

Here is the EDID from the "good" monitor:

# base64 /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid       
AP///////wBBDI/BFAYAABkdAQOAPCJ4KmehpVVNoicOUFS/7wDRwLMAlQCBgIFAgcABAQEBTdAA
oPBwPoAwIDUAVVAhAAAao2YAoPBwH4AwIDUAVVAhAAAaAAAA/ABQSEwgMjc2RThWCiAgAAAA/QAX
UB6gPAAKICAgICAgAQsCAzPxTJAEAx8TARJdXl9gYSMJBweDAQAAbQMMABAAOHggAGABAgNn2F3E
AXiAA+MPAAxWXgCgoKApUDAgNQBVUCEAAB4COoAYcTgtQFgsRQBVUCEAAB4BHQByUdAeIG4oVQBV
UCEAAB5NbICgcHA+gDAgOgBVUCEAABoAAAAATg==

Here is the EDID extracted from the HDTV causing the bug:

# base64 /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid
AP///////wAebQEAAQEBAQEZAQOAoFp4Cu6Ro1RMmSYPUFShCAAxQEVAYUBxQIGAAQEBAQEBAjqA
GHE4LUBYLEUAQIRjAAAeZiFQsFEAGzBAcDYAQIRjAAAeAAAA/QA6Ph5TEAAKICAgICAgAAAA/ABM
RyBUVgogICAgICAgAeYCAxnxSJAiIAUEAwIBIwlXB2cDDAAgAIAeAjqAGHE4LUBYLAQFQIRjAAAe
AR2AGHEcFiBYLCUAQIRjAACeAR0AclHQHiBuKFUAQIRjAAAejArQiiDgLRAQPpYAQIRjAAAYAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+A==

EDIT: I should mention that booting with the EDID "good" from the other monitor renders the TV not outputing anything. It indicates "invalid mode."

graysky2 commented 3 years ago

@mripard @popcornmix - I think the experiment swapping the EDIDs was a bit of a red herring. Turns out that if I simply extract the EDID from the HDTV and load it via /boot/cmdline.txt, I am able to run a kernel based on https://github.com/raspberrypi/linux/commit/3cae59f7aeffaf19313022eac4a92cb6cf3081ee without reverting the commit I found from the bisect. Could that mean something is wrong with EDID detection somehow?

For the record, on the RPi4 setup that originally triggered this bug:

# cp /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid /lib/firmware/edid.dat
# cat /boot/cmdline.txt 
root=/dev/mmcblk0p2 rw rootwait console=serial0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 drm.edid_firmware=edid.dat video=HDMI-A-1:D
popcornmix commented 3 years ago

I think the "D" at end of video= forces hotplug, which I think you are saying fixes the issue? (I'm a bit confused by your final comment that suggests the pi4 that triggered the bug has the edid= and video= bits on cmdline. Or are you saying it no longer has the bug with those added?) Try without the edid= part.

graysky2 commented 3 years ago

Or are you saying it no longer has the bug with those added?)

Correct.

Try without the edid= part.

Interesting... it appears that edid= part is not in fact needed at all. This works:

root=/dev/mmcblk0p2 rw rootwait console=serial0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 video=HDMI-A-1:D
popcornmix commented 3 years ago

I believe the video=HDMI-A-1:D is effectively the same as hdmi_force_hotplug=1. i.e. hotplug is ignored and assumed to always be asserted. The fact this makes a difference when you have hotplug connected (and you would imagine asserted) suggests something is funny with the signal. e.g. it's either deasserted or intermittent.

I've just tested LE here with video=HDMI-A-1:D and hdmi unplugged (both from boot and after booting) and it doesn't seem to provoke floods of the ASoC: error at snd_soc_dai_startup. I have 6 from hdmi 0 and 2 from hdmi 1. I don't get extra ones on plug/unplug.

graysky2 commented 3 years ago

I believe the video=HDMI-A-1:D is effectively the same as hdmi_force_hotplug=1. i.e. hotplug is ignored and assumed to always be asserted.

I removed video=HDMI-A-1:D from /boot/cmdline.txt and added hdmi_force_hotplug=1 to /boot/config.txt. Upon rebooting, the bug is triggered.

# cat /boot/config.txt
hdmi_force_hotplug=1
dtoverlay=vc4-kms-v3d,cma-512
dtoverlay=rpivid-v4l2
dtoverlay=
disable_overscan=1
disable_fw_kms_setup=1

# cat /boot/cmdline.txt 
root=/dev/mmcblk0p2 rw rootwait console=serial0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200

The bug is not triggered if I keep video=HDMI-A-1:D in /boot/cmdline.txt:

# cat /boot/config.txt
dtoverlay=vc4-kms-v3d,cma-512
dtoverlay=rpivid-v4l2
dtoverlay=
disable_overscan=1
disable_fw_kms_setup=1

# cat /boot/cmdline.txt 
root=/dev/mmcblk0p2 rw rootwait console=serial0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 video=HDMI-A-1:D
popcornmix commented 3 years ago

I removed video=HDMI-A-1:D from /boot/cmdline.txt and added hdmi_force_hotplug=1 to /boot/config.txt. Upon rebooting, the bug is triggered.

I meant video=HDMI-A-1:D when using kms is comparable to hdmi_force_hotplug=1 when not using kms. kms doesn't see config.txt entries.

graysky2 commented 3 years ago

I see. I am glad that I can suppress (fix?) the bug with the addition of video=HDMI-A-1:D to /boot/cmdline.txt... is the bisect I did useful at all in figuring out the root cause of this?

mcprat commented 2 years ago

Hi, I can confirm this issue which is also happening to me, however it is not thousands of lines, its about less than 50

I verified that the Fake KMS driver works fine, or at least the old way, where turning off monitors has no effect.

My situation is a little different so I wanted to explain my experience in full detail in hopes that its helpful. I might not be useful for debugging as I have never played with the kernel for the Pi 4 before.

for context my Pi 4 is set up like so:

I upgraded to 5.10.63 from (I think) 5.10.17 from early this year using sudo apt-get full-upgrade

The first reboot after upgrading, everything seemed fine. One of the monitors turns itself off after enough time with no signal, we commonly have both monitors off at the end of the day. Turning them back on, or turning only one of them off is when unusual behavior is noticed.

for me during a normal boot, both monitors come up with native resolution, but when I login the desktop environment switches to KDE, where I have monitor 1 set to 768p, so that both are the same resolution.

It almost seems like a new feature, that the desktop virtual space adapts to whichever monitor is on, but has issues in how its currently implemented. If I toggle one monitor at a time after booting with both on, it seems to adjust itself fine, but......

If both monitors are turned off, and then back on, monitor 1 goes back to its native resolution, not "remembering" that I had set it to 768p. re-applying the intended resolution fixes that. Sometimes the virtual desktop spaces end up overlapping, which I also have to re-adjust. (probably related to the resolution change, as the pixel offset for the second virtual desktop space seems to be the same)

If I boot with only monitor 1 on, I get the error lines described here, about 30-50 times, and its worth noting that audio still works (when turning monitor 2 on after boot)

[   27.815661] hdmi-audio-codec hdmi-audio-codec.2.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19

if I boot with only monitor 2 on, I get a different set of errors, and this sequence repeats about 20 times in the same second and then stops (ending up about the same length as the other case). I also seem to get this when toggling between monitors. Note that audio still works after this as well.

[  485.748846] hdmi-audio-codec hdmi-audio-codec.2.auto: Not able to map channels to speakers (-22)
[  485.748857] hdmi-audio-codec hdmi-audio-codec.2.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
[  485.748865]  MAI: ASoC: DAI prepare error: -22

if I boot headless, and then turn them on, there will be no graphics whatsoever, and both monitors show "no signal". However, I can still use Ctrl + Alt + F1 in order to get console on both screens, going back to the GUI with Ctrl + Alt + F7 gives me "no signal" again. But if I boot with at least 1 monitor on, I can turn the other on and it will get detected and display as expected, including the automatic adjustment of the virtual desktop space (except it might be native resolution instead of what I set it as).

Also, when booting headless (both monitors off), the ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 error is in dmesg exactly one time.

If I were to connect to the VNC server when it is headless, I will get a virtual desktop at minimum resolution which is not associated with any of the physical displays, as they would still show "no signal".

Toggling any of the monitors changes the virtual desktop space, and this is equally reflected in a VNC connection, except if I boot headless at first like I described.

I'm fine with using FKMS driver for now, but it would be nice to force hotplug like you have described for both my monitors. Is that addition to kernel command line for all monitors, or is "HDMI-A-1" a tag of some kind?

any documentation for video=??

popcornmix commented 2 years ago

any documentation for video=??

This is standard linux/kms, rather than pi specific. Here is a good description: https://wiki.archlinux.org/title/Kernel_mode_setting

If you are trying to boot with monitor powered off (and the monitor does not support reading the edid in this state) then you need to provide a file based edid, so the kernel and applications know what resolutions and features are supported. The link describes this with the drm.edid_firmware cmdline.txt option.

mcprat commented 2 years ago

Thanks for the link

I tried providing the edid for each monitor from a file, placing them in /usr/lib/firmware/edid like the wiki example It only seems to work for HDMI-A-1, get failure to load firmware for the second one giving up on that for now....

Right now the only change is adding to the end of cmdline video=HDMI-A-1:D video=HDMI-A-2:D and now I have expected behavior for both monitors: it doesn't matter which one is on, virtual desktop space is consistent again, and both display always detected even if they are off at boot time. There is also new kernel messages that indicates the connector is "forced on"

$ dmesg | grep drm
[   13.980794] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
[   14.697671] fb0: switching to vc4drmfb from simple
[   14.777074] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[   14.781084] [drm] forcing HDMI-A-1 connector on
[   14.964580] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[   14.964738] [drm] forcing HDMI-A-1 connector on
[   14.975036] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[   14.975248] [drm] forcing HDMI-A-2 connector on
[   15.050487] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[   15.050664] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[   15.050798] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[   15.050919] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[   15.051058] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[   15.051160] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[   15.051277] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[   15.052715] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 1
[   15.153178] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device

When I boot with all monitors on, no errors whatsoever, however if I boot with monitors off, in kernel log I get these messages looped 20 times like I said before

[   97.048640] hdmi-audio-codec hdmi-audio-codec.2.auto: Not able to map channels to speakers (-22)
[   97.048656] hdmi-audio-codec hdmi-audio-codec.2.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
[   97.048665]  MAI: ASoC: DAI prepare error: -22

One last strange thing, now that I have this change in cmdline, the first monitor changes mode to native 1080p when I change from desktops to TTY with Ctrl Alt F1, and changes mode again back to 768p when I go back to the desktop. With FKMS this was normal for boot and login, but not for TTY. There is also a noticeable overscan.

I have some lines in config.txt that I believe handled this for FKMS, but if I understood what I read here correctly, the KMS driver does not read from config.txt at all, so I would have to use edid= or video= in kernel command line now to fix overscan?

[EDID=KTC-42_TV]
hdmi_group=2
hdmi_mode=39
disable_overscan=1

I don't remember if mode changes between TTY and desktops on FKMS...will have to double check...

popcornmix commented 2 years ago

You can add to the end of the video= directive ,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48 to compensate for overscan.

mcprat commented 2 years ago

Thanks again

I found official docs for video= in case others are looking for it

https://www.kernel.org/doc/html/v5.10/fb/modedb.html

ckujau commented 2 years ago

This is still happening on an RPi 3B running Linux 5.10.78-2-osmc, with the HDMI cable attached, but the monitor switched off:

$ cat /proc/cmdline 
coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1  vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  root=/dev/mmcblk0p2 rootfstype=ext4 rootwait quiet osmcdev=rbp2

$ dmesg
[....]
cec-vc4: message 10 timed out
hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
jc-kynesim commented 2 years ago

Did this ever get resolved / understood? I get the same errors shortly after boot (maybe X startup?) and at some later time that I haven't traced. I can use hdmi audio in X but it seems to fail if I shut down X though I can quite plausibly believe that is misconfiguration on my part. I'm running Pi via KVM switch to 1920x1200 monitor (which does support audio). Running current (rpi-update) kernel.

[ 39.363725] hdmi-audio-codec hdmi-audio-codec.2.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 [ 39.363750] MAI: soc_pcm_open() failed (-19)

popcornmix commented 2 years ago

@jc-kynesim does video=HDMI-A-1:D in cmdline.txt avoid the issue for you?

I think if you are just getting a small number of those messages, then it's a known harmless issue. If you get 1000s or it's affecting ability to drive audio then there may be a bigger issue.

If you can drive audio from X and not outside X then I'd expect this is a higher level issue (e.g. pulse audio related).

jc-kynesim commented 2 years ago

No that line doesn't appear to change anything. It looks like I get the error (6 times) whenever I log into the console session (not running X by default in this case). I'd certainly believe pulse as the cause of everything bad. But when having audio issues and dmesg spits out something audio related it doesn't seen unreasonable to wonder if that is the problem.

popcornmix commented 2 years ago

This is what I see on a "working fine" system:

LibreELEC:~ # dmesg | grep snd_soc_dai_startup
[   12.341699] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[   12.342307] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[   12.350398] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[  168.984217] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[  192.747785] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[ 6310.170230] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
jc-kynesim commented 2 years ago

Fair enough - then its just that I have a few more (for whatever reason) than you do. It would be nice if we had none as they are somewhat distracting, but it is unlikely to be the cause of any of my woes.

thewriteway commented 2 years ago

Raspberry Pi 4 Model B Rev 1.5 Description: Debian GNU/Linux 11 (bullseye) Linux version 5.15.56-v8+ (dom@buildbot) (aarch64-linux-gnu-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) 1575 SMP PREEMPT Fri Jul 22 20:31:26 BST 2022

Standard OS deployment build with only network interface attached and the error still occur:

17.323700] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 [ 17.323772] MAI: soc_pcm_open() failed (-19) [ 17.324610] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 [ 17.324636] MAI: soc_pcm_open() failed (-19) [ 17.325311] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 [ 17.325337] MAI: soc_pcm_open() failed (-19) [ 17.332351] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 [ 17.332828] MAI: soc_pcm_open() failed (-19) [ 17.333352] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 [ 17.335332] MAI: soc_pcm_open() failed (-19) [ 17.336048] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 [ 17.336155] MAI: soc_pcm_open() failed (-19)

popcornmix commented 1 year ago

Latest rpi-update kernel (and rpi-5.15/6.0/6.1 trees) should avoid this error spam. Please report if issue is resolved.

acavalin commented 1 year ago

Latest rpi-update kernel (and rpi-5.15/6.0/6.1 trees) should avoid this error spam. Please report if issue is resolved.

I currently still have those errors.

dmesg -T

...
[Tue Dec  6 21:40:56 2022] hdmi-audio-codec hdmi-audio-codec.0.auto: Not able to map channels to speakers (-22)
[Tue Dec  6 21:40:56 2022] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
[Tue Dec  6 21:40:56 2022]  MAI: ASoC: soc_pcm_prepare() failed (-22)
[Tue Dec  6 21:40:56 2022] hdmi-audio-codec hdmi-audio-codec.0.auto: Not able to map channels to speakers (-22)
[Tue Dec  6 21:40:56 2022] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
[Tue Dec  6 21:40:56 2022]  MAI: ASoC: soc_pcm_prepare() failed (-22)
[Tue Dec  6 21:40:56 2022] hdmi-audio-codec hdmi-audio-codec.0.auto: Not able to map channels to speakers (-22)
[Tue Dec  6 21:40:56 2022] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
[Tue Dec  6 21:40:56 2022]  MAI: ASoC: soc_pcm_prepare() failed (-22)
[Tue Dec  6 21:40:56 2022] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[Tue Dec  6 21:40:56 2022]  MAI: soc_pcm_open() failed (-19)
[Tue Dec  6 21:40:56 2022] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[Tue Dec  6 21:40:56 2022]  MAI: soc_pcm_open() failed (-19)
[Tue Dec  6 21:40:56 2022] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[Tue Dec  6 21:40:56 2022]  MAI: soc_pcm_open() failed (-19)
...

I have a tv connected via hdmi but I don't use its speakers nor the output jack onboard, I use instead an USB PCM2704 for a better audio quality.

I have dtparam=audio=on in /boot/config/txt and this configuration in /etc/modprobe.d/local-audio.conf for reordering sound card:

# https://alsa.opensrc.org/MultipleCards#Reordering_the_driver_for_a_particular_card
#   08bb:27c4 Texas Instruments PCM2704C stereo audio DAC
#   1395:0025 Sennheiser Communications Headset [PC 8]
#   046d:0836 Logitech webcam mic
#options snd_bcm2835  enable_hdmi=0 enable_headphones=0  ## TAKES SLOTS 1 + 2,3 = HDMI[1,2]
options snd-usb-audio index=3,4,5 vid=0x08bb,0x1395,0x046d pid=0x27c4,0x0025,0x0836

cat /proc/version

Linux version 5.15.76-v7l+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1597 SMP Fri Nov 4 12:14:58 GMT 2022

uptime

 23:01:24 up 16 days,  4:25, 15 users,  load average: 1.32, 1.50, 1.49

cat /proc/device-tree/model

Raspberry Pi 4 Model B Rev 1.1

lsb_release -a

No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 11 (bullseye)
Release:    11
Codename:   bullseye

vcgencmd version

Oct 26 2022 11:09:05 
Copyright (c) 2012 Broadcom
version c72ad6b26ff40c91ef776b847436094ee63fabee (clean) (release) (start)

sudo rpi-eeprom-update -a

*** INSTALLING EEPROM UPDATES ***

BOOTLOADER: update available
   CURRENT: Tue 26 Apr 2022 10:24:28 AM UTC (1650968668)
    LATEST: Fri 25 Nov 2022 10:54:13 AM UTC (1669373653)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Dedicated VL805 EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1
   CURRENT: Tue 26 Apr 2022 10:24:28 AM UTC (1650968668)
    UPDATE: Fri 25 Nov 2022 10:54:13 AM UTC (1669373653)
    BOOTFS: /boot
Using recovery.bin for EEPROM update

EEPROM updates pending. Please reboot to apply the update.
To cancel a pending update run "sudo rpi-eeprom-update -r".
popcornmix commented 1 year ago

@acavalin

Latest rpi-update kernel (and rpi-5.15/6.0/6.1 trees) should avoid this error spam.

Linux version 5.15.76-v7l+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1597 SMP Fri Nov 4 12:14:58 GMT 2022

That's not latest rpi-update kernel (which you need to run rpi-update for). That version should report: Linux version 5.15.81-v7l+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1604 SMP Tue Dec 6 16:41:10 GMT 2022