<html><head></head><body><div class="ydp9c280aa6yahoo-style-wrap" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 13px;"><div></div>
<div><span style="color: rgb(38, 40, 42);">On Sunday, January 23, 2022, 09:10:53 AM CST, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:</span><br></div></div><div id="ydp7c9446abyahoo_quoted_3743177133" class="ydp7c9446abyahoo_quoted"><div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div><br></div>
<div dir="ltr" data-setdir="false"> <div><div>> Hello,</div><div>> </div><div>> Thanks for CC me Adam.</div><div>> </div><div>> On Fri, Jan 21, 2022 at 11:24:09AM -0600, Adam Ford wrote:</div><div>> > On Wed, Dec 29, 2021 at 10:19 PM Charles Stevens wrote:</div><div>> > ></div><div>> > > Hi All,</div><div>> > ></div><div>> > > I am working on a platform based on the Renesas RZ/G2 SoC family.</div><div>> > > This chip uses the rcar-du driver for the display. I would like to</div><div>> > > submit a patch to address the fact that the driver does not</div><div>> > > check/honor the flag DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE. My issue is</div><div>> > > that I would like to make as small a change to the driver as</div><div>> > > possible, but the panel bus_flags don't seem to even make it to the</div><div>> > > crtc driver. The crtc driver seems to use adjusted_mode to set the</div><div>> > > HSYNC and VSYNC polarity and as I said ignores the pixel clock</div><div>> > > polarity leaving it at the default of driving on the falling edge.</div><div>> > > In my investigations so far I have not figured out how to chase the</div><div>> > > pointers from the CRTC to the bridge to the panel in order to be</div><div>> > > able to look at bus_flags. My current approach also modifies the</div><div>> > > encoder initialization to cache the needed panel and then find the</div><div>> > > attached encoder during CRTC initialization to find the bus flags.</div><div>> > > This seems like a lot of work and not something that would be</div><div>> > > accepted as a patch. The OMAP DSS seems to have problems accessing</div><div>> > this flag as well. The TI driver goes so far as to document the</div><div>> > current approach as a HACK and suggest a fairly large change to the</div><div>> > driver to address the problem. Am I missing something? Is there an</div><div>> > easy way to get from a drm_crtc to a drm_panel that is in the same</div><div>> > pipeline?</div><div>> </div><div>> This is actually something I've experimented with before. I wrote</div><div>> patches, but never got a chance to post them. I've pushed them to</div><div>> git://linuxtv.org/pinchartl/media.git drm/du/syncpol if you want to have</div><div>> a look.</div><div>> </div><div>OK. I've looked over this patch and agree that it should work for my use case </div><div>too. Thank you.</div><div><br></div><div>> However, there's one issue with this approach: it's not correct :-) The</div><div>> CRTC shouldn't be configured based on the polarity of signals at the end</div><div>> of the pipeline, it needs to be configured based on the polarities</div><div>> expected by the next bridge in the chain. That may depend on the next</div><div>> bridge, which may depend on the next bridge, and so on. The information</div><div>> should thus be propagated from the panel towards the CRTC, one bridge at</div><div>> a time, the same way that we propagate formats with the bridge</div><div>> .atomic_get_input_bus_fmts() and .atomic_get_output_bus_fmts()</div><div>> operations. There's thus quite a bit of work required to handle all this.</div><div>> </div><div>Thank you for the description here. I can agree that this aproach seems a lot</div><div>better way. Propogating the flags though the bridges and not requiring drm</div><div>objects to know about other objects not directly connected makes a lot of sense.</div><div><br></div><div>So that leaves me with the question, what can I do to help move this along. I </div><div>would like to see ESCR_DCLKOINV get written in the rcar-du driver in mainline </div><div>Linux sometime in the near future :) </div><div><br></div><div>> > > Any pointers would be greatly appreciated!</div><div>> ></div><div>> > + Laurent, Kieran</div><div>> ></div><div>> > Charles,</div><div>> ></div><div>> > I added Laurent and Kieran because they appear as the maintainers for</div><div>> the rcar-du driver.</div><div>> </div><div>> </div><div>> --</div><div>> Regards,</div><div>> </div><div>> Laurent Pinchart</div></div><br><div class="ydp7c9446abyqt5075624753" id="ydp7c9446abyqtfd80687" dir="ltr" data-setdir="false">Regards,</div><div class="ydp7c9446abyqt5075624753" id="ydp7c9446abyqtfd80687" dir="ltr" data-setdir="false"> -charles</div></div>
</div>
</div></body></html>