From mboxrd@z Thu Jan 1 00:00:00 1970 From: giulio.benetti@micronovasrl.com (Giulio Benetti) Date: Wed, 24 Jan 2018 18:38:17 +0100 Subject: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly In-Reply-To: References: <1516474221-114596-1-git-send-email-giulio.benetti@micronovasrl.com> <1516474221-114596-2-git-send-email-giulio.benetti@micronovasrl.com> <20180122085112.7xo2t3x5ag4k2kpl@flea.lan> Message-ID: <59f7b542-3b1d-ff62-e290-37c47f4075ff@micronovasrl.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Il 22/01/2018 21:27, Giulio Benetti ha scritto: > Hi, > > Il 22/01/2018 09:51, Maxime Ripard ha scritto: >> On Sat, Jan 20, 2018 at 07:50:21PM +0100, Giulio Benetti wrote: >>> On previous handling, if specified DRM_MODE_FLAG_N*SYNC, >>> it was ignored, >>> because only PHSYNC and PVSYNC were taken into account. >>> DRM_MODE_FLAG_P*SYNC and DRM_MODE_FLAG_N*SYNC are not exclusive. >>> >>> If flags contains PVSYNC, it doesn't mean it is NVSYNC. >>> And it's true also the contrary. >>> Also, as I've checked with scope on A20, >>> if (flags & PVSYNC) then SUN4I_TCON0_IO_POL_VSYNC_POSITIVE >>> must be set, as name suggests. >>> It seems all display io polarities starts inverted if 0. >>> >>> Signed-off-by: Giulio Benetti >>> >>> PVSYNC and PHSYNC only >>> >>> Signed-off-by: Giulio Benetti >> >> Checkpatch: >> WARNING: Duplicate signature > > Sorry I didn't use ./scripts/checkpatch.pl > >> >>> --- >>> ? drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++-- >>> ? 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c >>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c >>> index 6121210..e873a37 100644 >>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c >>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c >>> @@ -224,10 +224,10 @@ static void sun4i_tcon0_mode_set_rgb(struct >>> sun4i_tcon *tcon, >>> ?????????????? SUN4I_TCON0_BASIC3_H_SYNC(hsync)); >>> ????? /* Setup the polarity of the various signals */ >>> -??? if (!(mode->flags & DRM_MODE_FLAG_PHSYNC)) >>> +??? if (mode->flags & DRM_MODE_FLAG_PHSYNC) >>> ????????? val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE; >>> -??? if (!(mode->flags & DRM_MODE_FLAG_PVSYNC)) >>> +??? if (mode->flags & DRM_MODE_FLAG_PVSYNC) >>> ????????? val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE; >> >> I'm not sure why you were talking of the differences between NVSYNC >> and PVSYNC if you're not making use of any of it here? > > Thinking about it more now, the point is that all Lcd IOs seem to be > inverted by default(at least on A20). > With inverted, I mean that if for example PVSYNC, > I should see vsync line low and when asserted to give VSync, > it goes high. > This is what I've checked with oscilloscope on A20. > Can someone give a try on A33? Otherwise I will, > but I will take some time. > On uboot, everything is treated equal to kernel, > but to have my falling edge dclk and low h/vsync I had to specify: > CONFIG_VIDEO_LCD_DCLK_PHASE=0 (giving me falling edge on dclk) > and > CONFIG_VIDEO_LCD_MODE="....,sync:3,..." > but digging into code, I see "sync:3" means H/VSYNC HIGH, > but I experience both LOW during their pulse. > >> >> Also, how was it tested? This seems quite weird that we haven't caught >> that one sooner, and I'm a bit worried about the possible regressions >> here. > > It sounds really strange to me too, > because everybody under uboot use "sync:3"(HIGH). > I will retry to measure, > unfortunately at home I don't have a scope, > but I think I'm going to have one soon, because of this. :) Here I am with scope captures and tcon0 registers dump: tcon0_regs => https://pasteboard.co/H4r8Zcs.png dclk_d0 => https://pasteboard.co/H4r8QRe.png dclk_de => https://pasteboard.co/H4r8zh4R.png dclk_vsnc => https://pasteboard.co/H4r8Hye.png As you can see circled in reg on registers, TCON0_IO_POL_REG = 0x00000000. But on all the waveforms you can see: - dclk_d0: clock phase is 0, but it starts with falling edge, otherwise the rising front overlaps dclk rising edge(not good), so to me this is falling, then I mean it Negative. - dclk_de: de pulse is clearly negative, even if register is 0 and its' polarity bit is 0. - dclk_vsnc: same as dclk_de - dclk_hsync: I didn't take scope screenshot but I can assure you it's negative. You can also check all the other registers about TCON0. Now I proceed testing it on A33, maybe the peripheral is slightly different between Axx SoCs, if I find it that way, it should be only a check about SoC or peripheral ID, and treat polarity as it should be done. Kind regards -- Giulio Benetti R&D Manager & Advanced Research 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 > >> >> Maxime >> > >