Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
In-Reply-To: <e74aacdf-3ff7-261d-997f-5b6566b66207@quicinc.com>
References: <20220503113246.13857-1-quic_tdas@quicinc.com> <CAE-0n53QZn8VYB-dxzwccYDURU-0qW3ZwsuOEECwrKGAhYzwgw@mail.gmail.com>
 <e74aacdf-3ff7-261d-997f-5b6566b66207@quicinc.com>
From:   Stephen Boyd <swboyd@chromium.org>
User-Agent: alot/0.10
Date:   Tue, 17 May 2022 01:31:35 -0700
Message-ID: <CAE-0n50auThk=yzzVMvc2bu7g47gBzv4pw1K+dqshRRpA5969w@mail.gmail.com>
Subject: Re: [PATCH v4] arm64: dts: qcom: sc7280: Add lpasscore & lpassaudio
 clock controllers
To:     Bjorn Andersson <bjorn.andersson@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Taniya Das <quic_tdas@quicinc.com>
Cc:     Douglas Anderson <dianders@chromium.org>,
        devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Quoting Taniya Das (2022-05-03 22:35:29)
> Hello Stephen,
>
> On 5/4/2022 12:40 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2022-05-03 04:32:46)
> >> Add the low pass audio clock controller device nodes. Keep the lpasscc
> >> clock node disabled and enabled for lpass pil based devices.
> >
> > Does it mean that we're going to have overlapping reg ranges between
> > nodes in DT for clk controllers? That is not proper DT style, indicating
> > that we should combine the overlapping nodes and then have some
> > compatible or DT property telling us how to treat the clks in the audio
> > subsystem.
> >
>
> In the case where PIL based LPASS node would be used, we would disable
> the other lpass clock controller nodes. Does that seem fine or I would
> need to map the complete range in the current PIL driver if that works.
>

Is the idea that we would have a set of nodes that have overlapping reg
ranges but only one or the other would be enabled? That seems confusing.
Why don't we simply have one node that has a different compatible string
or some DT property that reflects the programming model of choice? Or
use the protected-clocks property to list out the clks that we don't
want to have registered on the system.

We shouldn't need to have two entirely different nodes for the same
physical device in the SoC, so talking about PIL based LPASS is
confusing. Can you explain further?