Thread (23 messages) 23 messages, 4 authors, 2018-02-28

[PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

From: Giulio Benetti <hidden>
Date: 2018-02-07 12:50:04
Also in: dri-devel, lkml

Hi,

Il 07/02/2018 11:39, Maxime Ripard ha scritto:
On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
quoted
quoted
quoted
quoted
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

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.
If you have an A33 handy, you probably want to read that mail:
https://lists.freedesktop.org/archives/dri-devel/2017-July/147951.html

Especially the 90-phase part.
Here is a summary of different SoCs TCON:
With DCLK_Sel:
0x0 => normal phase
0x1 => 1/3 phase
0x2 => 2/3 phase

A10, A20

With DCLK_Sel:
0x0 => normal phase
0x1 => 1/3 phase
0x2 => 2/3 phase
0x5 => DCLK/2 phase 0
0x4 => DCLK/2 phase 90

A31, A31s, A33, A80, A83T

Also I've found that TCON1 has not this feature,
nor first, nor second case(at least is not described on user manuals).

So I could handle differently according to SoC.
Unfortunately there is not TCON register keeping IP version,
so the only way I see is to create a long if-or statement to understand
which kind of TCON we're using.

But what sounds not the best to me, is that DCLK is divided by 2 if
using phase 90. So we need to reconsider also bitclock driver according
to this.
I don't know if it make sense.

IMHO, I would keep only:
- As normal => "0x1 => 1/3 phase"
- As inverted => "0x0 => normal phase"

According to scope captures above on both A20 and A33.
Unfortunately I don't have other boards for the other SoCs to take captures.

What do you think?
Maxime
-- 
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help