Hi Cristian On Tue, 13 Oct 2026 at 01:16, Cristian Ciocaltea <[email protected]> wrote: > > Hi Dave, > > On 10/13/26 1:37 AM, Cristian Ciocaltea wrote: > > Historically, the HSM clock for BCM2835 was fixed at 163.7 MHz. Since > > the pixel clock had to be at least 1% below the HSM clock, it was capped > > at 162 MHz. > > > > Since commit cd4cb49dc5bb ("drm/vc4: hdmi: Adjust HSM clock rate > > depending on pixel rate"), the HSM clock rate is set to pixel clock * > > 101 / 100. For a 165 MHz pixel clock, this gives an HSM rate of 166.65 > > MHz, which, per Dave Stevenson, the hardware can handle without issues. > > > > Increase the max pixel clock to 165 MHz, which matches the maximum TMDS > > character rate of HDMI 1.0 through 1.2. > > It seems this will cause CEC register corruption: > > https://sashiko.dev/#/patchset/[email protected]?part=2 > > We can easily address this by clamping the CEC clock divider to its register > field width: > > - clk_cnt = cec_rate / CEC_CLOCK_FREQ; > + clk_cnt = min_t(unsigned long, cec_rate / CEC_CLOCK_FREQ, > + VC4_HDMI_CEC_DIV_CLK_CNT_MASK >> > + VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT); > > The consequence is that the CEC clock would run slightly faster than the > nominal > 40 kHz, i.e. (165000 × 101/100) / (2^12 - 1) = 40.6959 kHz. > > I think this is still within the CEC bit-timing tolerances and shouldn't cause > any issues. Could you please confirm?
My reading of the CEC spec agrees. All the timings have tolerance of +/- 0.2ms on values up to 4.5ms, so that would allow up to a 4.3% tolerance on frequency. The error from clipping the clock divider is 1.74%, so fairly comfortably within tolerance. It's only video modes with clocks in the range 162-165MHz that will have any inaccuracy, so pretty limited in scope anyway. Working backwards, achieving a 40kHz output with the max divider works out to be a 163.8MHz HSM clock, so that would appear to be why the limit was introduced in the first place. Thanks Dave > Regards, > Cristian > > > > > Suggested-by: Dave Stevenson <[email protected]> > > Signed-off-by: Cristian Ciocaltea <[email protected]> > > --- > > drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > > index 8e4623ccc4f8..e61f1b694dbe 100644 > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > > @@ -1507,7 +1507,7 @@ static void > > vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder, > > * users are able to use pixel clocks closer to HSM's, namely for > > * 1920x1200@60Hz. So it was decided to have leave a 1% margin between > > * both clocks. Which, for RPi0-3 implies a maximum pixel clock of > > - * 162MHz. > > + * 165MHz. > > * > > * Additionally, the AXI clock needs to be at least 25% of > > * pixel clock, but HSM ends up being the limiting factor. > > @@ -3363,7 +3363,7 @@ static const struct vc4_hdmi_variant bcm2835_variant > > = { > > .encoder_type = VC4_ENCODER_TYPE_HDMI0, > > .debugfs_name = "hdmi_regs", > > .card_name = "vc4-hdmi", > > - .max_pixel_clock = 162000000, > > + .max_pixel_clock = HDMI_1_0_TMDS_CHAR_RATE_MAX_HZ, > > .registers = vc4_hdmi_fields, > > .num_registers = ARRAY_SIZE(vc4_hdmi_fields), > > > >
