Renesas rcar-du and DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE

[Charles Stevens]

 On Sunday, January 23, 2022, 09:10:53 AM CST, Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote:
 
  > 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.> OK. I've looked over this patch and agree that it should work for my use case too. Thank you.
> 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.> Thank you for the description here. I can agree that this aproach seems a lotbetter way. Propogating the flags though the bridges and not requiring drmobjects to know about other objects not directly connected makes a lot of sense.
So that leaves me with the question, what can I do to help move this along. I would like to see ESCR_DCLKOINV get written in the rcar-du driver in mainline Linux sometime in the near future :) 
> > > 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
Regards,    -charles  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220124/3cfaec01/attachment-0001.htm>