mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®