Hi Lees, Thanks for your feedback! > From: Lee Jones <lee@xxxxxxxxxx> > 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@xxxxxxxxxxxxxx> > > > Sent: 03 January 2023 08:37 > > > To: Fabrizio Castro <fabrizio.castro.jz@xxxxxxxxxxx> > > > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx>; Bartosz Golaszewski > > > <brgl@xxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Krzysztof Kozlowski > > > <krzysztof.kozlowski+dt@xxxxxxxxxx>; Sebastian Reichel > <sre@xxxxxxxxxx>; > > > Geert Uytterhoeven <geert+renesas@xxxxxxxxx>; Lee Jones > <lee@xxxxxxxxxx>; > > > linux-gpio@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux- > > > kernel@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx; Chris Paterson > > > <Chris.Paterson2@xxxxxxxxxxx>; Biju Das <biju.das@xxxxxxxxxxxxxx>; > linux- > > > renesas-soc@xxxxxxxxxxxxxxx; Laurent Pinchart > > > <laurent.pinchart@xxxxxxxxxxxxxxxx>; Jacopo Mondi <jacopo@xxxxxxxxxx> > > > 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@xxxxxxxxxxx> 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 [李琼斯]
