Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D

[Nicolas Saenz Julienne <nsaenzjulienne@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2525 bytes --]

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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel