On Mon, 2020-03-16 at 13:57 +0000, Dave Stevenson wrote: > Hi Stefan and Nicolas > > Checking the docs it does state the restriction that Eric quotes. > > HDMI Core Clock (state machine clock) > Most of the HDMI logic operates on that clock. It > is asynchronous to system core clock and pixel > clock. Source for this clock can be chosen from > various PLLs in the chip. See CPR Manager for > details. > > This clock is also used for clocking pixel valve > when HDMI peripheral is used. See Pixel Valve > for details.axi_clock >= hdmi_core_clock > 108% of > pixel_clock. > > > The default max pixel clock from the firmware side is 162MHz. > > In the firmware source we have a comment > // HDMI state machine clock must be faster than pixel clock - > infinitessimally faster tested in simulation. > // Otherwise, exact value is unimportant - for HDMI operation. > // hdmi state machine clock now derived from PLLC_PER (typ > 500MHz, see relevant platform.c). > // > // However, CEC bit clock is derived from the HSM clock, and > the (programmable) CEC timing table > // is configured for a 40.00kHz CEC clock. > const unsigned margin = 1*1000*1000; > unsigned min_hsm_clock = margin + timings->pixel_freq; > const unsigned max_hsm_clock_for_cec = max(163682864, > hdmi_pixel_freq_limit); > > unsigned hdmi_state_machine_clock = max_hsm_clock_for_cec; > > So it adds 1MHz to the pixel clock for min_hsm_clock, but then doesn't > use the value. > Unless you do request a higher hdmi_pixel_freq_limit then the HSM is > running at the same 163.68MHz that Eric's driver hard codes, and our > max pixel clock is 162MHz. > Keeping it a fixed value makes sorting the divider for CEC easier. > > Just adopting a 162MHz limit with a suitable comment is probably the > most sensible move here, and Maxime's patches can pick up the same > value. I agree with Dave. Moreover, this was initially introduced to fix resolution negotiations with 4k devices, which use higher pixel clocks than HSM_CLOCK_FREQ. I've been reviewing common HDMI resolutions and 1200p60 seems to be the one closer to RPi's HSM limitations (as far as widely used aspect ratios are concerned). So I can't image how setting a smaller than HSM_CLOCK_FREQ limit here is going to break anything. That said I'm no expert in this area. Stefan, any opinions? Feel like sending a patch? :) Regards, Nicolas