[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c456f575-570f-40d6-9960-634da314e1d6@linaro.org>
Date: Mon, 18 Mar 2024 17:20:50 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Conor Dooley <conor@...nel.org>
Cc: Sylwester Nawrocki <s.nawrocki@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>, Alim Akhtar <alim.akhtar@...sung.com>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-samsung-soc@...r.kernel.org,
linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] dt-bindings: clock: samsung,s3c6400-clock: convert to DT
Schema
On 17/03/2024 16:49, Conor Dooley wrote:
> On Sun, Mar 17, 2024 at 04:26:55PM +0100, Krzysztof Kozlowski wrote:
>> On 17/03/2024 16:23, Conor Dooley wrote:
>>> On Tue, Mar 12, 2024 at 07:50:35PM +0100, Krzysztof Kozlowski wrote:
>>>> Convert Samsung S3C6400/S3C6410 SoC clock controller bindings to DT
>>>> schema.
>>>
>>>> +description: |
>>>> + There are several clocks that are generated outside the SoC. It is expected
>>>> + that they are defined using standard clock bindings with following
>>>> + clock-output-names:
>>>> + - "fin_pll" - PLL input clock (xtal/extclk) - required,
>>>> + - "xusbxti" - USB xtal - required,
>>>> + - "iiscdclk0" - I2S0 codec clock - optional,
>>>> + - "iiscdclk1" - I2S1 codec clock - optional,
>>>> + - "iiscdclk2" - I2S2 codec clock - optional,
>>>> + - "pcmcdclk0" - PCM0 codec clock - optional,
>>>> + - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
>>>
>>> I know you've only transfered this from the text binding, but what is
>>> the relevance of this to the binding for this clock controller? This
>>> seems to be describing some ?fixed? clocks that must be provided in
>>> addition to this controller. I guess there's probably no other suitable
>>> place to mention these?
>>
>> To make it correct, these should be made clock inputs to the clock
>> controller, even if the driver does not take them, however that's
>> obsolete platform which might be removed from kernel this or next year,
>> so I don't want to spend time on it.
>
> I think the comment should probably mention that these are the expected
> inputs, part of me thought that that was what you were getting at but I
> wasn't sure if instead they were inputs to some other IP on the SoC.
I can change it, but just to emphasize: in half a year or next year we
will probably remove entire platform, thus also this binding.
Best regards,
Krzysztof
Powered by blists - more mailing lists