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:

quoted

[Adding Shawn on Cc]

Thanks Fabio.

quoted

On Wed, Feb 7, 2018 at 9:11 AM, Sascha Hauer <s.hauer@pengutronix.d
e> wrote:

quoted

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