search

msm8916-mainline / linux-mdss-dsi-panel-driver-generator

Generate Linux DRM panel kernel driver based on QCOM MDSS DSI device tree
GNU General Public License v2.0
53 stars 33 forks source link

panel: Chain in `post-panel-on-command` #36

Open MarijnS95 opened 10 months ago

MarijnS95 commented 10 months ago

This is a perfect contender for the .prepare() -> .enable() split; on Sony panels the unblank command is typically in post-panel-on to make it happen after the panel is prepared, the bridge is on, and pixel data is flowing.

Without this pretty much all our panels are generated with a driver that never unblanks the panel.

stephan-gh commented 10 months ago

Hm, but the way you added this here it's sent as part of the prepare() callback and not as part of enable(). Should we generate an enable() callback in the generator somehow to make it match the equivalent downstream behavior?

MarijnS95 commented 10 months ago

@stephan-gh with "for the .prepare() -> .enable() split" I meant the future possibility for doing so; I don't think that's really in the works yet though?

In part because we currently have prepare_prev_first which only applies to enable/prepare, but not to disable/prepare giving "unbalanced" functions.

MarijnS95 commented 8 months ago

@stephan-gh :eyes:

stephan-gh commented 8 months ago

I think we should at least add a FIXME comment in the code that these are generally not meant to be chained to the prepare() sequence. It sounds more like they belong into .enable() (which we don't generate at all at the moment).

The qcom,mdss-dsi-post-on-backlight is probably even more difficult since the name suggests it should run after the backlight has been already enabled. Currently there is no easy way to do this on mainline because backlight_enable() runs even after ->enable() is called: https://elixir.bootlin.com/linux/v6.6-rc5/source/drivers/gpu/drm/drm_panel.c#L203

MarijnS95 commented 7 months ago

@stephan-gh sure, I'm just not seeing how we could do that with the way the code is currently set up. Maybe add a self.comment to ~CommandSequence~ Command for this?

MarijnS95 commented 7 months ago

Started hacking in something ugly that doesn't really work, above idea is still more likable since only the parser in panel.py knows where this sequence came from.

stephan-gh commented 7 months ago

Hm, I wonder if we could parse that kind of stuff in a separate CommandSequence (next to on and off) and then just emit it immediately next to on in the driver generator for now.