On 09/05/2025 04:58, Andy Yan wrote:
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?
Yes, just create a separate commit, folding the header into the source file.
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
--
With best wishes
Dmitry
