From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Stephan Gerhold <stephan@gerhold.net>
Cc: Melody Olvera <quic_molvera@quicinc.com>,
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
Subject: Re: [PATCH v2 2/3] arm64: dts: qcom: Add base QDU1000/QRU1000 DTSIs
Date: Thu, 20 Oct 2022 13:59:40 -0400 [thread overview]
Message-ID: <835d3432-daf2-e824-5c84-7d47604f586f@linaro.org> (raw)
In-Reply-To: <Y1GCs6uCz5o9az+v@gerhold.net>
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.
Just note, that even in proposed frequency->board DTS, it is still
possible to use the clock-fixed-factor.
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-10-20 18:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-14 22:11 [PATCH v2 0/3] Add base device tree files for QDU1000/QRU1000 Melody Olvera
2022-10-14 22:11 ` [PATCH v2 1/3] dt-bindings: arm: qcom: Document QDU1000/QRU1000 SoCs and boards Melody Olvera
2022-10-15 13:19 ` Krzysztof Kozlowski
2022-10-16 22:58 ` Rob Herring
2022-10-14 22:11 ` [PATCH v2 2/3] arm64: dts: qcom: Add base QDU1000/QRU1000 DTSIs Melody Olvera
2022-10-15 13:28 ` Krzysztof Kozlowski
2022-10-19 20:21 ` Melody Olvera
2022-10-20 12:41 ` Krzysztof Kozlowski
2022-10-20 13:54 ` Stephan Gerhold
2022-10-20 16:08 ` Krzysztof Kozlowski
2022-10-20 16:26 ` Krzysztof Kozlowski
2022-10-20 17:18 ` Stephan Gerhold
2022-10-20 17:59 ` Krzysztof Kozlowski [this message]
2022-10-20 18:55 ` Melody Olvera
2022-10-15 15:11 ` Krzysztof Kozlowski
2022-10-18 22:15 ` Krzysztof Kozlowski
2022-10-19 18:56 ` Melody Olvera
2022-10-24 0:53 ` Richard Acayan
2022-10-24 17:10 ` Melody Olvera
2022-10-24 22:28 ` Richard Acayan
2022-10-24 22:31 ` Melody Olvera
2022-10-24 22:51 ` Richard Acayan
2022-10-24 22:56 ` Melody Olvera
2022-10-14 22:11 ` [PATCH v2 3/3] arm64: dts: qcom: Add base QDU1000/QRU1000 IDP DTs Melody Olvera
2022-10-15 13:29 ` Krzysztof Kozlowski
2022-10-19 21:16 ` Melody Olvera
2022-10-20 12:39 ` Krzysztof Kozlowski
2022-10-18 22:10 ` kernel test robot
2022-10-15 0:04 ` [PATCH v2 0/3] Add base device tree files for QDU1000/QRU1000 Melody Olvera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=835d3432-daf2-e824-5c84-7d47604f586f@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_molvera@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=stephan@gerhold.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®