All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacopo Mondi <jacopo@jmondi.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Magnus Damm <magnus.damm@gmail.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/5] dt-bindings: media: max9286: Define 'maxim,gpio-poc'
Date: Thu, 15 Apr 2021 08:54:20 +0200	[thread overview]
Message-ID: <20210415065420.lbba2hig4p2ynx6c@uno.localdomain> (raw)
In-Reply-To: <YHd/AKIfxIHhTjWO@pendragon.ideasonboard.com>

Hi Laurent,

On Thu, Apr 15, 2021 at 02:47:12AM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Wed, Apr 14, 2021 at 03:51:24PM +0200, Jacopo Mondi wrote:
> > Define a new vendor property in the maxim,max9286 binding schema.
> >
> > The new property allows to declare that the remote camera
> > power-over-coax is controlled by one of the MAX9286 gpio lines.
> >
> > As it is currently not possible to establish a regulator as consumer
> > of the MAX9286 gpio controller for this purpose, the property allows to
> > declare that the camera power is controlled by the MAX9286 directly.
> >
> > The property accepts a gpio-index (0 or 1) and one line polarity
> > flag as defined by dt-bindings/gpio/gpio.h.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> >  .../bindings/media/i2c/maxim,max9286.yaml     | 53 ++++++++++++++++++-
> >  1 file changed, 52 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > index ee16102fdfe7..480a491f3744 100644
> > --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > @@ -70,6 +70,24 @@ properties:
> >        a remote serializer whose high-threshold noise immunity is not enabled
> >        is 100000 micro volts
> >
> > +  maxim,gpio-poc:
>
> I would have written poc-gpio to match the order of the GPIO bindings
> syntax.
>

That's what I had :) but then the property gets matched against the
gpio schema and I get complains because it expects a phandle as first
argument... Maybe there's a way I've missed to prevent the property to
be matched with *-gpio ?

> > +    $ref: '/schemas/types.yaml#/definitions/uint32-array'
> > +    minItems: 2
> > +    maxItems: 2
> > +    description: |
> > +      Identifier of gpio line that controls Power over Coax to the cameras and
>
> I'd write "Index of the MAX9286 GPIO output that ..." to make it clear
> that this is not a generic GPIO.
>

Ack

> > +      the associated polarity flag (GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW)
> > +      as defined in <include/dt-bindings/gpio/gpio.h>.
> > +
> > +      When the remote cameras power is controlled by one of the MAX9286 gpio
> > +      lines, this property has to be used to specify which line among the two
> > +      available ones controls the remote camera power enablement.
> > +
> > +      When this property is used it is not possible to register a gpio
> > +      controller as the gpio lines are controlled directly by the MAX9286 and
> > +      not available for consumers, nor the 'poc-supply' property should be
> > +      specified.
>
> Only one of the two lines would be controlled directly. Shouldn't we
> still register a GPIO controller for the other line ?

I considered that and thought it was a bit of an overkill (and I also
had a bit of troubles identifying how to register only gpio #1, as it
would be identified as gpio #0 if the actual #0 is not registered)

>
> Could you also mention somewhere that the first item in the array should
> be 0 or 1 ? It may be hard to express in a YAML schema, so I'm fine just
> documenting it in the description.
>

Sure, I tried identifying how to express that with yaml and failed :)

> I've been wondering whether this would be a common enough issue that it
> could justify support in the GPIO core to handle consumer-provider
> loops, but even if that happens at some point in the future, I think the
> proposal here is good enough and we won't need to switch.
>

Please note that with the suggestion offline from rob I will add to
the next version:

# If 'maxim,gpio-poc' is present, then 'poc-supply' and 'gpio-controller'
# are not allowed.
if:
  required:
    - maxim,gpio-poc
then:
  allOf:
    - not:
        required:
          - poc-supply
    - not:
        required:
          - gpio-controller

> > +
> >    ports:
> >      $ref: /schemas/graph.yaml#/properties/ports
> >
> > @@ -182,7 +200,6 @@ required:
> >    - reg
> >    - ports
> >    - i2c-mux
> > -  - gpio-controller
> >
> >  additionalProperties: false
> >
> > @@ -327,4 +344,38 @@ examples:
> >            };
> >          };
> >        };
> > +
> > +      /*
> > +       * Example of a deserializer that controls the camera Power over Coax
> > +       * through one of its gpio lines.
> > +       */
> > +      gmsl-deserializer@6c {
> > +        compatible = "maxim,max9286";
> > +        reg = <0x6c>;
> > +        enable-gpios = <&gpio 14 GPIO_ACTIVE_HIGH>;
> > +
> > +        /*
> > +         * The remote camera power is controlled by MAX9286 GPIO line #0.
> > +         * No 'poc-supply' nor 'gpio-controller' are specified.
> > +         */
> > +        maxim,gpio-poc = <0 GPIO_ACTIVE_LOW>;
> > +
> > +        /*
> > +         * Do not describe connections as they're the same as in the previous
> > +         * example.
> > +         */
> > +        ports {
> > +          #address-cells = <1>;
> > +          #size-cells = <0>;
> > +
> > +          port@4 {
> > +            reg = <4>;
> > +          };
> > +        };
> > +
> > +        i2c-mux {
> > +          #address-cells = <1>;
> > +          #size-cells = <0>;
> > +        };
> > +      };
> >      };
>
> It's customary to indent DT examples with 4 spaces. The existing
> examples use two spaces, so maybe a patch on top of this would be useful
> to increase readability ?
>

Ah weird! I can add a patch before this one!

> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>

Thanks
   j

> --
> Regards,
>
> Laurent Pinchart

  reply	other threads:[~2021-04-15  6:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 13:51 [PATCH v3 0/5] arm64: dts: renesas: Enable GMSL on R8A77970 V3M Eagle Jacopo Mondi
2021-04-14 13:51 ` [PATCH v3 1/5] dt-bindings: media: max9286: Define 'maxim,gpio-poc' Jacopo Mondi
2021-04-14 23:47   ` Laurent Pinchart
2021-04-15  6:54     ` Jacopo Mondi [this message]
2021-04-15  6:59       ` Geert Uytterhoeven
2021-04-14 13:51 ` [PATCH v3 2/5] media: i2c: max9286: Use "maxim,gpio-poc" property Jacopo Mondi
2021-04-15  0:00   ` Laurent Pinchart
2021-04-15  6:58     ` Jacopo Mondi
2021-04-15 19:14       ` Laurent Pinchart
2021-04-16  7:43         ` Jacopo Mondi
2021-04-16 22:18           ` Laurent Pinchart
2021-04-14 13:51 ` [PATCH v3 3/5] arm64: dts: renesas: eagle: Enable MAX9286 Jacopo Mondi
2021-04-14 23:49   ` Laurent Pinchart
2021-04-14 13:51 ` [PATCH v3 4/5] arm64: dts: renesas: eagle: Add GMSL .dtsi Jacopo Mondi
2021-04-14 23:53   ` Laurent Pinchart
2021-04-15  7:00     ` Jacopo Mondi
2021-04-14 13:51 ` [PATCH v3 5/5] arm64: dts: renesas: eagle: Include eagle-gmsl Jacopo Mondi
2021-04-14 23:50   ` Laurent Pinchart

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=20210415065420.lbba2hig4p2ynx6c@uno.localdomain \
    --to=jacopo@jmondi.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=jacopo+renesas@jmondi.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=robh+dt@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.