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

Message ID 20180201174923.7385-1-l.stach@pengutronix.de
State New
Headers show
Series
  • [v2,1/3] dt-bindings: add binding for i.MX8MQ IOMUXC
Related show

Commit Message

Lucas Stach Feb. 1, 2018, 5:49 p.m.
This adds the binding for the i.MX8MQ pin controller, in the same
fashion as earlier i.MX SoCs.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
v2: switch to generic pinconf properties
---
 .../bindings/pinctrl/fsl,imx8mq-pinctrl.txt        | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt

Comments

Rob Herring Feb. 5, 2018, 6:09 a.m. | #1
On Thu, Feb 01, 2018 at 06:49:21PM +0100, Lucas Stach wrote:
> This adds the binding for the i.MX8MQ pin controller, in the same
> fashion as earlier i.MX SoCs.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> v2: switch to generic pinconf properties
> ---
>  .../bindings/pinctrl/fsl,imx8mq-pinctrl.txt        | 39 ++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt
> new file mode 100644
> index 000000000000..5c5d2d835d05
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt
> @@ -0,0 +1,39 @@
> +* Freescale IMX8MQ IOMUX Controller
> +
> +Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
> +for common binding part and usage.
> +
> +=== Pin Controller Node ===
> +
> +Required properties:
> +- compatible: "fsl,imx8mq-iomuxc"
> +- reg: Must contain the base physical address and size of the iomuxc registers.
> +
> +=== Pin Configuration Node ===
> +Required properties:
> +- pinmux: Array of integersy, representing a group of pins mux setting.
> +	The format is pinmux = <PIN_FUNC_ID>, PIN_FUNC_ID is a pin working on
> +	a specific function.
> +
> +	Refer to imx8mq-pinfunc.h in device tree source folder for all available
> +	imx8mq PIN_FUNC_ID.
> +
> +Optional Properties:
> +- drive-strength		Integer: controls Drive Strength

I thought drive-strength is supposed to be be in mA. We should not have 
differing units in common properties. 

There was an Atmel binding the other day that this came up. 

> +					0: driver disabled
> +					1: 255 Ohm
> +					2: 105 Ohm
> +					3:  75 Ohm
> +					4:  85 Ohm
> +					5:  65 Ohm
> +					6:  45 Ohm
> +					7:  40 Ohm
> +- slew-rate:			Integer: controls Slew Rate
> +					0: Slow
> +					1: Medium
> +					2: Fast
> +					3: Maximum
> +- drive-open-drain		Bool: enable Open-drian
> +- bias-pull-up			Bool: enable Pull-up
> +- input-schmitt-enable		Bool: enable schmitt-trigger
> +- input-enable			Bool: enable input, overriding module settings
> -- 
> 2.15.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lucas Stach Feb. 5, 2018, 10:09 a.m. | #2
Am Montag, den 05.02.2018, 00:09 -0600 schrieb Rob Herring:
> On Thu, Feb 01, 2018 at 06:49:21PM +0100, Lucas Stach wrote:
> > This adds the binding for the i.MX8MQ pin controller, in the same
> > fashion as earlier i.MX SoCs.
> > 
> > > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > ---
> > v2: switch to generic pinconf properties
> > ---
> >  .../bindings/pinctrl/fsl,imx8mq-pinctrl.txt        | 39 ++++++++++++++++++++++
> >  1 file changed, 39 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt
> > new file mode 100644
> > index 000000000000..5c5d2d835d05
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt
> > @@ -0,0 +1,39 @@
> > +* Freescale IMX8MQ IOMUX Controller
> > +
> > +Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
> > +for common binding part and usage.
> > +
> > +=== Pin Controller Node ===
> > +
> > +Required properties:
> > +- compatible: "fsl,imx8mq-iomuxc"
> > +- reg: Must contain the base physical address and size of the iomuxc registers.
> > +
> > +=== Pin Configuration Node ===
> > +Required properties:
> > +- pinmux: Array of integersy, representing a group of pins mux setting.
> > > > +	The format is pinmux = <PIN_FUNC_ID>, PIN_FUNC_ID is a pin working on
> > > > +	a specific function.
> > +
> > > > +	Refer to imx8mq-pinfunc.h in device tree source folder for all available
> > > > +	imx8mq PIN_FUNC_ID.
> > +
> > +Optional Properties:
> > +- drive-strength		Integer: controls Drive Strength
> 
> I thought drive-strength is supposed to be be in mA. We should not have 
> differing units in common properties. 
> 
> There was an Atmel binding the other day that this came up.

I know it's in the common binding, but it's going to be very hard to
support. The drive-strength in mA really depends on external loading of
the pin and the pin voltage, at least for the most widespread
controllers that only switch between resistors, instead of driving the
pin by a current regulator.
So we would need much more information, which doesn't really seem
practical.

I would much prefer if we just remove unit from the common binding and
let the drivers define it in a way that fits their hardware
description.

It's the same thing with the slew-rate really, but the common binding
didn't make the mistake to define a single unit there, with many
pincontrollers being really vague about how fast the slew really is,
but some may actually define it in uS or whatever else makes sense.

Regards,
Lucas
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij Feb. 5, 2018, 11:13 p.m. | #3
On Mon, Feb 5, 2018 at 11:09 AM, Lucas Stach <l.stach@pengutronix.de> wrote:

>> > +Optional Properties:
>> > +- drive-strength           Integer: controls Drive Strength
>>
>> I thought drive-strength is supposed to be be in mA. We should not have
>> differing units in common properties.
>>
>> There was an Atmel binding the other day that this came up.
>
> I know it's in the common binding, but it's going to be very hard to
> support. The drive-strength in mA really depends on external loading of
> the pin and the pin voltage, at least for the most widespread
> controllers that only switch between resistors, instead of driving the
> pin by a current regulator.

How does this circuit really look? Can you sketch something so
we understand what is going on electronically here?

The way I imagine most drive strength out there works is by simply
connection more MOS-totempoles after each other and each of them
has a production-technology-related max output current like 4mA, so
by putting two in a series yoy double that to 8 mA.

Is that what you mean with "current regulator"?

If you mean rather "output impedance", that is something else and
something we need a new (generic) property for. I never saw that
before, really.

> I would much prefer if we just remove unit from the common binding and
> let the drivers define it in a way that fits their hardware
> description.

Yeah but is this really the same thing even ...

> It's the same thing with the slew-rate really, but the common binding
> didn't make the mistake to define a single unit there, with many
> pincontrollers being really vague about how fast the slew really is,
> but some may actually define it in uS or whatever else makes sense.

I agree with that. Also for skewrate and output time delays
(skew delay).

It's very unclear how cell libraries really implement this.
But with drive strength I thought we knew it ...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lucas Stach Feb. 6, 2018, 10:53 a.m. | #4
Hi Linus,

Am Dienstag, den 06.02.2018, 00:13 +0100 schrieb Linus Walleij:
> > On Mon, Feb 5, 2018 at 11:09 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> 
> > > > +Optional Properties:
> > > > +- drive-strength           Integer: controls Drive Strength
> > > 
> > > I thought drive-strength is supposed to be be in mA. We should not have
> > > differing units in common properties.
> > > 
> > > There was an Atmel binding the other day that this came up.
> > 
> > I know it's in the common binding, but it's going to be very hard to
> > support. The drive-strength in mA really depends on external loading of
> > the pin and the pin voltage, at least for the most widespread
> > controllers that only switch between resistors, instead of driving the
> > pin by a current regulator.
> 
> How does this circuit really look? Can you sketch something so
> we understand what is going on electronically here?

There is no description of how the circuit really looks like and I
would very much prefer this not being a prerequisite to get some
software support in place.

The best description we have is from NXP AN5078:
"The drive strength enable (DSE) can be explained as series resistance
between an ideal driver's output and its load. To achieve maximal
transferred power, the impedance of the driver has to match the load
impedance."

Which means the control bits don't really vary the output impedance,
but the description models it like that. If we _assume_ the simple MOS
totempole setup then adding more totempoles will bring down the output
impedance.

> The way I imagine most drive strength out there works is by simply
> connection more MOS-totempoles after each other and each of them
> has a production-technology-related max output current like 4mA, so
> by putting two in a series yoy double that to 8 mA.

So with this description in mind the drive-strength property doesn't
describe an actual real world drive-strength, but some maximum current
output under ideal load matching?

That's pretty confusing actually, as in a real-world setup increasing
the drive-strength property value might negatively affect the load
matching, leading to _decreasing_ the actual drive-strength.

> Is that what you mean with "current regulator"?
> 
> If you mean rather "output impedance", that is something else and
> something we need a new (generic) property for. I never saw that
> before, really.

So, just because the description of the drive-strength value uses some
(idealized) output impedance, we are now going to introduce yet another
property for the same thing? This is confusing to people reading the
reference manual, which never speaks about output-impedance, but always
about drive-strength.

Hardware people (the ones responsible to come up with the padctrl
settings) are much more likely to read the reference manual than any
idealized dt-binding. I want to make it as easy as possible for them to
match up the hardware and reference manual with the DT description.
So, can we please just keep the drive-strength property and deal with
it being described in different units in different hardware manuals?

Regards,
Lucas
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij Feb. 6, 2018, 2:32 p.m. | #5
On Tue, Feb 6, 2018 at 11:53 AM, Lucas Stach <l.stach@pengutronix.de> wrote:

Hi Lucas,

your reply seems a bit annoyed.

Are you annoyed with me?

In that case please take it down a bit, I understand it can
be stressful as developer, but I need to maintain the stuff
we're pushing in for years to come and it's my job to
ask the tricksy questions.

> Am Dienstag, den 06.02.2018, 00:13 +0100 schrieb Linus Walleij:
>> > On Mon, Feb 5, 2018 at 11:09 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
>>
>> > > > +Optional Properties:
>> > > > +- drive-strength           Integer: controls Drive Strength
>> > >
>> > > I thought drive-strength is supposed to be be in mA. We should not have
>> > > differing units in common properties.
>> > >
>> > > There was an Atmel binding the other day that this came up.
>> >
>> > I know it's in the common binding, but it's going to be very hard to
>> > support. The drive-strength in mA really depends on external loading of
>> > the pin and the pin voltage, at least for the most widespread
>> > controllers that only switch between resistors, instead of driving the
>> > pin by a current regulator.
>>
>> How does this circuit really look? Can you sketch something so
>> we understand what is going on electronically here?
>
> There is no description of how the circuit really looks like and I
> would very much prefer this not being a prerequisite to get some
> software support in place.

That depends. If you're a hobbyist with limited access to
documentation I agree. In that case let's go for something
that floats your project, I'm fine with that. I have a weak spot
for people with a good project and limited resources, so I
am here to help. I'd say then let's go for some "nxp,foo" property.

If you are working for NXP directly or under contract, what you say
is that the left hand does not know what the right hand is doing and that
is never a good sign. Such as the hardware and software departments
do not talk to each other, do not have each other mail addresses
and practice what is called "throw over the wall-engineering".
Or throw it all the way over to Pengutronix, maybe, a separate
legal entity they don't even prioritize to inform. What do I know.

In this latter case it is more or less my responsibility as subsystem
maintainer to push back at NXP as a legal body, it has nothing to
do with the people involved. Especially not you personally. In this
case I am adressing your organization, not you.

So which one is it?

> The best description we have is from NXP AN5078:
> "The drive strength enable (DSE) can be explained as series resistance
> between an ideal driver's output and its load. To achieve maximal
> transferred power, the impedance of the driver has to match the load
> impedance."
>
> Which means the control bits don't really vary the output impedance,
> but the description models it like that. If we _assume_ the simple MOS
> totempole setup then adding more totempoles will bring down the output
> impedance.

+- drive-strength               Integer: controls Drive Strength
+                                       0: driver disabled
+                                       1: 255 Ohm
+                                       2: 105 Ohm
+                                       3:  75 Ohm
+                                       4:  85 Ohm
+                                       5:  65 Ohm
+                                       6:  45 Ohm
+                                       7:  40 Ohm

As for equal resistances R = Rx/N assuming it is
really 255 Ohms internal resistance per totempole:

1: 255
2: 127,5
3: 85
4: 63,75
5: 51
6: 42,5
7: 36,4

I don't know. Something is not right. Maybe this is how
CMOS work under load?

>> The way I imagine most drive strength out there works is by simply
>> connection more MOS-totempoles after each other and each of them
>> has a production-technology-related max output current like 4mA, so
>> by putting two in a series yoy double that to 8 mA.
>
> So with this description in mind the drive-strength property doesn't
> describe an actual real world drive-strength, but some maximum current
> output under ideal load matching?

I guess that is what other datasheets have been listing.
I have personally seen a few of those.

I don't know if it is as simple as a totem-pole, I guess
IIRC under ideal circumstances the internal resistance of an
operational amplifier is zero. E.g. on a popular TTL part uA 741
it is 5.5 milliohms. What is Rout for a normal CMOS totem-pole?
Some googling suggests ~400 Ohm so 255 Ohm may not be
so far off.

