linux-mediatek.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christian Marangi <ansuelsmth@gmail.com>
To: Lee Jones <lee@kernel.org>
Cc: "Lorenzo Bianconi" <lorenzo@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Sean Wang" <sean.wang@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"Uwe Kleine-König" <ukleinek@kernel.org>,
	linux-mediatek@lists.infradead.org, linux-gpio@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	upstream@airoha.com, benjamin.larsson@genexis.eu,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v5 3/5] mfd: airoha: Add support for Airoha EN7581 MFD
Date: Thu, 3 Oct 2024 00:42:39 +0200	[thread overview]
Message-ID: <66fdcc62.df0a0220.15bce8.4398@mx.google.com> (raw)
In-Reply-To: <20241002132518.GD7504@google.com>

On Wed, Oct 02, 2024 at 02:25:18PM +0100, Lee Jones wrote:
> On Tue, 01 Oct 2024, Lorenzo Bianconi wrote:
> 
> > From: Christian Marangi <ansuelsmth@gmail.com>
> > 
> > Support for Airoha EN7581 Multi Function Device that
> > expose PINCTRL functionality and PWM functionality.
> 
> The device is a jumble of pinctrl registers, some of which can oscillate.
> 
> This is *still* not an MFD.
> 
> If you wish to spread this functionality over 2 drivers, use syscon to
> obtain the registers and simple-mfd to automatically probe the drivers.
>

Hi Lee,

let me summarize the situation so it's more clear why
this additional mfd driver.

There were various iteration for these 2 driver (pinctrl and PWM).
Due to the fact that these 2 are placed in the same register block
with the PWM register in the middle, we proposed various .yaml schema
that could better model it.

The first idea was to map the single register used by the 2 driver.

        pio: pinctrl@1fa20214 {
                compatible = "airoha,en7581-pinctrl";
                reg = <0x0 0x1fa20214 0x0 0x30>,
                        <0x0 0x1fa2027c 0x0 0x8>,
                        <0x0 0x1fbf0234 0x0 0x4>,
                        <0x0 0x1fbf0268 0x0 0x4>,
                        <0x0 0x1fa2001c 0x0 0x50>,
                        <0x0 0x1fa2018c 0x0 0x4>,
                        <0x0 0x1fbf0204 0x0 0x4>,
                        <0x0 0x1fbf0270 0x0 0x4>,
                        <0x0 0x1fbf0200 0x0 0x4>,
                        <0x0 0x1fbf0220 0x0 0x4>,
                        <0x0 0x1fbf0260 0x0 0x4>,
                        <0x0 0x1fbf0264 0x0 0x4>,
                        <0x0 0x1fbf0214 0x0 0x4>,
                        <0x0 0x1fbf0278 0x0 0x4>,
                        <0x0 0x1fbf0208 0x0 0x4>,
                        <0x0 0x1fbf027c 0x0 0x4>,
                        <0x0 0x1fbf0210 0x0 0x4>,
                        <0x0 0x1fbf028c 0x0 0x4>,
                        <0x0 0x1fbf0290 0x0 0x4>,
                        <0x0 0x1fbf0294 0x0 0x4>,
                        <0x0 0x1fbf020c 0x0 0x4>,
                        <0x0 0x1fbf0280 0x0 0x4>,
                        <0x0 0x1fbf0284 0x0 0x4>,
                        <0x0 0x1fbf0288 0x0 0x4>;

                gpio-controller;
                #gpio-cells = <2>;
                gpio-ranges = <&pio 0 13 47>;

                ...

        };

        pwm@1fbf0224 {
                compatible = "airoha,en7581-pwm";
                reg = <0x1fbf0224 0x10>,
                      <0x1fbf0238 0x28>,
                      <0x1fbf0298 0x8>;
                #pwm-cells = <3>;
        };

This was quickly rejected as it introduced way more complication
to workaround the overlapping addresses. (the device should map the
entire register space)

The second proposal was a parent+child implementation with the
pinctrl parent and the PWM child by referencing a syscon from
the parent.

        pio: pinctrl@1fbf0200 {
                compatible = "airoha,en7581-pinctrl", "simple-mfd", "syscon";
                reg = <0x1fbf0200 0x0 0xbc>;
                airoha,chip-scu = <&chip_scu>;
                ....

                pwm {
                        compatible = "airoha,en7581-pwm";
                        ...
                };
        };

Also this second proposal was rejected by device tree folks
as the device implement both pinctrl and PWM in the register
space and they are not actually separate devices.

There was also an additional proposal with the entire register
map in a dedicated node with syscon and pwm + pinctrl using it.
This was also rejected by device tree folks. (node that have only
a syscon are a nono)

It was suggested that this is a case of MFD (multi-functional-device)

As suggested we proposed a simple-mfd implementation following
common pattern. Parent node with simple-mfd and syscon compatible
and 2 child nodes, one with pinctrl and the other with PWM with each
his own compatible.

        mfd@1fbf0200 {
                compatible = "airoha,en7581-gpio-mfd";
                reg = <0x0 0x1fbf0200 0x0 0xc0>;

                interrupt-parent = <&gic>;
                interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;

                pio: pinctrl {
                        compatible = "airoha,en7581-pinctrl";

                        gpio-controller;
                        #gpio-cells = <2>;

                        interrupt-controller;
                        #interrupt-cells = <2>;
                };

                pwm: pwm {
                        compatible = "airoha,en7581-pwm";

                        #pwm-cells = <3>;
                        status = "disabled";
                };
        };

Also this was rejected by device tree folks as the property for
pinctrl and pwm needed to be in the MFD node and there should't
be child node with single compatible.
This comes from the fact that DT needs to describe how the HW is
modelled and not how the drivers are implemented.

Finally Rob agreed and added the Reviwed-by on the current
implementation with single MFD node with pinctrl and pwm.
Also Conor and Krzysztof agreed on this solution for the task.

    mfd@1fbf0200 {
        compatible = "airoha,en7581-gpio-sysctl";
        reg = <0x1fbf0200 0xc0>;

        interrupt-parent = <&gic>;
        interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;

        gpio-controller;
        #gpio-cells = <2>;

        interrupt-controller;
        #interrupt-cells = <2>;

        #pwm-cells = <3>;

        pinctrl {
                ...
        };
    };

With the following implementation, the only way to probe the
additional driver is with a specialized mfd driver that probe the
2 driver by name and we can't really use a simple-mfd implementation
as that requires child nodes with compatibles.

Sorry for the long message and I honestly hope we can find together
a common path for this between driver and Documentation.

Is it clear now why we had to ultimely had to implement and model things
this way?

--
        Ansuel



  reply	other threads:[~2024-10-02 22:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-01 17:29 [PATCH v5 0/5] Add mfd, pinctrl and pwm support to EN7581 SoC Lorenzo Bianconi
2024-10-01 17:29 ` [PATCH v5 1/5] dt-bindings: arm: airoha: Add the chip-scu node for " Lorenzo Bianconi
2024-10-01 17:29 ` [PATCH v5 2/5] dt-bindings: mfd: Add support for Airoha EN7581 GPIO System Controller Lorenzo Bianconi
2024-10-01 17:29 ` [PATCH v5 3/5] mfd: airoha: Add support for Airoha EN7581 MFD Lorenzo Bianconi
2024-10-02 13:25   ` Lee Jones
2024-10-02 22:42     ` Christian Marangi [this message]
2024-10-08 22:04     ` Lorenzo Bianconi
2024-10-09 10:48       ` Lee Jones
2024-10-09 10:55         ` Lee Jones
2024-10-10 10:14           ` Christian Marangi
2024-10-10 10:41             ` Christian Marangi
2024-10-10 16:25             ` Lee Jones
2024-10-10 19:34             ` Linus Walleij
2024-10-10 21:41               ` Lorenzo Bianconi
2024-10-11  6:51                 ` Linus Walleij
2024-10-01 17:29 ` [PATCH v5 4/5] pinctrl: airoha: Add support for EN7581 SoC Lorenzo Bianconi
2024-10-02 13:27   ` Linus Walleij
2024-10-02 15:37     ` Lorenzo Bianconi
2024-10-01 17:29 ` [PATCH v5 5/5] pwm: " Lorenzo Bianconi

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=66fdcc62.df0a0220.15bce8.4398@mx.google.com \
    --to=ansuelsmth@gmail.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=benjamin.larsson@genexis.eu \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh@kernel.org \
    --cc=sean.wang@kernel.org \
    --cc=ukleinek@kernel.org \
    --cc=upstream@airoha.com \
    /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;
as well as URLs for NNTP newsgroup(s).