[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5654018.DvuYhMxLoT@z3ntu.xyz>
Date: Tue, 14 Mar 2023 19:33:06 +0100
From: Luca Weiss <luca@...tu.xyz>
To: Sakari Ailus <sakari.ailus@....fi>
Cc: Rob Herring <robh@...nel.org>, linux-kernel@...r.kernel.org,
Mauro Carvalho Chehab <mchehab@...nel.org>,
~postmarketos/upstreaming@...ts.sr.ht,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-media@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
devicetree@...r.kernel.org,
Shunqian Zheng <zhengsq@...k-chips.com>,
phone-devel@...r.kernel.org,
Helen Koike <helen.koike@...labora.com>
Subject: Re: [PATCH] media: dt-bindings: ov2685: convert to dtschema
On Dienstag, 14. März 2023 13:00:52 CET Sakari Ailus wrote:
> Hi Luca,
>
> On Thu, Feb 09, 2023 at 05:46:48PM +0100, Luca Weiss wrote:
> > +CC Helen Koike
> >
> > On Montag, 6. Februar 2023 22:50:08 CET Rob Herring wrote:
> > > On Mon, 06 Feb 2023 21:23:16 +0100, Luca Weiss wrote:
> > > > Convert the text-based dt-bindings to yaml.
> > > >
> > > > Changes from original txt:
> > > > * Take wording for various properties from other yaml bindings, this
> > > >
> > > > removes e.g. volt amount from schema since it isn't really relevant
> > > > and the datasheet is a better source.
> > > >
> > > > * Don't make reset-gpios a required property since it can be tied to
> > > >
> > > > DOVDD instead.
> > > >
> > > > Signed-off-by: Luca Weiss <luca@...tu.xyz>
> > > > ---
> > > >
> > > > .../devicetree/bindings/media/i2c/ov2685.txt | 41 ---------
> > > > .../devicetree/bindings/media/i2c/ovti,ov2685.yaml | 101
> > > > +++++++++++++++++++++ MAINTAINERS
> > > >
> > > > | 1 +
> > > >
> > > > 3 files changed, 102 insertions(+), 41 deletions(-)
> > >
> > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> > > on your patch (DT_CHECKER_FLAGS is new in v5.13):
> > >
> > > yamllint warnings/errors:
> > >
> > > dtschema/dtc warnings/errors:
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > medi a/rockchip-isp1.example.dtb: camera@3c: 'clocks' is a required
> > > property From schema:
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > med
> > > ia/i2c/ovti,ov2685.yaml
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > med
> > > ia/rockchip-isp1.example.dtb: camera@3c: 'clock-names' is a required
> > > property From schema:
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > med
> > > ia/i2c/ovti,ov2685.yaml
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > med
> > > ia/rockchip-isp1.example.dtb: camera@3c: 'dvdd-supply' is a required
> > > property From schema:
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > med
> > > ia/i2c/ovti,ov2685.yaml
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > med
> > > ia/rockchip-isp1.example.dtb: camera@3c: 'avdd-supply' is a required
> > > property From schema:
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > med
> > > ia/i2c/ovti,ov2685.yaml
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > med
> > > ia/rockchip-isp1.example.dtb: camera@3c: 'dovdd-supply' is a required
> > > property From schema:
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/
> > > med
> > > ia/i2c/ovti,ov2685.yaml
> >
> > Looks like rockchip-isp1.yaml uses very incomplete sensor examples in
> > their
> > binding example, which sort of makes sense since those bindings are
> > showing
> > the rockchip isp bindings and contain the bare minimum to show how a
> > sensor is connected in dt.
> >
> > Not sure how to solve this - ov2685 is also one of three sensors that are
> > used very abbreviated there.
>
> Could these regulators be simply made optional?
Sure, from driver side it would just get dummy regulators instead.
Still the clocks are also missing in this rockchip example. Any suggestion
what to do about those?
Honestly I don't want to spend too much time on some ISP docs that I don't
really care about, would be nice if the maintainers of that could do that...
Regards
Luca
Powered by blists - more mailing lists