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 maxime.ripard@bootlin.com 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 giulio.benetti@micronovasrl.com
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