On Thu, Jan 25, 2018 at 05:50:18PM +0100, Giulio Benetti wrote: > > > > > > 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 <giulio.benetti@xxxxxxxxxxxxxxxx> > > > > > > > > > > > > > > PVSYNC and PHSYNC only > > > > > > > > > > > > > > Signed-off-by: Giulio Benetti <giulio.benetti@xxxxxxxxxxxxxxxx> > > > > > > > > > > > > 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. > > > > > > Here I am with A33 waveforms: > > > tcon0_regs => https://pasteboard.co/H4rXfN0M.png > > > dclk_d0 => https://pasteboard.co/H4rVXwy.png > > > dclk_de => https://pasteboard.co/H4rWDt8.png > > > dclk_vsnc => https://pasteboard.co/H4rWRACu.png > > > dclk_hsync => https://pasteboard.co/H4rWK6I.png > > > > Thanks, that's really helpful. > > > > > It behaves the same way as A20, so as I mean IO polarity, > > > all signals(except D0-D23), are inverted. > > > For A33 I've used A33-OLinuXino. > > > For A20 our LiNova1. > > > > Indeed, HSYNC and VSYNC look inverted. > > Yes, so they should be inverted inside the driver. Yep. And the LCD panels used on our boards as well in order to avoid any breakages. > > I don't really know what the polarity of D0 would be just by > > judging at that capture, but we would have noticed if the colors > > were inverted for quite some time now. > > D0-D23 are correct. > > With that capture, I mean to show you instead dclk is inverted, as > dclk samples D0 on falling edge. Ah right, DCLK being the first channel? > So 0 is NEGEDGE and 1 is POSEDGE(1/3 of clock phase). > 1/3 clock phase seems enough to me to be considered POSEDGE, > 2/3 instead risks to go too much to the right of D0(even if it could work). Do you have captures with both settings? > > DE seems to be active high though, since it's only going to be at > > a logical low level when data are not transmitted, so during the > > blank periods. > > Yes, you're right, DE is data enable, and is asserted high as 0. No, it is asserted high as 1 > But it must be added. > I'm planning to send a new patchset with all these things corrected for > kernel. Ok. > A little out of thread but: > I'd like to send one for u-boot too, > but this means also to modify every sunxi "sync:3" to "sync:0" and > vice-versa. > > What do you think? That it's going to be a nightmare... We've advertised since the very beginning something, and we're about to break it. I'm not sure we want to do that. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
