On Sunday, January 23, 2022, 09:10:53 AM CST, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> 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 lot
better way. Propogating the flags though the bridges and not requiring drm
objects 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
