Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <bb2e92c8-8e19-8840-c1ec-8c7ef667fdbf@quicinc.com>
Date:   Thu, 20 Oct 2022 11:55:06 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH v2 2/3] arm64: dts: qcom: Add base QDU1000/QRU1000 DTSIs
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        Stephan Gerhold <stephan@gerhold.net>
CC:     Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
References: <20221014221138.7552-1-quic_molvera@quicinc.com>
 <20221014221138.7552-3-quic_molvera@quicinc.com>
 <56af2a04-1b21-000d-e3f9-86b6ac74aaf2@linaro.org>
 <a0032338-482f-0de7-5952-c3c8b8423df6@quicinc.com>
 <50372a15-56ce-6ad6-f622-00624b909db8@linaro.org>
 <Y1FTJgloEi5ag2/j@gerhold.net>
 <9fbe1bf5-a84d-c56b-1c0e-6848ee3d30fe@linaro.org>
 <Y1GCs6uCz5o9az+v@gerhold.net>
 <835d3432-daf2-e824-5c84-7d47604f586f@linaro.org>
Content-Language: en-US
From:   Melody Olvera <quic_molvera@quicinc.com>
In-Reply-To: <835d3432-daf2-e824-5c84-7d47604f586f@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 10/20/2022 10:59 AM, Krzysztof Kozlowski wrote:
> On 20/10/2022 13:18, Stephan Gerhold wrote:
>>> No, it puts attention to the board designer that he needs to provide the
>>> clock in his design.
>>>
>>> We had such talks about other platforms, although I do not have any
>>> recent bookmarks. Something older:
>>>
>>> https://lore.kernel.org/all/3382034.5ADO0F7naY@wuerfel/
>>>
>>> https://lore.kernel.org/linux-samsung-soc/53DAB0A6.9030700@gmail.com/
>>>
>> If I understand you correctly your argument for having the clock in the
>> board DTS instead of the SoC DTSI is:
>>
>> The SoC DTSI describes the components of the SoC, while the board DTS
>> describes the components of the board (built around the SoC). The clock
>> is part of the board (and not the SoC) and therefore belongs into the
>> board DTS and not the SoC DTSI. Having the SoC/board components clearly
>> separated ensures people writing new board DTS pay attention to
>> everything board-specific.
>>
>> Correct? This sounds reasonable to me.
> Yes.
>
>> However, the main question of my previous mail was: Why do you
>> alternatively recommend to keep the clock defined in the SoC DTSI and to
>> just put the clock-frequency into the board DTS? This sounds like a
>> contradiction of the above to me: the clock is still (partially)
>> described as part of the SoC, even though it belongs to the board.
> The proposal is a trade-off, compromise between code duplication and
> above recommendation of splitting SoC <-> board.
>
> As you said, all boards will provide this clock, so it is reasonable to
> put some pieces of it in the SoC DTSI to avoid duplication. But the
> final piece - what clock is there exactly (model, frequency etc) should
> be put in board DTS to clarify that this comes with board.
>
>> Someone writing a board DTS should not just put attention to the
>> clock-frequency, but also if they have a single fixed-clock or
>> maybe some kind of clock-fixed-factor setup, as I wrote.
> True. If such setup is probably, then my recommendation would be to put
> entire clock to the board.
Going through this thread, this seems to be the conclusion. Will all clock nodes to the
DTS files.
>
> Just note, that even in proposed frequency->board DTS, it is still
> possible to use the clock-fixed-factor.
>
>
Thanks,
Melody