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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.