On Wednesday, April 18, 2018 10:53 AM, Archit Taneja wrote:
> On Wednesday 18 April 2018 01:58 PM, Daniel Mack wrote:
>> On Wednesday, April 18, 2018 10:06 AM, Archit Taneja wrote:
>>> One easy way to get around this would be to not try to set the clock
>>> rates every time we try to send a command. We just enable/disable them.
>>
>> Yes, that could work as well, but how about rounding the rates in the
>> callback that exists for that purpose? We're off by a fraction of a
>> permille only, after all.
>
> Sorry, forgot to respond to that in your last mail. I wasn't fully
> clear about how we'd do it.
>
> Do you mean that we call clk_round_rate() on the byte and pixel
> clocks in dsi_link_clk_enable_6g() after we set the rates?
No, before. AFAIU, the clk core calls into the clock provider's
.round_rate() callback if it exists to determine the exact rate that it
is about to set. With this, the driver can return a rate that it
actually supports.
The MSM PLL driver currently only clamps the values in that callback,
but it could be smarter than that and return the closest rate to the
desired rate they can actually generate. The calculations based on the
various registers in dsi_pll_{14,28}nm_clk_recalc_rate() beat me though,
so it's not immediately clear how to get the math right to implement
that properly.
Thanks,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
