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?
Any pointers would be greatly appreciated!
Thanks!
-charles
On Wed, Dec 29, 2021 at 10:19 PM Charles Stevens chazste@yahoo.com 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?
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.
adam
Thanks!
-charles
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.
On Sunday, January 23, 2022, 09:10:53 AM CST, Laurent Pinchart laurent.pinchart@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
dri-devel@lists.freedesktop.org
-
Adam Ford -
Charles Stevens -
Laurent Pinchart