[PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

Jonathan Marek jonathan at marek.ca
Wed Mar 4 13:16:54 UTC 2020


The msm DSI driver does predate the addition of those fields and doesn't 
use them at all.

Seems like it would be a bit of a hack too, since the frequency we want 
to use is not the "real limits of the hardware"..

On 3/4/20 4:10 AM, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:49 PM Jonathan Marek <jonathan at marek.ca> wrote:
> 
>> This is a command mode panel and the the msm/mdp5 driver uses the
>> vrefresh field for the actual refresh rate, while the dotclock field is
>> used for the DSI clocks. The dotclock needed to be a bit higher than
>> necessary otherwise the panel would not work.
> 
> I don't know if this predates the support for defining DSI clocks
> but for what we have in the kernel right now this is wrong.
> 
> struct mipi_dsi_device contains:
> 
>   * @hs_rate: maximum lane frequency for high speed mode in hertz, this should
>   * be set to the real limits of the hardware, zero is only accepted for
>   * legacy drivers
>   * @lp_rate: maximum lane frequency for low power mode in hertz, this should
>   * be set to the real limits of the hardware, zero is only accepted for
>   * legacy drivers
> 
> The MDP driver should use these frequencies for a DSI command
> mode panel, and the panel driver should define them.
> 
> These two clocks are/can be/should be completely orthogonal to
> the dotclock/pixelclock inside the panel, which is likely driven from
> its own crystal directly from the panel-internal framebuffer.
> 
> Yours,
> Linus Walleij
> 


More information about the dri-devel mailing list