Re: [PATCH v3] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML

From: Krzysztof Kozlowski
Date: Tue Dec 20 2022 - 05:00:34 EST


On 19/12/2022 15:23, Johan Jonker wrote:
>
>
> On 12/19/22 14:04, Krzysztof Kozlowski wrote:
>> On 19/12/2022 13:32, Johan Jonker wrote:
>>> Convert rockchip-lvds.txt to YAML.
>>>
>>> Changed:
>>> Add power-domains property.
>>> Requirements between PX30 and RK3288
>>>
>>> Signed-off-by: Johan Jonker <jbx6244@xxxxxxxxx>
>>> ---
>>>
>>> Changed V3:
>>> Filename matching compatible style
>>> Drop "Regulator phandle for "
>>> Specify properties and requirements per SoC
>>> Sort order and restyle
>>>
>>> Changed V2:
>>> Fix title
>>> ---
>>> .../display/rockchip/rockchip,lvds.yaml | 170 ++++++++++++++++++
>>> .../display/rockchip/rockchip-lvds.txt | 92 ----------
>>> 2 files changed, 170 insertions(+), 92 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
>>> delete mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
>>> new file mode 100644
>>> index 000000000..03b002a05
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
>>> @@ -0,0 +1,170 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Rockchip low-voltage differential signal (LVDS) transmitter
>>> +
>>> +maintainers:
>>> + - Sandy Huang <hjc@xxxxxxxxxxxxxx>
>>> + - Heiko Stuebner <heiko@xxxxxxxxx>
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - rockchip,px30-lvds
>>> + - rockchip,rk3288-lvds
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + clocks:
>>> + maxItems: 1
>>> +
>>> + clock-names:
>>> + const: pclk_lvds
>>> +
>>> + avdd1v0-supply:
>>> + description: 1.0V analog power.
>>> +
>>> + avdd1v8-supply:
>>> + description: 1.8V analog power.
>>> +
>>> + avdd3v3-supply:
>>> + description: 3.3V analog power.
>>> +
>>> + rockchip,grf:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description: Phandle to the general register files syscon.
>>> +
>>> + rockchip,output:
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum: [rgb, lvds, duallvds]
>>> + description: This describes the output interface.
>>> +
>>> + phys:
>>> + maxItems: 1
>>> +
>>> + phy-names:
>>> + const: dphy
>>> +
>>> + pinctrl-names:
>>> + const: lcdc
>>> +
>>> + pinctrl-0: true
>>> +
>>> + power-domains:
>>> + maxItems: 1
>>> +
>>> + ports:
>>> + $ref: /schemas/graph.yaml#/properties/ports
>>> +
>>> + properties:
>>> + port@0:
>>> + $ref: /schemas/graph.yaml#/properties/port
>>> + description:
>>> + Video port 0 for the VOP input.
>>> + The remote endpoint maybe vopb or vopl.
>>> +
>>> + port@1:
>>> + $ref: /schemas/graph.yaml#/properties/port
>>> + description:
>>> + Video port 1 for either a panel or subsequent encoder.
>>> +
>>> + required:
>>> + - port@0
>>> + - port@1
>>> +
>>> +required:
>>> + - compatible
>>> + - rockchip,grf
>>> + - rockchip,output
>>> + - ports
>>> +
>>> +allOf:
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: rockchip,px30-lvds
>>> +
>>> + then:
>>> + properties:
>>> + reg: false
>>> + clocks: false
>>> + clock-names: false
>>> + avdd1v0-supply: false
>>> + avdd1v8-supply: false
>>> + avdd3v3-supply: false
>>> +
>>
>
>> I see one compatible expects regmap from parent (grf is the parent here)
>> and other is directly on MMIO bus. Not the best combination... Maybe
>> this should be just split to two separate bindings? Looking at driver,
>> their code is also very different between these two variants.
>
> Looking at the manufacturer tree we can expect the rest with grf parent, but also in the same driver combined with different registers and common probe.
> Due to common probe I prefer one common document.

Bindings are not representing Linux driver structure, so common probe is
not really argument. If you create one driver (one probe) handling
different devices like RTC, extcon, regulator and clocks, does it mean
it must be one binding? No.

You are over-complicating bindings now.

These are entirely different devices - their programming model and how
they are modeled in the DTS.

Best regards,
Krzysztof