Hi Jani and Maxime
On 1/17/2024 2:16 AM, Jani Nikula wrote:
On Wed, 17 Jan 2024, Maxime Ripard <mripard@xxxxxxxxxx> wrote:
Hi,
On Tue, Jan 16, 2024 at 02:22:03PM -0800, Jessica Zhang wrote:
This series introduces a simulated MIPI DSI panel.
Currently, the only way to validate DSI connectors is with a physical
panel. Since obtaining physical panels for all possible DSI configurations
is logistically infeasible, introduce a way for DSI drivers to simulate a
panel.
This will be helpful in catching DSI misconfiguration bugs and catching
performance issues for high FPS panels that might not be easily
obtainable.
For now, the simulated panel driver only supports setting customized
modes via the panel_simlation.mode modparam. Eventually, we would like
to add more customizations (such as configuring DSC, dual DSI, etc.).
I think that it's more complicated than it needs to be.
Both too complicated and not complicated enough! :p
The end goal is to have a framework to be able to validate the display
pipeline with MIPI panels of any resolution , DSC/non-DSC, different
MIPI flags etc.
Historically, QC has been having an in-house framework to validate the
panels in a simulated way as its logistically not possible to procure
every panel from every vendor. This has been working pretty well but its
not upstream yet. So we would like to work with the community to work on
a model which works for everyone and this RFC was initiated with that in
mind.
There is simulation infrastructure in place in upstream for HDMI/DP in
the form of chamelium based testing in IGT but no such fwk exists for
DSI displays.
Different MIPI panels and resolutions test out not only the DSI
controller but the entire display pipeline as based on resolution,
compression and MIPI mode flags different parts of the pipeline can get
exercised.
Why do we need to support (and switch to) both the actual and
"simulated" panel?
As per my discussion on IRC with the panel/bridge maintainers and DT
maintainers, a simulation panel does not qualify for its own devicetree
as its not a real hardware so we needed to come up with a way to have a
module which can be attached to the encoder without its own bindings and
devicetree. Thats what led to this RFC.
Wouldn't it be simpler if we had a vkms-like panel that we could either
configure from DT or from debugfs that would just be registered the
usual way and would be the only panel we register?
No, we need to have validate actual hardware pipeline with the simulated
panel. With vkms, actual display pipeline will not be validated. With
incorrect display pipeline misconfigurations arising from different
panel combinations, this can easily be caught with any existing IGT CRC
testing. In addition, all performance related bugs can also be easily
caught by simulating high resolution displays.
I get the idea of trying to test DSI code without panels, and looking at
the goals above, I think your vkms suggestion is going to fall short of
those goals.
However, my gut feeling is that creating a simulated panel to catch DSI
misconfiguration etc. is going to be insanely complicated, and this
series doesn't even scratch the surface.
I guess my questions are, what's the scope here really, are those goals
realistic, does more code already exist beyond this skeleton?
This series is only a starting RFC to be able to validate any display
mode. This would have to be extended to be able to customize different
pieces of the panel. Lets talk about the customizable pieces:
1) Display resolution with timings (drm_display_mode)
2) Compression/non-compression
3) Command mode/Video mode
4) MIPI mode flags
5) DCS commands for panel enable/disable and other panel sequences
6) Power-up/Power-down sequence for the panel
Without a physical panel, yes its hard to validate if anything is wrong
with (4) OR (5), the display might not come up at all visually. But from
our experience, thats only a small portion and the real benefit of this
framework will actually be from the validation failures we will catch
from (1) to (4).
This RFC only provides a way to customize (1) at the moment as we wanted
to get some feedback from the community about the best way which will
work for everyone to customize all these parameters.
We are willing to expand this series based on the generic way we agree
on to customize other params.
Yes, debugfs is an option too. But typically MIPI displays need some
parameters configured to attach the panel to the encoder. So perhaps we
can boot the simulation panel with a default resolution passed through
command line and then across a modeset switch (1) to (4).
Thanks
Abhinav
BR,
Jani.
