-----Original Message-----
From: A.s. Dong
Sent: 2018年2月7日 19:03
To: 'Linus Walleij' <redacted>; Lucas Stach
[off-list ref]; dl-linux-imx [off-list ref]; Gary Bisson
[off-list ref]; Vladimir Zapolskiy
[off-list ref]; Sascha Hauer [off-list ref]
Cc: Rob Herring <robh@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
linux-gpio@vger.kernel.org; open list:OPEN FIRMWARE AND FLATTENED
DEVICE TREE BINDINGS [off-list ref];
patchwork-lst@pengutronix.de
Subject: RE: [PATCH v2 1/3] dt-bindings: add binding for i.MX8MQ IOMUXC

Hi Linus,

quoted

-----Original Message-----
From: Linus Walleij [mailto:linus.walleij@linaro.org]
Sent: 2018年2月7日 17:09
To: Lucas Stach <l.stach@pengutronix.de>; A.s. Dong
[off-list ref]; dl-linux-imx [off-list ref]; Gary Bisson
[off-list ref]; Vladimir Zapolskiy
[off-list ref]; Sascha Hauer [off-list ref]
Cc: Rob Herring <robh@kernel.org>; Mark Rutland
[off-list ref]; linux-gpio@vger.kernel.org; open list:OPEN
FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
[off-list ref]; patchwork-lst@pengutronix.de
Subject: Re: [PATCH v2 1/3] dt-bindings: add binding for i.MX8MQ
IOMUXC

On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

I take it you guys are colleagues?

quoted

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.

I feel terribly sorry that did not come up in the first time these two days as I was
busy with some other urgent things requested by my boss.
It should be my responsibility as I promised to take that ownership before.

I quickly went through the email and I fully understand your concern.
As I'm not a specialist on the HW internals of IOMUX design, i already forwarded
the Issue to our IP owner.

Due to it's already off work time at my side, I will discuss with him tomorrow
Morning and get back to you later.

And i will carefully review the reference manual and doc on my hands.
Hopefully I can give you some information later you want.

Here is some information from our IP designer.
It probably explains why i.MX uses Ohm to represents driver strength.

"Electrical spec for different interfaces typically define output driver in Ohm.
So we follow the same way to comply with spec requirement. Also, for the
board designer it is important to know the driver impedance to match the
driver and PCB trace resistance. Defining the driver in Ohm allows to
calculate IR drop, as well as output slew rate, which are important to know."

An example from eMMC 5.1 spec:

Table 206 - I/O driver strength types
0x0		50Ω		x1
0x1		33Ω		x1.5
0x2		66Ω		x0.75
0x3		100Ω	x0.5
0x4		40Ω		x1.2

And for one question you asked in another email.
- Is the intended usage for impedance matching?
For low frequency interface, for example, I2C/GPIO, it’s not necessary. 
For high frequency interface, for example, DDR/HS200/HS400/Rawnand
differential 200M, in theory, we should consider impedance matching for
better signal quality. Anyway, we can check that by board level simulation
with spice model.

And IC guys thought Ohm probably is more suitable for high speed
IO pads.

Hope it helps.

Regards
Dong Aisheng

Regards
Dong Aisheng

quoted

quoted

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

quoted

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?

quoted

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.

quoted

quoted

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,*".

quoted

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 [off-list ref]
M:      Sascha Hauer [off-list ref]
R:      Fabio Estevam [off-list ref]

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

quoted

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

quoted

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.

quoted

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.

quoted

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

N�����r��y���b�X��ǧv�^�)޺{.n�+���z��z��z)���w*jg���
�����ݢj.�۰\��M��gj��a����' ��ޢ�
���j:+v���w�j�m��������zZ+�����ݢj"��!�i