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. -- Regards, Laurent Pinchart
