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 X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DA6DC4743C for ; Mon, 21 Jun 2021 23:35:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5E0A8611BD for ; Mon, 21 Jun 2021 23:35:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231821AbhFUXiF (ORCPT ); Mon, 21 Jun 2021 19:38:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231268AbhFUXiE (ORCPT ); Mon, 21 Jun 2021 19:38:04 -0400 Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F09EC061756 for ; Mon, 21 Jun 2021 16:35:48 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id j11-20020a9d738b0000b02903ea3c02ded8so19475596otk.5 for ; Mon, 21 Jun 2021 16:35:48 -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=AXhLaNRlItV846H2J1h+pbbqWtyd8CdKwFzlrXFypk4=; b=vvX+3l5Iko5F5wawiBO2oOulWbnrWs/EuReLSqZd2mbbkLKe8RelP36ZHfTveJH05P QC/lDKAN69gONbAmSOO8q2KwLJS2E42g51BDbocUcWiFfI9KHbY/EerPwfVDZ9HwgsMg GNZUTtFtY7DFeiwBBCUcgEv/n1BNNN9s9YONKr+m6lpXqKnfxI0d2Ygf3s8MAiJh8VKZ qdnx3xfbV3KI/BuHNMHtSI+buAbTTGui6WBd8vdhtS2fJPNsQ7fYyiMyyp54cmF0vWkV XSRGPl/dqom3nL5l7rF1ghp5Ru3KCEjcPqSC4DBqgRw6DjYMGXKVsVia22fnzsdSgpP6 iX+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=AXhLaNRlItV846H2J1h+pbbqWtyd8CdKwFzlrXFypk4=; b=aSzdMf/XeDdhNLWvrTOBaXV6+jNFhPT+Adju+ygGYa97zfL4rjBvhiGOntXFbc5URC 3sPrU76PIrIxcjmwmXUtspt9+Uv+Iv+dcTcn64bbFItRe3HDKfSyQrO0ceruSjgvT1Ur HDXcWmijG4LI4B1Dlhx+e/dd7gT12qFaF++Zm6nv6gvJVeMsLTTmwTDWGa26GiNF3TSM GnZwUurtBwY29ModPNnjD96rtw7eXn36tvRSvqhadb/d1hqDoDfwJljFPtveZfXEN69S DY/pebYlkxTp4F/rRV0B9tV1nm85aAIJouLU+fWu/39cQgn+lnZMck30dV1dOp1NzUBF mbzA== X-Gm-Message-State: AOAM533DW7dL3hIwVr435ZXepK2CZzaQr/n6hpRfBNFMMUZUr1XR4Hu5 MLH18o6x+XxXuKrHfe+mTLelew== X-Google-Smtp-Source: ABdhPJwbgQBwTmzxN8A2Pyo1XyUa/E+pwItXExwq/V3hdrGj2dPjnmw3yUMqCY8jNO69G8h7xQ7yRA== X-Received: by 2002:a05:6830:2244:: with SMTP id t4mr483428otd.336.1624318547911; Mon, 21 Jun 2021 16:35:47 -0700 (PDT) Received: from yoga (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id 24sm2292069oiz.26.2021.06.21.16.35.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Jun 2021 16:35:47 -0700 (PDT) Date: Mon, 21 Jun 2021 18:35:44 -0500 From: Bjorn Andersson To: Rob Herring Cc: Jassi Brar , Martin Botka , ~postmarketos/upstreaming@lists.sr.ht, Konrad Dybcio , AngeloGioacchino Del Regno , Marijn Suijten , jamipkettunen@somainline.org, Andy Gross , linux-arm-msm , Linux Kernel Mailing List Subject: Re: [PATCH V3 3/3] mailbox: qcom-apcs: Add SM6125 compatible Message-ID: References: <20210612094631.89980-1-martin.botka@somainline.org> <20210612094631.89980-3-martin.botka@somainline.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: linux-kernel@vger.kernel.org On Mon 21 Jun 18:19 CDT 2021, Rob Herring wrote: > On Mon, Jun 21, 2021 at 5:10 PM Jassi Brar wrote: > > > > On Mon, Jun 21, 2021 at 2:46 PM Rob Herring wrote: > > > > > > On Sun, Jun 20, 2021 at 10:03 PM Jassi Brar wrote: > > > > > > > > On Sat, Jun 12, 2021 at 4:46 AM Martin Botka > > > > wrote: > > > > > > > > > > This commit adds compatible for the SM6125 SoC > > > > > > > > > > Signed-off-by: Martin Botka > > > > > --- > > > > > Changes in V2: > > > > > None > > > > > Changes in V3: > > > > > Change compatible to apcs-hmss-global > > > > > drivers/mailbox/qcom-apcs-ipc-mailbox.c | 5 +++++ > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c b/drivers/mailbox/qcom-apcs-ipc-mailbox.c > > > > > index f25324d03842..f24c5ad8d658 100644 > > > > > --- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c > > > > > +++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c > > > > > @@ -57,6 +57,10 @@ static const struct qcom_apcs_ipc_data sdm660_apcs_data = { > > > > > .offset = 8, .clk_name = NULL > > > > > }; > > > > > > > > > > +static const struct qcom_apcs_ipc_data sm6125_apcs_data = { > > > > > + .offset = 8, .clk_name = NULL > > > > > +}; > > > > > + > > > > > static const struct qcom_apcs_ipc_data apps_shared_apcs_data = { > > > > > .offset = 12, .clk_name = NULL > > > > > }; > > > > > @@ -166,6 +170,7 @@ static const struct of_device_id qcom_apcs_ipc_of_match[] = { > > > > > { .compatible = "qcom,sc8180x-apss-shared", .data = &apps_shared_apcs_data }, > > > > > { .compatible = "qcom,sdm660-apcs-hmss-global", .data = &sdm660_apcs_data }, > > > > > { .compatible = "qcom,sdm845-apss-shared", .data = &apps_shared_apcs_data }, > > > > > + { .compatible = "qcom,sm6125-apcs-hmss-global", .data = &sm6125_apcs_data }, > > > > > { .compatible = "qcom,sm8150-apss-shared", .data = &apps_shared_apcs_data }, > > > > > { .compatible = "qcom,sdx55-apcs-gcc", .data = &sdx55_apcs_data }, > > > > > {} > > > > > > > > > These all are basically different names for the same controller. > > > > The 'offset' is a configuration parameter and the 'clock', when NULL, > > > > is basically some "always-on" clock. > > > > I am sure we wouldn't be doing it, if the controller was third-party. > > > > > > If newer implementations are 'the same', then they should have a > > > fallback compatible to the existing one that is the same and no driver > > > change is needed. If the differences are board or instance (within an > > > SoC) specific, then a DT property would be appropriate. > > > > > The controllers (13 now) only differ by the 'offset' where the > > registers are mapped. Clock-name is a pure s/w artifact. > > So, maybe we could push all these in DT. > > Why is 'reg' not used for the offset? > The DT node and its "reg" describes the whole IP block. The particular register that we care of has, as you can see, moved around during the various platforms and some incarnations of this IP block provides controls for CPU-related clocks as well. We can certainly have the multiple compatible points to the same apcs_data, but I'm not able to spot a reasonable "catch-all compatible" given that I don't see any natural groupings. > In any case, we can't really get rid of the first 13 instances though... > Right, we have the problem that we have DTBs out there that relies on these compatibles, but as Jassi requests we'd have to start describing the internal register layout in DT - which this binding purposefully avoids. Regards, Bjorn