Does anyone else know?

This is pretty interesting stuff :D

> That's pretty confusing actually, as in a real-world setup increasing
> the drive-strength property value might negatively affect the load
> matching, leading to _decreasing_ the actual drive-strength.

This sounds like a perfect argument to create a new
property "output-impedance" and use that in my ears.
It makes more sense to a designer, because what they
really want to do, electrically, is to match impedances.

I am thinking some designer writing this device tree.
What they want to control is the output impedance, not
drive strength. So that name makes more sense.

>> Is that what you mean with "current regulator"?
>>
>> If you mean rather "output impedance", that is something else and
>> something we need a new (generic) property for. I never saw that
>> before, really.
>
> So, just because the description of the drive-strength value uses some
> (idealized) output impedance, we are now going to introduce yet another
> property for the same thing?

Yes it seems like a good idea, if (by your own line of reasoning)
it is the physical principle underlying these resistance settings.
Then we are likely to see it again.

> This is confusing to people reading the
> reference manual, which never speaks about output-impedance, but always
> about drive-strength.

Since we are already (obviously) confused, we have to choose
the lesser evil here.

Apparently what (board- system-) designers want to do is match
output resistance to load, I would argue that it is more confusing
to call that "drive strength", i.e. what is misleading is not what I am
discussing here, but the manual you are referring to. Just a bad
piece of technical writing.

> Hardware people (the ones responsible to come up with the padctrl
> settings) are much more likely to read the reference manual than any
> idealized dt-binding.

Can we talk to them about this?

I don't like to think about them as some foreign people in a far
away dimension we can never understand or communicate
with, how do they really do what they do?

> I want to make it as easy as possible for them to
> match up the hardware and reference manual with the DT description.

I was hoping we could dig in a bit and figure out what we
are going to do and why and how these people think.

I want to avoid poking magic values we don't really understand
into registers and using the manual as alchemic magic or
spellbook, essentially. (As so often happens...)

> So, can we please just keep the drive-strength property and deal with
> it being described in different units in different hardware manuals?

If you want something to match the specific hardware
manual from NXP and you don't want it to be translated
into the units of the DT binding, then I think it is better
to use something prefixed "nxp,*".

That clearly indicates that this is some NXP oddity that
we don't really understand.

I was just hoping not to introduce too many of these.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lucas Stach Feb. 6, 2018, 3:47 p.m. | #6
Hi Linus,

Am Dienstag, den 06.02.2018, 15:32 +0100 schrieb Linus Walleij:
> On Tue, Feb 6, 2018 at 11:53 AM, Lucas Stach <l.stach@pengutronix.de>
> wrote:
> 
> Hi Lucas,
> 
> your reply seems a bit annoyed.
> 
> Are you annoyed with me?
> 
> In that case please take it down a bit, I understand it can
> be stressful as developer, but I need to maintain the stuff
> we're pushing in for years to come and it's my job to
> ask the tricksy questions.

To be fully honest I'm a bit annoyed with the pinctrl framework making
things (IMHO) unnecessarily complex, for what is basically a pretty
easy task. But I'll try to keep things focused on the technical issue
at hand, so we can all make some progress.

> > Am Dienstag, den 06.02.2018, 00:13 +0100 schrieb Linus Walleij:
> > > > On Mon, Feb 5, 2018 at 11:09 AM, Lucas Stach <l.stach@pengutron
> > > > ix.de> wrote:
> > > > > > +Optional Properties:
> > > > > > +- drive-strength           Integer: controls Drive
> > > > > > Strength
> > > > > 
> > > > > I thought drive-strength is supposed to be be in mA. We
> > > > > should not have
> > > > > differing units in common properties.
> > > > > 
> > > > > There was an Atmel binding the other day that this came up.
> > > > 
> > > > I know it's in the common binding, but it's going to be very
> > > > hard to
> > > > support. The drive-strength in mA really depends on external
> > > > loading of
> > > > the pin and the pin voltage, at least for the most widespread
> > > > controllers that only switch between resistors, instead of
> > > > driving the
> > > > pin by a current regulator.
> > > 
> > > How does this circuit really look? Can you sketch something so
> > > we understand what is going on electronically here?
> > 
> > There is no description of how the circuit really looks like and I
> > would very much prefer this not being a prerequisite to get some
> > software support in place.
> 
> That depends. If you're a hobbyist with limited access to
> documentation I agree. In that case let's go for something
> that floats your project, I'm fine with that. I have a weak spot
> for people with a good project and limited resources, so I
> am here to help. I'd say then let's go for some "nxp,foo" property.
> 
> If you are working for NXP directly or under contract, what you say
> is that the left hand does not know what the right hand is doing and
> that
> is never a good sign. Such as the hardware and software departments
> do not talk to each other, do not have each other mail addresses
> and practice what is called "throw over the wall-engineering".
> Or throw it all the way over to Pengutronix, maybe, a separate
> legal entity they don't even prioritize to inform. What do I know.
> 
> In this latter case it is more or less my responsibility as subsystem
> maintainer to push back at NXP as a legal body, it has nothing to
> do with the people involved. Especially not you personally. In this
> case I am adressing your organization, not you.
> 
> So which one is it?

Neither. Pengutronix is mostly contracted by customers of NXP to enable
stuff in mainline. So I'm not working on this in my spare time, but I
still have to deal with the fact that I can only get the information
from the reference manual, NXP downstream BSPs and the occasional
helpful NXP employee.

Also even if we were inside of NXP, pad cells are usually something
that chip makers buy or get from the Fab design library. So probably
even they don't know what's inside exactly.

> > The best description we have is from NXP AN5078:
> > "The drive strength enable (DSE) can be explained as series
> > resistance
> > between an ideal driver's output and its load. To achieve maximal
> > transferred power, the impedance of the driver has to match the
> > load
> > impedance."
> > 
> > Which means the control bits don't really vary the output
> > impedance,
> > but the description models it like that. If we _assume_ the simple
> > MOS
> > totempole setup then adding more totempoles will bring down the
> > output
> > impedance.
> 
> +- drive-strength               Integer: controls Drive Strength
> +                                       0: driver disabled
> +                                       1: 255 Ohm
> +                                       2: 105 Ohm
> +                                       3:  75 Ohm
> +                                       4:  85 Ohm
> +                                       5:  65 Ohm
> +                                       6:  45 Ohm
> +                                       7:  40 Ohm
> 
> As for equal resistances R = Rx/N assuming it is
> really 255 Ohms internal resistance per totempole:
> 
> 1: 255
> 2: 127,5
> 3: 85
> 4: 63,75
> 5: 51
> 6: 42,5
> 7: 36,4
> 
> I don't know. Something is not right. Maybe this is how
> CMOS work under load?

Semiconductor physics tends to be slightly more complex than this. :)

> > > The way I imagine most drive strength out there works is by
> > > simply
> > > connection more MOS-totempoles after each other and each of them
> > > has a production-technology-related max output current like 4mA,
> > > so
> > > by putting two in a series yoy double that to 8 mA.
> > 
> > So with this description in mind the drive-strength property
> > doesn't
> > describe an actual real world drive-strength, but some maximum
> > current
> > output under ideal load matching?
> 
> I guess that is what other datasheets have been listing.
> I have personally seen a few of those.
> 
> I don't know if it is as simple as a totem-pole, I guess
> IIRC under ideal circumstances the internal resistance of an
> operational amplifier is zero. E.g. on a popular TTL part uA 741
> it is 5.5 milliohms. What is Rout for a normal CMOS totem-pole?
> Some googling suggests ~400 Ohm so 255 Ohm may not be
> so far off.
> 
> Does anyone else know?
> 
> This is pretty interesting stuff :D

Interesting indeed, but pretty far away from the dt-binding we set out
to discuss. And even if we might come up with a simplistic model of
what's going on inside the pad cell, how do we know if it matches
reality? Does this really help us define a useful binding?

> > That's pretty confusing actually, as in a real-world setup
> > increasing
> > the drive-strength property value might negatively affect the load
> > matching, leading to _decreasing_ the actual drive-strength.
> 
> This sounds like a perfect argument to create a new
> property "output-impedance" and use that in my ears.
> It makes more sense to a designer, because what they
> really want to do, electrically, is to match impedances.
> 
> I am thinking some designer writing this device tree.
> What they want to control is the output impedance, not
> drive strength. So that name makes more sense.
> 
> > > Is that what you mean with "current regulator"?
> > > 
> > > If you mean rather "output impedance", that is something else and
> > > something we need a new (generic) property for. I never saw that
> > > before, really.
> > 
> > So, just because the description of the drive-strength value uses
> > some
> > (idealized) output impedance, we are now going to introduce yet
> > another
> > property for the same thing?
> 
> Yes it seems like a good idea, if (by your own line of reasoning)
> it is the physical principle underlying these resistance settings.
> Then we are likely to see it again.
> 
> > This is confusing to people reading the
> > reference manual, which never speaks about output-impedance, but
> > always
> > about drive-strength.
> 
> Since we are already (obviously) confused, we have to choose
> the lesser evil here.
> 
> Apparently what (board- system-) designers want to do is match
> output resistance to load, I would argue that it is more confusing
> to call that "drive strength", i.e. what is misleading is not what I
> am
> discussing here, but the manual you are referring to. Just a bad
> piece of technical writing.

What usually happens is that hardware (I'm talking about board/system
here) designers start by reading the reference manual and hardware
design guide and work with that. They come up with all the necessary
configuration in the terms of the manual.

After that they or someone else has to translate this into DT. Things
get confusing when the reference manual and the DT binding disagree
about the used terms.

> > Hardware people (the ones responsible to come up with the padctrl
> > settings) are much more likely to read the reference manual than
> > any
> > idealized dt-binding.
> 
> Can we talk to them about this?
> 
> I don't like to think about them as some foreign people in a far
> away dimension we can never understand or communicate
> with, how do they really do what they do?

I wasn't referring to the chip design people, but board designers. I
talk to them quite often, but it's a lot easier if the Linux people and
board designers agree on the terms used. :)

> > I want to make it as easy as possible for them to
> > match up the hardware and reference manual with the DT description.
> 
> I was hoping we could dig in a bit and figure out what we
> are going to do and why and how these people think.
> 
> I want to avoid poking magic values we don't really understand
> into registers and using the manual as alchemic magic or
> spellbook, essentially. (As so often happens...)
> 
> > So, can we please just keep the drive-strength property and deal
> > with
> > it being described in different units in different hardware
> > manuals?
> 
> If you want something to match the specific hardware
> manual from NXP and you don't want it to be translated
> into the units of the DT binding, then I think it is better
> to use something prefixed "nxp,*".

> That clearly indicates that this is some NXP oddity that
> we don't really understand.

I'm not keen on using the common padctrl stuff, which already bloats
the DT description compared to i.MX6, and then again need to introduce
custom properties. That's just worst of both worlds, verbose DT to use
the common stuff, mixed with special properties, only valid on this
single controller.

If you insist I guess I'm fine with compromising on an "output-
impedance" common property, but then this just makes things harder for
everyone involved, as the impedance even seems to vary slightly with
the used pad voltage. So to not get into a combinatorial explosion, we
would need to describe this property as somethings like "output
impedance at 3.3v)", at least on this specific hardware.

Or we could agree that drive-strength property could be described in
some unit that makes sense on each controller. mA for hardware
described with some fabled ideal load matching, Ohms for hardware that
models it this way with maximum drive strength at the point of best
load matching.

In the end this is about mapping 3 hardware bits to a DT description...

Regards,
Lucas

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij Feb. 7, 2018, 9:09 a.m. | #7
On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@pengutronix.de> wrote:

> To be fully honest I'm a bit annoyed with the pinctrl framework making
> things (IMHO) unnecessarily complex, for what is basically a pretty
> easy task.

My ambition is to make things readable, understandable and
maintainable. In generic terms, incorporating a bunch of knowledge
of the electronics that really happen into the stuff we encode in
the kernel.

I guess it varies a bit on what goal one has.

If the goal is "ship product with upstream kernel really fast now"
then things like pinctrl-single.c where we just hammer magic values
into registers, make sense. OMAP developers had no idea whatsoever
what their ASIC people or cell library authors were doing so they
just threw in the towel. HiSilicon also use this. Intels ambition was
to use ACPI BIOS to handle all pin control and route around the kernel
altogether, but that is not working out so well for them I think.

All of them are approaches to avoid putting the hairy details into the
kernel, just poke some magic values into some magic registers
and be happy.

So i.MX could have been like that, but then I guess you need to take
legacy into account and discuss with the other i.MX driver authors
about how they really wanted and want to do things.

Their current silence wrt this mailchain is actually becoming a
problem, and the problem is that discussing with you falls upwards
to me as subsystem maintainer. Which sucks. I prefer that people
who know this hardware discuss amongst themselves how they
want things to work.

