lkml.org 
[lkml]   [2018]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly
    From
    Date
    Hi,

    Il 08/02/2018 21:40, Maxime Ripard ha scritto:
    > On Wed, Feb 07, 2018 at 01:49:59PM +0100, Giulio Benetti wrote:
    >> Hi,
    >>
    >> Il 07/02/2018 11:39, Maxime Ripard ha scritto:
    >>> On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
    >>>>>>> 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
    >
    > Have you tested the option 4 and 5 there too?
    >
    >> 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
    >
    > Ok, great, so Chen-Yu was right :)
    >
    > I guess the option 5 (DCLK/2 phase 0) is still to early, just like
    > you've shown in the previous captures?

    Exactly, it is like this:
    https://pasteboard.co/H4r8QRe.png but with clock divided by 2.

    >
    >> Also I've found that TCON1 has not this feature,
    >> nor first, nor second case(at least is not described on user manuals).
    >
    > At lot of things are not described, unfortunately...
    >
    >> 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.
    >
    > You can base that on the compatible, and add a field in the
    > sun4i_tcon_quirks structure, that will avoid the if statements you
    > mentionned.
    >
    >> 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"
    >
    > So that would mean sampling at raising edge on this one??

    Exactly rising edge.

    >
    >> - As inverted => "0x0 => normal phase"
    >
    > And falling edge?

    Yes.

    >
    > If so, and if remember the captures properly, the sampling would occur
    > right before the rise, and not really around the fall.
    >
    > Would 2/3 be better here?

    Yes, you're right, 2/3 phase is better:

    1/3 phase: https://pasteboard.co/H4VehON.png
    2/3 phase: https://pasteboard.co/H4Veq8a.png

    Take a look at the bit in middle(yellow) sampled by clock(blue).

    Rising edge is almost in the middle of D0 bit.

    >
    >> 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?
    >
    > I guess we can make that part applicable to all SoCs, we haven't seen
    > any significant differences on those part.

    So let's keep:
    - As normal(rising edge) => IO_POL_REG "0x2 => 2/3 phase"
    - As inverted(falling edge) => IO_POL_REG "0x0 => normal phase"

    Ok?

    >
    > Maxime
    >


    --
    Giulio Benetti
    CTO

    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

    \
     
     \ /
      Last update: 2018-02-15 19:06    [W:5.709 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site