Hello,
Thanks for CC me Adam.
On Fri, Jan 21, 2022 at 11:24:09AM -0600, Adam Ford wrote:
On Wed, Dec 29, 2021 at 10:19 PM Charles Stevens wrote:
Hi All,
I am working on a platform based on the Renesas RZ/G2 SoC family. This chip uses the rcar-du driver for the display. I would like to submit a patch to address the fact that the driver does not check/honor the flag DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE. My issue is that I would like to make as small a change to the driver as possible, but the panel bus_flags don't seem to even make it to the crtc driver. The crtc driver seems to use adjusted_mode to set the HSYNC and VSYNC polarity and as I said ignores the pixel clock polarity leaving it at the default of driving on the falling edge. In my investigations so far I have not figured out how to chase the pointers from the CRTC to the bridge to the panel in order to be able to look at bus_flags. My current approach also modifies the encoder initialization to cache the needed panel and then find the attached encoder during CRTC initialization to find the bus flags. This seems like a lot of work and not something that would be accepted as a patch. The OMAP DSS seems to have problems accessing this flag as well. The TI driver goes so far as to document the current approach as a HACK and suggest a fairly large change to the driver to address the problem. Am I missing something? Is there an easy way to get from a drm_crtc to a drm_panel that is in the same pipeline?
This is actually something I've experimented with before. I wrote patches, but never got a chance to post them. I've pushed them to git://linuxtv.org/pinchartl/media.git drm/du/syncpol if you want to have a look.
However, there's one issue with this approach: it's not correct :-) The CRTC shouldn't be configured based on the polarity of signals at the end of the pipeline, it needs to be configured based on the polarities expected by the next bridge in the chain. That may depend on the next bridge, which may depend on the next bridge, and so on. The information should thus be propagated from the panel towards the CRTC, one bridge at a time, the same way that we propagate formats with the bridge .atomic_get_input_bus_fmts() and .atomic_get_output_bus_fmts() operations. There's thus quite a bit of work required to handle all this.
Any pointers would be greatly appreciated!
- Laurent, Kieran
Charles,
I added Laurent and Kieran because they appear as the maintainers for the rcar-du driver.