Surely Sascha must have an opinion? It means much to me
what he wants to do. I take it you guys are colleagues?

> Pengutronix is mostly contracted by customers of NXP to enable
> stuff in mainline. So I'm not working on this in my spare time, but I
> still have to deal with the fact that I can only get the information
> from the reference manual, NXP downstream BSPs and the occasional
> helpful NXP employee.

Hm I see, this seems like a bit of crappy position to be in when
you just want to ask someone in hardware how things really work.

But we have Freescale i.MX maintainers on the inside of the company
now NXP (soon Qualcomm? soon Broadcom?).

Hell this mail is even going to linux-imx@nxp.com, what do they do
with it? Put it in a mailbox and never read it?

Surely someone on the inside must be able to provide some details.

> Also even if we were inside of NXP, pad cells are usually something
> that chip makers buy or get from the Fab design library. So probably
> even they don't know what's inside exactly.

Yeah that is what I call "throw over the wall engineering".
It's not good, if NXP works with information brick walls like that it is
not any good for them, because it is not any good for their customers.

Not something you or I can fix though...

> What usually happens is that hardware (I'm talking about board/system
> here) designers start by reading the reference manual and hardware
> design guide and work with that. They come up with all the necessary
> configuration in the terms of the manual.

Sometimes half-guessing and a bit of trial-and-error right?

> After that they or someone else has to translate this into DT. Things
> get confusing when the reference manual and the DT binding disagree
> about the used terms.

I see.

>> If you want something to match the specific hardware
>> manual from NXP and you don't want it to be translated
>> into the units of the DT binding, then I think it is better
>> to use something prefixed "nxp,*".
>
>> That clearly indicates that this is some NXP oddity that
>> we don't really understand.
>
> I'm not keen on using the common padctrl stuff, which already bloats
> the DT description compared to i.MX6,

This you need to discuss with the generic i.MX driver maintainers.
They are the maintainers of drivers/pinctrl/freescale/* after all.

They never put an entry in MAINTAINERS though, but I
always regarded these as the pinctrl maintainers for i.MX:

ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
M:      Shawn Guo <shawnguo@kernel.org>
M:      Sascha Hauer <kernel@pengutronix.de>
R:      Fabio Estevam <fabio.estevam@nxp.com>

On top of this, Dong Aisheng, Gary Bisson and
Vladimir Zapolskiy has made major contributions.

It's a little ecosystem on its own, not really to be discussed
by just you and me. I wonder where the rest of the voices are,
I hope not silenced by organizational stress after the NXP
merger...

> and then again need to introduce
> custom properties. That's just worst of both worlds, verbose DT to use
> the common stuff, mixed with special properties, only valid on this
> single controller.

No matter how much you dislike it, it is what e.g. Qualcomm is
doing. (Who might soon be one and the same as NXP I hear.)

> If you insist I guess I'm fine with compromising on an "output-
> impedance" common property, but then this just makes things harder for
> everyone involved, as the impedance even seems to vary slightly with
> the used pad voltage. So to not get into a combinatorial explosion, we
> would need to describe this property as somethings like "output
> impedance at 3.3v)", at least on this specific hardware.

Hm, should it me "nxp,drive-strength" then, as it is just some
magic value? I guess "nxp,magic-drive-strength" is not going to
cut it :D

Also maybe we should use the old "freescale,*" notation for legacy
reasons... I don't know. This Vendor prefix seems less stable
than the chipsets.

> Or we could agree that drive-strength property could be described in
> some unit that makes sense on each controller. mA for hardware
> described with some fabled ideal load matching, Ohms for hardware that
> models it this way with maximum drive strength at the point of best
> load matching.

I am not like stubbornly against. I just want some discussion here,
it would be nice to know the opinion of the i.MX maintainers.

> In the end this is about mapping 3 hardware bits to a DT description...

Pleas don't think about it like "can't we just do this real simple
thing now, just merge this and stop being an ass".

Things just poking three bits can look very simple, like in so
many BSPs:

volatile unsigned long *foo;

foo = (unsigned long *) 0xfec0be00;
*foo &= ~0x700;
*foo |= 0x200; /* do the magic */

