On Wed, Feb 28, 2024 at 01:49:34PM -0800, Jessica Zhang wrote: > > > On 2/2/2024 2:15 AM, Maxime Ripard wrote: > > On Tue, Jan 30, 2024 at 09:53:13AM +0100, Daniel Vetter wrote: > > > > > > > > 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. > > > > > > > > > > That's not what I meant. What I meant was that something like a > > > > > user-configurable, generic, panel driver would be a good idea. Just like > > > > > vkms (with the debugfs patches) is for a full blown KMS device. > > > > > > > > > > > > > Let me respond for both this question and the one below from you/Jani. > > > > > > > > Certainly having user-configurable information is a goal here. The end-goal > > > > is to make everything there in the existing panels such as below like I > > > > wrote: > > > > > > > > 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 > > > > > > > > But, we also have to see what all is feasible today from the DRM fwk > > > > standpoint. There are some limitations about what is boot-time configurable > > > > using bootparams and what is runtime configurable (across a modeset) using > > > > debugfs. > > > > > > > > 1) Today, everything part of struct mipi_dsi_device needs to be available at > > > > boot time from what I can see as we need that while calling > > > > mipi_dsi_attach(). So for that we went with boot-params. > > > > > > > > 2) For the list of modes, we can move this to a debugfs like > > > > "populate_modes" which the client using a sim panel can call before picking > > > > a mode and triggering a commit. > > > > > > > > But we need to have some default mode and configuration. > > > > > > Uh, at the risk of sounding a bit like I'm just chasing the latest > > > buzzwords, but this sounds like something that's screaming for ebpf. > > > > I make a half-joke to Jani on IRC about it, but I was also being > > half-serious. If the goal we want to have is to fully emulate any panel > > variation, ebpf really looks like the best and most flexible way > > forward. > > Hi Maxime and Daniel, > > For our current sim panel requirements, we can go with implementing the > configfs first then add ebpf if requirements get more complex. Agreed, this is definitely the pragmatic approach to get this going. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
