[PATCH v2 2/2] drm/bridge: tc358767: Improve DPI output pixel clock accuracy

Marek Vasut marex at denx.de
Mon Nov 25 23:50:42 UTC 2024


On 11/25/24 2:17 PM, Maxime Ripard wrote:
> On Fri, Nov 22, 2024 at 03:32:57PM +0200, Dmitry Baryshkov wrote:
>> On Tue, Nov 12, 2024 at 03:05:37AM +0100, Marek Vasut wrote:
>>> The Pixel PLL is not very capable and may come up with wildly inaccurate
>>> clock. Since DPI panels are often tolerant to slightly higher pixel clock
>>> without being operated outside of specification, calculate two Pixel PLL
>>> from either mode clock or display_timing .pixelclock.max , whichever is
>>> higher. Since the Pixel PLL output clock frequency calculation always
>>> returns lower frequency than the requested clock frequency, passing in
>>> the higher clock frequency should result in output clock frequency which
>>> is closer to the expected pixel clock.
>>>
>>> For the Chefree CH101 panel with 13 MHz Xtal input clock, the frequency
>>> without this patch is 65 MHz which is out of the panel specification of
>>> 68.9..73.4 MHz, while with this patch it is 71.5 MHz which is well within
>>> the specification and far more accurate.
>>
>> Granted that most of the panel drivers do not implement get_timings()
>> and granted that there are no current users of that interface, I think
>> we should move away from it (and maybe even drop it completely from
>> drm_panel).
> 
> I think we should do the opposite :)
> 
> Panels usually have a pretty large operating window, and the current
> construct only works because nobody really uses the same panels (or
> we're hiding that behind different compatibles) across SoCs or
> generation. Or we're working around it.

I am using the same panels on NXP MX6/MX8 and STM32MP1 with wildly 
different pipeline setups too.

> It's kind of a mess, and it gets messy in encoders too: some will filter
> out panel modes, some won't. Some will adjust timings to fit their
> clocks, some won't. etc.
> 
> Going forward, switching everyone to a timing-like interface and
> providing a set of helpers to adjust timings within possible boundaries
> to fit a clock rate is doable and should be done imo.
Maybe it would be better to have multiple modes and mark them with 
MIN/TYP/MAX flag , so at least there wouldn't be two sets of structures 
describing the same thing, but only one structure (drm_display_mode) ?


More information about the dri-devel mailing list