Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp909522imu; Tue, 11 Dec 2018 09:24:20 -0800 (PST) X-Google-Smtp-Source: AFSGD/UtJ5U6lZJP0Q6+amPk5dnSXf5wmsedlqja0E19k/D1BsSHjgomL7OEdK+e+eq4KKI1jbCE X-Received: by 2002:a63:68c4:: with SMTP id d187mr15149793pgc.11.1544549060289; Tue, 11 Dec 2018 09:24:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544549060; cv=none; d=google.com; s=arc-20160816; b=prCRj1VCAglXwCWghntjAKCuXl6wiURtie/brxEuDDa+R2UkOhYFY9SR3g4+BTFUT6 snb9QvWWBcoWkk1+EFIh/e9Zaj8CMKpzJEBNHHDbLr96W5MPIhkJbcQcebgvtz+WGymO opoQkH6SBBft/+Uh+xkMYqMEQFQ63AhRx6s/k0yqX848iLIq5ZIidLIMfAfF/AVp7pov MBKpgCCQ8dXZ48OcIcX06cB8E81c7HJpLoWwr1+p4bfXAVC8WSt3o3sqJu8tYGZf0BMr 7G6C37NMv+rUtaqtSgaPcUcjSWsk2VTI/s1nWwwweZv4Egk8zuQC70TNZv00Jae0Us9P /Wwg== 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:from:references:cc:to:subject:dkim-signature; bh=VPraqUW3GhkTKal5st/29AZxQVMUwnzPhhwvGBBl7kw=; b=wQA+RTMQ4wnhN0IPjhHEvpY9no3xYGd/Vz1tuTq3WkqxXKs3FNeVDu1rI3ULheX4Rm ek8HO+FISOGDGgJQBAGPw74iMtAgRvVxfW9G2dzQb8FB0ukOwYjK61J2fdV/ggvZSZ1b Sz9CuZEPWdu53S3/MNme0Q8CY4NbrkMPr8QHjK3j0LxPlbFRy3t14n2Lo491JP5JlFcR LM46M1xuMxph+lkyKvMzXx1E73dx116HCoV37ydIZBJeKD25+pS/Kuqzo7zMybeCdrfB lkcC5okJ75BjCcCkwiiKvjz4D93S91U+4+bBQsHjPIFSg3BNWAax2qG1CCO1gyrUHNeM 0zzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@micronovasrl.com header.s=dkim header.b="Q/XCbD4Y"; 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 u8si13348993plh.385.2018.12.11.09.24.05; Tue, 11 Dec 2018 09:24:20 -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="Q/XCbD4Y"; 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 S1727262AbeLKRUo (ORCPT + 99 others); Tue, 11 Dec 2018 12:20:44 -0500 Received: from mail.micronovasrl.com ([212.103.203.10]:42438 "EHLO mail.micronovasrl.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726464AbeLKRUo (ORCPT ); Tue, 11 Dec 2018 12:20:44 -0500 Received: from mail.micronovasrl.com (mail.micronovasrl.com [127.0.0.1]) by mail.micronovasrl.com (Postfix) with ESMTP id 9DCDFB00B91 for ; Tue, 11 Dec 2018 18:20:41 +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:from:from:references:to:subject:subject; s=dkim; t= 1544548840; x=1545412841; bh=lzUdzsh9nSO9ox+zpeQnept2f623iwFC8hL wWZnPPSs=; b=Q/XCbD4YW822u/bs0Rq3ekC73D/QRPYHFw5BVL2ICy3xLTR7h7Y aZjNbYAE5IGpZU2wa+gd0ptGHK3kGKm0kvKeivz3BSZ5K4sUdfft7hViXuV69C8d N5XQIIUpL0W2UVXY9Aufy/j9ZLcwhav5v9ZJxH2udhJHR/oevhZ43ji0= 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 WKFC7Wxxc27a for ; Tue, 11 Dec 2018 18:20:40 +0100 (CET) Received: from [192.168.2.69] (88-149-228-83.v4.ngi.it [88.149.228.83]) by mail.micronovasrl.com (Postfix) with ESMTPSA id 7C26DB00307; Tue, 11 Dec 2018 18:20:39 +0100 (CET) Subject: Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity To: Jonathan Liu Cc: Maxime Ripard , Chen-Yu Tsai , linux-arm-kernel , dri-devel , linux-kernel References: <1518717288-123578-1-git-send-email-giulio.benetti@micronovasrl.com> <57d929cf-4458-dae4-36d4-4e89170eba4a@micronovasrl.com> From: Giulio Benetti Message-ID: <05786c98-6bc9-44f1-91ea-14452448cced@micronovasrl.com> Date: Tue, 11 Dec 2018 18:20:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; 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 Jonathan, Il 11/12/2018 11:49, Jonathan Liu ha scritto: > Hi Giulio, > > On Thu, 6 Dec 2018 at 22:00, Giulio Benetti > wrote: >> >> Hi Jonathan, >> >> Il 06/12/2018 08:29, Jonathan Liu ha scritto: >>> Hi Giulio, >>> >>> On Thu, 15 Feb 2018 at 17:54, Giulio Benetti >>> wrote: >>>> >>>> Differently from other Lcd signals, HSYNC and VSYNC signals >>>> result inverted if their bits are cleared to 0. >>>> >>>> Invert their settings of IO_POL register. >>>> >>>> Signed-off-by: Giulio Benetti >>>> --- >>>> 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 3c15cf2..aaf911a 100644 >>>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c >>>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c >>>> @@ -389,10 +389,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; >>>> >>>> regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG, >>> >>> I am running Linux 4.19.6 and noticed with Olimex LCD-OLinuXino-7TS 7" >>> LCD touchscreen (Innolux AT070TN92) connected to Olimex >>> A20-OLinuXino-MICRO that the image does not display correctly after >>> this change. >>> The image is shifted to the right. >>> >>> Reverting the change results in the image being displayed correctly on >>> the screen. >>> >>> I have in the device tree a "panel" node with compatible = >>> "innolux,at070tn92" which uses the timings in >>> drivers/gpu/drm/panel/panel-simple.c. >>> >>> Any ideas? > >> >> Checking Display Datasheet: >> https://www.olimex.com/Products/Retired/A13-LCD7-TS/resources/S700-AT070TN92.pdf >> >> Page 13 section 3.3.2 you can see it needs active low VS and HS. >> >> You can refer to this Thread and check scope captures about VS and HS >> versus TCON0_IOPOL register: >> https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html >> >> There should be something that wrongly sets one of these or both: >> mode->flags |= DRM_MODE_FLAG_PHSYNC; >> and/or >> mode->flags |= DRM_MODE_FLAG_PVSYNC; >> >> Checked in panel-simple.c but it's not there. > > flags is 0 because it is not assigned in the struct definition for the panel. I don't think it is 0, because otherwise IO_POL_REG wouldn't be set to 0x03000000 but to 0. What is checked is exactly mode->flags, so the problem seems to be upstream. This is my doubt, it seems mode->flags is not initialized or overriden at a certain point, this is why I want to debug it with Jtag tomorrow. > Before this change, TCON0_IO_POL_REG would be 0x03000000 (both bits > set to 1) and image displays correctly > After this change, TCON0_IO_POL_REG is 0x00000000 (both bits set to 0) > and image doesn't display correctly. > > Checked using "devmem2 0x01c0c088" on A20-OLinuXino-MICRO Rev J. 0x03000000 as I've triple checked with scope means Positive H/Vsync, and 0x00000000 Negative H/VSync. Please check on the Thread I've pointed you above where there are all the links to the scope captures. Are you completely sure you're using the correct panel? This is because if with 0x03000000 it works correctly, it means that you're using Positive VS and HS but on datasheet on Figure 3.2 it shows that they must be negative. Do you have any chance to measure those signals with a scope? Tomorrow, while debugging, I'll re-check H/Vsync signals again. Kind regards -- 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