DPI panel configuration #4753
DPI panel configuration #4753
Conversation
|
Oooo shiny. A quick glance though and it looks OK but I have absolutely no way of testing it. This is a real lifesaver for those coming in from using dpi-timings in config.txt. Chances of being accepted upstream, minus ONE BILLION. But that's their problem, not ours. Reading back through some of the comments on this sort of thing, apparently writing loads of custom code and rebuilding the kernel is the correct way, not some easy to use DT overlay approach. |
Actually the only controversial bit is "drm/panel-simple: Allow the bus format to be read from DT for panel-dpi". The main support is in mainline, and this is only a couple of minor tweaks to stop it logging errors. A very similar thing has been proposed before - https://lkml.org/lkml/2017/10/13/956. And actually there was a solution merged that then got reverted - https://lore.kernel.org/all/[email protected]/T/ / torvalds/linux@d021d75 |
There was a problem hiding this comment.
Apart from the nitpicky README convention, my other comments are a suggestion of how to improve the bus format selection, replacing the selectively enabling fragments model with writing explicit phandle values directly from parameters, similar to what you've already done for bus-format itself.
panel-dpi doesn't know the bit depth, so in the same way that DPI is guessed for the connector type, guess that it'll be 8bpc. Signed-off-by: Dave Stevenson <[email protected]>
When using the "panel-dpi" compatible string, desc as passed from DT is a dumy entry, and panel_dpi_probe allocates a new one and attaches it to the panel. However panel_simple_probe has already taken a local copy of the variable, which means all the validation is done against the empty dummy structure, not the configured data. Update the local variable after panel_dpi_probe. Signed-off-by: Dave Stevenson <[email protected]>
The "panel-dpi" compatible string configures panel from device tree, but it doesn't provide any way of configuring the bus format (colour representation), nor does it populate it. Add a DT parameter "bus-format" that allows the MEDIA_BUS_FMT_xxx value to be specified from device tree. Signed-off-by: Dave Stevenson <[email protected]>
DRM provides flags for inverting pixel clock and output enable signals, but these were not mapped to the relevant registers. Add those mappings. Signed-off-by: Dave Stevenson <[email protected]>
In a couple of error/incomplete configuration cases, the DPI_FORMAT bits wouldn't get set. Adopt a default of RGB666 in all these cases. Signed-off-by: Dave Stevenson <[email protected]>
Adds the pinctrl defines for the RGB565 DPI output modes. Signed-off-by: Dave Stevenson <[email protected]>
Uses the "panel-dpi" compatible to set panel timings from DT. Signed-off-by: Dave Stevenson <[email protected]>
|
Requested changes made. I do need to find my Kippah and screen and check that the output is as expected, but otherwise I think we're good to go. |
Found, and it works fine. |
See: raspberrypi/linux#4755 kernel: DPI panel configuration See: raspberrypi/linux#4753 kernel: KMS 7" DSI panel and touchscreen fixes See: raspberrypi/linux#4750 kernel: drm/vc4: Hold pm_runtime for vc4 See: raspberrypi/linux#4706
See: raspberrypi/linux#4755 kernel: DPI panel configuration See: raspberrypi/linux#4753 kernel: KMS 7" DSI panel and touchscreen fixes See: raspberrypi/linux#4750 kernel: drm/vc4: Hold pm_runtime for vc4 See: raspberrypi/linux#4706
Adds a generic DPI panel configuration overlay
@JamesH65 Could do with some testing, and possibly even a magic script to convert a
dpi_output_format=anddpi_timings=line into the relevant overlay parameters.Not all output modes are configured as the relevant MEDIA_BUS_FMT_xxx defines don't exist.