Received: by 10.223.176.46 with SMTP id f43csp1039373wra; Wed, 24 Jan 2018 09:39:05 -0800 (PST) X-Google-Smtp-Source: AH8x226EjfpUEWdT+x000/RI8eB69QG7mvWkZ1mTct8lWDXLaWD5fHYoBstH4GN8cWF4jewiE9dh X-Received: by 2002:a17:902:20e8:: with SMTP id v37-v6mr8747577plg.66.1516815545538; Wed, 24 Jan 2018 09:39:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516815545; cv=none; d=google.com; s=arc-20160816; b=M6MuJdlCIaaxLixXU7dW1ZC5SgnEE2e0ZbTOHghVv8DdnMUVwIe1zMEW8op6dgEEwo OtahAhteFXV5GzRTJlo2VoTIOfo8gpdNc2NTEBf5jfMW7Okw1FvdIdrxeKe4QCTNoXK3 fN+MDN/zf9keuEUtZo1jwScs4PiYV1xGUmSk6IrvgA+TedOMLU5/xM8a3axt6v9jn6pR uWNl0jRuLc/H1RotzuoJhpApEQ5kpIe/OaFegaD6GoQA51D0h78ju9KJkMlCNesqMbyM bsUHzFguf2LjK599DUPdXeEEKM605MKK83ZVqXGixbVZs6URN3CbwiioHHXuHL6URTeT hczA== 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=uVEKA0gUuS0/g2bqntDr38OsxupMuI9OEZjU1WAXavA=; b=YRuXvloUkBRWdz11D0mdGk7fvutHD2UXAXIryUAv4pEJdnJf+1xAR4w+U3GsvjuvAR +yfXb9qx9RocUd1LUtUW5BLa/eELpggG0wHpVYdnAqWeO91l8218iiGjwwv25e+9uq9a 6x1kqhzY8olhUxWYnw8Zf1S5OucgtACKQYVUV1rIU2hSbpjBtX/AKhcBq/9wWFr87wrK 8C2iGSJ3jy5i4Shm2c3r5O4hgmLhyfFmzgvpwciNrh8SU9skrv3Ndc5wwxFRKmbl333T aM/xa0qDjFSTVPZROKDEMkv4QL+zb6qChBL+DumujuAC3uTwa/lRFRXn5IBisRHEo5uz Dtng== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@micronovasrl.com header.s=dkim header.b=jtzirEwT; 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 j3-v6si482855pld.676.2018.01.24.09.38.51; Wed, 24 Jan 2018 09:39:05 -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=jtzirEwT; 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 S964974AbeAXRiY (ORCPT + 99 others); Wed, 24 Jan 2018 12:38:24 -0500 Received: from mail.micronovasrl.com ([212.103.203.10]:58850 "EHLO mail.micronovasrl.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964840AbeAXRiT (ORCPT ); Wed, 24 Jan 2018 12:38:19 -0500 Received: from mail.micronovasrl.com (mail.micronovasrl.com [127.0.0.1]) by mail.micronovasrl.com (Postfix) with ESMTP id 07D52B00B83 for ; Wed, 24 Jan 2018 18:38:18 +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= 1516815496; x=1517679497; bh=a9YNUHBPiW8TUy3zGlxQmkQybjCDuu7mQ/X GHUYuEd8=; b=jtzirEwTuI4UMbTafhJd5AoWyjePyMJ5FeidCzSEH0CwWhI2Sgs H86myi7deiGP8YZaIAye0Fn+UoV5ENSNtXINyGB9lnNim+5DW93GKTDc/WCYHC4g U9k+yRvFeNGSXnPPNd1lTuLculLAb2QO7lRrS4dAUGzgzxhW1cxFmdK8= 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 jFEC43SBoP_b for ; Wed, 24 Jan 2018 18:38:16 +0100 (CET) Received: from [192.168.123.11] (unknown [192.168.123.11]) by mail.micronovasrl.com (Postfix) with ESMTPSA id 5D025B0098B; Wed, 24 Jan 2018 18:38:16 +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> Message-ID: <59f7b542-3b1d-ff62-e290-37c47f4075ff@micronovasrl.com> Date: Wed, 24 Jan 2018 18:38:17 +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: 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 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. 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 >> > >