[v4,5/5] dt-bindings: arm: qcom: Add more sc7180 Chromebook board bindings

This adds board bindings for boards that are downstream but not quite
upstream yet.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
---
Normally this bindings doc would go together in the same series that
adds the device trees. In this case, Joe has been sending patches
supporting these Chromebooks. His most recent posting is:

https://lore.kernel.org/r/20220510154406.v5.1.Id769ddc5dbf570ccb511db96da59f97d08f75a9c@changeid/

If he were to add this patch to the end of his v6, however, it would
make things a bit more complicated simply becuase it would cause
conflicts with all the other patches in this series. ...so steady
state it would be correct to keep it in the series with the device
tree files, but for this one time I think it makes sense to keep all
the Chromebook board bindings patches together.

(no changes since v2)

Changes in v2:
- Use a "description" instead of a comment for each item.
- Use the marketing name instead of the code name where possible.

 .../devicetree/bindings/arm/qcom.yaml         | 92 +++++++++++++++++++
 1 file changed, 92 insertions(+)

On 20/05/2022 23:38, Douglas Anderson wrote:
> This adds board bindings for boards that are downstream but not quite
> upstream yet.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Normally this bindings doc would go together in the same series that
> adds the device trees. In this case, Joe has been sending patches
> supporting these Chromebooks. His most recent posting is:
> 
> https://lore.kernel.org/r/20220510154406.v5.1.Id769ddc5dbf570ccb511db96da59f97d08f75a9c@changeid/
> 
> If he were to add this patch to the end of his v6, however, it would
> make things a bit more complicated simply becuase it would cause
> conflicts with all the other patches in this series. ...so steady
> state it would be correct to keep it in the series with the device
> tree files, but for this one time I think it makes sense to keep all
> the Chromebook board bindings patches together.
> 
> (no changes since v2)
> 
> Changes in v2:
> - Use a "description" instead of a comment for each item.
> - Use the marketing name instead of the code name where possible.
> 
>  .../devicetree/bindings/arm/qcom.yaml         | 92 +++++++++++++++++++
>  1 file changed, 92 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 3d150d1a93cd..277faf59db57 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -263,6 +263,16 @@ properties:
>            - const: google,homestar
>            - const: qcom,sc7180
>  
> +      - description: Google Kingoftown (rev0)
> +        items:
> +          - const: google,kingoftown-rev0
> +          - const: qcom,sc7180
> +
> +      - description: Google Kingoftown (newest rev)
> +        items:
> +          - const: google,kingoftown
> +          - const: qcom,sc7180
> +
>        - description: Acer Chromebook Spin 513 (rev0)
>          items:
>            - const: google,lazor-rev0
> @@ -364,6 +374,48 @@ properties:
>            - const: google,lazor-sku6
>            - const: qcom,sc7180
>  
> +      - description: Google Mrbland with AUO panel (rev0)
> +        items:
> +          - const: google,mrbland-rev0-sku0
> +          - const: qcom,sc7180
> +
> +      - description: Google Mrbland with AUO panel (newest rev)
> +        items:
> +          - const: google,mrbland-sku1536
> +          - const: qcom,sc7180
> +
> +      - description: Google Mrbland with BOE panel (rev0)
> +        items:
> +          - const: google,mrbland-rev0-sku16

Similar question to patch #3, this could be:


+      - description: Google Mrbland
+        items:
+          - enum:
+              - google,mrbland-rev0-sku0     # AUO panel (rev0)
+              - google,mrbland-rev0-sku16    # BOE panel (rev0)
+          - const: qcom,sc7180

and the file gets smaller and easier to read.


Best regards,
Krzysztof

On Mon, May 23, 2022 at 09:19:03AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Sun, May 22, 2022 at 1:01 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 20/05/2022 23:38, Douglas Anderson wrote:
> > > This adds board bindings for boards that are downstream but not quite
> > > upstream yet.
> > >
> > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> > > ---
> > > Normally this bindings doc would go together in the same series that
> > > adds the device trees. In this case, Joe has been sending patches
> > > supporting these Chromebooks. His most recent posting is:
> > >
> > > https://lore.kernel.org/r/20220510154406.v5.1.Id769ddc5dbf570ccb511db96da59f97d08f75a9c@changeid/
> > >
> > > If he were to add this patch to the end of his v6, however, it would
> > > make things a bit more complicated simply becuase it would cause
> > > conflicts with all the other patches in this series. ...so steady
> > > state it would be correct to keep it in the series with the device
> > > tree files, but for this one time I think it makes sense to keep all
> > > the Chromebook board bindings patches together.
> > >
> > > (no changes since v2)
> > >
> > > Changes in v2:
> > > - Use a "description" instead of a comment for each item.
> > > - Use the marketing name instead of the code name where possible.
> > >
> > >  .../devicetree/bindings/arm/qcom.yaml         | 92 +++++++++++++++++++
> > >  1 file changed, 92 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> > > index 3d150d1a93cd..277faf59db57 100644
> > > --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> > > @@ -263,6 +263,16 @@ properties:
> > >            - const: google,homestar
> > >            - const: qcom,sc7180
> > >
> > > +      - description: Google Kingoftown (rev0)
> > > +        items:
> > > +          - const: google,kingoftown-rev0
> > > +          - const: qcom,sc7180
> > > +
> > > +      - description: Google Kingoftown (newest rev)
> > > +        items:
> > > +          - const: google,kingoftown
> > > +          - const: qcom,sc7180
> > > +
> > >        - description: Acer Chromebook Spin 513 (rev0)
> > >          items:
> > >            - const: google,lazor-rev0
> > > @@ -364,6 +374,48 @@ properties:
> > >            - const: google,lazor-sku6
> > >            - const: qcom,sc7180
> > >
> > > +      - description: Google Mrbland with AUO panel (rev0)
> > > +        items:
> > > +          - const: google,mrbland-rev0-sku0
> > > +          - const: qcom,sc7180
> > > +
> > > +      - description: Google Mrbland with AUO panel (newest rev)
> > > +        items:
> > > +          - const: google,mrbland-sku1536
> > > +          - const: qcom,sc7180
> > > +
> > > +      - description: Google Mrbland with BOE panel (rev0)
> > > +        items:
> > > +          - const: google,mrbland-rev0-sku16
> >
> > Similar question to patch #3, this could be:
> >
> >
> > +      - description: Google Mrbland
> > +        items:
> > +          - enum:
> > +              - google,mrbland-rev0-sku0     # AUO panel (rev0)
> > +              - google,mrbland-rev0-sku16    # BOE panel (rev0)
> > +          - const: qcom,sc7180
> >
> > and the file gets smaller and easier to read.
> 
> Ah, I guess this answers the question of the description that I asked
> in the previous patch. Of course, this goes opposite of the feedback I
> got from Stephen in previous versions of the patch where he requested
> that I use "description" instead of comments for things. ;-)
> 
> In any case, for now I'll hold off waiting for other opinions here
> since I still feel that the "one entry per dts" is easier to read /
> reason about.

I leave it to the sub-arch maintainers to decide. I somewhat prefer as 
Krzysztof suggested. Some platforms (and most of the ones I converted) 
all the boards for an SoC are one entry (except for the 3 string cases). 
So the above looks like a good middle ground grouping revs or variations 
of boards.

Rob