Message-ID: <TYWPR01MB87753C261831519F4D6788E5C2F49@TYWPR01MB8775.jpnprd01.prod.outlook.com>
Date:   Tue, 3 Jan 2023 15:46:37 +0000
From:   Fabrizio Castro <fabrizio.castro.jz@...esas.com>
To:     Lee Jones <lee@...nel.org>
CC:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Sebastian Reichel <sre@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Chris Paterson <Chris.Paterson2@...esas.com>,
        Biju Das <biju.das@...renesas.com>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Jacopo Mondi <jacopo@...ndi.org>
Subject: RE: [PATCH v2 2/4] mfd: Add RZ/V2M PWC core driver

Hi Lees,

Thanks for your feedback!

> From: Lee Jones <lee@...nel.org>
> Sent: 03 January 2023 12:52
> Subject: Re: [PATCH v2 2/4] mfd: Add RZ/V2M PWC core driver
> 
> On Tue, 03 Jan 2023, Fabrizio Castro wrote:
> 
> > Hi Geert,
> >
> > Thanks for your feedback!
> >
> > > -----Original Message-----
> > > From: Geert Uytterhoeven <geert@...ux-m68k.org>
> > > Sent: 03 January 2023 08:37
> > > To: Fabrizio Castro <fabrizio.castro.jz@...esas.com>
> > > Cc: Linus Walleij <linus.walleij@...aro.org>; Bartosz Golaszewski
> > > <brgl@...ev.pl>; Rob Herring <robh+dt@...nel.org>; Krzysztof Kozlowski
> > > <krzysztof.kozlowski+dt@...aro.org>; Sebastian Reichel
> <sre@...nel.org>;
> > > Geert Uytterhoeven <geert+renesas@...der.be>; Lee Jones
> <lee@...nel.org>;
> > > linux-gpio@...r.kernel.org; devicetree@...r.kernel.org; linux-
> > > kernel@...r.kernel.org; linux-pm@...r.kernel.org; Chris Paterson
> > > <Chris.Paterson2@...esas.com>; Biju Das <biju.das@...renesas.com>;
> linux-
> > > renesas-soc@...r.kernel.org; Laurent Pinchart
> > > <laurent.pinchart@...asonboard.com>; Jacopo Mondi <jacopo@...ndi.org>
> > > Subject: Re: [PATCH v2 2/4] mfd: Add RZ/V2M PWC core driver
> > >
> > > Hi Fabrizio,
> > >
> > > On Wed, Dec 21, 2022 at 10:09 PM Fabrizio Castro
> > > <fabrizio.castro.jz@...esas.com> wrote:
> > > > The External Power Sequence Controller (PWC) IP (found in the
> > > > RZ/V2M SoC) is a controller for external power supplies (regulators
> > > > and power switches), and it supports the following features: it
> > > > generates a power on/off sequence for external power supplies,
> > > > it generates an on/off sequence for the LPDDR4 core power supply
> > > > (LPVDD), it comes with General-Purpose Outputs, and it processes
> > > > key input signals.
> > >
> > > Thanks for your patch!
> > >
> > > > The PWC is basically a Multi-Function Device (MFD), its software
> > > > support comes with a core driver, and specialized drivers for
> > > > its specific features.
> > >
> > > I have to admit I'm not such a big fan of MFD.  In this driver,
> > > you are not even sharing resources in the MFD cells, just the mapped
> > > register base.  So I think you can easily save +100 LoC and reduce
> > > maintenance synchronization overhead across subsystems by just having
> > > a single non-MFD driver instead.
> > >
> > > Did you pick MFD because the PWC poweroff feature depends on board
> > > wiring, and thus is optional?
> >
> > I am not a big fan of MFD, either.
> 
> Interesting.
> 
> Could you both elaborate further please?

I have nothing against MFD, it's just that, as I am finding out, it looks
like there is always a reason to not go down that road.
I have tried simple-mfd (which I think is a brilliant solution, especially
when combined with syscon), and it didn't fly. With this version I have tried
another approach based on MFD, and it's not flying.
I'll end up with a single driver supporting the various features of this
MFD device, which is fine, yet the software will have nothing to do with
MFD.

> 
> > I picked MFD because we were not 100% sure of what the IP could do
> > when we started working on it.
> > I have received more information regarding the IP now (which I don't
> > have the liberty to discuss), I am still not 100% sure that's all
> > of it, but basically its support may require expansion later on.
> >
> > I liked the solution based on syscon and simple-mfd for several reasons,
> > but having dropped syscon and simple-mfd due to issues with the dt-
> bindings
> > I have moved on with a core driver to instantiate the required SW
> support.
> > We could of course move to a unified driver if that makes more sense?
> > If we were to move to unified driver, under which directory would you
> > suggest we put it?
> 
> If you do not have any resources to share, you can simply register each
> of the devices via Device Tree.  I do not see a valid reason to force a
> parent / child relationship for your use-case.

There would probably be overlapping on the same memory region, which would
lead to ioremapping the same region multiple times, which is something
I would prefer to avoid if possible.

> 
> Many people attempt to use MFD as a dumping ground / workaround for a
> bunch of reasons.  Some valid, others not so much.

As it turns out, it looks like I don't have valid reasons to use MFD,
therefore I'll switch to a single, non MFD, driver.

Thank you for taking the time to look into this though! Really
appreciated.

Fab

> 
> --
> Lee Jones [李琼斯]

Powered by blists - more mailing lists