linux-kernel - Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <59f7b542-3b1d-ff62-e290-37c47f4075ff@micronovasrl.com>
Date:   Wed, 24 Jan 2018 18:38:17 +0100
From:   Giulio Benetti <giulio.benetti@...ronovasrl.com>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     airlied@...ux.ie, wens@...e.org, dri-devel@...ts.freedesktop.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE
 correctly

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 <giulio.benetti@...ronovasrl.com>
>>>
>>> PVSYNC and PHSYNC only
>>>
>>> Signed-off-by: Giulio Benetti <giulio.benetti@...ronovasrl.com>
>>
>> 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
>>
> 
>