Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp38736pxb; Wed, 1 Sep 2021 21:10:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxp6SqNKHgRPrWdQ1b9yN/S2xzKZx7xcxf3UYaGwXIc0vf/Bth28LKYkoabszekE/ZM+05 X-Received: by 2002:a17:906:3bc1:: with SMTP id v1mr1490197ejf.182.1630555817082; Wed, 01 Sep 2021 21:10:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630555817; cv=none; d=google.com; s=arc-20160816; b=fgtX4DqoXH9eCOsGMWpRLi/gA9CBFdzFZZE5xLAkAdwnlAO2kTH9o5RRrK2Yc472S+ rh82f6zs6C5BroB+cHrdTnNdrQ2CnlkBd6Fr/+D/mQuqLdFwx3hI7dSMpNp22eLpHQ/j UbCRHBKlDCEBI3tzlycHEE0hgYHN+ZzCUiFW/3F78jG1O7I7WVIBj7662qrwWNrpDFBC 9+x8+RpQXjoyOV1iRA6tRapi4PApszwMLrKoNFb+T6eMcKPexJ/Y4F612p3ckHRG5UU2 FMZXhtjQ6Ib5Nh+ZlkKdi8v4Cwk7aaGBPSHeZIYEYiTanGSxEEYjMFSy2trf4C4bNSqJ 6NNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:date:to:cc:from:subject :references:in-reply-to:content-transfer-encoding:mime-version :dkim-signature; bh=HpDiHPr5tzHytCqu5CQZscZspq4NcytE/1CKZEFxjc8=; b=d1ZMzQD9+9i9JR0xfGizK9LWBQI21xVRvR/upiuoBTE4iWyV3GHrGohylAUvsGvejk KfbCS0r0eoS9yrOzhyYwEQsN+pWg5MjOAERI2rnvDlbEmFpkzhnW9JKutzh+FGYUfa8K KueQvNRgEudwuv3e73vPhN1CeuJWq+j3SiUJQOC2tFgipyIQYh5dzHEs/TbaIpmJAo3Z hbJmZT1/6L9cGJ+DCVqPVHTLOi0Y85FLZYFV1RJV9SP2wWVL3kukGahDYZr1AMCW94nQ rrNNkYSzMaKpJ9smRQOG73HQlINzZ7z+gxBVpqKlM9JY+WkfawuhQSFa4u0+VWTJOqd5 4TuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BkJcSTHP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ec31si852807edb.235.2021.09.01.21.09.51; Wed, 01 Sep 2021 21:10:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BkJcSTHP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242373AbhIBDrG (ORCPT + 99 others); Wed, 1 Sep 2021 23:47:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:41794 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233122AbhIBDrF (ORCPT ); Wed, 1 Sep 2021 23:47:05 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BF09761041; Thu, 2 Sep 2021 03:46:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630554367; bh=e/r7aNYpXqByZsD0ObhSpe/4xl4wcGCv20OudDQBW9Y=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=BkJcSTHPMbL1+5MtpZOJLVg+Nnrfc2PyezFl0mS8WjZ6eQrzEDmGhFdhwXSgDGbJn OjFzEFjxRgH48VZxYkfLoV3a1pBh1tVTfMUKA92k8S9mxeI5AoHJjwSFm5Hhqpotm6 vcl9GRWine+M1ZEkmEPukQzrDx1wKGjzZ1wPkMcrIuUpSzd9b0PHLnGAUgM4p5S0zK DtOo0e5p9VKARBXoOumhoNCs9lNRcCCByZK5muQyPayjzlKB2351XVtIiaUQw2HB3D GZbLb0PlDH2Ca/z0EikPWuZ742PsJyJykQPtVpMw9RSspJMVgpgwDoKo+lRoqCQF2t DfjIKKYWgeisg== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20210830182445.167527-1-marijn.suijten@somainline.org> <20210830182445.167527-2-marijn.suijten@somainline.org> <163036177339.2676726.12271104951144475163@swboyd.mtv.corp.google.com> <163036399040.2676726.5816296584899284140@swboyd.mtv.corp.google.com> <163047451225.42057.10341429266269552927@swboyd.mtv.corp.google.com> Subject: Re: [PATCH v2 1/2] drm/msm/dsi: Use "ref" fw clock instead of global name for VCO parent From: Stephen Boyd Cc: Bjorn Andersson , linux-arm-msm@vger.kernel.org, phone-devel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht, AngeloGioacchino Del Regno , Konrad Dybcio , Martin Botka , Jami Kettunen , Pavel Dubrova , Andy Gross , Michael Turquette , Rob Clark , Sean Paul , David Airlie , Daniel Vetter , Dmitry Baryshkov , Abhinav Kumar , Jonathan Marek , Matthias Kaehlcke , Douglas Anderson , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, Stephen Boyd To: Bjorn Andersson , Dmitry Baryshkov , Marijn Suijten Date: Wed, 01 Sep 2021 20:46:06 -0700 Message-ID: <163055436647.405991.3416730531261875767@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Marijn Suijten (2021-09-01 01:49:10) > Hi Stephen, >=20 > On 2021-08-31 22:35:12, Stephen Boyd wrote: > > Quoting Marijn Suijten (2021-08-30 16:10:26) > > >=20 > > > I'm 95% sure this shouldn't cause any problems given current DTs and > > > their history, but that's probably not enough. This might also impact > > > DTs that have not yet been upstreamed, but afaik the general stance is > > > to not care and actually serve as a fair hint/warning before new DTs > > > make it to the list. > > >=20 > > > If there is a protocol in place to deprecate, warn, and eventually > > > remove this reliance on global clock names I'm more than happy to add > > > .name as a temporary fallback, even if likely unneeded. Otherwise we > > > might never get rid of it. > >=20 > > I'm not aware of any protocol to deprecate, warn, and remove the > > fallback name. It's a fallback because it can't ever really be removed. >=20 > That is unfortunate, I was hoping for a breaking "kernel release" at > some point where we could say "no more, update your DTs first". But > that may not be possible in every scenario? >=20 > > Anyway, if you're not willing to add the .name then that's fine. >=20 > I feel like .name has caused more problems for us than it solves, but in > a fallback position it might be fine. My main gripe is that I don't > want DT to rely on the clock to also be discoverable through the clock > tree, which we've seen on many occasions (not sure if the former was > done upstream, but: "xo" being renamed to "xo_board", and DSI PLL clocks > loosing +1 causing a naming mismatch with what mmcc expects, to name > some examples). Omitting .name is the only way to enforce that. The simple approach to take is anything new should use fw_name. The name member is only there for the backup mode when the DT isn't properly setup to describe connections between clk controllers. If the code is new then name can be omitted and everything is OK. Otherwise, if parent_names was already being used, then most likely it will need to be set as .name in the clk_parent_data struct to maintain compatibility. If parent_names was wrong, then it was all broken to begin with and .name can be omitted. >=20 > > We can > > deal with the problem easily by adding a .name in the future if someone > > complains that things aren't working. Sound like a plan? If so, it's > > probably good to add some sort of note in the commit text so that when > > the bisector lands on this patch they can realize that this > > intentionally broke them. >=20 > I'm all for this but lack the industrial knowledge to sign off on the > approach. Bjorn and Dmitry should ack/agree before going ahead (you may > wonder why I'm worrying about getting clock drivers and DT in sync on > platforms I don't own...): >=20 > We have the following situations: > - apq8064 used the wrong clock. Bjorn acknowledged that landing the DT > fix in 5.15, and this patch in 5.16 should give enough time for DT to > be updated (this is nothing we can fix with .name anyway). > - msm8974 doesn't have the clock at all. Dmitry recommended to add > .name for this specific case, but I'm wondering if the 5.15 -> 5.16 > window is enough to update DTs too? > - msm8916 and sdm845 had the missing "ref" clock added three years ago. > Would a 5.16 kernel still work in any meaningful way with a DT that > old? >=20 > Should we decide on a case-by-case basis whether to add .name, ie. only > for (some/all) of the aforementioned SoCs? >=20 I sort of glossed over this, sorry. Hopefully what I wrote above can guide you and then we shouldn't really need to worry about anything?