From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4E680C4167B for ; Mon, 27 Nov 2023 09:17:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:In-reply-to: Date:Subject:Cc:To:From:References:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Wq/4hyuZ7fhPmC4x+hoLS+8f072EY3RqxDTuApmLJy4=; b=nKNtJFnybAXuG6 L9GoWi4sJAUDBpZAa3JWHWthAtEnD+jAjzpgsyg5BKb926pjfqI8/ZU3b1RkuLV3jiPwpdxw/COeY vy1YFxDI2K5cFbslkCRKSzaR119zr+NPGV+gcZV0FNMlXdBUBVjqiX7S4UIQqV2AwpQSErRyvBy2r bnfKyb4NiDBGP3DJkDfpknQHlZLFTG+Nn6TvQDEzFTtfFJKA/MdwxZvU3GjDEAUZVRHgnqFGHse+w +KK/pls3H44IhuVfrpxP5BXE/xJ0idCydihSyxy0qLYwujuQ6H6xEdo8SYkDQURLteVX7c+mBVocd Ug84o3DLz0p8ErHi98Og==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r7XkI-001x24-36; Mon, 27 Nov 2023 09:17:38 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r7XkC-001wyK-1y for linux-phy@lists.infradead.org; Mon, 27 Nov 2023 09:17:36 +0000 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2c878e228b4so48415131fa.1 for ; Mon, 27 Nov 2023 01:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1701076649; x=1701681449; darn=lists.infradead.org; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=bEIoGh5O/BzqSyDdvmfvLEUiDH4K1xP/uQvVNiufgcU=; b=VPW8POsDcupfKptbXQR90kbleqlgwLsdgrgujMJy36DLn3dtRvFD8GswBPtLG7gBZQ RZUpRqo3tD9g4Y2cAEo62yYj1me422uGMVvtAdGJ3ceSsJGFoirvDnBb997UwbIMminG uoXwv5tiw+kCmqYvhaymoywHXjN3y8cu/2mH/OAJREhezepACLiddQ0J7F/4EpCdsQF1 gJzWJdrB3E2pHxuMgITAlPuGFEBV/8Ai4ZAPekoCSh14SjAQCoCAFDxJzHODyc3CHxtx +o5JKgPqm3ebRIM/Zqkf/E3WQJvb+HYub0/W9++pZDTitWW4Rwyv3TSWQPF0OilEjvs9 +Tdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701076649; x=1701681449; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bEIoGh5O/BzqSyDdvmfvLEUiDH4K1xP/uQvVNiufgcU=; b=clx+eBZE37ekqzFmK9iZ18Ev6ClOKZo/DZqCK1DN7t2l1r7zolnvdfXk4xuhYYXiUR arVRAebzrQ6zX0/NOdSQJ/CaChXEBJtDBGnuBbYyWcjiK2ccSu++brZfoXwPiRQGDTWp 81Hn/JP1p1j3hU9OV1KqH0yp085sDiNiIyV3Ewy8+2vh4f14xLcQnoJ3nlF42USryhE+ DLN9UAC4HgcTAhJsvwh46fuVFszm/zoakuD8HApIMBoNwT13fhAekDRnmxxPIqgjbG5M gLwzHkTDnR46M4tcqHCMmCObbVQAHlcqZ2RnZTyzEwR7rH4DElYK8W2Lye825F3Ww6CC vYhw== X-Gm-Message-State: AOJu0YxK1yplgkV4eOoj78it+MGCFaMM4GJ0bOWsu1RLaN3Nby0WSwWB 5ssQ8T+ujtX2QIxxGBm3VY96MQ== X-Google-Smtp-Source: AGHT+IGy/JmtaB1RId0/b5RlEgolNkKFgTxdlq7MWzbR6GDUGon0doGnidwbBevghTckT6+7ygTSrA== X-Received: by 2002:a2e:8387:0:b0:2c8:8745:8f0b with SMTP id x7-20020a2e8387000000b002c887458f0bmr6234114ljg.47.1701076648575; Mon, 27 Nov 2023 01:17:28 -0800 (PST) Received: from localhost ([2a01:e0a:3c5:5fb1:fd31:fff0:e26c:d593]) by smtp.gmail.com with ESMTPSA id dm16-20020a0560000bd000b0032d09f7a713sm11439739wrb.18.2023.11.27.01.17.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Nov 2023 01:17:28 -0800 (PST) References: <20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed139e6@linaro.org> <20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-8-95256ed139e6@linaro.org> <1jbkbjdxk8.fsf@starbuckisacylon.baylibre.com> <1j34wvdtux.fsf@starbuckisacylon.baylibre.com> <41a1246e-c885-460a-8208-16844e95e1ae@linaro.org> User-agent: mu4e 1.10.8; emacs 29.1 From: Jerome Brunet To: neil.armstrong@linaro.org Cc: Jerome Brunet , Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Kevin Hilman , Martin Blumenstingl , David Airlie , Daniel Vetter , Jagan Teki , Nicolas Belin , Vinod Koul , Kishon Vijay Abraham I , Remi Pommarel , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-phy@lists.infradead.org, Rob Herring Subject: Re: [PATCH v9 08/12] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF Date: Mon, 27 Nov 2023 09:38:28 +0100 In-reply-to: <41a1246e-c885-460a-8208-16844e95e1ae@linaro.org> Message-ID: <1jjzq3zhaw.fsf@starbuckisacylon.baylibre.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231127_011732_682537_FEDCBB05 X-CRM114-Status: GOOD ( 26.21 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org >> >>> >>> I suspect mipi_dsi_pxclk_div was added to achieve fractional vclk/bitclk ratios, >>> since it doesn't exist on AXG. Not sure we would ever need it... and none >>> of the other upstream DSI drivers supports such setups. >>> >>> The main reasons I set only mipi_dsi_pxclk in DT is because : >>> 1) the DSI controller requires a bitclk to respond, pclk is not enough >>> 2) GP0 is disabled with an invalid config at cold boot, thus we cannot >>> rely on a default/safe rate on an initial prepare_enable(). >>> This permits setting initial valid state for the DSI controller, while >>> the actual bitclk and vclk are calculated dynamically with panel/bridge >>> runtime parameters. >> Nothing against setting rate in DT when it is static. Setting it then >> overriding it is not easy to follow. > > Yup, would be simpler to only have parenting set in DT, since it must > stay static, I'm fine trying to move rate setup to code. > >> To work around GP0 not being set, assuming you want to keep rate >> propagation as it is, you could call clk_set_rate() on cts_encl (possibly w/o >> enabling it) to force a setup on gp0 then clk_prepare_enable() on >> pxclk. You'd get a your safe rate on GP0 and the clock you need on pxclk. >> It is a bit hackish. Might be better to claim gp0 in your driver to >> manage it directly, cutting rate propagation above it to control each >> branch of the subtree as you need. It seems you need to have control over >> that anyway and it would be clear GP0 is expected to belong to DSI. > > Controlling the PLL from the DSI controller seems violating too much layers, > DSI controller driver is not feed directly by the PLL so it's a non-sense > regarding DT properties. Not sure what you mean by this. You have shown in your the commit message that the DSI clocks make significant subtree. I don't see a problem if you need to manage the root of that subtree. I'd be great if you didn't need to, but it is what it is ... > > Setting a safe clock from the DSI controller probe is an idea, but again I > don't know which value I should use... You mentionned that the problem comes DSI bridges that needs to change at runtime. I don't know much about those TBH, but is there anyway you can come up with a static GP0 rate that would then be able to divide to serve all the rates bridge would need in your use case ? GP0 can go a lot higher than ~100MHz and there are dividers unused in the tree it seems. I suppose there is a finite number of required rate for each use case ? If there are not too many and there is a common divider that allows a common rate GP0 can do, it would solve your problem. It's a lot of if but It is worth checking. This is how audio works and DT assigned rate is a good match in this case. > > I'll review the clk parenting flags and try to hack something. > > Thanks, > Neil > > -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy