From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
Masami Hiramatsu <mhiramat@kernel.org>
Cc: soc@kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/5] arm64: dts: uniphier: Add NX1 SoC and boards support
Date: Sat, 12 Nov 2022 01:42:12 +0900 [thread overview]
Message-ID: <3200aea8-55df-9718-01ac-e15633e13de7@socionext.com> (raw)
In-Reply-To: <36680a5e-7b0c-4d7e-f039-734e9304dc18@linaro.org>
On 2022/11/11 23:40, Krzysztof Kozlowski wrote:
> On 11/11/2022 09:48, Kunihiko Hayashi wrote:
>> Hi Krzysztof,
>>
>> On 2022/11/09 0:11, Krzysztof Kozlowski wrote:
>>> On 08/11/2022 15:30, Kunihiko Hayashi wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 2022/11/08 20:13, Krzysztof Kozlowski wrote:
>>>>> On 07/11/2022 11:34, Kunihiko Hayashi wrote:
>>>>>> Initial version of devicetree sources for NX1 SoC and boards.
>>>>>>
>>>>>> NX1 SoC belongs to the UniPhier armv8 architecture platform, and is
>>>>>> designed for IoT and AI/ML application fields.
>>>>>>
>>>>>
>>>>>> +
>>>>>> + soc_glue: syscon@1f800000 {
>>>>>> + compatible = "socionext,uniphier-nx1-soc-glue",
>>>>>> + "simple-mfd", "syscon";
>>>>>> + reg = <0x1f800000 0x2000>;
>>>>>> +
>>>>>> + pinctrl: pinctrl {
>>>>>> + compatible = "socionext,uniphier-nx1-pinctrl";
>>>>>
>>>>> So instead of documenting the hardware precisily, you have one big bag
>>>>> for everything under simple-mfd. This is not how the SoC should be
>>>>> described in DTS.
>>>>
>>>> Sorry I don't understand. This is inherited from the previous
>>>> descriptions,
>>>> but is there some example to express DTS correctly about that?
>>>
>>> I think yes, although it actually depends what is this hardware.
>>> Generally speaking, do not use simple-mfd and syscon when these are not
>>> really simple devices. There are quite many in your DTS, which got my
>>> attention. Instead - have regular device with or without children.
>>>
>>> There is no real need to have this a simple-mfd with one children
>>> without any resources (no address space, no clocks, no interrupts,
>>> nothing).
>>>
>>> Why this syscon/mfd and pinctrl is not a regular, one device?
>>
>> The mfd/syscon.yaml says:
>> System controller node represents a register region containing a set
>> of miscellaneous registers.
>>
>> The "soc-glue" is exactly this, it contains various register functions
>> and might be referred to the drivers.
>>
>> For example in this NX1 dts, ethernet node points to "soc-glue" node.
>>
>> eth: ethernet@15000000 {
>> compatible = "socionext,uniphier-nx1-ave4";
>> ...
>> socionext,syscon-phy-mode = <&soc_glue 0>;
>> };
>>
>> Since such register region is not often systematically designed,
>> it is tough to cut out as specific memory region for "pinctrl".
>
> So your choice is instead use entire address space as pinctrl - as a
> child device without IO address space. That's also not a good solution.
This structure follow the existing UniPhier SoCs, so it is necessary
to re-think the structure of all SoCs, not just this NX1 SoC.
>>
>> And more, the existing pinctrl driver uses of_get_parent() and
>> syscon_node_to_regmap(), so this change breaks compatibility.
>
> This is a new DTS, so what compatibility is broken? With old kernel?
> There was no compatibility with this Devicetree. Anyway using driver
> implementation as reason for specific hardware description (DTS) is also
> not correct.
In this same area, mode selector, clock selector, phy configuration etc,
exist together in a mixed manner. There is a kind of design issues.
From this point of view, I should separate the new devicetree once
from this patch series, and it is necessary to consider syscon DT schema
and related drivers for existing SoCs.
>>>>>> + };
>>>>>> + };
>>>>>> +
>>>>>> + soc-glue@1f900000 {
>>>>>> + compatible = "simple-mfd";
>>>>>
>>>>> No, it is not allowed on its own. You need a specific compatible and
>>>>> bindings describing its children.
>>>>
>>>> I saw the definition of "simple-mfd" itself is only in mfd/mfd.txt.
>>>>
>>>> Currently there are only efuse devices as children, and this space means
>>>> nothing. I think it had better define the devices directly.
>>>
>>> You need to start describe the hardware. efuse is an efuse, not MFD.
>>> pinctrl is pinctrl not MFD + pinctrl.
>>
>> This region also has multiple functions, though, the efuse might be
>> cut out as specific region without "simple-mfd", unlike pinctrl.
>
> simple-mfd itself does not mean region has multiple functions, but that
> children do not depend on anything from the parent device.
>
> You over-use syscon and simple-mfd in multiple places. of course some of
> them will be reasonable, but now it does not.
It takes more time to review existing structures, especially patch 1/5.
Thank you,
---
Best Regards
Kunihiko Hayashi
prev parent reply other threads:[~2022-11-11 16:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 10:34 [PATCH v2 0/5] Add UniPhier boards support Kunihiko Hayashi
2022-11-07 10:34 ` [PATCH v2 1/5] dt-bindings: arm: uniphier: Add system controller bindings Kunihiko Hayashi
2022-11-08 11:09 ` Krzysztof Kozlowski
2022-11-08 14:30 ` Kunihiko Hayashi
2022-11-08 15:08 ` Krzysztof Kozlowski
2022-11-11 8:49 ` Kunihiko Hayashi
2022-11-07 10:34 ` [PATCH v2 2/5] dt-bindings: arm: uniphier: Add Pro5 boards Kunihiko Hayashi
2022-11-07 10:34 ` [PATCH v2 3/5] ARM: dts: uniphier: Add Pro5 board support Kunihiko Hayashi
2022-11-07 10:34 ` [PATCH v2 4/5] dt-bindings: arm: uniphier: Add NX1 boards Kunihiko Hayashi
2022-11-07 10:34 ` [PATCH v2 5/5] arm64: dts: uniphier: Add NX1 SoC and boards support Kunihiko Hayashi
2022-11-08 11:13 ` Krzysztof Kozlowski
2022-11-08 14:30 ` Kunihiko Hayashi
2022-11-08 15:11 ` Krzysztof Kozlowski
2022-11-11 8:48 ` Kunihiko Hayashi
2022-11-11 14:40 ` Krzysztof Kozlowski
2022-11-11 16:42 ` Kunihiko Hayashi [this message]
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=3200aea8-55df-9718-01ac-e15633e13de7@socionext.com \
--to=hayashi.kunihiko@socionext.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=olof@lixom.net \
--cc=robh+dt@kernel.org \
--cc=soc@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox