Received: by 10.223.176.46 with SMTP id f43csp1159908wra; Wed, 24 Jan 2018 11:38:12 -0800 (PST) X-Google-Smtp-Source: AH8x227HPMzRTrt769oM1TXjJVjMNWpY0jz0+4xgv2y1hLGRigIeDZyyt0XN2uhSeYwqN7VkN+A5 X-Received: by 10.101.83.8 with SMTP id m8mr11733991pgq.247.1516822692115; Wed, 24 Jan 2018 11:38:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516822692; cv=none; d=google.com; s=arc-20160816; b=dAqsmjC3wz2REW4WLDXJOemKuiU6stFeXzA098/9NS9J7mZsgnpyg+eF3ozf1quRGi SpfQpcVdR/5Ot2xF+pL9evCWDbu/M3mw6GVwNxDzKpaBEg3w6nHh8urwbytB4xelGGM/ ygsz7CTRNjjFicVrBhXThiCAK7DBBOkeUcwC9QY+CtOVyhAQhU5FVvruEEZHHFGytZFY 1zhGpcFRqfcRgMDlxGjIpI4rOBPP0tmx01qrQpQXncOKVwdVe8dqupQoFdX4u4wHLTvt Kz4ekQrLOAAQ2yraWM2DXtLPlACIc88+6DOhHA7YenwQRJaO+57ZgNy5Dish78ttqnGi eMiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject:dkim-signature :arc-authentication-results; bh=2RZjG+5kzGuWJCQxt74zBFqL6Q6KfP5TngxrccH3Y1E=; b=DL4QrAz1kYQAW+LpJbARqXjIqlClDlbBSC8/yp3oYpGLkbry6zoRUAYg/3iqxbemS5 OUGqS4WcoWqzKvRinsmWTeQycTG0VViWtbnnovMUa4arnJWSl4DRq36SHjsiDB0S4wb+ thNokEEilUotWzY2jjLmR/cUwXPX/DVODX4zOiu50DCozviXXkhScQdSy+EYj4lBzMDA R8iOumQOzwnRedee36VIu7xFJB1qaCqv9bL9cgX38koY6MxBkvzkKAmHlt4iNaeEz/vc FzuyTF8QJKf0MLWEOMXORQmetRpT5IIF86pzejLBuqnnPTKuyHH/kn1wuSD6qO+Inyer W/Ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@micronovasrl.com header.s=dkim header.b=ejPPEP+V; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x11-v6si613959plm.734.2018.01.24.11.37.57; Wed, 24 Jan 2018 11:38:12 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@micronovasrl.com header.s=dkim header.b=ejPPEP+V; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752557AbeAXThc (ORCPT + 99 others); Wed, 24 Jan 2018 14:37:32 -0500 Received: from mail.micronovasrl.com ([212.103.203.10]:34128 "EHLO mail.micronovasrl.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752339AbeAXThb (ORCPT ); Wed, 24 Jan 2018 14:37:31 -0500 Received: from mail.micronovasrl.com (mail.micronovasrl.com [127.0.0.1]) by mail.micronovasrl.com (Postfix) with ESMTP id 05F7AB01537 for ; Wed, 24 Jan 2018 20:37:30 +0100 (CET) Authentication-Results: mail.micronovasrl.com (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=micronovasrl.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=micronovasrl.com; h=content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:references:to:from:from:subject:subject; s=dkim; t= 1516822648; x=1517686649; bh=l6z0O/Ak8E40CiFHIvgBTrDtvjZaNEpxtYm DYizlb2I=; b=ejPPEP+VaGC8Qc+mVBc5OtOBO3wC0uaJiRUwhJ/PoihVOPf3a2d 6/b/iWQxkTxCmDtZwbQqXEME1cjJmCVCJssO25LS3lhAhNjRmSE2wAxFq89YcCdg u3CXaStFax8mvimg37rf1kXe8ghhcUKM11oJ1rsDC+B9w86Ee4rzudMU= X-Virus-Scanned: Debian amavisd-new at mail.micronovasrl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=4.5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=unavailable autolearn_force=no Received: from mail.micronovasrl.com ([127.0.0.1]) by mail.micronovasrl.com (mail.micronovasrl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rH3NDtUmO5Pl for ; Wed, 24 Jan 2018 20:37:28 +0100 (CET) Received: from [192.168.123.11] (unknown [192.168.123.11]) by mail.micronovasrl.com (Postfix) with ESMTPSA id 82671B005F1; Wed, 24 Jan 2018 20:37:27 +0100 (CET) Subject: Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly From: Giulio Benetti To: Maxime Ripard Cc: airlied@linux.ie, wens@csie.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org 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> <59f7b542-3b1d-ff62-e290-37c47f4075ff@micronovasrl.com> Message-ID: <9929d894-53c3-a7e9-a328-a00cfc1ef546@micronovasrl.com> Date: Wed, 24 Jan 2018 20:37:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <59f7b542-3b1d-ff62-e290-37c47f4075ff@micronovasrl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: it Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Il 24/01/2018 18:38, Giulio Benetti ha scritto: > 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 >>>> >>>> PVSYNC and PHSYNC only >>>> >>>> Signed-off-by: Giulio Benetti >>> >>> 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 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. Do you agree with me? > > 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