[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0902b606-ae47-4358-ae5d-b11f9208a352@kernel.org>
Date: Wed, 17 Dec 2025 13:31:56 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Matthias Fend <matthias.fend@...end.at>,
Kieran Bingham <kieran.bingham@...asonboard.com>,
Umang Jain <uajain@...lia.com>, Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: linux-media@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] media: dt-bindings: imx283: add clock-noncontinuous
On 17/12/2025 13:26, Matthias Fend wrote:
> Hi Krzysztof,
>
> thanks for your feedback.
>
> Am 17.12.2025 um 13:03 schrieb Krzysztof Kozlowski:
>> On 17/12/2025 08:06, Matthias Fend wrote:
>>> Add the optional clock-noncontinuous endpoint property that allows enabling
>>> MIPI CSI-2 non-continuous clock operations.
>>>
>>> Signed-off-by: Matthias Fend <matthias.fend@...end.at>
>>> ---
>>> Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml
>>> index e4f49f1435a5c2e6e1507d250662ea6ecbf3c7dc..a91695f5618767ac851e5bc72b347a21da77c52d 100644
>>> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml
>>> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml
>>> @@ -59,6 +59,7 @@ properties:
>>> - const: 3
>>> - const: 4
>>>
>>> + clock-noncontinuous: true
>>
>> Drop, it's already there via referenced schema.
>>
>>> link-frequencies: true
>>>
>>> required:
>>> @@ -99,6 +100,7 @@ examples:
>>> imx283: endpoint {
>>> remote-endpoint = <&cam>;
>>> data-lanes = <1 2 3 4>;
>>> + clock-noncontinuous;
>>
>> And updating example just for this is rather churn.
>
> I thought it was worth the change because the example now reflects the
> original (before this series) behavior of the sensor.
I don't understand this, so let's clarify - extend the example only if
this is necessary, IOW existing code is wrong.
Your commit msg does not indicate anything wrong about existing code.
Best regards,
Krzysztof
Powered by blists - more mailing lists