Hi all,
Il 26/02/2018 13:31, Anatolij Gustschin ha scritto:
Hi all,
On Fri, 16 Feb 2018 14:10:25 +0100
Maxime Ripard [email protected] wrote:
Hi,
On Thu, Feb 15, 2018 at 06:40:53PM +0100, Giulio Benetti wrote:
Differently from other Lcd signals, HSYNC and VSYNC signals
result inverted if their bits are cleared to 0.
Invert their settings of IO_POL register.
Signed-off-by: Giulio Benetti <[email protected]>
---
drivers/video/sunxi/lcdc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/sunxi/lcdc.c b/drivers/video/sunxi/lcdc.c
index 4cb86fb..007057c 100644
--- a/drivers/video/sunxi/lcdc.c
+++ b/drivers/video/sunxi/lcdc.c
@@ -132,9 +132,9 @@ void lcdc_tcon0_mode_set(struct sunxi_lcdc_reg * const lcdc,
}
val = SUNXI_LCDC_TCON0_IO_POL_DCLK_PHASE(dclk_phase);
- if (mode->flags & DISPLAY_FLAGS_HSYNC_LOW)
+ if (mode->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= SUNXI_LCDC_TCON_HSYNC_MASK;
- if (mode->flags & DISPLAY_FLAGS_VSYNC_LOW)
+ if (mode->flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= SUNXI_LCDC_TCON_VSYNC_MASK;
As we discussed earlier, I'm really not sure this is worth it. This is
going to break all the boards out there that store the modeline in the
environment. And we should fix all the defconfigs (but that's the easy
part).
Anatolij, any suggestion?
from the patch description it is not clear to me which problem this
patch tries to solve. AFAICS in the driver code, mode->flags is
initialized either from input data in the EDID blob, sync properties
in "display-timings" device tree node or from the built-in mode
string. I assume the driver already works properly when reading
the sync flags from all these sources. It seems this patch can
also break boards without modeline in the environment. Can't you
adjust sync flags in your CONFIG_VIDEO_LCD_MODE to get the LCD
output working without patching the driver?
Sure I can put sync:3, no problem for me.
Actually this patch seems to be too dangerous to be applied as Maxime
pointed and you confirmes.
Anyway, this patch corrects HSYNC and VSYNC polarity.
Now it's wrong, I triple-checked with scope.
Please take a look at this discussion:
https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html
There are also links to pasteboard with scope captures against IO_POL
register.
It was regarding Linux but u-boot too.
As I've written there, IMHO I think that nobody is using rgb displays
driven in HV mode nowadays, but only in DE mode.
So maybe this patch is correct, but useless, unless soon or late,
someone tries to drive display without HSYNC and VSYNC connected.
What I see around is that rgb displays have both sync systems,
and DE mode has priority over HV sync.
It's only a pity having 4 macros that work on the contrary they state:
- DISPLAY_FLAGS_HSYNC_HIGH
- DISPLAY_FLAGS_HSYNC_LOW
- DISPLAY_FLAGS_VSYNC_HIGH
- DISPLAY_FLAGS_VSYNC_LOW
But if it is dangerous, I understand dropping this patch.
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
Thanks,
Anatolij
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