But this is not helpful for developers or maintainers. That is IMHO
why we have the frameworks and all the DT standardization in
the first place, exactly so we understand what we are doing.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
A.s. Dong Feb. 7, 2018, 11:02 a.m. | #8
SGkgTGludXMsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGludXMg
V2FsbGVpaiBbbWFpbHRvOmxpbnVzLndhbGxlaWpAbGluYXJvLm9yZ10NCj4gU2VudDogMjAxOOW5
tDLmnIg35pelIDE3OjA5DQo+IFRvOiBMdWNhcyBTdGFjaCA8bC5zdGFjaEBwZW5ndXRyb25peC5k
ZT47IEEucy4gRG9uZw0KPiA8YWlzaGVuZy5kb25nQG54cC5jb20+OyBkbC1saW51eC1pbXggPGxp
bnV4LWlteEBueHAuY29tPjsgR2FyeSBCaXNzb24NCj4gPGdhcnkuYmlzc29uQGJvdW5kYXJ5ZGV2
aWNlcy5jb20+OyBWbGFkaW1pciBaYXBvbHNraXkNCj4gPHZsYWRpbWlyX3phcG9sc2tpeUBtZW50
b3IuY29tPjsgU2FzY2hhIEhhdWVyIDxrZXJuZWxAcGVuZ3V0cm9uaXguZGU+DQo+IENjOiBSb2Ig
SGVycmluZyA8cm9iaEBrZXJuZWwub3JnPjsgTWFyayBSdXRsYW5kIDxtYXJrLnJ1dGxhbmRAYXJt
LmNvbT47DQo+IGxpbnV4LWdwaW9Admdlci5rZXJuZWwub3JnOyBvcGVuIGxpc3Q6T1BFTiBGSVJN
V0FSRSBBTkQgRkxBVFRFTkVEDQo+IERFVklDRSBUUkVFIEJJTkRJTkdTIDxkZXZpY2V0cmVlQHZn
ZXIua2VybmVsLm9yZz47DQo+IHBhdGNod29yay1sc3RAcGVuZ3V0cm9uaXguZGUNCj4gU3ViamVj
dDogUmU6IFtQQVRDSCB2MiAxLzNdIGR0LWJpbmRpbmdzOiBhZGQgYmluZGluZyBmb3IgaS5NWDhN
USBJT01VWEMNCj4gDQo+IE9uIFR1ZSwgRmViIDYsIDIwMTggYXQgNDo0NyBQTSwgTHVjYXMgU3Rh
Y2ggPGwuc3RhY2hAcGVuZ3V0cm9uaXguZGU+IHdyb3RlOg0KPiANCj4gPiBUbyBiZSBmdWxseSBo
b25lc3QgSSdtIGEgYml0IGFubm95ZWQgd2l0aCB0aGUgcGluY3RybCBmcmFtZXdvcmsgbWFraW5n
DQo+ID4gdGhpbmdzIChJTUhPKSB1bm5lY2Vzc2FyaWx5IGNvbXBsZXgsIGZvciB3aGF0IGlzIGJh
c2ljYWxseSBhIHByZXR0eQ0KPiA+IGVhc3kgdGFzay4NCj4gDQo+IE15IGFtYml0aW9uIGlzIHRv
IG1ha2UgdGhpbmdzIHJlYWRhYmxlLCB1bmRlcnN0YW5kYWJsZSBhbmQgbWFpbnRhaW5hYmxlLiBJ
bg0KPiBnZW5lcmljIHRlcm1zLCBpbmNvcnBvcmF0aW5nIGEgYnVuY2ggb2Yga25vd2xlZGdlIG9m
IHRoZSBlbGVjdHJvbmljcyB0aGF0IHJlYWxseQ0KPiBoYXBwZW4gaW50byB0aGUgc3R1ZmYgd2Ug
ZW5jb2RlIGluIHRoZSBrZXJuZWwuDQo+IA0KPiBJIGd1ZXNzIGl0IHZhcmllcyBhIGJpdCBvbiB3
aGF0IGdvYWwgb25lIGhhcy4NCj4gDQo+IElmIHRoZSBnb2FsIGlzICJzaGlwIHByb2R1Y3Qgd2l0
aCB1cHN0cmVhbSBrZXJuZWwgcmVhbGx5IGZhc3Qgbm93Ig0KPiB0aGVuIHRoaW5ncyBsaWtlIHBp
bmN0cmwtc2luZ2xlLmMgd2hlcmUgd2UganVzdCBoYW1tZXIgbWFnaWMgdmFsdWVzIGludG8NCj4g
cmVnaXN0ZXJzLCBtYWtlIHNlbnNlLiBPTUFQIGRldmVsb3BlcnMgaGFkIG5vIGlkZWEgd2hhdHNv
ZXZlciB3aGF0IHRoZWlyDQo+IEFTSUMgcGVvcGxlIG9yIGNlbGwgbGlicmFyeSBhdXRob3JzIHdl
cmUgZG9pbmcgc28gdGhleSBqdXN0IHRocmV3IGluIHRoZSB0b3dlbC4NCj4gSGlTaWxpY29uIGFs
c28gdXNlIHRoaXMuIEludGVscyBhbWJpdGlvbiB3YXMgdG8gdXNlIEFDUEkgQklPUyB0byBoYW5k
bGUgYWxsIHBpbg0KPiBjb250cm9sIGFuZCByb3V0ZSBhcm91bmQgdGhlIGtlcm5lbCBhbHRvZ2V0
aGVyLCBidXQgdGhhdCBpcyBub3Qgd29ya2luZyBvdXQgc28NCj4gd2VsbCBmb3IgdGhlbSBJIHRo
aW5rLg0KPiANCj4gQWxsIG9mIHRoZW0gYXJlIGFwcHJvYWNoZXMgdG8gYXZvaWQgcHV0dGluZyB0
aGUgaGFpcnkgZGV0YWlscyBpbnRvIHRoZSBrZXJuZWwsIGp1c3QNCj4gcG9rZSBzb21lIG1hZ2lj
IHZhbHVlcyBpbnRvIHNvbWUgbWFnaWMgcmVnaXN0ZXJzIGFuZCBiZSBoYXBweS4NCj4gDQo+IFNv
IGkuTVggY291bGQgaGF2ZSBiZWVuIGxpa2UgdGhhdCwgYnV0IHRoZW4gSSBndWVzcyB5b3UgbmVl
ZCB0byB0YWtlIGxlZ2FjeSBpbnRvDQo+IGFjY291bnQgYW5kIGRpc2N1c3Mgd2l0aCB0aGUgb3Ro
ZXIgaS5NWCBkcml2ZXIgYXV0aG9ycyBhYm91dCBob3cgdGhleSByZWFsbHkNCj4gd2FudGVkIGFu
ZCB3YW50IHRvIGRvIHRoaW5ncy4NCj4gDQo+IFRoZWlyIGN1cnJlbnQgc2lsZW5jZSB3cnQgdGhp
cyBtYWlsY2hhaW4gaXMgYWN0dWFsbHkgYmVjb21pbmcgYSBwcm9ibGVtLCBhbmQgdGhlDQo+IHBy
b2JsZW0gaXMgdGhhdCBkaXNjdXNzaW5nIHdpdGggeW91IGZhbGxzIHVwd2FyZHMgdG8gbWUgYXMg
c3Vic3lzdGVtIG1haW50YWluZXIuDQo+IFdoaWNoIHN1Y2tzLiBJIHByZWZlciB0aGF0IHBlb3Bs
ZSB3aG8ga25vdyB0aGlzIGhhcmR3YXJlIGRpc2N1c3MgYW1vbmdzdA0KPiB0aGVtc2VsdmVzIGhv
dyB0aGV5IHdhbnQgdGhpbmdzIHRvIHdvcmsuDQo+IA0KPiBTdXJlbHkgU2FzY2hhIG11c3QgaGF2
ZSBhbiBvcGluaW9uPyBJdCBtZWFucyBtdWNoIHRvIG1lIHdoYXQgaGUgd2FudHMgdG8gZG8uDQo+
IEkgdGFrZSBpdCB5b3UgZ3V5cyBhcmUgY29sbGVhZ3Vlcz8NCj4gDQo+ID4gUGVuZ3V0cm9uaXgg
aXMgbW9zdGx5IGNvbnRyYWN0ZWQgYnkgY3VzdG9tZXJzIG9mIE5YUCB0byBlbmFibGUgc3R1ZmYN
Cj4gPiBpbiBtYWlubGluZS4gU28gSSdtIG5vdCB3b3JraW5nIG9uIHRoaXMgaW4gbXkgc3BhcmUg
dGltZSwgYnV0IEkgc3RpbGwNCj4gPiBoYXZlIHRvIGRlYWwgd2l0aCB0aGUgZmFjdCB0aGF0IEkg
Y2FuIG9ubHkgZ2V0IHRoZSBpbmZvcm1hdGlvbiBmcm9tDQo+ID4gdGhlIHJlZmVyZW5jZSBtYW51
YWwsIE5YUCBkb3duc3RyZWFtIEJTUHMgYW5kIHRoZSBvY2Nhc2lvbmFsIGhlbHBmdWwNCj4gPiBO
WFAgZW1wbG95ZWUuDQo+IA0KPiBIbSBJIHNlZSwgdGhpcyBzZWVtcyBsaWtlIGEgYml0IG9mIGNy
YXBweSBwb3NpdGlvbiB0byBiZSBpbiB3aGVuIHlvdSBqdXN0IHdhbnQgdG8NCj4gYXNrIHNvbWVv
bmUgaW4gaGFyZHdhcmUgaG93IHRoaW5ncyByZWFsbHkgd29yay4NCj4gDQo+IEJ1dCB3ZSBoYXZl
IEZyZWVzY2FsZSBpLk1YIG1haW50YWluZXJzIG9uIHRoZSBpbnNpZGUgb2YgdGhlIGNvbXBhbnkg
bm93IE5YUA0KPiAoc29vbiBRdWFsY29tbT8gc29vbiBCcm9hZGNvbT8pLg0KPiANCj4gSGVsbCB0
aGlzIG1haWwgaXMgZXZlbiBnb2luZyB0byBsaW51eC1pbXhAbnhwLmNvbSwgd2hhdCBkbyB0aGV5
IGRvIHdpdGggaXQ/IFB1dA0KPiBpdCBpbiBhIG1haWxib3ggYW5kIG5ldmVyIHJlYWQgaXQ/DQo+
IA0KPiBTdXJlbHkgc29tZW9uZSBvbiB0aGUgaW5zaWRlIG11c3QgYmUgYWJsZSB0byBwcm92aWRl
IHNvbWUgZGV0YWlscy4NCj4gDQoNCkkgZmVlbCB0ZXJyaWJseSBzb3JyeSB0aGF0IGRpZCBub3Qg
Y29tZSB1cCBpbiB0aGUgZmlyc3QgdGltZSB0aGVzZSB0d28gZGF5cyBhcyBJIHdhcw0KYnVzeSB3
aXRoIHNvbWUgb3RoZXIgdXJnZW50IHRoaW5ncyByZXF1ZXN0ZWQgYnkgbXkgYm9zcy4NCkl0IHNo
b3VsZCBiZSBteSByZXNwb25zaWJpbGl0eSBhcyBJIHByb21pc2VkIHRvIHRha2UgdGhhdCBvd25l
cnNoaXAgYmVmb3JlLg0KDQpJIHF1aWNrbHkgd2VudCB0aHJvdWdoIHRoZSBlbWFpbCBhbmQgSSBm
dWxseSB1bmRlcnN0YW5kIHlvdXIgY29uY2Vybi4NCkFzIEknbSBub3QgYSBzcGVjaWFsaXN0IG9u
IHRoZSBIVyBpbnRlcm5hbHMgb2YgSU9NVVggZGVzaWduLCBpIGFscmVhZHkgZm9yd2FyZGVkIHRo
ZQ0KSXNzdWUgdG8gb3VyIElQIG93bmVyLiANCg0KRHVlIHRvIGl0J3MgYWxyZWFkeSBvZmYgd29y
ayB0aW1lIGF0IG15IHNpZGUsIEkgd2lsbCBkaXNjdXNzIHdpdGggaGltIHRvbW9ycm93DQpNb3Ju
aW5nIGFuZCBnZXQgYmFjayB0byB5b3UgbGF0ZXIuDQoNCkFuZCBpIHdpbGwgY2FyZWZ1bGx5IHJl
dmlldyB0aGUgcmVmZXJlbmNlIG1hbnVhbCBhbmQgZG9jIG9uIG15IGhhbmRzLg0KSG9wZWZ1bGx5
IEkgY2FuIGdpdmUgeW91IHNvbWUgaW5mb3JtYXRpb24gbGF0ZXIgeW91IHdhbnQuDQoNClJlZ2Fy
ZHMNCkRvbmcgQWlzaGVuZw0KDQo+ID4gQWxzbyBldmVuIGlmIHdlIHdlcmUgaW5zaWRlIG9mIE5Y
UCwgcGFkIGNlbGxzIGFyZSB1c3VhbGx5IHNvbWV0aGluZw0KPiA+IHRoYXQgY2hpcCBtYWtlcnMg
YnV5IG9yIGdldCBmcm9tIHRoZSBGYWIgZGVzaWduIGxpYnJhcnkuIFNvIHByb2JhYmx5DQo+ID4g
ZXZlbiB0aGV5IGRvbid0IGtub3cgd2hhdCdzIGluc2lkZSBleGFjdGx5Lg0KPiANCj4gWWVhaCB0
aGF0IGlzIHdoYXQgSSBjYWxsICJ0aHJvdyBvdmVyIHRoZSB3YWxsIGVuZ2luZWVyaW5nIi4NCj4g
SXQncyBub3QgZ29vZCwgaWYgTlhQIHdvcmtzIHdpdGggaW5mb3JtYXRpb24gYnJpY2sgd2FsbHMg
bGlrZSB0aGF0IGl0IGlzIG5vdCBhbnkgZ29vZA0KPiBmb3IgdGhlbSwgYmVjYXVzZSBpdCBpcyBu
b3QgYW55IGdvb2QgZm9yIHRoZWlyIGN1c3RvbWVycy4NCj4gDQo+IE5vdCBzb21ldGhpbmcgeW91
IG9yIEkgY2FuIGZpeCB0aG91Z2guLi4NCj4gDQo+ID4gV2hhdCB1c3VhbGx5IGhhcHBlbnMgaXMg
dGhhdCBoYXJkd2FyZSAoSSdtIHRhbGtpbmcgYWJvdXQgYm9hcmQvc3lzdGVtDQo+ID4gaGVyZSkg
ZGVzaWduZXJzIHN0YXJ0IGJ5IHJlYWRpbmcgdGhlIHJlZmVyZW5jZSBtYW51YWwgYW5kIGhhcmR3
YXJlDQo+ID4gZGVzaWduIGd1aWRlIGFuZCB3b3JrIHdpdGggdGhhdC4gVGhleSBjb21lIHVwIHdp
dGggYWxsIHRoZSBuZWNlc3NhcnkNCj4gPiBjb25maWd1cmF0aW9uIGluIHRoZSB0ZXJtcyBvZiB0
aGUgbWFudWFsLg0KPiANCj4gU29tZXRpbWVzIGhhbGYtZ3Vlc3NpbmcgYW5kIGEgYml0IG9mIHRy
aWFsLWFuZC1lcnJvciByaWdodD8NCj4gDQo+ID4gQWZ0ZXIgdGhhdCB0aGV5IG9yIHNvbWVvbmUg
ZWxzZSBoYXMgdG8gdHJhbnNsYXRlIHRoaXMgaW50byBEVC4gVGhpbmdzDQo+ID4gZ2V0IGNvbmZ1
c2luZyB3aGVuIHRoZSByZWZlcmVuY2UgbWFudWFsIGFuZCB0aGUgRFQgYmluZGluZyBkaXNhZ3Jl
ZQ0KPiA+IGFib3V0IHRoZSB1c2VkIHRlcm1zLg0KPiANCj4gSSBzZWUuDQo+IA0KPiA+PiBJZiB5
b3Ugd2FudCBzb21ldGhpbmcgdG8gbWF0Y2ggdGhlIHNwZWNpZmljIGhhcmR3YXJlIG1hbnVhbCBm
cm9tIE5YUA0KPiA+PiBhbmQgeW91IGRvbid0IHdhbnQgaXQgdG8gYmUgdHJhbnNsYXRlZCBpbnRv
IHRoZSB1bml0cyBvZiB0aGUgRFQNCj4gPj4gYmluZGluZywgdGhlbiBJIHRoaW5rIGl0IGlzIGJl
dHRlciB0byB1c2Ugc29tZXRoaW5nIHByZWZpeGVkICJueHAsKiIuDQo+ID4NCj4gPj4gVGhhdCBj
bGVhcmx5IGluZGljYXRlcyB0aGF0IHRoaXMgaXMgc29tZSBOWFAgb2RkaXR5IHRoYXQgd2UgZG9u
J3QNCj4gPj4gcmVhbGx5IHVuZGVyc3RhbmQuDQo+ID4NCj4gPiBJJ20gbm90IGtlZW4gb24gdXNp
bmcgdGhlIGNvbW1vbiBwYWRjdHJsIHN0dWZmLCB3aGljaCBhbHJlYWR5IGJsb2F0cw0KPiA+IHRo
ZSBEVCBkZXNjcmlwdGlvbiBjb21wYXJlZCB0byBpLk1YNiwNCj4gDQo+IFRoaXMgeW91IG5lZWQg
dG8gZGlzY3VzcyB3aXRoIHRoZSBnZW5lcmljIGkuTVggZHJpdmVyIG1haW50YWluZXJzLg0KPiBU
aGV5IGFyZSB0aGUgbWFpbnRhaW5lcnMgb2YgZHJpdmVycy9waW5jdHJsL2ZyZWVzY2FsZS8qIGFm
dGVyIGFsbC4NCj4gDQo+IFRoZXkgbmV2ZXIgcHV0IGFuIGVudHJ5IGluIE1BSU5UQUlORVJTIHRo
b3VnaCwgYnV0IEkgYWx3YXlzIHJlZ2FyZGVkIHRoZXNlIGFzDQo+IHRoZSBwaW5jdHJsIG1haW50
YWluZXJzIGZvciBpLk1YOg0KPiANCj4gQVJNL0ZSRUVTQ0FMRSBJTVggLyBNWEMgQVJNIEFSQ0hJ
VEVDVFVSRQ0KPiBNOiAgICAgIFNoYXduIEd1byA8c2hhd25ndW9Aa2VybmVsLm9yZz4NCj4gTTog
ICAgICBTYXNjaGEgSGF1ZXIgPGtlcm5lbEBwZW5ndXRyb25peC5kZT4NCj4gUjogICAgICBGYWJp
byBFc3RldmFtIDxmYWJpby5lc3RldmFtQG54cC5jb20+DQo+IA0KPiBPbiB0b3Agb2YgdGhpcywg
RG9uZyBBaXNoZW5nLCBHYXJ5IEJpc3NvbiBhbmQgVmxhZGltaXIgWmFwb2xza2l5IGhhcyBtYWRl
IG1ham9yDQo+IGNvbnRyaWJ1dGlvbnMuDQo+IA0KPiBJdCdzIGEgbGl0dGxlIGVjb3N5c3RlbSBv
biBpdHMgb3duLCBub3QgcmVhbGx5IHRvIGJlIGRpc2N1c3NlZCBieSBqdXN0IHlvdSBhbmQgbWUu
IEkNCj4gd29uZGVyIHdoZXJlIHRoZSByZXN0IG9mIHRoZSB2b2ljZXMgYXJlLCBJIGhvcGUgbm90
IHNpbGVuY2VkIGJ5IG9yZ2FuaXphdGlvbmFsDQo+IHN0cmVzcyBhZnRlciB0aGUgTlhQIG1lcmdl
ci4uLg0KPiANCj4gPiBhbmQgdGhlbiBhZ2FpbiBuZWVkIHRvIGludHJvZHVjZQ0KPiA+IGN1c3Rv
bSBwcm9wZXJ0aWVzLiBUaGF0J3MganVzdCB3b3JzdCBvZiBib3RoIHdvcmxkcywgdmVyYm9zZSBE
VCB0byB1c2UNCj4gPiB0aGUgY29tbW9uIHN0dWZmLCBtaXhlZCB3aXRoIHNwZWNpYWwgcHJvcGVy
dGllcywgb25seSB2YWxpZCBvbiB0aGlzDQo+ID4gc2luZ2xlIGNvbnRyb2xsZXIuDQo+IA0KPiBO
byBtYXR0ZXIgaG93IG11Y2ggeW91IGRpc2xpa2UgaXQsIGl0IGlzIHdoYXQgZS5nLiBRdWFsY29t
bSBpcyBkb2luZy4gKFdobw0KPiBtaWdodCBzb29uIGJlIG9uZSBhbmQgdGhlIHNhbWUgYXMgTlhQ
IEkgaGVhci4pDQo+IA0KPiA+IElmIHlvdSBpbnNpc3QgSSBndWVzcyBJJ20gZmluZSB3aXRoIGNv
bXByb21pc2luZyBvbiBhbiAib3V0cHV0LQ0KPiA+IGltcGVkYW5jZSIgY29tbW9uIHByb3BlcnR5
LCBidXQgdGhlbiB0aGlzIGp1c3QgbWFrZXMgdGhpbmdzIGhhcmRlciBmb3INCj4gPiBldmVyeW9u
ZSBpbnZvbHZlZCwgYXMgdGhlIGltcGVkYW5jZSBldmVuIHNlZW1zIHRvIHZhcnkgc2xpZ2h0bHkg
d2l0aA0KPiA+IHRoZSB1c2VkIHBhZCB2b2x0YWdlLiBTbyB0byBub3QgZ2V0IGludG8gYSBjb21i
aW5hdG9yaWFsIGV4cGxvc2lvbiwgd2UNCj4gPiB3b3VsZCBuZWVkIHRvIGRlc2NyaWJlIHRoaXMg
cHJvcGVydHkgYXMgc29tZXRoaW5ncyBsaWtlICJvdXRwdXQNCj4gPiBpbXBlZGFuY2UgYXQgMy4z
dikiLCBhdCBsZWFzdCBvbiB0aGlzIHNwZWNpZmljIGhhcmR3YXJlLg0KPiANCj4gSG0sIHNob3Vs
ZCBpdCBtZSAibnhwLGRyaXZlLXN0cmVuZ3RoIiB0aGVuLCBhcyBpdCBpcyBqdXN0IHNvbWUgbWFn
aWMgdmFsdWU/IEkNCj4gZ3Vlc3MgIm54cCxtYWdpYy1kcml2ZS1zdHJlbmd0aCIgaXMgbm90IGdv
aW5nIHRvIGN1dCBpdCA6RA0KPiANCj4gQWxzbyBtYXliZSB3ZSBzaG91bGQgdXNlIHRoZSBvbGQg
ImZyZWVzY2FsZSwqIiBub3RhdGlvbiBmb3IgbGVnYWN5IHJlYXNvbnMuLi4gSQ0KPiBkb24ndCBr
bm93LiBUaGlzIFZlbmRvciBwcmVmaXggc2VlbXMgbGVzcyBzdGFibGUgdGhhbiB0aGUgY2hpcHNl
dHMuDQo+IA0KPiA+IE9yIHdlIGNvdWxkIGFncmVlIHRoYXQgZHJpdmUtc3RyZW5ndGggcHJvcGVy
dHkgY291bGQgYmUgZGVzY3JpYmVkIGluDQo+ID4gc29tZSB1bml0IHRoYXQgbWFrZXMgc2Vuc2Ug
b24gZWFjaCBjb250cm9sbGVyLiBtQSBmb3IgaGFyZHdhcmUNCj4gPiBkZXNjcmliZWQgd2l0aCBz
b21lIGZhYmxlZCBpZGVhbCBsb2FkIG1hdGNoaW5nLCBPaG1zIGZvciBoYXJkd2FyZSB0aGF0DQo+
ID4gbW9kZWxzIGl0IHRoaXMgd2F5IHdpdGggbWF4aW11bSBkcml2ZSBzdHJlbmd0aCBhdCB0aGUg
cG9pbnQgb2YgYmVzdA0KPiA+IGxvYWQgbWF0Y2hpbmcuDQo+IA0KPiBJIGFtIG5vdCBsaWtlIHN0
dWJib3JubHkgYWdhaW5zdC4gSSBqdXN0IHdhbnQgc29tZSBkaXNjdXNzaW9uIGhlcmUsIGl0IHdv
dWxkIGJlDQo+IG5pY2UgdG8ga25vdyB0aGUgb3BpbmlvbiBvZiB0aGUgaS5NWCBtYWludGFpbmVy
cy4NCj4gDQo+ID4gSW4gdGhlIGVuZCB0aGlzIGlzIGFib3V0IG1hcHBpbmcgMyBoYXJkd2FyZSBi
aXRzIHRvIGEgRFQgZGVzY3JpcHRpb24uLi4NCj4gDQo+IFBsZWFzIGRvbid0IHRoaW5rIGFib3V0
IGl0IGxpa2UgImNhbid0IHdlIGp1c3QgZG8gdGhpcyByZWFsIHNpbXBsZSB0aGluZyBub3csIGp1
c3QNCj4gbWVyZ2UgdGhpcyBhbmQgc3RvcCBiZWluZyBhbiBhc3MiLg0KPiANCj4gVGhpbmdzIGp1
c3QgcG9raW5nIHRocmVlIGJpdHMgY2FuIGxvb2sgdmVyeSBzaW1wbGUsIGxpa2UgaW4gc28gbWFu
eSBCU1BzOg0KPiANCj4gdm9sYXRpbGUgdW5zaWduZWQgbG9uZyAqZm9vOw0KPiANCj4gZm9vID0g
KHVuc2lnbmVkIGxvbmcgKikgMHhmZWMwYmUwMDsNCj4gKmZvbyAmPSB+MHg3MDA7DQo+ICpmb28g
fD0gMHgyMDA7IC8qIGRvIHRoZSBtYWdpYyAqLw0KPiANCj4gQnV0IHRoaXMgaXMgbm90IGhlbHBm
dWwgZm9yIGRldmVsb3BlcnMgb3IgbWFpbnRhaW5lcnMuIFRoYXQgaXMgSU1ITyB3aHkgd2UgaGF2
ZQ0KPiB0aGUgZnJhbWV3b3JrcyBhbmQgYWxsIHRoZSBEVCBzdGFuZGFyZGl6YXRpb24gaW4gdGhl
IGZpcnN0IHBsYWNlLCBleGFjdGx5IHNvIHdlDQo+IHVuZGVyc3RhbmQgd2hhdCB3ZSBhcmUgZG9p
bmcuDQo+IA0KPiBZb3VycywNCj4gTGludXMgV2FsbGVpag0K
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sascha Hauer Feb. 7, 2018, 11:11 a.m. | #9
On Wed, Feb 07, 2018 at 10:09:20AM +0100, Linus Walleij wrote:
> On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@pengutronix.de> wrote:
> 
> > To be fully honest I'm a bit annoyed with the pinctrl framework making
> > things (IMHO) unnecessarily complex, for what is basically a pretty
> > easy task.
> 
> My ambition is to make things readable, understandable and
> maintainable. In generic terms, incorporating a bunch of knowledge
> of the electronics that really happen into the stuff we encode in
> the kernel.
> 
> I guess it varies a bit on what goal one has.
> 
> If the goal is "ship product with upstream kernel really fast now"
> then things like pinctrl-single.c where we just hammer magic values
> into registers, make sense. OMAP developers had no idea whatsoever
> what their ASIC people or cell library authors were doing so they
> just threw in the towel. HiSilicon also use this. Intels ambition was
> to use ACPI BIOS to handle all pin control and route around the kernel
> altogether, but that is not working out so well for them I think.
> 
> All of them are approaches to avoid putting the hairy details into the
> kernel, just poke some magic values into some magic registers
> and be happy.
> 
> So i.MX could have been like that, but then I guess you need to take
> legacy into account and discuss with the other i.MX driver authors
> about how they really wanted and want to do things.
> 
> Their current silence wrt this mailchain is actually becoming a
> problem, and the problem is that discussing with you falls upwards
> to me as subsystem maintainer. Which sucks. I prefer that people
> who know this hardware discuss amongst themselves how they
> want things to work.
> 
> Surely Sascha must have an opinion? It means much to me
> what he wants to do. I take it you guys are colleagues?

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.

