On 26/05/25 16:02, Tommaso Merciai wrote:
Hi All,
Thanks for your comments.
On 26/05/25 15:18, Dmitry Baryshkov wrote:
On 26/05/2025 14:40, Maxime Ripard wrote:
On Mon, May 26, 2025 at 01:19:23PM +0200, Tommaso Merciai wrote:
Hi Laurent,
Thanks for your comment.
On 26/05/25 12:49, Laurent Pinchart wrote:
On Mon, May 26, 2025 at 11:58:37AM +0200, Tommaso Merciai wrote:
Hi Maxime,
Thanks for your comment.
On 26/05/25 11:26, Maxime Ripard wrote:
Hi,
On Mon, May 26, 2025 at 10:54:52AM +0200, Tommaso Merciai wrote:
After adv7511_mode_set() was merged into .atomic_enable(), only the
native resolution is working when using modetest.
This is caused by incorrect timings: adv7511_mode_set() must not be
merged into .atomic_enable().
Move adv7511_mode_set() back to the .mode_set() callback in
drm_bridge_funcs to restore correct behavior.
Fixes: 0a9e2f0a6466 ("drm/bridge: adv7511: switch to the HDMI
connector helpers")
Reported-by: Biju Das <biju.das...@bp.renesas.com>
Closes: https://lore.kernel.org/all/aDB8bD6cF7qiSpKd@tom-desktop/
Signed-off-by: Tommaso Merciai <tommaso.merciai...@bp.renesas.com>
Explaining why, both in the commit log and the comments, would be
nice.
Because I can't think of any good reason it just can't work for that
bridge.
Sorry, let me clarify and share with you some details:
adv7511_mode_set:
- Is setting up timings registers for the DSI2HDMI bridge in
our case
we are using ADV7535 bridge.
rzg2l_mipi_dsi_atomic_enable:
- Is setting up the vclock for the DSI ip
Testing new/old implementation a bit we found the following:
root@smarc-rzg3e:~# modetest -M rzg2l-du -d -s HDMI-
A-1:800x600-56.25@XR24
setting mode 800x600-56.25Hz on connectors HDMI-A-1, crtc 62
[ 49.273134] adv7511_mode_set_old: drm_mode_vrefresh(mode) = 56
[ 49.281006] rzg2l_mipi_dsi_atomic_enable: mode->clock: 36000
root@smarc-rzg3e:~# modetest -M rzg2l-du -d -s HDMI-
A-1:800x600-56.25@XR24
setting mode 800x600-56.25Hz on connectors HDMI-A-1, crtc 62
[ 74.076881] rzg2l_mipi_dsi_atomic_enable: mode->clock: 36000
[ 74.092130] adv7511_mode_set: drm_mode_vrefresh(adj_mode) = 56
Same result but different timing (in function call perspective):
- old: adv7511_mode_set() is call before
rzg2l_mipi_dsi_atomic_enable()
- new: adv7511_mode_set() is call after
rzg2l_mipi_dsi_atomic_enable()
What is "old" and "new" here ? Is it before and after Dmitry's
patch, or
before and after yours ? Please be precise when describing problems.
Sorry, you are completely right:
- old --> before Dmitry's patch
- new --> after Dmitry's patch
What do you think? Thanks in advance.
You're only explaining above what the "old" and "new" behaviours are,
and claiming one of them is causing an issue, but you're not
explaining
*why* it causes an issue. That's what your commit message is
expected to
detail.
Thanks for the clarification! :)
I will send v2 explaining better this.
In particular, if the driver needs to have mode_set called before
atomic_enable, you should say why moving the call to mode_set earlier in
the function wouldn't work.
It might be the same thing as we had on PS8640: it had to be brought
up before the host starts the DSI link, so that there is no clock
input on the DSI clock lane.
Some updates on my side:
I'm not seeing any differences from a regs perspective when using the
old driver version (before Dmitry's patch) and the new driver version
(after Dmitry's patch).
In particular, i2cdump -f -y 7 0x4c shows me the same result.
Please ignore this (wrong address)
The right test is: i2cdump -f -y 7 0x3d
And I'm seeing the following differences:
# WORK:
reg | val
0x3d → 0x00
0x3e → 0x00
# DON't WORK
reg | val
0x3d → 0x10
0x3e → 0x40
Thanks & Regards,
Tommaso
Unfortunately, since I don't have the ADV7535 datasheet, I believe this
issue may be related to the functions call sequence.
I agree with Dmitry's theory.
Let me gently know if you need some more test on my side. Thanks in
advance.
Regards,
Tommaso
