Re: [PATCH v2 2/8] drm/vc4: hdmi: Bump BCM2835 max pixel clock to 165 MHz

[Dave Stevenson]

Hi Cristian

On Tue, 13 Oct 2026 at 01:16, Cristian Ciocaltea
<cristian.ciocaltea@xxxxxxxxxxxxx> 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/20261013-vc4-common-scramb-v2-0-a41d15e131ad@xxxxxxxxxxxxx?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 <dave.stevenson@xxxxxxxxxxxxxxx>
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxxxxxx>
> > ---
> >  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),
> >
> >