On Fri, 18 May 2018, Amelie DELAUNAY wrote: > On 05/17/2018 08:36 AM, Lee Jones wrote: > > On Wed, 16 May 2018, Amelie DELAUNAY wrote: > > > >> > >> > >> On 05/16/2018 04:20 PM, Linus Walleij wrote: > >>> On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY <amelie.delaunay@xxxxxx> wrote: > >>> > >>>> Indeed, stmfx has other functions than GPIO. But, after comments done > >>>> here: [1] and there: [2], it has been decided to move MFD parent/GPIO > >>>> child drivers into a single PINCTRL/GPIO driver because of the following > >>>> reasons: > >>>> - Other stmfx functions (IDD measurement and TouchScreen controller) are > >>>> not used on any of the boards using an stmfx and supported by Linux, so > >>>> no way to test these functions, and no need to maintain them while they > >>>> are not being used. > >>>> - But, in the case a new board will use more than GPIO function on > >>>> stmfx, the actual implementation allow to easily extract common init > >>>> part of stmfx and put it in an MFD driver. > >>>> > >>>> So I could remove gpio sub-node and put its contents in stmfx node and > >>>> keep single PINCTRL/GPIO driver for the time being. > >>>> Please advise, > >>> > >>> I would normally advice to use the right modeling from the start, create > >>> the MFD driver and spawn the devices from there. It is confusing > >>> if the layout of the driver(s) doesn't really match the layout of the > >>> hardware. > >>> > >>> I understand that it is a pain to write new MFD drivers to get your > >>> things going and it would be "nice to get this working really quick > >>> now" but in my experience it is better to do it right from the start. > >>> > >> > >> Hi Linus, > >> > >> Thanks for your advice. I understand the point. > >> So, the right modeling would be to: > >> - create an MFD driver with the common init part of stmfx > >> - remove all common init part of stmfx-pinctrl driver and keep only all > >> gpio/pinctrl functions. > >> > >> I will not develop the other stmfx functions (IDD measurement driver and > >> TouchScreen controller driver) because, as explained ealier, they are > >> not used on any of the boards using an stmfx and supported by Linux, so > >> no way to test these functions, and no need to maintain them while they > >> are not being used. > >> > >> Lee, are you OK with that ? > > > > I missed a lot of this conversation I think, but from what I've read, > > it sounds fine. > > > > I summarize the situation: > - I still don't have an official datasheet for STMFX device which could > justify the use of an MFD driver; > - the MFD driver will contain the STMFX chip initialization stuff such > as regmap initialization (regmap structure will be shared with the > child), chip initialization, global interrupt management; > - there will be only one child (GPIO/PINCTRL node) for the time being. > > So, is "MFD driver + GPIO/PINCTRL driver" the right modeling, and does > it still sound fine after this summary ? :) It is starting to sound like there will only ever be one child device, which starts to cross the line into "this is not an MFD" (M = Multi) territory. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