Sascha
Fabio Estevam Feb. 7, 2018, 11:41 a.m. | #10
[Adding Shawn on Cc]

On Wed, Feb 7, 2018 at 9:11 AM, Sascha Hauer <s.hauer@pengutronix.de> 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 am also happy with the current plain register values in device tree.

Having two methods (plain register values on most of i.MX SoCs and the
new generic one for imx7ulp, imx8mq) is confusing for the end users.

I would prefer to use the plain register values in device tree for all
i.MX SoCs instead.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
A.s. Dong Feb. 7, 2018, 1:21 p.m. | #11
Hi Sascha,

> -----Original Message-----

> From: Sascha Hauer [mailto:s.hauer@pengutronix.de]

> Sent: 2018年2月7日 19:12

> To: Linus Walleij <linus.walleij@linaro.org>

> Cc: Lucas Stach <l.stach@pengutronix.de>; A.s. Dong

> <aisheng.dong@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Gary Bisson

> <gary.bisson@boundarydevices.com>; Vladimir Zapolskiy

> <vladimir_zapolskiy@mentor.com>; Sascha Hauer <kernel@pengutronix.de>;

> Mark Rutland <mark.rutland@arm.com>; Rob Herring <robh@kernel.org>;

> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

> <devicetree@vger.kernel.org>; patchwork-lst@pengutronix.de;

> linux-gpio@vger.kernel.org

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

> 

> On Wed, Feb 07, 2018 at 10:09:20AM +0100, Linus Walleij wrote:

> > On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@pengutronix.de> wrote:

> >

> > > To be fully honest I'm a bit annoyed with the pinctrl framework

> > > making things (IMHO) unnecessarily complex, for what is basically a

> > > pretty easy task.

> >

> > My ambition is to make things readable, understandable and

> > maintainable. In generic terms, incorporating a bunch of knowledge of

> > the electronics that really happen into the stuff we encode in the

> > kernel.

> >

> > I guess it varies a bit on what goal one has.

> >

> > If the goal is "ship product with upstream kernel really fast now"

> > then things like pinctrl-single.c where we just hammer magic values

> > into registers, make sense. OMAP developers had no idea whatsoever

> > what their ASIC people or cell library authors were doing so they just

> > threw in the towel. HiSilicon also use this. Intels ambition was to

> > use ACPI BIOS to handle all pin control and route around the kernel

> > altogether, but that is not working out so well for them I think.

> >

> > All of them are approaches to avoid putting the hairy details into the

> > kernel, just poke some magic values into some magic registers and be

> > happy.

> >

> > So i.MX could have been like that, but then I guess you need to take

> > legacy into account and discuss with the other i.MX driver authors

> > about how they really wanted and want to do things.

> >

> > Their current silence wrt this mailchain is actually becoming a

> > problem, and the problem is that discussing with you falls upwards to

> > me as subsystem maintainer. Which sucks. I prefer that people who know

> > this hardware discuss amongst themselves how they want things to work.

> >

> > Surely Sascha must have an opinion? It means much to me what he wants

> > to do. I take it you guys are colleagues?

> 

> 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.

> 


Probably as I first implemented generic pinconfig support for i.MX, personally
I'm tend to it a bit, mainly because below reasons we find in real situations:

First and most important, plain register value is a bit error prone.
(Actually we meet many times of issues during internal development).
User has to compose it manually by refer to reference manual
which might be more easy to mistake than using standard binding property.

And not everyone would like to compose the register value manually
when writing their device tree, they may simply do copy & paste of an exist one
and quickly test, if it works, everything is done. They don't know which setting is actually
used as they can see nothing from the plain register value. Untill the device becomes
unwork in some special circumstances, then they have to waste a lot time to find out
the pad setting issue. This happens especially more often when switch to
a new SoC while the pad config register layout changed a bit.
We certainly would like to avoid it!

Secondly, plain register value is also unreadable and unmaintainable,
also not quite friendly in reviewing other one's patches.

Last, it might be trivial, people don't want to refer to reference manual
again and again once being asked which driver strength or something else
Is used.

Regards
Dong Aisheng

> Sascha

> 

> --

> Pengutronix e.K.                           |

> |

> Industrial Linux Solutions                 |

> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.p

> engutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7C2644d871

> 2e234a6c2e7a08d56e1b9b29%7Cbd8a2a2207224ec7b35f1c4f0497e341%7C0%

> 7C0%7C636535987211269744&sdata=vImuWxtT7Ya0uxEHrnROUYZ%2BiCWLs8

> LmxWB5oNPcgjk%3D&reserved=0  |

> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |

> Amtsgericht Hildesheim, HRA 2686           | Fax:

