Hi Dmitry, Thanks for you review.
在 2025-05-05 00:16:35，"Dmitry Baryshkov" <dmitry.barysh...@oss.qualcomm.com> 写道： >On Sat, May 03, 2025 at 04:42:04PM +0200, Heiko Stübner wrote: >> Am Dienstag, 22. April 2025, 09:04:39 Mitteleuropäische Sommerzeit schrieb >> Andy Yan: >> > From: Andy Yan <andy....@rock-chips.com> >> > >> > When preparing to convert the current inno hdmi driver into a >> > bridge driver, I found that there are several issues currently >> > existing with it: >> > >> > 1. When the system starts up, the first time it reads the EDID, it >> > will fail. This is because RK3036 HDMI DDC bus requires it's PHY's >> > reference clock to be enabled first before normal DDC communication >> > can be carried out. >> > >> > 2. The signal is unstable. When running the glmark2 test on the screen, >> > there is a small probability of seeing some screen flickering. >> > This is because The HSYNC/VSYNC polarity of rk3036 HDMI are controlled >> > by GRF. This part is missing in the current driver. >> > >> > PATCH 1~6 are try to Fix Document in the dt-binding, then add the >> > missing part in driver and dts. >> > PATCH 7 converts the curren driver to drm bridge mode. >> >> After resurrecting my rk3036-kylin which hasn't sucessfully booted in a >> while, I could veryify this series, so on a rk3036-kylin >> >> Tested-by: Heiko Stuebner <he...@sntech.de> >> >> >> I'll probably apply patches 1-4 to drm-misc later today, as that solely >> touches the Rockchip (and only rk3036-)side and patches 5+6 to the >> rockchip tree. >> >> Patch 7 should probably get some attention by people more familiar with >> drm-bridges, so I'll let that sit for a bit longer. > >I will take a look later, but on the first glance it looks like there >are too many things going on in that patch, including some unnecessary >fnction movements and define movements, etc. I would kindly ask to split These registers were initially defined in a separate header file(inno_hdmi.h), but they were only used by a single C file, so I think it's not necessary to put them in a separate header file. I decided to simply merge them into the inno_hdmi.c file. If I first create a patch and separately carry out the merging of this register definition, would that be possible? And I will try to avoid function movements in next version. >the non-functional refactorings and the functional ones (splitting to a >library, etc). Will do in next version. > >> >> >> Thanks a lot for working on all this >> Heiko >> >> > >-- >With best wishes >Dmitry
