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 > Why do we need to support (and switch to) both the actual and > "simulated" panel? > > 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? 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? BR, Jani. -- Jani Nikula, Intel