> +49-5121-206917-5555 |
Sascha Hauer Feb. 7, 2018, 1:49 p.m. | #12
On Wed, Feb 07, 2018 at 01:21:44PM +0000, A.s. Dong wrote:
> Hi Sascha,
> 
> > -----Original Message-----
> > From: Sascha Hauer [mailto:s.hauer@pengutronix.de]
> > Sent: 2018年2月7日 19:12
> > To: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Lucas Stach <l.stach@pengutronix.de>; A.s. Dong
> > <aisheng.dong@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Gary Bisson
> > <gary.bisson@boundarydevices.com>; Vladimir Zapolskiy
> > <vladimir_zapolskiy@mentor.com>; Sascha Hauer <kernel@pengutronix.de>;
> > Mark Rutland <mark.rutland@arm.com>; Rob Herring <robh@kernel.org>;
> > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > <devicetree@vger.kernel.org>; patchwork-lst@pengutronix.de;
> > linux-gpio@vger.kernel.org
> > Subject: Re: [PATCH v2 1/3] dt-bindings: add binding for i.MX8MQ IOMUXC
> > 
> > On Wed, Feb 07, 2018 at 10:09:20AM +0100, Linus Walleij wrote:
> > > On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@pengutronix.de> wrote:
> > >
> > > > To be fully honest I'm a bit annoyed with the pinctrl framework
> > > > making things (IMHO) unnecessarily complex, for what is basically a
> > > > pretty easy task.
> > >
> > > My ambition is to make things readable, understandable and
> > > maintainable. In generic terms, incorporating a bunch of knowledge of
> > > the electronics that really happen into the stuff we encode in the
> > > kernel.
> > >
> > > I guess it varies a bit on what goal one has.
> > >
> > > If the goal is "ship product with upstream kernel really fast now"
> > > then things like pinctrl-single.c where we just hammer magic values
> > > into registers, make sense. OMAP developers had no idea whatsoever
> > > what their ASIC people or cell library authors were doing so they just
> > > threw in the towel. HiSilicon also use this. Intels ambition was to
> > > use ACPI BIOS to handle all pin control and route around the kernel
> > > altogether, but that is not working out so well for them I think.
> > >
> > > All of them are approaches to avoid putting the hairy details into the
> > > kernel, just poke some magic values into some magic registers and be
> > > happy.
> > >
> > > So i.MX could have been like that, but then I guess you need to take
> > > legacy into account and discuss with the other i.MX driver authors
> > > about how they really wanted and want to do things.
> > >
> > > Their current silence wrt this mailchain is actually becoming a
> > > problem, and the problem is that discussing with you falls upwards to
> > > me as subsystem maintainer. Which sucks. I prefer that people who know
> > > this hardware discuss amongst themselves how they want things to work.
> > >
> > > Surely Sascha must have an opinion? It means much to me what he wants
> > > to do. I take it you guys are colleagues?
> > 
> > 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.
> > 
> 
> Probably as I first implemented generic pinconfig support for i.MX, personally
> I'm tend to it a bit, mainly because below reasons we find in real situations:
> 
> First and most important, plain register value is a bit error prone.
> (Actually we meet many times of issues during internal development).
> User has to compose it manually by refer to reference manual
> which might be more easy to mistake than using standard binding property.
> 
> And not everyone would like to compose the register value manually
> when writing their device tree, they may simply do copy & paste of an exist one
> and quickly test, if it works, everything is done. They don't know which setting is actually
> used as they can see nothing from the plain register value. Untill the device becomes
> unwork in some special circumstances, then they have to waste a lot time to find out
> the pad setting issue. This happens especially more often when switch to
> a new SoC while the pad config register layout changed a bit.
> We certainly would like to avoid it!
> 
> Secondly, plain register value is also unreadable and unmaintainable,
> also not quite friendly in reviewing other one's patches.
> 
> Last, it might be trivial, people don't want to refer to reference manual
> again and again once being asked which driver strength or something else
> Is used.

These issues could be solved by bitmask defines aswell, no need to bloat
the dtbs with strings.

