Allwinner H3: Orange Pi PC CEC degraded for SONY TV in 11.0 and 12.0-devel from working perfectly in 10.X

ds000 · April 2, 2023 at 8:43 PM

The Allwinner H3 support on the Orange Pi PC matured a lot over the years, appreciate that! Unfortunately the once perfectly working CEC control somehow degraded in newer versions. I checked the older 10.X standard image available for direct download - working like a charm. In 11.0 and the development branch it is really sluggish for SONY KDL50W805B (works perfect for some older SAMSUNG model):

In many cases it switches the TV (SONY FullHD, 5y) on and switches to the proper HDMI
The message that the CEC adapter got recognized takes longer to appear compared to 10.X version (in kodi main screen)
Sometimes the Orange Pi reacts to key presses on the TV remote, often not. Usually, double presses do not get recognized. If running for a while, nothing happens any more
When switching off kodi and getting down to the commandline (cec-ctl) it won't react as well
I checked CPU frequencies and scaling governors if they could have an impact on that - no changes in behavior

Other devices like a Pine Rock64 work with the newest version without problems.

From cec-ctl I get (kodi stopped to avoid blocking of the device):

Code

LibreELEC:~ # cec-ctl -d/dev/cec0 --to 0 --standby

Driver Info:

       Driver Name                : sun8i-dw-hdmi
       Adapter Name               : dw_hdmi
       Capabilities               : 0x0000010e
               Logical Addresses
               Transmit
               Passthrough
               Connector Info
       Driver version             : 6.1.19
       Available Logical Addresses: 4
       DRM Connector Info         : card 0, connector 51
       Physical Address           : 4.0.0.0
       Logical Address Mask       : 0x0100
       CEC Version                : 2.0
       Vendor ID                  : 0x000c03 (HDMI)
       OSD Name                   : 'Playback'
       Logical Addresses          : 1 (Allow RC Passthrough)

         Logical Address          : 8 (Playback Device 2)
           Primary Device Type    : Playback
           Logical Address Type   : Playback
           All Device Types       : Playback
           RC TV Profile          : None
           Device Features        :
               None

Transmit from Playback Device 2 to TV (8 to 0):
STANDBY (0x36)
       Sequence: 150 Tx Timestamp: 860.150555s
       Tx, Not Acknowledged (4), Max Retries

Display More

I can provide the kodi debug messages for CEC, but they pretty much say the same as for the command line tool.

I checked for differences in the kernel code for CEC, didn't see much changes here from the kernel used in 10.X and the latest ones (I'm not an expert though). I've no idea what might influence the CEC implementation showing such effects Any ideas where to look for a solution/fix?

I'd like to do some minor modifications to the image and thus compile the package by my self. Works perfectly for 11.0 and the latest stuff, but not for 10.X any more.

Thank you!

**jernej** · April 15, 2023 at 12:37 PM

I have no idea what could be wrong with CEC. As you said, not much changed. Ideally, you should try to bisect changes and figured out which PR caused the issue. Most likely it will be a kernel update.

You can check if changing board name to "xunlong,orangepi-pc" at https://github.com/LibreELEC/Libr…r-H3.patch#L191 mitigates the issue.

ds000 · April 16, 2023 at 2:41 PM

Hi! Thank you for the pointer! But sorry, I'm a bit lost here: Checked the build directory, the patch you name got applied for the kernel. How (where) can I change the board name as you indicate (doing it for making the image results in "invalid choice")?

**jernej** · April 16, 2023 at 3:08 PM

Edit the patch (you can do that directly, just replace any board name with yours), build the image and update your current system with it.

If done properly, you should see different CEC driver name.

ds000 · April 16, 2023 at 4:19 PM

Wow, cool! Replaced *pc-plus with *pc (wondering why that board is not listed), recompiled, restarted. That fixed the problem Thanks a lot!!

**jernej** · April 16, 2023 at 5:44 PM

Well, I'm glad it works for you, but that's just workaround. It uses software implementation of CEC instead of HW. It would be great to figure what's wrong.

ds000 · April 16, 2023 at 9:56 PM

I've got only a rough understanding of CEC, so no idea what is hardware/software doing in here: How could I help? I've got two working devices on that particular TV: Pine64 (RK3328 SoC) and an older ODRIOD C2 (Amlogic 905). All three devices work properly with the named Samsung without flaw.

**jernej** · April 18, 2023 at 6:05 AM

difference is only if CEC protocol is completely implemented in software (algorithm in kernel determines when pin goes to 1 or 0, determined by timer) or in hardware (driver only reads what message was received or sends one out). Obviously, you want hardware to do as much as possible, as that leaves CPU to do better things. Also, time sensitive events, like when pin has to go to 1 or 0, are completely done in hardware and thus not dependent on CPU load which might introduce some lag.

So, it's interesting to me that software implementation works better than hardware. Usually, it's other way around. Only explanation for that is 32k clock accuracy, which is used by HW CEC implementation for timing events. But I don't see a reason why that would be a problem. Maybe you can confirm that indeed dedicated crystal is used by executing devmem 0x01f00004 w. It should have value 1.

Best way to determine what happened would be to first find PR on github which broke HW CEC. That could be done via git bisect.

ds000 · February 7, 2024 at 8:47 PM

I was distracted with other stuff and boards for a while: Came back to the Orange Pi PC. The new images work really great. Unfortunately the patch for software CEC does not work any more, running the build linux throws a message that it assumes the patch was already applied. Same state with the Sony (non-working) and Samsung TVs like before, but without the mitigation option.

**jernej** · February 8, 2024 at 12:30 PM

Provide your updated patch and I can take a look.

ds000 · February 9, 2024 at 12:31 PM

I just took the patch from an earlier kernel (which fixed the aforementioned problem):

Diff

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 
From: Jernej Skrabec <[email protected]> 
Date: Mon, 11 Oct 2021 20:13:41 +0200 
Subject: [PATCH] HACK: SW CEC implementation for H3 

Many H3 boards lack 32768 Hz external oscillator, so internal RC is used 
instead. However, it's too unstable for CEC. Use SW implementation 
instead. That makes it usable, albeit sensitive to cpufreq changes. 

Signed-off-by: Jernej Skrabec <[email protected]> 
--- 
drivers/gpu/drm/sun4i/Kconfig          |  2 + 
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  | 13 ++++ 
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 83 +++++++++++++++++++++++++- 
3 files changed, 96 insertions(+), 2 deletions(-) 

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig 
index 5755f0432e77..b93eb2fb52ce 100644 
--- a/drivers/gpu/drm/sun4i/Kconfig 
+++ b/drivers/gpu/drm/sun4i/Kconfig 
@@ -56,6 +56,8 @@ config DRM_SUN8I_DW_HDMI 
       tristate "Support for Allwinner version of DesignWare HDMI" 
       depends on DRM_SUN4I 
       select DRM_DW_HDMI 
+       select CEC_CORE 
+       select CEC_PIN 
       help 
         Choose this option if you have an Allwinner SoC with the 
         DesignWare HDMI controller with custom HDMI PHY. If M is 
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h 
index bffe1b9cd3dc..61c97619cba1 100644 
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h 
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h 
@@ -13,6 +13,8 @@

Display More

maybe, this was not the brightest idea

**jernej** · February 9, 2024 at 12:34 PM

No, you have to modify patch again, since patches are rebased from time to time, so they can be applied on newer versions.

ds000 · February 12, 2024 at 9:39 PM

It looks quite confusing: The first part of the patch is (already) applied and visible in the kernel sources, later stuff is missing at all (the to be replaced stuff as well). I have to look deeper into that ...