[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3cdc8b67-c088-808a-c141-c70c9b8a8a9c@linaro.org>
Date: Tue, 16 Aug 2022 13:15:43 +0300
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Samuel Holland <samuel@...lland.org>, Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Maxime Ripard <mripard@...nel.org>
Cc: Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...ux.ie>,
Jagan Teki <jagan@...rulasolutions.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH 2/4] dt-bindings: display: sun6i-dsi: Add the A100 variant
On 13/08/2022 01:58, Samuel Holland wrote:
> Hi Krzysztof,
>
> On 8/12/22 5:49 AM, Krzysztof Kozlowski wrote:
>> On 12/08/2022 10:42, Samuel Holland wrote:
>>> The "40nm" MIPI DSI controller found in the A100 and D1 SoCs has the
>>> same register layout as previous SoC integrations. However, its module
>>> clock now comes from the TCON, which means it no longer runs at a fixed
>>> rate, so this needs to be distinguished in the driver.
>>>
>>> The controller also now uses pins on Port D instead of dedicated pins,
>>> so it drops the separate power domain.
>>>
>>> Signed-off-by: Samuel Holland <samuel@...lland.org>
>>> ---
>>> Removal of the vcc-dsi-supply is maybe a bit questionable. Since there
>>> is no "VCC-DSI" pin anymore, it's not obvious which pin actually does
>>> power the DSI controller/PHY. Possibly power comes from VCC-PD or VCC-IO
>>> or VCC-LVDS. So far, all boards have all of these as always-on supplies,
>>> so it is hard to test.
>>>
>>> .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 28 +++++++++++++++----
>>> 1 file changed, 23 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
>>> index ae55ef3fb1fe..c53c25b87bd4 100644
>>> --- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
>>> +++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
>>> @@ -12,9 +12,14 @@ maintainers:
>>>
>>> properties:
>>> compatible:
>>> - enum:
>>> - - allwinner,sun6i-a31-mipi-dsi
>>> - - allwinner,sun50i-a64-mipi-dsi
>>> + oneOf:
>>> + - enum:
>>> + - allwinner,sun6i-a31-mipi-dsi
>>> + - allwinner,sun50i-a64-mipi-dsi
>>> + - allwinner,sun50i-a100-mipi-dsi
>>
>> While you are moving code, how about bringing alphabetical order?
>
> I have put the sun*i prefix in numeric order, which matches (almost) all of our
5 is before 6, so strictly numerical order would be:
allwinner,sun50i-a64-mipi-dsi
allwinner,sun50i-a100-mipi-dsi
allwinner,sun6i-a31-mipi-dsi
> other bindings. It roughly corresponds to chronological order as well. It
> doesn't make much sense to me to sort sun50i (ARM64 SoCs) between sun5i and
> sun6i (early ARMv7 SoCs).
However if you say you already implemented some order (obvious for
Allwinner folks), then of course it is fine with me. I just hope other
people will get figure out this order, so they can maintain it.
So assuming there is some order:
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Best regards,
Krzysztof
Powered by blists - more mailing lists