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 <jonat...@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
