Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 26 Jan 2018 15:56:08 +0100
From:   Maxime Ripard <maxime.ripard@free-electrons.com>
To:     Giulio Benetti <giulio.benetti@micronovasrl.com>
Cc:     airlied@linux.ie, wens@csie.org, dri-devel@lists.freedesktop.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE
 correctly
Message-ID: <20180126145608.5s6c6ltpvrko7iyv@flea.lan>
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>
 <aa724bd5-cfb1-128c-af32-db29253f32aa@micronovasrl.com>
 <59f7b542-3b1d-ff62-e290-37c47f4075ff@micronovasrl.com>
 <9929d894-53c3-a7e9-a328-a00cfc1ef546@micronovasrl.com>
 <20180125152117.qikemrwl7f35ssjg@flea.lan>
 <d79602b9-8e04-8250-fd7f-f52b8e16c575@micronovasrl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="4rnjpwaka2i6bs3n"
Content-Disposition: inline
In-Reply-To: <d79602b9-8e04-8250-fd7f-f52b8e16c575@micronovasrl.com>
User-Agent: NeoMutt/20171215
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--4rnjpwaka2i6bs3n
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 exclusi=
ve.
> > > > > > >=20
> > > > > > > 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.
> > > > > > >=20
> > > > > > > Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.co=
m>
> > > > > > >=20
> > > > > > > PVSYNC and PHSYNC only
> > > > > > >=20
> > > > > > > Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.co=
m>
> > > > > >=20
> > > > > > Checkpatch:
> > > > > > WARNING: Duplicate signature
> > > > >=20
> > > > > Sorry I didn't use ./scripts/checkpatch.pl
> > > > >=20
> > > > > >=20
> > > > > > > ---
> > > > > > >  =A0 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
> > > > > > >  =A0 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > >=20
> > > > > > > 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,
> > > > > > >  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SUN4I_TCON0_BASIC=
3_H_SYNC(hsync));
> > > > > > >  =A0=A0=A0=A0=A0 /* Setup the polarity of the various signals=
 */
> > > > > > > -=A0=A0=A0 if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
> > > > > > > +=A0=A0=A0 if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > > > > > >  =A0=A0=A0=A0=A0=A0=A0=A0=A0 val |=3D SUN4I_TCON0_IO_POL_HSYN=
C_POSITIVE;
> > > > > > > -=A0=A0=A0 if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
> > > > > > > +=A0=A0=A0 if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > > > > > >  =A0=A0=A0=A0=A0=A0=A0=A0=A0 val |=3D SUN4I_TCON0_IO_POL_VSYN=
C_POSITIVE;
> > > > > >=20
> > > > > > I'm not sure why you were talking of the differences between NV=
SYNC
> > > > > > and PVSYNC if you're not making use of any of it here?
> > > > >=20
> > > > > 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=3D0 (giving me falling edge on dclk)
> > > > > and
> > > > > CONFIG_VIDEO_LCD_MODE=3D"....,sync:3,..."
> > > > > but digging into code, I see "sync:3" means H/VSYNC HIGH,
> > > > > but I experience both LOW during their pulse.
> > > > >=20
> > > > > >=20
> > > > > > 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 regre=
ssions
> > > > > > here.
> > > > >=20
> > > > > 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. :)
> > > >=20
> > > > Here I am with scope captures and tcon0 registers dump:
> > > > tcon0_regs =3D> https://pasteboard.co/H4r8Zcs.png
> > > > dclk_d0 =3D> https://pasteboard.co/H4r8QRe.png
> > > > dclk_de =3D> https://pasteboard.co/H4r8zh4R.png
> > > > dclk_vsnc =3D> https://pasteboard.co/H4r8Hye.png
> > > >=20
> > > > As you can see circled in reg on registers,
> > > > TCON0_IO_POL_REG =3D 0x00000000.
> > > > But on all the waveforms you can see:
> > > > - dclk_d0: clock phase is 0, but it starts with falling edge, other=
wise
> > > > 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 i=
t's
> > > > negative.
> > > >=20
> > > > You can also check all the other registers about TCON0.
> > > >=20
> > > > 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.
> > >=20
> > > Here I am with A33 waveforms:
> > > tcon0_regs =3D> https://pasteboard.co/H4rXfN0M.png
> > > dclk_d0 =3D> https://pasteboard.co/H4rVXwy.png
> > > dclk_de =3D> https://pasteboard.co/H4rWDt8.png
> > > dclk_vsnc =3D> https://pasteboard.co/H4rWRACu.png
> > > dclk_hsync =3D> https://pasteboard.co/H4rWK6I.png
> >=20
> > Thanks, that's really helpful.
> >=20
> > > 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.
> >=20
> > Indeed, HSYNC and VSYNC look inverted.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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

--=20
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

--4rnjpwaka2i6bs3n
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAlprQYcACgkQ0rTAlCFN
r3QtQw/5ARJjo1rSGVYU46pAqaRErFmGRpREl3OlWnbv/t06oBYiY3tM8oICwlPi
rWG+57V6Jnnx3ymVuF5qwts8giIqUJkyMxxo5hNgk6AO4E+09kOzEpwZx54fUZ3K
kRdG2iBOrCo/CFuBrUrqPDR6nAttzVww9UzbiFLXChTTcx3sfB4C6qhFnSzU3wKk
ZBkq4DyB33AzmhqTRklZSkTmaqFnuabgHhxEG+zMbEjbIc8xu2zen463Tanhge8p
eXurha/1xEFtwQAKhuwIeL2Rrd/C5NdOPvC8v9MkuYKFnFU0WVWIZEHi9NM75TNb
sHXjB9U+lon233MVSCnT+yE+oK2Y75C36dWKW1lAs7avsuMz69YQJ7Pt6dylk/IY
HSXdQXuY0v3aQbgvHxj9iVdY721MkQ+KwNZzyIRECjhA/utXp5gwuy53RpezDZy6
vu0S93kNE2iKuAOeA5AiyN44QlYdN+Tz/IlfqwknHvxNxqTcidAT1XaPpOc/nBmn
6N6zmnCpTGnDGGOXDf5aEBDM8wJi0H6hCoP3oXPlhRK76HOq3qljQTUyBZug2NAE
IqbxR/FH1sFaHvGSsqrjZHT7JC81DIuM0LpNNXmtsFKKBPN23OkkpBQl1Qx0dusw
mtN6BYHCDM0COxrK3jPJ+1Q6cqBNddcw7KpVfStHGL1+w/x3sic=
=ja6W
-----END PGP SIGNATURE-----

--4rnjpwaka2i6bs3n--