Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1159841imm; Wed, 20 Jun 2018 12:41:05 -0700 (PDT) X-Google-Smtp-Source: ADUXVKI6dSepk+ZwD6SyGICWjASduBrewZ75lAl0oMZRRwqRO1S4/kIC3lVb0tsSUi9I+v3xz+tv X-Received: by 2002:a17:902:8308:: with SMTP id bd8-v6mr25350842plb.329.1529523665897; Wed, 20 Jun 2018 12:41:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529523665; cv=none; d=google.com; s=arc-20160816; b=O4ADaHc8qC565bKIOZACLBdwcGIgBMTfre6bOU7FPkQYBbgTHJegfogjFKGHioIUzK UWA4JFpGlMECKmxER0JmlwnArEewL8ffElPDylsN/WMMhRzv/zZGbHgaBf61UrYnSXs7 1k/3oE/OcKSlB5W5JVCH0aXR/PV3+sP+Xf5LiiCzWRvP0GsGWtZ+UHuZ5R54sWj1sFqq od/Chewl16wEfHYCoa2Ds2ZU3gvUDJYNEzfeepB5na1ijwJSwxYA5qPArMxAgL6Q3c2B p6QtwutQJe5uHuWm2JmEhPM1Ov60gh08MBy2DOHKTn/kbU/ldfQ3JR6QVy3/PaExb29I PY9A== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=3PYWcsD3Ilf3M5oEN309ScsL8/k15U+YhIOl3Z5NTyM=; b=F833Oe7O2JYDHmY7Bap/59hNed2tVtKIr70OQofdseiPdc5yBpL2gO6g6TW4uRYuvH xfnOnJW+X3U60T3g5y19GNcZuwnASarluW9cD00DTZl6qVX6+IwSS/QmKq9+rupkI/2/ lazwy4n3N39JncFFs8FCGfuhB5WiZCzv7hF4c/QFyEQsEBgOWPdTXiXGTcfvplHERT4s UoMle63J7yCwgJXwM4eQQiezU1DCKC1P9A6ZnzRV0ED8fTDO7MiNT05ZKcyD2Mt7sLHD CkTrVVSSTaAnj9UF5FjnRL3fWbr1iM1U9nVDthinpTFNxeVw8AqCq3PlJ1kt/qKfGLK2 Xccw== ARC-Authentication-Results: i=1; mx.google.com; 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 w2-v6si2528998pgs.59.2018.06.20.12.40.51; Wed, 20 Jun 2018 12:41:05 -0700 (PDT) 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; 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 S932654AbeFTTjE convert rfc822-to-8bit (ORCPT + 99 others); Wed, 20 Jun 2018 15:39:04 -0400 Received: from mailoutvs2.siol.net ([185.57.226.193]:41719 "EHLO mail.siol.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932170AbeFTTjD (ORCPT ); Wed, 20 Jun 2018 15:39:03 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.siol.net (Postfix) with ESMTP id 9ED2D520BAA; Wed, 20 Jun 2018 21:39:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at psrvmta11.zcs-production.pri Received: from mail.siol.net ([127.0.0.1]) by localhost (psrvmta11.zcs-production.pri [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id X07i_zUdikTL; Wed, 20 Jun 2018 21:39:16 +0200 (CEST) Received: from mail.siol.net (localhost [127.0.0.1]) by mail.siol.net (Postfix) with ESMTPS id B68EB520D80; Wed, 20 Jun 2018 21:39:16 +0200 (CEST) Received: from jernej-laptop.localnet (unknown [194.152.15.144]) (Authenticated sender: 031275009) by mail.siol.net (Postfix) with ESMTPA id CAE6C520BAA; Wed, 20 Jun 2018 21:39:13 +0200 (CEST) From: Jernej =?utf-8?B?xaBrcmFiZWM=?= To: Chen-Yu Tsai Cc: Maxime Ripard , Rob Herring , David Airlie , Gustavo Padovan , Maarten Lankhorst , Sean Paul , Mark Rutland , dri-devel , devicetree , linux-arm-kernel , linux-kernel , linux-clk , linux-sunxi Subject: Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate Date: Wed, 20 Jun 2018 21:37:44 +0200 Message-ID: <2581098.bNJirayF9O@jernej-laptop> In-Reply-To: References: <20180612200036.21483-1-jernej.skrabec@siol.net> <3871160.F3Km1rQkUz@jernej-laptop> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a): > On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec wrote: > > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a): > >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec > >> > >> wrote: > >> > Hi, > >> > > >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a): > >> >> Hi, > >> >> > >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote: > >> >> > TV TCONs connected to TCON TOP have to enable additional gate in > >> >> > order > >> >> > to work. > >> >> > > >> >> > Add support for such TCONs. > >> >> > > >> >> > Signed-off-by: Jernej Skrabec > >> >> > --- > >> >> > > >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++ > >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++ > >> >> > 2 files changed, 15 insertions(+) > >> >> > > >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c > >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index > >> >> > 08747fc3ee71..0afb5a94a414 > >> >> > 100644 > >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c > >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c > >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device > >> >> > *dev, > >> >> > > >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n"); > >> >> > return PTR_ERR(tcon->clk); > >> >> > > >> >> > } > >> >> > > >> >> > + > >> >> > + if (tcon->quirks->has_tcon_top_gate) { > >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top"); > >> >> > + if (IS_ERR(tcon->top_clk)) { > >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus > >> >> > clock\n"); > >> >> > + return PTR_ERR(tcon->top_clk); > >> >> > + } > >> >> > + clk_prepare_enable(tcon->top_clk); > >> >> > + } > >> >> > + > >> >> > >> >> Is it required for the TCON itself to operate, or does the TCON > >> >> requires the TCON TOP, which in turn requires that clock to be > >> >> functional? > >> >> > >> >> I find it quite odd to have a clock that isn't meant for a particular > >> >> device to actually be wired to another device. I'm not saying this > >> >> isn't the case, but it would be a first. > >> > > >> > Documentation doesn't say much about that gate. I did few tests and > >> > TCON > >> > registers can be read and written even if TCON TOP TV TCON gate is > >> > disabled. However, there is no image, as expected. > >> > >> The R40 manual does include it in the diagram, on page 504. There's also > >> a > >> mux to select whether the clock comes directly from the CCU or the TV > >> encoder (a feedback mode?). I assume this is the gate you are referring > >> to > >> here, in which case it is not a bus clock, but rather the TCON module or > >> channel clock, strangely routed. > >> > >> > More interestingly, I enabled test pattern directly in TCON to > >> > eliminate > >> > influence of the mixer. As soon as I disabled that gate, test pattern > >> > on > >> > HDMI screen was gone, which suggest that this gate influences something > >> > inside TCON. > >> > > >> > Another test I did was that I moved enable/disable gate code to > >> > sun4i_tcon_channel_set_status() and it worked just as well. > >> > > >> > I'll ask AW engineer what that gate actually does, but from what I saw, > >> > I > >> > would say that most appropriate location to enable/disable TCON TOP TV > >> > TCON > >> > gate is TCON driver. Alternatively, TCON TOP driver could check if any > >> > TV > >> > TCON is in use and enable appropriate gate. However, that doesn't sound > >> > right to me for some reason. > >> > >> If what I said above it true, then yes, the appropriate location to > >> enable > >> it is the TCON driver, but moreover, the representation of the clock tree > >> should be fixed such that the TCON takes the clock from the TCON TOP as > >> its > >> channel/ module clock instead. That way you don't need this patch, but > >> you'd add another for all the clock routing. > > > > Can you be more specific? I not sure what you mean here. > > For clock related properties in the device tree: > > &tcon_top { > clocks = <&ccu CLK_BUS_TCON_TOP>, > <&ccu CLK_TCON_TV0>, > <&tve0>, > <&ccu CLK_TCON_TV1>, > <&tve1>; > clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1"; > clock-output-names = "tcon-top-tv0", "tcon-top-tv1"; > }; > > &tcon_tv0 { > clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>' > clock-names = "ahb", "tcon-ch1"; > }; > > A diagram would look like: > | This part is TCON TOP | > > v v > CCU CLK_TCON_TV0 --|----\ | > > | mux ---- gate ----|-- TCON_TV0 > > TVE0 --------------|----/ | > > And the same goes for TCON_TV1 and TVE1. > > The user manual is a bit lacking on how TVE outputs a clock though. I didn't yet received any response on HW details from AW till now, but I would like to post new version of patches soon. While chaining like you described could be implemented easily, I don't think it really represents HW as it is. Tests showed that these two clocks are independent, otherwise register writes/reads wouldn't be possible with tcon- top gate disabled. I chose tcon-top bus clock as a parent becase if it is not enabled, it simply won't work. However, if everyone feels chaining is the best way to implement it, I'll do it. Best regards, Jernej