From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Jacopo Mondi <jacopo@jmondi.org>,
Tommaso Merciai <tommaso.merciai@amarulasolutions.com>
Cc: linuxfancy@googlegroups.com, linux-amarula@amarulasolutions.com,
quentin.schulz@theobroma-systems.com,
Daniel Scally <djrscally@gmail.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 5/6] media: dt-bindings: ov5693: document YAML binding
Date: Tue, 12 Jul 2022 17:32:45 +0200 [thread overview]
Message-ID: <47aa4fbc-9cf4-7ac3-2fb4-2135a7703212@linaro.org> (raw)
In-Reply-To: <20220712152538.jh4ufxik7icllox6@uno.localdomain>
On 12/07/2022 17:25, Jacopo Mondi wrote:
> Hi Krzysztof
> could you have a look at the below question ?
Sorry, there was a bunch of quoted text without end. When you reply
under quote, please remove the rest of the quote. None of us have a lot
of time to waste on scrolling emails...
>
> If no need to resend from Tommaso I think the series could be
> collected for v5.20.
>
> On Mon, Jul 11, 2022 at 11:37:05AM +0200, Jacopo Mondi wrote:
>> Hi Tommaso, Krzysztof,
>>
>> This has been reviewed by Krzysztof already, so I guess it's fine,
>> but let me ask anyway
>>
>> On Thu, Jun 30, 2022 at 03:48:34PM +0200, Tommaso Merciai wrote:
>>> Add documentation of device tree in YAML schema for the OV5693
>>> CMOS image sensor from Omnivision
>>>
>>> Signed-off-by: Tommaso Merciai <tommaso.merciai@amarulasolutions.com>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>> ---
>>> Changes since v1:
>>> - Fix allOf position as suggested by Krzysztof
>>> - Remove port description as suggested by Krzysztof
>>> - Fix EOF as suggested by Krzysztof
>>>
>>> Changes since v2:
>>> - Fix commit body as suggested by Krzysztof
>>>
>>> Changes since v3:
>>> - Add reviewed-by tags, suggested by Jacopo, Krzysztof
>>>
>>> Changes since v4:
>>> - Remove wrong Sakari reviewed-by tag, suggested by Krzysztof, Sakari
>>>
>>> .../bindings/media/i2c/ovti,ov5693.yaml | 106 ++++++++++++++++++
>>> MAINTAINERS | 1 +
>>> 2 files changed, 107 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
>>> new file mode 100644
>>> index 000000000000..b83c9fc04023
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
>>> @@ -0,0 +1,106 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +# Copyright (c) 2022 Amarulasolutions
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov5693.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Omnivision OV5693 CMOS Sensor
>>> +
>>> +maintainers:
>>> + - Tommaso Merciai <tommaso.merciai@amarulasolutions.com>
>>> +
>>> +description: |
>>> + The Omnivision OV5693 is a high performance, 1/4-inch, 5 megapixel, CMOS
>>> + image sensor that delivers 2592x1944 at 30fps. It provides full-frame,
>>> + sub-sampled, and windowed 10-bit MIPI images in various formats via the
>>> + Serial Camera Control Bus (SCCB) interface.
>>> +
>>> + OV5693 is controlled via I2C and two-wire Serial Camera Control Bus (SCCB).
>>> + The sensor output is available via CSI-2 serial data output (up to 2-lane).
>>> +
>>> +allOf:
>>> + - $ref: /schemas/media/video-interface-devices.yaml#
>>> +
>>> +properties:
>>> + compatible:
>>> + const: ovti,ov5693
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + clocks:
>>> + description:
>>> + System input clock (aka XVCLK). From 6 to 27 MHz.
>>> + maxItems: 1
>>> +
>>> + dovdd-supply:
>>> + description:
>>> + Digital I/O voltage supply, 1.8V.
>>> +
>>> + avdd-supply:
>>> + description:
>>> + Analog voltage supply, 2.8V.
>>> +
>>> + dvdd-supply:
>>> + description:
>>> + Digital core voltage supply, 1.2V.
>>> +
>>> + reset-gpios:
>>> + description:
>>> + The phandle and specifier for the GPIO that controls sensor reset.
>>> + This corresponds to the hardware pin XSHUTDN which is physically
>>> + active low.
>>> + maxItems: 1
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - clocks
>>> + - dovdd-supply
>>> + - avdd-supply
>>> + - dvdd-supply
>>
>> Should supplies be made mandatory ? Sensors are often powered by fixed
>> rails. Do we want DTS writers to create "fixed-regulators" for all of
>> them ? The fact the regulator framework creates dummies if there's no
>> entry in .dts for a regulator makes me think it's fine to have them
>> optional, but I understand how Linux works should not be an indication
>> of how a bindings should look like.
>>
>
> This question ^ :)
My generic answer for generic devices would be - if resource is
physically required (one need to connect the wire), I would say it
should be also required in the bindings. This also forces driver
developer to think about these resources and might result on
portable/better code.
However your point is correct that it might create many "fake"
regulators, because pretty often these are fixed on the board and not
controllable. Therefore I am fine with not requiring them - to adjust
the bindings to real life cases.
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-07-12 15:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220630134835.592521-1-tommaso.merciai@amarulasolutions.com>
2022-06-30 13:48 ` [PATCH v5 5/6] media: dt-bindings: ov5693: document YAML binding Tommaso Merciai
2022-07-11 9:36 ` Jacopo Mondi
2022-07-11 11:11 ` Tommaso Merciai
2022-07-11 12:36 ` Jacopo Mondi
2022-07-11 14:49 ` Tommaso Merciai
2022-07-12 15:25 ` Jacopo Mondi
2022-07-12 15:32 ` Krzysztof Kozlowski [this message]
2022-07-12 16:12 ` Jacopo Mondi
2022-07-12 16:16 ` Krzysztof Kozlowski
2022-07-12 16:17 ` Tommaso Merciai
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=47aa4fbc-9cf4-7ac3-2fb4-2135a7703212@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=djrscally@gmail.com \
--cc=jacopo@jmondi.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-amarula@amarulasolutions.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linuxfancy@googlegroups.com \
--cc=mchehab@kernel.org \
--cc=quentin.schulz@theobroma-systems.com \
--cc=robh+dt@kernel.org \
--cc=tommaso.merciai@amarulasolutions.com \
/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