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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 262EEC433F5 for ; Tue, 12 Apr 2022 20:10:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233573AbiDLUMV (ORCPT ); Tue, 12 Apr 2022 16:12:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234944AbiDLUMA (ORCPT ); Tue, 12 Apr 2022 16:12:00 -0400 Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1A9062BEC for ; Tue, 12 Apr 2022 13:07:38 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id r8so20176974oib.5 for ; Tue, 12 Apr 2022 13:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=HS/t9fInoBASlo5XNi/0B/mBl/RmkpwKB28iS3MPbuY=; b=lkBFXM7aaukUHOGTj1Ot2swztuEx9Ac+pPU5fa3ML5oaYHBBbxyM1yco+GVNGPyiLq 0l/peM1b/Cadt9njBgMHbFAtpCoKguiT9dNODNqahVT8/WGH/VNerKkPYZJG/TpskZwE fBqS2KoJyyd6LdkFmRqpPMMyV/gLWE7/iPl+PYZ62CpL5w/OGz62cDndGa9udw6oLMxX iKZk8pYaF0t5uL3P9cxvYLkuWA2pcHseFbj8X1Xy3dZsPPohtzF+Tz+u+GgUWQeL4GyX gK41UDwjUB9xRQpkP94OVRK80uB5/oGCjMg8lrNO3ODFKkCGVG7npVuhEY1xLpqvEdD4 WLkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=HS/t9fInoBASlo5XNi/0B/mBl/RmkpwKB28iS3MPbuY=; b=IIglgvCmYVj+w5D3Fe/yl3GsFymy196LBVAo19paeKI78F7YN8NSso82muCs/v4Brx myAB25BwacxS6suibpfG17hT73LwfoSR5Em9UURDRpZKNh/IotvN5nAFqRaCc6ekjSRN J6spFjY/v8rXhSQNbaxFIVvIjOIsJEjvqO/lNAs+8pFOLFjjgESvzUyDQdZlWqybW9wA Cd5lGUet40hUOjGXKDs0j9FbFZm3smCEODnFpcB4sjZf8vGOM2PFaR1Fjglc04jL8wSX Jq4G6a8qxdLHDLpocxeJDR5OQlOgcSM5Rf8IbxrA/m62YlqbQRi5YiChNmvsrEvtjx32 WF0g== X-Gm-Message-State: AOAM531gQX4zI4a8GZirbE/LXTkSRbWiGcs8Kr7mOnLSeOwpHcZFPHxa y18H4KNandQudzoV2t7b7egkdw== X-Google-Smtp-Source: ABdhPJzoB3ldGw8dI1IaA47ugaHgwdHizRBi2jaMxfcrdgLQQ7xwYbP5cKugEete7oH7ExqXNlJVeA== X-Received: by 2002:a05:6808:1115:b0:2ec:e78e:3fc0 with SMTP id e21-20020a056808111500b002ece78e3fc0mr2580411oih.207.1649793991113; Tue, 12 Apr 2022 13:06:31 -0700 (PDT) Received: from ripper ([2600:1700:a0:3dc8:205:1bff:fec0:b9b3]) by smtp.gmail.com with ESMTPSA id v17-20020a9d69d1000000b005b2319a08c4sm13705206oto.18.2022.04.12.13.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 13:06:30 -0700 (PDT) Date: Tue, 12 Apr 2022 13:08:44 -0700 From: Bjorn Andersson To: Dmitry Baryshkov Cc: Stephen Boyd , Amit Kucheria , Andy Gross , Krzysztof Kozlowski , Michael Turquette , Rob Herring , Thara Gopinath , linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org Subject: Re: [PATCH v2 0/4] arm: qcom: qcom-apq8064: add separate device node for tsens Message-ID: References: <20220406002648.393486-1-dmitry.baryshkov@linaro.org> <20220406154028.EC897C385A3@smtp.kernel.org> <20220412184304.79012C385A8@smtp.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue 12 Apr 12:20 PDT 2022, Dmitry Baryshkov wrote: > On Tue, 12 Apr 2022 at 21:43, Stephen Boyd wrote: > > > > Quoting Dmitry Baryshkov (2022-04-06 12:57:30) > > > On Wed, 6 Apr 2022 at 18:40, Stephen Boyd wrote: > > > > > > > > Quoting Dmitry Baryshkov (2022-04-05 17:26:44) > > > > > Currently gcc-msm8960 driver manually creates tsens device. Instantiate > > > > > the device using DT node instead. This follow the IPQ8064 device tree > > > > > schema. > > > > > > > > Why can't the schema be changed? > > > > > > But these commits change the schema. They make apq8064 follow more > > > logical scheme of ipq8064. > > > > > > > Sounds like ipq8064 and apq8064 follow different schemas. Is there any > > benefit to harmonizing the two vs. just leaving it as it is in the dts > > and making the schema match whatever the dts has? > > I'd prefer to harmonize them. It makes no sense to have two different > approaches for the single IP block (shared between ipq and apq/msm). > And having a separate device tree node for the tsens removes a > dependency from gcc on the nvmem/qfprom. > Note, upstream qcom-msm8960.dtsi doesn't describe tsens at all, so we > don't have to worry about it. > The apq8064 design was chosen in order to make the dts represent the GCC being a single hardware block, and the fact that this is a clock and a thermal driver in Linux is an implementation decision. Seems like we forgot about this decision when we introduce the ipq8064... I'm not against harmonizing the two, but I don't see any changes to Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml and the clock patch describes what happens, but not why (i.e. if it's to harmonize the implementations the commit message should say so). Regards, Bjorn