Sascha
Shawn Guo Feb. 8, 2018, 8:56 a.m. | #13
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.de> 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.

Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
A.s. Dong Feb. 8, 2018, 11:54 a.m. | #14
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBLnMuIERvbmcNCj4gU2VudDog
MjAxOOW5tDLmnIg35pelIDE5OjAzDQo+IFRvOiAnTGludXMgV2FsbGVpaicgPGxpbnVzLndhbGxl
aWpAbGluYXJvLm9yZz47IEx1Y2FzIFN0YWNoDQo+IDxsLnN0YWNoQHBlbmd1dHJvbml4LmRlPjsg
ZGwtbGludXgtaW14IDxsaW51eC1pbXhAbnhwLmNvbT47IEdhcnkgQmlzc29uDQo+IDxnYXJ5LmJp
c3NvbkBib3VuZGFyeWRldmljZXMuY29tPjsgVmxhZGltaXIgWmFwb2xza2l5DQo+IDx2bGFkaW1p
cl96YXBvbHNraXlAbWVudG9yLmNvbT47IFNhc2NoYSBIYXVlciA8a2VybmVsQHBlbmd1dHJvbml4
LmRlPg0KPiBDYzogUm9iIEhlcnJpbmcgPHJvYmhAa2VybmVsLm9yZz47IE1hcmsgUnV0bGFuZCA8
bWFyay5ydXRsYW5kQGFybS5jb20+Ow0KPiBsaW51eC1ncGlvQHZnZXIua2VybmVsLm9yZzsgb3Bl
biBsaXN0Ok9QRU4gRklSTVdBUkUgQU5EIEZMQVRURU5FRA0KPiBERVZJQ0UgVFJFRSBCSU5ESU5H
UyA8ZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc+Ow0KPiBwYXRjaHdvcmstbHN0QHBlbmd1dHJv
bml4LmRlDQo+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggdjIgMS8zXSBkdC1iaW5kaW5nczogYWRkIGJp
bmRpbmcgZm9yIGkuTVg4TVEgSU9NVVhDDQo+IA0KPiBIaSBMaW51cywNCj4gDQo+ID4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBMaW51cyBXYWxsZWlqIFttYWlsdG86bGlu
dXMud2FsbGVpakBsaW5hcm8ub3JnXQ0KPiA+IFNlbnQ6IDIwMTjlubQy5pyIN+aXpSAxNzowOQ0K
PiA+IFRvOiBMdWNhcyBTdGFjaCA8bC5zdGFjaEBwZW5ndXRyb25peC5kZT47IEEucy4gRG9uZw0K
PiA+IDxhaXNoZW5nLmRvbmdAbnhwLmNvbT47IGRsLWxpbnV4LWlteCA8bGludXgtaW14QG54cC5j
b20+OyBHYXJ5IEJpc3Nvbg0KPiA+IDxnYXJ5LmJpc3NvbkBib3VuZGFyeWRldmljZXMuY29tPjsg
VmxhZGltaXIgWmFwb2xza2l5DQo+ID4gPHZsYWRpbWlyX3phcG9sc2tpeUBtZW50b3IuY29tPjsg
U2FzY2hhIEhhdWVyIDxrZXJuZWxAcGVuZ3V0cm9uaXguZGU+DQo+ID4gQ2M6IFJvYiBIZXJyaW5n
IDxyb2JoQGtlcm5lbC5vcmc+OyBNYXJrIFJ1dGxhbmQNCj4gPiA8bWFyay5ydXRsYW5kQGFybS5j
b20+OyBsaW51eC1ncGlvQHZnZXIua2VybmVsLm9yZzsgb3BlbiBsaXN0Ok9QRU4NCj4gPiBGSVJN
V0FSRSBBTkQgRkxBVFRFTkVEIERFVklDRSBUUkVFIEJJTkRJTkdTDQo+ID4gPGRldmljZXRyZWVA
dmdlci5rZXJuZWwub3JnPjsgcGF0Y2h3b3JrLWxzdEBwZW5ndXRyb25peC5kZQ0KPiA+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0ggdjIgMS8zXSBkdC1iaW5kaW5nczogYWRkIGJpbmRpbmcgZm9yIGkuTVg4
TVENCj4gPiBJT01VWEMNCj4gPg0KPiA+IE9uIFR1ZSwgRmViIDYsIDIwMTggYXQgNDo0NyBQTSwg
THVjYXMgU3RhY2ggPGwuc3RhY2hAcGVuZ3V0cm9uaXguZGU+IHdyb3RlOg0KPiA+DQo+ID4gPiBU
byBiZSBmdWxseSBob25lc3QgSSdtIGEgYml0IGFubm95ZWQgd2l0aCB0aGUgcGluY3RybCBmcmFt
ZXdvcmsNCj4gPiA+IG1ha2luZyB0aGluZ3MgKElNSE8pIHVubmVjZXNzYXJpbHkgY29tcGxleCwg
Zm9yIHdoYXQgaXMgYmFzaWNhbGx5IGENCj4gPiA+IHByZXR0eSBlYXN5IHRhc2suDQo+ID4NCj4g
PiBNeSBhbWJpdGlvbiBpcyB0byBtYWtlIHRoaW5ncyByZWFkYWJsZSwgdW5kZXJzdGFuZGFibGUg
YW5kDQo+ID4gbWFpbnRhaW5hYmxlLiBJbiBnZW5lcmljIHRlcm1zLCBpbmNvcnBvcmF0aW5nIGEg
YnVuY2ggb2Yga25vd2xlZGdlIG9mDQo+ID4gdGhlIGVsZWN0cm9uaWNzIHRoYXQgcmVhbGx5IGhh
cHBlbiBpbnRvIHRoZSBzdHVmZiB3ZSBlbmNvZGUgaW4gdGhlIGtlcm5lbC4NCj4gPg0KPiA+IEkg
Z3Vlc3MgaXQgdmFyaWVzIGEgYml0IG9uIHdoYXQgZ29hbCBvbmUgaGFzLg0KPiA+DQo+ID4gSWYg
dGhlIGdvYWwgaXMgInNoaXAgcHJvZHVjdCB3aXRoIHVwc3RyZWFtIGtlcm5lbCByZWFsbHkgZmFz
dCBub3ciDQo+ID4gdGhlbiB0aGluZ3MgbGlrZSBwaW5jdHJsLXNpbmdsZS5jIHdoZXJlIHdlIGp1
c3QgaGFtbWVyIG1hZ2ljIHZhbHVlcw0KPiA+IGludG8gcmVnaXN0ZXJzLCBtYWtlIHNlbnNlLiBP
TUFQIGRldmVsb3BlcnMgaGFkIG5vIGlkZWEgd2hhdHNvZXZlcg0KPiA+IHdoYXQgdGhlaXIgQVNJ
QyBwZW9wbGUgb3IgY2VsbCBsaWJyYXJ5IGF1dGhvcnMgd2VyZSBkb2luZyBzbyB0aGV5IGp1c3Qg
dGhyZXcgaW4NCj4gdGhlIHRvd2VsLg0KPiA+IEhpU2lsaWNvbiBhbHNvIHVzZSB0aGlzLiBJbnRl
bHMgYW1iaXRpb24gd2FzIHRvIHVzZSBBQ1BJIEJJT1MgdG8NCj4gPiBoYW5kbGUgYWxsIHBpbiBj
b250cm9sIGFuZCByb3V0ZSBhcm91bmQgdGhlIGtlcm5lbCBhbHRvZ2V0aGVyLCBidXQNCj4gPiB0
aGF0IGlzIG5vdCB3b3JraW5nIG91dCBzbyB3ZWxsIGZvciB0aGVtIEkgdGhpbmsuDQo+ID4NCj4g
PiBBbGwgb2YgdGhlbSBhcmUgYXBwcm9hY2hlcyB0byBhdm9pZCBwdXR0aW5nIHRoZSBoYWlyeSBk
ZXRhaWxzIGludG8gdGhlDQo+ID4ga2VybmVsLCBqdXN0IHBva2Ugc29tZSBtYWdpYyB2YWx1ZXMg
aW50byBzb21lIG1hZ2ljIHJlZ2lzdGVycyBhbmQgYmUgaGFwcHkuDQo+ID4NCj4gPiBTbyBpLk1Y
IGNvdWxkIGhhdmUgYmVlbiBsaWtlIHRoYXQsIGJ1dCB0aGVuIEkgZ3Vlc3MgeW91IG5lZWQgdG8g
dGFrZQ0KPiA+IGxlZ2FjeSBpbnRvIGFjY291bnQgYW5kIGRpc2N1c3Mgd2l0aCB0aGUgb3RoZXIg
aS5NWCBkcml2ZXIgYXV0aG9ycw0KPiA+IGFib3V0IGhvdyB0aGV5IHJlYWxseSB3YW50ZWQgYW5k
IHdhbnQgdG8gZG8gdGhpbmdzLg0KPiA+DQo+ID4gVGhlaXIgY3VycmVudCBzaWxlbmNlIHdydCB0
aGlzIG1haWxjaGFpbiBpcyBhY3R1YWxseSBiZWNvbWluZyBhDQo+ID4gcHJvYmxlbSwgYW5kIHRo
ZSBwcm9ibGVtIGlzIHRoYXQgZGlzY3Vzc2luZyB3aXRoIHlvdSBmYWxscyB1cHdhcmRzIHRvIG1l
IGFzDQo+IHN1YnN5c3RlbSBtYWludGFpbmVyLg0KPiA+IFdoaWNoIHN1Y2tzLiBJIHByZWZlciB0
aGF0IHBlb3BsZSB3aG8ga25vdyB0aGlzIGhhcmR3YXJlIGRpc2N1c3MNCj4gPiBhbW9uZ3N0IHRo
ZW1zZWx2ZXMgaG93IHRoZXkgd2FudCB0aGluZ3MgdG8gd29yay4NCj4gPg0KPiA+IFN1cmVseSBT
YXNjaGEgbXVzdCBoYXZlIGFuIG9waW5pb24/IEl0IG1lYW5zIG11Y2ggdG8gbWUgd2hhdCBoZSB3
YW50cyB0bw0KPiBkby4NCj4gPiBJIHRha2UgaXQgeW91IGd1eXMgYXJlIGNvbGxlYWd1ZXM/DQo+
ID4NCj4gPiA+IFBlbmd1dHJvbml4IGlzIG1vc3RseSBjb250cmFjdGVkIGJ5IGN1c3RvbWVycyBv
ZiBOWFAgdG8gZW5hYmxlIHN0dWZmDQo+ID4gPiBpbiBtYWlubGluZS4gU28gSSdtIG5vdCB3b3Jr
aW5nIG9uIHRoaXMgaW4gbXkgc3BhcmUgdGltZSwgYnV0IEkNCj4gPiA+IHN0aWxsIGhhdmUgdG8g
ZGVhbCB3aXRoIHRoZSBmYWN0IHRoYXQgSSBjYW4gb25seSBnZXQgdGhlIGluZm9ybWF0aW9uDQo+
ID4gPiBmcm9tIHRoZSByZWZlcmVuY2UgbWFudWFsLCBOWFAgZG93bnN0cmVhbSBCU1BzIGFuZCB0
aGUgb2NjYXNpb25hbA0KPiA+ID4gaGVscGZ1bCBOWFAgZW1wbG95ZWUuDQo+ID4NCj4gPiBIbSBJ
IHNlZSwgdGhpcyBzZWVtcyBsaWtlIGEgYml0IG9mIGNyYXBweSBwb3NpdGlvbiB0byBiZSBpbiB3
aGVuIHlvdQ0KPiA+IGp1c3Qgd2FudCB0byBhc2sgc29tZW9uZSBpbiBoYXJkd2FyZSBob3cgdGhp
bmdzIHJlYWxseSB3b3JrLg0KPiA+DQo+ID4gQnV0IHdlIGhhdmUgRnJlZXNjYWxlIGkuTVggbWFp
bnRhaW5lcnMgb24gdGhlIGluc2lkZSBvZiB0aGUgY29tcGFueQ0KPiA+IG5vdyBOWFAgKHNvb24g
UXVhbGNvbW0/IHNvb24gQnJvYWRjb20/KS4NCj4gPg0KPiA+IEhlbGwgdGhpcyBtYWlsIGlzIGV2
ZW4gZ29pbmcgdG8gbGludXgtaW14QG54cC5jb20sIHdoYXQgZG8gdGhleSBkbw0KPiA+IHdpdGgg
aXQ/IFB1dCBpdCBpbiBhIG1haWxib3ggYW5kIG5ldmVyIHJlYWQgaXQ/DQo+ID4NCj4gPiBTdXJl
bHkgc29tZW9uZSBvbiB0aGUgaW5zaWRlIG11c3QgYmUgYWJsZSB0byBwcm92aWRlIHNvbWUgZGV0
YWlscy4NCj4gPg0KPiANCj4gSSBmZWVsIHRlcnJpYmx5IHNvcnJ5IHRoYXQgZGlkIG5vdCBjb21l
IHVwIGluIHRoZSBmaXJzdCB0aW1lIHRoZXNlIHR3byBkYXlzIGFzIEkgd2FzDQo+IGJ1c3kgd2l0
aCBzb21lIG90aGVyIHVyZ2VudCB0aGluZ3MgcmVxdWVzdGVkIGJ5IG15IGJvc3MuDQo+IEl0IHNo
b3VsZCBiZSBteSByZXNwb25zaWJpbGl0eSBhcyBJIHByb21pc2VkIHRvIHRha2UgdGhhdCBvd25l
cnNoaXAgYmVmb3JlLg0KPiANCj4gSSBxdWlja2x5IHdlbnQgdGhyb3VnaCB0aGUgZW1haWwgYW5k
IEkgZnVsbHkgdW5kZXJzdGFuZCB5b3VyIGNvbmNlcm4uDQo+IEFzIEknbSBub3QgYSBzcGVjaWFs
aXN0IG9uIHRoZSBIVyBpbnRlcm5hbHMgb2YgSU9NVVggZGVzaWduLCBpIGFscmVhZHkgZm9yd2Fy
ZGVkDQo+IHRoZSBJc3N1ZSB0byBvdXIgSVAgb3duZXIuDQo+IA0KPiBEdWUgdG8gaXQncyBhbHJl
YWR5IG9mZiB3b3JrIHRpbWUgYXQgbXkgc2lkZSwgSSB3aWxsIGRpc2N1c3Mgd2l0aCBoaW0gdG9t
b3Jyb3cNCj4gTW9ybmluZyBhbmQgZ2V0IGJhY2sgdG8geW91IGxhdGVyLg0KPiANCj4gQW5kIGkg
d2lsbCBjYXJlZnVsbHkgcmV2aWV3IHRoZSByZWZlcmVuY2UgbWFudWFsIGFuZCBkb2Mgb24gbXkg
aGFuZHMuDQo+IEhvcGVmdWxseSBJIGNhbiBnaXZlIHlvdSBzb21lIGluZm9ybWF0aW9uIGxhdGVy
IHlvdSB3YW50Lg0KPiANCg0KSGVyZSBpcyBzb21lIGluZm9ybWF0aW9uIGZyb20gb3VyIElQIGRl
c2lnbmVyLg0KSXQgcHJvYmFibHkgZXhwbGFpbnMgd2h5IGkuTVggdXNlcyBPaG0gdG8gcmVwcmVz
ZW50cyBkcml2ZXIgc3RyZW5ndGguDQoNCiJFbGVjdHJpY2FsIHNwZWMgZm9yIGRpZmZlcmVudCBp
bnRlcmZhY2VzIHR5cGljYWxseSBkZWZpbmUgb3V0cHV0IGRyaXZlciBpbiBPaG0uDQpTbyB3ZSBm
b2xsb3cgdGhlIHNhbWUgd2F5IHRvIGNvbXBseSB3aXRoIHNwZWMgcmVxdWlyZW1lbnQuIEFsc28s
IGZvciB0aGUNCmJvYXJkIGRlc2lnbmVyIGl0IGlzIGltcG9ydGFudCB0byBrbm93IHRoZSBkcml2
ZXIgaW1wZWRhbmNlIHRvIG1hdGNoIHRoZQ0KZHJpdmVyIGFuZCBQQ0IgdHJhY2UgcmVzaXN0YW5j
ZS4gRGVmaW5pbmcgdGhlIGRyaXZlciBpbiBPaG0gYWxsb3dzIHRvDQpjYWxjdWxhdGUgSVIgZHJv
cCwgYXMgd2VsbCBhcyBvdXRwdXQgc2xldyByYXRlLCB3aGljaCBhcmUgaW1wb3J0YW50IHRvIGtu
b3cuIg0KDQpBbiBleGFtcGxlIGZyb20gZU1NQyA1LjEgc3BlYzoNCg0KVGFibGUgMjA2IC0gSS9P
IGRyaXZlciBzdHJlbmd0aCB0eXBlcw0KMHgwCQk1MM6pCQl4MQ0KMHgxCQkzM86pCQl4MS41DQow
eDIJCTY2zqkJCXgwLjc1DQoweDMJCTEwMM6pCXgwLjUNCjB4NAkJNDDOqQkJeDEuMg0KDQpBbmQg
Zm9yIG9uZSBxdWVzdGlvbiB5b3UgYXNrZWQgaW4gYW5vdGhlciBlbWFpbC4NCi0gSXMgdGhlIGlu
dGVuZGVkIHVzYWdlIGZvciBpbXBlZGFuY2UgbWF0Y2hpbmc/DQpGb3IgbG93IGZyZXF1ZW5jeSBp
bnRlcmZhY2UsIGZvciBleGFtcGxlLCBJMkMvR1BJTywgaXTigJlzIG5vdCBuZWNlc3NhcnkuwqAN
CkZvciBoaWdoIGZyZXF1ZW5jeSBpbnRlcmZhY2UsIGZvciBleGFtcGxlLCBERFIvSFMyMDAvSFM0
MDAvUmF3bmFuZA0KZGlmZmVyZW50aWFsIDIwME0sIGluIHRoZW9yeSwgd2Ugc2hvdWxkIGNvbnNp
ZGVyIGltcGVkYW5jZSBtYXRjaGluZyBmb3INCmJldHRlciBzaWduYWwgcXVhbGl0eS4gQW55d2F5
LCB3ZSBjYW4gY2hlY2sgdGhhdCBieSBib2FyZCBsZXZlbCBzaW11bGF0aW9uDQp3aXRoIHNwaWNl
IG1vZGVsLg0KDQpBbmQgSUMgZ3V5cyB0aG91Z2h0IE9obSBwcm9iYWJseSBpcyBtb3JlIHN1aXRh
YmxlIGZvciBoaWdoIHNwZWVkDQpJTyBwYWRzLg0KDQpIb3BlIGl0IGhlbHBzLg0KDQpSZWdhcmRz
DQpEb25nIEFpc2hlbmcNCg0KPiBSZWdhcmRzDQo+IERvbmcgQWlzaGVuZw0KPiANCj4gPiA+IEFs
c28gZXZlbiBpZiB3ZSB3ZXJlIGluc2lkZSBvZiBOWFAsIHBhZCBjZWxscyBhcmUgdXN1YWxseSBz
b21ldGhpbmcNCj4gPiA+IHRoYXQgY2hpcCBtYWtlcnMgYnV5IG9yIGdldCBmcm9tIHRoZSBGYWIg
ZGVzaWduIGxpYnJhcnkuIFNvIHByb2JhYmx5DQo+ID4gPiBldmVuIHRoZXkgZG9uJ3Qga25vdyB3
aGF0J3MgaW5zaWRlIGV4YWN0bHkuDQo+ID4NCj4gPiBZZWFoIHRoYXQgaXMgd2hhdCBJIGNhbGwg
InRocm93IG92ZXIgdGhlIHdhbGwgZW5naW5lZXJpbmciLg0KPiA+IEl0J3Mgbm90IGdvb2QsIGlm
IE5YUCB3b3JrcyB3aXRoIGluZm9ybWF0aW9uIGJyaWNrIHdhbGxzIGxpa2UgdGhhdCBpdA0KPiA+
IGlzIG5vdCBhbnkgZ29vZCBmb3IgdGhlbSwgYmVjYXVzZSBpdCBpcyBub3QgYW55IGdvb2QgZm9y
IHRoZWlyIGN1c3RvbWVycy4NCj4gPg0KPiA+IE5vdCBzb21ldGhpbmcgeW91IG9yIEkgY2FuIGZp
eCB0aG91Z2guLi4NCj4gPg0KPiA+ID4gV2hhdCB1c3VhbGx5IGhhcHBlbnMgaXMgdGhhdCBoYXJk
d2FyZSAoSSdtIHRhbGtpbmcgYWJvdXQNCj4gPiA+IGJvYXJkL3N5c3RlbQ0KPiA+ID4gaGVyZSkg
ZGVzaWduZXJzIHN0YXJ0IGJ5IHJlYWRpbmcgdGhlIHJlZmVyZW5jZSBtYW51YWwgYW5kIGhhcmR3
YXJlDQo+ID4gPiBkZXNpZ24gZ3VpZGUgYW5kIHdvcmsgd2l0aCB0aGF0LiBUaGV5IGNvbWUgdXAg
d2l0aCBhbGwgdGhlIG5lY2Vzc2FyeQ0KPiA+ID4gY29uZmlndXJhdGlvbiBpbiB0aGUgdGVybXMg
b2YgdGhlIG1hbnVhbC4NCj4gPg0KPiA+IFNvbWV0aW1lcyBoYWxmLWd1ZXNzaW5nIGFuZCBhIGJp
dCBvZiB0cmlhbC1hbmQtZXJyb3IgcmlnaHQ/DQo+ID4NCj4gPiA+IEFmdGVyIHRoYXQgdGhleSBv
ciBzb21lb25lIGVsc2UgaGFzIHRvIHRyYW5zbGF0ZSB0aGlzIGludG8gRFQuDQo+ID4gPiBUaGlu
Z3MgZ2V0IGNvbmZ1c2luZyB3aGVuIHRoZSByZWZlcmVuY2UgbWFudWFsIGFuZCB0aGUgRFQgYmlu
ZGluZw0KPiA+ID4gZGlzYWdyZWUgYWJvdXQgdGhlIHVzZWQgdGVybXMuDQo+ID4NCj4gPiBJIHNl
ZS4NCj4gPg0KPiA+ID4+IElmIHlvdSB3YW50IHNvbWV0aGluZyB0byBtYXRjaCB0aGUgc3BlY2lm
aWMgaGFyZHdhcmUgbWFudWFsIGZyb20NCj4gPiA+PiBOWFAgYW5kIHlvdSBkb24ndCB3YW50IGl0
IHRvIGJlIHRyYW5zbGF0ZWQgaW50byB0aGUgdW5pdHMgb2YgdGhlIERUDQo+ID4gPj4gYmluZGlu
ZywgdGhlbiBJIHRoaW5rIGl0IGlzIGJldHRlciB0byB1c2Ugc29tZXRoaW5nIHByZWZpeGVkICJu
eHAsKiIuDQo+ID4gPg0KPiA+ID4+IFRoYXQgY2xlYXJseSBpbmRpY2F0ZXMgdGhhdCB0aGlzIGlz
IHNvbWUgTlhQIG9kZGl0eSB0aGF0IHdlIGRvbid0DQo+ID4gPj4gcmVhbGx5IHVuZGVyc3RhbmQu
DQo+ID4gPg0KPiA+ID4gSSdtIG5vdCBrZWVuIG9uIHVzaW5nIHRoZSBjb21tb24gcGFkY3RybCBz
dHVmZiwgd2hpY2ggYWxyZWFkeSBibG9hdHMNCj4gPiA+IHRoZSBEVCBkZXNjcmlwdGlvbiBjb21w
YXJlZCB0byBpLk1YNiwNCj4gPg0KPiA+IFRoaXMgeW91IG5lZWQgdG8gZGlzY3VzcyB3aXRoIHRo
ZSBnZW5lcmljIGkuTVggZHJpdmVyIG1haW50YWluZXJzLg0KPiA+IFRoZXkgYXJlIHRoZSBtYWlu
dGFpbmVycyBvZiBkcml2ZXJzL3BpbmN0cmwvZnJlZXNjYWxlLyogYWZ0ZXIgYWxsLg0KPiA+DQo+
ID4gVGhleSBuZXZlciBwdXQgYW4gZW50cnkgaW4gTUFJTlRBSU5FUlMgdGhvdWdoLCBidXQgSSBh
bHdheXMgcmVnYXJkZWQNCj4gPiB0aGVzZSBhcyB0aGUgcGluY3RybCBtYWludGFpbmVycyBmb3Ig
aS5NWDoNCj4gPg0KPiA+IEFSTS9GUkVFU0NBTEUgSU1YIC8gTVhDIEFSTSBBUkNISVRFQ1RVUkUN
Cj4gPiBNOiAgICAgIFNoYXduIEd1byA8c2hhd25ndW9Aa2VybmVsLm9yZz4NCj4gPiBNOiAgICAg
IFNhc2NoYSBIYXVlciA8a2VybmVsQHBlbmd1dHJvbml4LmRlPg0KPiA+IFI6ICAgICAgRmFiaW8g
RXN0ZXZhbSA8ZmFiaW8uZXN0ZXZhbUBueHAuY29tPg0KPiA+DQo+ID4gT24gdG9wIG9mIHRoaXMs
IERvbmcgQWlzaGVuZywgR2FyeSBCaXNzb24gYW5kIFZsYWRpbWlyIFphcG9sc2tpeSBoYXMNCj4g
PiBtYWRlIG1ham9yIGNvbnRyaWJ1dGlvbnMuDQo+ID4NCj4gPiBJdCdzIGEgbGl0dGxlIGVjb3N5
c3RlbSBvbiBpdHMgb3duLCBub3QgcmVhbGx5IHRvIGJlIGRpc2N1c3NlZCBieSBqdXN0DQo+ID4g
eW91IGFuZCBtZS4gSSB3b25kZXIgd2hlcmUgdGhlIHJlc3Qgb2YgdGhlIHZvaWNlcyBhcmUsIEkg
aG9wZSBub3QNCj4gPiBzaWxlbmNlZCBieSBvcmdhbml6YXRpb25hbCBzdHJlc3MgYWZ0ZXIgdGhl
IE5YUCBtZXJnZXIuLi4NCj4gPg0KPiA+ID4gYW5kIHRoZW4gYWdhaW4gbmVlZCB0byBpbnRyb2R1
Y2UNCj4gPiA+IGN1c3RvbSBwcm9wZXJ0aWVzLiBUaGF0J3MganVzdCB3b3JzdCBvZiBib3RoIHdv
cmxkcywgdmVyYm9zZSBEVCB0bw0KPiA+ID4gdXNlIHRoZSBjb21tb24gc3R1ZmYsIG1peGVkIHdp
dGggc3BlY2lhbCBwcm9wZXJ0aWVzLCBvbmx5IHZhbGlkIG9uDQo+ID4gPiB0aGlzIHNpbmdsZSBj
b250cm9sbGVyLg0KPiA+DQo+ID4gTm8gbWF0dGVyIGhvdyBtdWNoIHlvdSBkaXNsaWtlIGl0LCBp
dCBpcyB3aGF0IGUuZy4gUXVhbGNvbW0gaXMgZG9pbmcuDQo+ID4gKFdobyBtaWdodCBzb29uIGJl
IG9uZSBhbmQgdGhlIHNhbWUgYXMgTlhQIEkgaGVhci4pDQo+ID4NCj4gPiA+IElmIHlvdSBpbnNp
c3QgSSBndWVzcyBJJ20gZmluZSB3aXRoIGNvbXByb21pc2luZyBvbiBhbiAib3V0cHV0LQ0KPiA+
ID4gaW1wZWRhbmNlIiBjb21tb24gcHJvcGVydHksIGJ1dCB0aGVuIHRoaXMganVzdCBtYWtlcyB0
aGluZ3MgaGFyZGVyDQo+ID4gPiBmb3IgZXZlcnlvbmUgaW52b2x2ZWQsIGFzIHRoZSBpbXBlZGFu
Y2UgZXZlbiBzZWVtcyB0byB2YXJ5IHNsaWdodGx5DQo+ID4gPiB3aXRoIHRoZSB1c2VkIHBhZCB2
b2x0YWdlLiBTbyB0byBub3QgZ2V0IGludG8gYSBjb21iaW5hdG9yaWFsDQo+ID4gPiBleHBsb3Np
b24sIHdlIHdvdWxkIG5lZWQgdG8gZGVzY3JpYmUgdGhpcyBwcm9wZXJ0eSBhcyBzb21ldGhpbmdz
DQo+ID4gPiBsaWtlICJvdXRwdXQgaW1wZWRhbmNlIGF0IDMuM3YpIiwgYXQgbGVhc3Qgb24gdGhp
cyBzcGVjaWZpYyBoYXJkd2FyZS4NCj4gPg0KPiA+IEhtLCBzaG91bGQgaXQgbWUgIm54cCxkcml2
ZS1zdHJlbmd0aCIgdGhlbiwgYXMgaXQgaXMganVzdCBzb21lIG1hZ2ljDQo+ID4gdmFsdWU/IEkg
Z3Vlc3MgIm54cCxtYWdpYy1kcml2ZS1zdHJlbmd0aCIgaXMgbm90IGdvaW5nIHRvIGN1dCBpdCA6
RA0KPiA+DQo+ID4gQWxzbyBtYXliZSB3ZSBzaG91bGQgdXNlIHRoZSBvbGQgImZyZWVzY2FsZSwq
IiBub3RhdGlvbiBmb3IgbGVnYWN5DQo+ID4gcmVhc29ucy4uLiBJIGRvbid0IGtub3cuIFRoaXMg
VmVuZG9yIHByZWZpeCBzZWVtcyBsZXNzIHN0YWJsZSB0aGFuIHRoZSBjaGlwc2V0cy4NCj4gPg0K
PiA+ID4gT3Igd2UgY291bGQgYWdyZWUgdGhhdCBkcml2ZS1zdHJlbmd0aCBwcm9wZXJ0eSBjb3Vs
ZCBiZSBkZXNjcmliZWQgaW4NCj4gPiA+IHNvbWUgdW5pdCB0aGF0IG1ha2VzIHNlbnNlIG9uIGVh
Y2ggY29udHJvbGxlci4gbUEgZm9yIGhhcmR3YXJlDQo+ID4gPiBkZXNjcmliZWQgd2l0aCBzb21l
IGZhYmxlZCBpZGVhbCBsb2FkIG1hdGNoaW5nLCBPaG1zIGZvciBoYXJkd2FyZQ0KPiA+ID4gdGhh
dCBtb2RlbHMgaXQgdGhpcyB3YXkgd2l0aCBtYXhpbXVtIGRyaXZlIHN0cmVuZ3RoIGF0IHRoZSBw
b2ludCBvZg0KPiA+ID4gYmVzdCBsb2FkIG1hdGNoaW5nLg0KPiA+DQo+ID4gSSBhbSBub3QgbGlr
ZSBzdHViYm9ybmx5IGFnYWluc3QuIEkganVzdCB3YW50IHNvbWUgZGlzY3Vzc2lvbiBoZXJlLCBp
dA0KPiA+IHdvdWxkIGJlIG5pY2UgdG8ga25vdyB0aGUgb3BpbmlvbiBvZiB0aGUgaS5NWCBtYWlu
dGFpbmVycy4NCj4gPg0KPiA+ID4gSW4gdGhlIGVuZCB0aGlzIGlzIGFib3V0IG1hcHBpbmcgMyBo
YXJkd2FyZSBiaXRzIHRvIGEgRFQgZGVzY3JpcHRpb24uLi4NCj4gPg0KPiA+IFBsZWFzIGRvbid0
IHRoaW5rIGFib3V0IGl0IGxpa2UgImNhbid0IHdlIGp1c3QgZG8gdGhpcyByZWFsIHNpbXBsZQ0K
PiA+IHRoaW5nIG5vdywganVzdCBtZXJnZSB0aGlzIGFuZCBzdG9wIGJlaW5nIGFuIGFzcyIuDQo+
ID4NCj4gPiBUaGluZ3MganVzdCBwb2tpbmcgdGhyZWUgYml0cyBjYW4gbG9vayB2ZXJ5IHNpbXBs
ZSwgbGlrZSBpbiBzbyBtYW55IEJTUHM6DQo+ID4NCj4gPiB2b2xhdGlsZSB1bnNpZ25lZCBsb25n
ICpmb287DQo+ID4NCj4gPiBmb28gPSAodW5zaWduZWQgbG9uZyAqKSAweGZlYzBiZTAwOw0KPiA+
ICpmb28gJj0gfjB4NzAwOw0KPiA+ICpmb28gfD0gMHgyMDA7IC8qIGRvIHRoZSBtYWdpYyAqLw0K
PiA+DQo+ID4gQnV0IHRoaXMgaXMgbm90IGhlbHBmdWwgZm9yIGRldmVsb3BlcnMgb3IgbWFpbnRh
aW5lcnMuIFRoYXQgaXMgSU1ITw0KPiA+IHdoeSB3ZSBoYXZlIHRoZSBmcmFtZXdvcmtzIGFuZCBh
bGwgdGhlIERUIHN0YW5kYXJkaXphdGlvbiBpbiB0aGUgZmlyc3QNCj4gPiBwbGFjZSwgZXhhY3Rs
eSBzbyB3ZSB1bmRlcnN0YW5kIHdoYXQgd2UgYXJlIGRvaW5nLg0KPiA+DQo+ID4gWW91cnMsDQo+
ID4gTGludXMgV2FsbGVpag0K
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lucas Stach Feb. 8, 2018, 3:28 p.m. | #15
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 linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Fabio Estevam Feb. 8, 2018, 7:19 p.m. | #16
Hi Lucas,

