[Bug?] CEC / 4K TV / Mode 87

[johnjore]

I have a 4K TV where CEC works fine in 1080p mode with these settings in config.txt:

# 1080p
hdmi_group=1
hdmi_mode=16

In 4K / Mode 87, CEC does not work:

hdmi_group=2
hdmi_mode=87
hdmi_cvt 3840 2160 24
hdmi_pixel_freq_limit=400000000
max_framebuffer_width=3840
max_framebuffer_height=2160

The TV does not appear when scanning for CEC devices. I dont appear to be the only one, see Pulse-Eight/libcec#381. As CEC works with a standard resolution, but not a custom one, I suspect, the hardware elements are ok (TV, HDMI cable etc), but that custom mode 87 somehow does not have CEC enabled as the only changes are the entries in config.txt and a reboot?

Bug? By design?

Are there any logs I can provide or additional debug information to see where / what the issue is?

TV is a Toshiba 49U5766DB and the Raspberry Pi is a Model 1 B (One of the first ones with the (not used) yellow analog TV output.

I've also run rpi-update to update to the latest available firmware.

[bvandergiessen]

I'm also having this issue (with a Panasonic and a Philips), and after some probing, it seems to be due purely to the maximum pixel frequency - the 'overclocking' of the pixel clock. Apparently the standard clock frequency is 163,682,864 Hz, and when I set higher frequencies in /boot/config.txt, like

hdmi_pixel_freq_limit=175000000

CEC communication with the tv's starts to break down soon. (The presence of custom modes doesn't make a difference.) The Panasonic starts having difficulty around 175 MHz (7% overclocked), and the Philips even earlier.

Of course pixel clock overclocking is "untested and unsupported", so we can't expect it to be flawless. But I wonder how difficult a fix would be. Maybe the CEC messaging is timed by the pixel clock, and it just gets too fast for the tv to detect. Could the speed with respect to the pixel clock easily be halved, so we can set the pixel clock to 327.4 MHz and have CEC working as well? Or can CEC speed be made more 'absolute', not expressed as a fixed number of pixel clock cycles per CEC bit?

[JamesH65]

@popcornmix Any thoughts on this? Or close?

[popcornmix]

This is a side effect of "untested and unsupported".
The HDMI state machine clock needs to be at least as high as pixel clock (hdmi_pixel_freq_limit).
And the CEC bit clock is derived from the HDMI state machine clock.

So I think overclocking the pixel clock results in overclocking the CEC clock.

Following the code, we do have enabled CEC_USE_FIXED_VALUE_DIVIDER enabled, and possibly disabling that will produce a divider that handles the unexpected frequency better.

I don't have a 4K display with CEC support, so can't test this but here is a test firmware if @bvandergiessen wants to try it.
https://drive.google.com/uc?id=1zmI8zgDRRLt3vp0BCa303C_TofHG_scQ&export=download

[bvandergiessen]

I tested that version of the firmware, and it didn't make a difference (still doesn't work).

[bvandergiessen]

My understanding is that the source code is not available (read-only) to regular users - so we can't go hunting for other parameters that may play a role in this. Is that a correct assumption?

[JamesH65]

Yes, the code that drives it all is in the closed source firmware. Not sure if there is a mailbox call that could be used to set parameters on config.txt, might be worth thinking about.

[bvandergiessen]

But @popcornmix if you disable CEC_USE_FIXED_VALUE_DIVIDER, does the firmware then calculate a value divider? Or is that not implemented?

[popcornmix]

The code looks like:

//Some number between the HDMI state machine clock frequency for 720p and 1080p
//Does not matter if the two sets of dividers are the same
#define CEC_HSM_CLK_CUT_OFF 120000000
   const uint32_t cec_bit_time = 25000; //desired CEC bit timer period in ns
   static const uint32_t low_divider    = 2500-1; // Period = 25us, exactly (Was 24.996923us)
   static const uint32_t high_divider   = 4092-1; // Period = 24.9995625 us (Was 24.996923us)
   //We aim to get the CEC clock period to be 25us
#ifdef CEC_USE_FIXED_VALUE_DIVIDER
   uint32_t divider = (hsm_clk >= CEC_HSM_CLK_CUT_OFF) ? high_divider : low_divider;
#else
   uint32_t divider = (uint32_t)((((uint64_t) (hsm_clk) * cec_bit_time) + 500000000LL) / (1000000000LL));
#endif

So it looks like the fixed code just handles 720p and 1080p accurately and other state machine clocks will be scaled.
It looks like the non-fixed case should be getting this right, but I didn't write this code.

divider seems to be a 12-bit number, so I think that gives a limit of 163MHz for the state machine clock.

So, you either use a fixed divisor which means CEC is clocked too fast when pixel clock is overclocked, or you try to use a variable divisor which overflows the bits in the divisor register, resulting in too high a CEC clock. I'm not sure this is something the hardware can support.

[bvandergiessen]

Thanks, that might explain it. So the way divider is used is more or less implemented in hardware, where it seems to occupy a 12-bit register, right?

[popcornmix]

Yes, the divider register is limited to 12-bits in hardware.