Re: [PATCH v2 1/3] dt-bindings: add binding for i.MX8MQ IOMUXC

[Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

Am Donnerstag, den 08.02.2018, 16:56 +0800 schrieb Shawn Guo:
> On Wed, Feb 07, 2018 at 09:41:22AM -0200, Fabio Estevam wrote:
> > [Adding Shawn on Cc]
> 
> Thanks Fabio.
> 
> > On Wed, Feb 7, 2018 at 9:11 AM, Sascha Hauer <s.hauer@pengutronix.d
> > e> wrote:
> > 
> > > My opinion is that all that is generic about padctrl is a device
> > > driver
> > > saying "Put my pins into a suitable mode". That is what padctrl
> > > is good
> > > for and we are there for years now. I have always been happy with
> > > the
> > > plain register values in the device tree. Before device tree we
> > > had
> > > exactly these values in the board files and I never heard anyone
> > > complaining about it. There were defines for the bits in the
> > > register
> > > which you could use when you were unhappy with plain register
> > > values.
> > > 
> > > It's really trivial to look in the reference manual to make up
> > > the
> > > needed register values. It's also trivial to take a register
> > > value
> > > and look into the reference manual what this value does. Every
> > > translation layer, call it generic properties, just makes things
> > > more
> > > complicated. Often enough our input is register value tables
> > > from either our customers our from spreadsheets from FSL/NXP.
> > > Every
> > > translation layer in the way just means we have to translate the
> > > already
> > > existing register values into something hoping that this
> > > correctly
> > > translates back into the register values.
> > > 
> > > It's not that some board designer comes up with "I need a drive
> > > strength
> > > of 150mA" and wants to put that value into the device tree.
> > > Instead they
> > > start with the reference manual, see which values they can (must)
> > > adjust
> > > and then adjust the values until they are happy. No one wants to
> > > ask
> > > questions like "How do I have to manipulate that device tree to
> > > change
> > > that particular bit?"
> > > 
> > > As said, I am happy with plain register values in the device tree
> > > and
> > > I consider everything else overengineered.
> > > FSL/NXP Reference Manuals are freely available and of high
> > > quality so
> > > everybody can understand the register values. There's nothing
> > > magic to
> > > them. That might change slightly when the Manuals are not
> > > available, but
> > > even then I think that not the device tree ABI is the right place
> > > to
> > > add that missing documentation.
> > 
> > I agree 100% with Sascha.
> 
> I would vote for not going generic pinconf either, as the controversy
> here starts from something, that indicates the generic stuff doesn't
> work for i.MX.

So it seems with that we are at a point where the majority vote of
users/maintainers are in favor of keeping the binding that has served
us well on MX5/6. Which is right where we started with v1 of the MX8
patches.

How do we proceed? I would like to send out a respin of those series
next week. Can we all agree to roll back the pinctrl binding to the
MX5/6 one? Or are there still major reservations against it? I would
like to avoid introducing any unnecessary churn.

Regards,
Lucas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html