On Thu, Feb 8, 2018 at 1:28 PM, Lucas Stach <l.stach@pengutronix.de> wrote:

> 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

Yes, looks like a good plan IMHO.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij Feb. 23, 2018, 10:08 a.m. | #17
On Thu, Feb 8, 2018 at 4:28 PM, Lucas Stach <l.stach@pengutronix.de> wrote:

> 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.

What we need to see is for i.MX maintainers to agree, e.g.
figure out how to do all stuff in drivers/pinctrl/freescale/*
should be engineered going forward.

(Maybe that filepath and symbols needs to be renamed drivers/pinctrl/imx
by the way, this platform seems to change company more often
than I change my car tyres.)

I'll try to follow up on the resulting patch series.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt
new file mode 100644
index 000000000000..5c5d2d835d05
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.txt
@@ -0,0 +1,39 @@ 
+* Freescale IMX8MQ IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
+for common binding part and usage.
+
+=== Pin Controller Node ===
+
+Required properties:
+- compatible: "fsl,imx8mq-iomuxc"
+- reg: Must contain the base physical address and size of the iomuxc registers.
+
+=== Pin Configuration Node ===
+Required properties:
+- pinmux: Array of integersy, representing a group of pins mux setting.
+	The format is pinmux = <PIN_FUNC_ID>, PIN_FUNC_ID is a pin working on
+	a specific function.
+
+	Refer to imx8mq-pinfunc.h in device tree source folder for all available
+	imx8mq PIN_FUNC_ID.
+
+Optional Properties:
+- drive-strength		Integer: controls Drive Strength
+					0: driver disabled
+					1: 255 Ohm
+					2: 105 Ohm
+					3:  75 Ohm
+					4:  85 Ohm
+					5:  65 Ohm
+					6:  45 Ohm
+					7:  40 Ohm
+- slew-rate:			Integer: controls Slew Rate
+					0: Slow
+					1: Medium
+					2: Fast
+					3: Maximum
+- drive-open-drain		Bool: enable Open-drian
+- bias-pull-up			Bool: enable Pull-up
+- input-schmitt-enable		Bool: enable schmitt-trigger
+- input-enable			Bool: enable input, overriding module settings